EPISODE 1608

[INTRODUCTION]

[0:00:00] ANNOUNCER: Shopify is an e-commerce platform focused on enabling small businesses to sell online. The company was founded in 2006 and has since then become a core technology of online business infrastructure. 

Mike Shaver is a distinguished engineer at Shopify and previously worked at Facebook, Mozilla, Oracle, and others. At Shopify, he works on the core team, which handles storefronts, merchant experience and the commerce engine. 

He joins the show to talk about Shopify's bet on Rust, their shift to Google Cloud and the experience of changing from a management role to a high-level individual contributor role. 

This episode of Software Engineering Daily is hosted by Sean Falconer. Check the show notes for more information on Sean's work and where to find him.

[INTERVIEW]

[0:01:00] SF: Mike, welcome to the show.

[0:01:02] MS: Thank you. Great to be here.

[0:01:02] SF: Yeah. Thanks so much for being here. I wanted to start out with kind of digging a little bit into your current role and a little bit of your history. You're a distinguished engineer today at Shopify. And I believe this is your first IC role in a while. I was kind of curious to talk a little bit about that transition. Why move from IC? From management? And what are some of the differences and some of the things that you're looking for as an IC versus a manager? 

[0:01:28] MS: Yeah, for sure. I'd spent the previous 15 years of my career in various executive management roles. And that's actually what I applied for when I reached out to Shopify and I was looking for a role. Interviewed to be VP engineering and they came back and said, "Actually, we'd like you here as a distinguished engineer." Which I first thought meant I failed the management part of the interview. But they assured me that wasn't the case. 

And it took a little while actually for me to get comfortable with that, right? I mean, I've always been very technical for a manager. But for a manager is doing a lot of work there. And I think very highly of Shopify as a technical company. Am I going to be able to really pull my weight as one of the most senior technical ICs in the company? 

And then, what is that role, right? There aren't very many of us. There was only one other at the time. And I guess at some point I sort of decided this was Shopify's problem, right? They knew more about their needs than I did. And if I was willing to give it a try, then we would do it. I thought there was a good chance that I would end up back in management within the year that I'd – this wouldn't be the right role for me. But Shopify would have some management need and I'd switch over and be a VP somewhere. But it hasn't happened. 

And I think I've found a pretty great role for myself in providing technical leadership without having to do organizational management. I talk about it as being like a VP that they don't let anybody report to, which means I spend a lot more time on the business and technology problems than on performance reviews, and hiring, and headcount and so forth.

[0:02:41] SF: Yeah. I mean, I think when you've reached a level of like a distinguished engineer, it's not like you're not in a leadership position or even in a position where you're mentoring people. They might not necessarily report directly to you. There are still, I guess, aspects of managing from a coaching, mentoring perspective, but you don't necessarily have the direct responsibility of hiring, and performance reviews, and so forth. 

And to be honest, I've been a manager or basically like a sort of a player-coach IC manager for most of my career. And there are a lot of times where I think like my life would be a lot simpler and less stressful if I focus kind of purely on the IC part. Because there is personal challenges that come along with managing people. There are also a lot of high highs when you see people really succeed under someone you're hired or something like that. But it's different than being purely IC and sort of focusing on yourself and your own contributions.

[0:03:27] MS: Yeah. And one of the things that I really had to think of it was I've spent 15-plus years building up all of these leadership tools, and patterns and self-identity, right? Identify as someone who's an executive. And I can tell people I'm a vice president, and that's very fancy. How much of that was going to port over, right? How much was I really starting over? And how much would I be using those same leadership capabilities with a different focus or in a different way? And I've been very happy with how that's turned out. And I hope Shopify has as well.

[0:03:52] SF: Yeah. Given your background – and we can touch on some of the places that you worked in the past and some of the things that you've done. But you worked for a lot of great organizations. I'm sure, in many ways, there are a lot of opportunities available to you. Why Shopify? You mentioned that you reached out to them. What was kind of like piqued your interest of all the variety of companies and engineering roles that you could be seeking? 

[0:04:13] MS: Yeah. I have been very fortunate to be in a lot of right places at a lot of right times. And so, I'm a little bit greedy that way, right? I want to be somewhere that can have a real impact on the world. I used to say between Facebook mobile and Firefox, at any given time, a billion people are mad at me about their software. And I want to make that kind of in people's lives. 

When I was sort of narrowing down my career direction for what I think of as this arc, I had decided that I really wanted to do something in commerce. Because I hadn't done a lot in that space. And it felt like a really important aspect of software engineering and the internet that I just wanted to learn more about. 

And so, I sort of narrowed down to Stripe and Shopify and settled on Shopify in part because of this proposal that I would become a distinguished engineer. I mean, I wasn't totally sure that it was the right role for me and it felt weird. And people were asking, "Are you getting into demotion?" 

But that Shopify was so creative and thoughtful about getting the right people in the right role for themselves and for what Shopify's needs were. I thought that was really interesting. And it gave me sort of a peak into what being a leader at that company might be like. 

I've always thought very highly of Shopify as a technical company and as a product company, though I don't – I was not a merchant myself. And I'll admit, I like the idea of working for a Canadian company again. I don't know that we're as different as the prototype, super-apologetic Canadian goes. I work with a lot of non-apologetic Canadians day-to-day. But it felt nice to be sort of batting for the home team again that way too. And, yeah, it gives me an opportunity to have pretty broad impact on the world through a company that I believe in a lot.

[0:05:38] SF: Speaking on behalf of apologetic Canadians, I get that desire. I think that there's deep down inside my Canadian roots after living in United States now for 13 years or so, I would love or at some point crave the idea of sort of having that connection to a Canadian company and helping them succeed. 

I think in engineering we kind of are in a luxurious position where a lot of organizations support both very senior IC and very senior manager tracks. And that's not something that exists in all businesses. And I think that's really nice. Because you can be a fantastic engineer or whatever it is that you are really good at, but it doesn't necessarily mean that you're cut up for management. 

And there are people who could straddle both, but there are people who are great managers who maybe are not as strong on whatever the domain expertise is, but they're really, really good at like working and building teams and making them perform well. And I think that's one thing that's very nice and unique about working in technology and engineering, is a lot of companies are going to have these parallel tracks.

[0:06:36] MS: And that's actually something that we've rolled out at Shopify over the last year as well is those parallel tracks and other what we call disciplines, marketing, UX, data, sales, and so forth, legal. That there are IC tracks that now go up much higher. You don't have to move into management in order to broaden the reach and impact you can have. 

We've also done something that's interesting I think where we've tried to separate the scope people operate even within like an IC track. The scope people operate at from how good they are at that scope. Some people are going to be better in a more abstract architectural role than they are fretting every CPU instruction. And sometimes that's the opposite. 

And we didn't want people to feel that they had to move to a higher level of abstraction in order to progress their career or their comp. You can continue to be someone who focuses on a very specific piece of important technology and not ever worry about how all these things come together with the business strategy or the overall architecture of the whole system and continue to get growth in comp and growth in influence. 

And so, I think some of those practices coming out of engineering to the rest of tech and beyond that could be really valuable. Because as you say, being good at IC isn't a predictor of being good at management. And for a long time, that's how people found managers, when you took your best IC off the field.

[0:07:40] SF: Yeah and I think there was pressure for IC to feel like if I want to progress in my career, then I need to go this manager path even if it's not necessarily fit. 

[0:07:48] MS: You tell your parents at Thanksgiving, "Yeah, I'm a manager now." And they assume that that's a promotion, right? Where, really, it's a lateral move in a lot of ways. It's a change in job.

[0:07:56] SF: Mm-hmm. Absolutely. You mentioned that at Shopify now, even within the IC roles and engineering, you might have people who are – they're kind of leaning into where their strengths are. Maybe you're looking at more of the abstract level. Or you could be more hands-on keyboard, threading CPU instructions, and so forth. Where are you in terms of what you're focused on? What product areas do you focus on? And are you more hands-on keyboard? Or you're looking at this at an abstraction level? 

[0:08:21] MS: I'm the distinguished engineer for core, which is sort of everything you get with Shopify out of the box. For the merchant experience and storefronts, the commerce engine that's behind that. And it's more than I could actually sort of know all in detail. I've had to make some abstraction choices. But I really am responsible for how the whole of it comes together from a technical perspective. 

We have very strong and very technically apt product management. I don't have to swim upstream very often. But, yeah. My responsibility there is to make sure that the technical parts of core. How we're engineering it? What we're building for in the future? Where we're making tradeoffs are made well. 

Obviously, I can't make all those decisions. I don't want to. I feel like, as a leader, I'm doing a better job if I'm making fewer decisions, right? It means I've set the context correctly. People have a high level of autonomy and they can make decisions in that and they can do it confidently. 

And so a lot of what I do is work with teams less at the code artifact level, though sometimes. And more at the incipient design, right? This is the thing we think we need to build. And I say a lot, my job is to keep people from building things, right? Find a simpler way. Find a smaller thing we can start with. Find a way to reduce the complexity of interactions with the other parts of the system. And so, I feel like the less software we build, the better I'm doing my job. Though, obviously, we're still building software.

[0:09:26] SF: And then, are you also looking at sort of future investments or looking down the road at where you need to be as an either like from an engineering investment standpoint on the technology side six, 12 months down the road? 

[0:09:37] MS: Yeah. Absolutely. And I think sometimes even beyond that. As an example of this, Shopify has always been a very Ruby-centric organization. But there are some places where Ruby doesn't reach where we want in terms of some of the performance characteristics or memory management characteristics. And so, we needed a systems language. 

And I led the process for figuring out what did we want in a systems language? What do we want to reach for when we couldn't reach for Ruby? We settled on Rust. I think it's been a good choice for us. But that was really the beginning of our Rust journey and like what's required to roll that out? And is that the right community and ecosystem for us to be betting on? Do we need to hedge it in some way? Or do we want to dive all the way into it? And we decided we did. The same way we did with Ruby, right? We joined the foundation. We're funding some work. And we're starting to use it more internally. Some of those kinds of things. 

But, also, is it time to do an experiment on something? Or is it time to revisit a premise we had, "Hey, we can't do this thing at the edge. Well, maybe we can now." Right? Cloudflare and Google have rolled out a bunch of stuff. Maybe it's time to look at that again. Or, no. We know this thing. So we shouldn't go down that path on that kind of time horizon. But 12 months is a long time in tech, right? 12 months ago, only the researchers were talking about LLMs. And now my hairdresser asks about them. 

[0:10:42] SF: Yeah. My dad's asking. 

[0:10:44] MS: Yeah.

[0:10:44] SF: Yeah. I mean, the things – not to dip too much into gen AI. Because I think that could derail us for easily an hour. But the speed of development, speed of learning and execution, and launches is just insane right now. 

[0:10:56] MS: Yeah. Absolutely. I think it's a very – it feels early web to me, right? We're going to do a bunch of stuff we're going to look back in a couple years and say that was like pets.com, or Webvan, or whatever. But now we've got Webvan and we call it Uber Eats. Some of that stuff will come back. 

But we really are at a delightfully sort of juicy time for experimentation and trying new stuff. You see a lot of repetitive application of it, right? This is an LLM for dogs. This is an LLM for weather predictions. And it's good that that kind of stuff can be done. The technology is that rich. But I think we really haven't seen yet and figured out as an industry where are the places that this is really going to add value even given some hallucination or given some execution cost. And where are the places it just doesn't pay for itself? 

[0:11:37] SF: Yeah. I mean, we have to go through sort of the natural progression with any technology. You have the hype cycle. And then you have kind of like your despair or disillusionment. And then, finally, like the real work kind of starts. And we saw that. You likened to early web. I've made the same analogy. It feels like sort of internet late 90s, .com boom. And there was the pets.com and so forth. But there was also great ideas and companies that came out of that. And some of those ideas were just too early to actually create and realize that there wasn't enough people basically on the internet at the time to make some of those things work. But then, fast forward 10 years or so, some of those ideas come back and they're gigantic companies today. 

[0:12:14] MS: And scale enables a lot, right? We see this with computers. We can do these things so quickly now that we couldn't do 10 years ago that things can happen in real-time and be part of our daily lives that before were post-processed renderings and so forth. And I think we'll see the same thing with scale of people participating this and the domains that these things operate in. 

[0:12:31] SF: You mentioned you know this sort of investment in system language around Rust from the original investment of Ruby. And I'm assuming some of the like original decision-making around Ruby was probably had to do with the time and place of when Shopify started. And Ruby on Rails kind of really being in like the zeitgeist at that point. How is the decision to essentially invest, like make that choice to invest in Rust and then do all the things that you're doing around like joining that foundation and supporting it and stuff? How is that technical decision made versus going in a different direction?

[0:13:02] MS: Yeah. We didn't open an RFP process for systems languages internally. And we had people that were using Go in the Kubernetes space. And we had people using Java in the data space with the various pipeline tools that were there. And that was sort of what I observed that like we were investing in systems language, but we weren't doing it in a Shopify way, which is really to pick a stack and invest deeply in it and get the most out of it that we can, right? 

We're not a million microservices. Everybody in their own flavor company. We're a monolith company. We're going to make this shared investment. And so, that process, a lot of was Toby drives a lot of technical exploration. He's a very curious and quick technologist. 

Stuff shows up on his radar. It's like, "Hey, there's this zig thing that's sort of – it's kind of like C, but it's not. It might be a better place for us to be than extending Ruby in C." We talked about how Go has a lot of traction in a lot of places. And we looked about Rust. And you could do something like Haskel or similar. But I think we pushed those away a little bit earlier. We're more of a vocational organization than a research one. And so, we wanted stuff that was a little more approachable. 

But then it was a matter of like, "Hey, what problems do we have or anticipate? And how would we prefer to solve them?" Right? And one of the things, we looked at Go and said, "Hey, it's got a bunch of these tools. But it's really hard to extend Ruby with that." There's no good way to call between them. You got multiple GC's that have to interact. Go has some challenges around data races at scale. And there are some patterns there that are harder to be sure about. And we really want that safety in our systems language. 

We kind of just – myself and a bunch of other people that are in sort of Toby's immediate technical orbit vetted it around for several months until we decided we needed to make it decision. And then I sort of drove those, "Okay. Which of these is better here? Which of these is better there?" Model it out. In a few years, where will we be? Where do we want to make an investment in this? 

And that's similar – I mean, I wasn't here for the transition to Google Cloud. But before that, Shopify was a data center swapping hard drives, sort of running power kind of company. Decided the cloud was ready for Shopify and it was time to move on to that. And we invest very deeply in our relationship with Google. And we build very closely on that platform. We use Vertex. We use BigTable. Those kinds of things. Because we don't want to hedge our stack. We don't want to say, "Oh, we should do this thing in the most abstract way. Because we might change to something else later." 

We do abstract this stuff over the network. Because we might use a different programming language. This is our stack. We accept it will be expensive to change. But let's get the most out of it that we can. 

[0:15:13] SF: There's all the sort of technical decision-makings that you're making around like a choice like Rust. But are you also looking at what's it look like from like a potential hiring standpoint as well? What kind of talent out there exists that we might be able to bring into the organization if we make sort of this investment in this particular technology? Or is that not a factor? 

[0:15:32] MS: It's not a huge factor for us. I think there are certainly cases where we hire for specific expertise. It tends to not be stack expertise. We have another distinguished engineer, Mike Tamir, who works on the AI side in the data space. And I don't even know what stack he used before. But that's not what we hired for. And some of that comes from fast engineering growth in a world where not a lot of people were getting taught Ruby at school. Hiring people who had Ruby experience was just an unacceptable filter on the scale that Shopify wanted to grow its engineering force. 

And so, the expectation is we're going to hire people who know how to program and who aren't emotionally or identity-wise locked to a specific stack. And we'll teach them the typing. We'll teach them the syntax. But, fundamentally, it's about ability to design systems and do we want to – are you somebody we want to trust with an important technical decision? Do we want to have you in the room when we're trying to make a hard call or debug a system that's not behaving? And that's more what it's been about. Rather than about specific technical items. 

We do invest deeply in those stacks. We do have people who are expert in that. We have a Ruby and Rails infrastructure team. And we build a YJIT for Ruby. And those are people who are very deep in those stacks. And we definitely would hire people into those roles who that's not going to be your first experience with Ruby. 

But some of the Jit staff even, they came from Jit backgrounds and compiler backgrounds, but not Ruby ones. And be able to say, "Hey, bring that expertise into our stack world." And that's more important to us than whether they can save a month reading a Ruby book at the start.

[0:16:50] SF: Right. Yeah. And then in terms of where you're at today – you mentioned that you're not a million microservices. It's a monolith. You move from essentially running your own data centers to Google Cloud. Is everything running on Google Cloud today? Or are you running hybrid cloud in some fashion? 

[0:17:06] MS: Pretty much everything's on Google Cloud. I would say Google Cloud and on Cloudflare, we're increasingly using their edge computing capabilities as well. The performance of commerce is super important. And so, everywhere we can shave off latency by using a system like that is valuable to us. 

But, yeah, we're all in on Google Cloud. We watch stuff like everybody else does. What other Cloud vendors are doing. What we're seeing in hybrid computing spaces. Interesting stuff like oxide. Sort of bringing back the rack with modern cloud manageability to it. And those are all interesting things. 

And we investigate them and sort of have an idea of when they might be worth looking at. But none of our engineers are hedging against, "Oh, is this going to have to run on-prem as well? Or do I have to do this in a way that it can work on AWS?" We want them focused on getting the most out of that stack they can. 

And we just accept that some of those changes are going to be expensive. But we'd rather pay that when we're sure we want to make a change and pay that in little tiny bits through all of our software development. Hedging that decision.

[0:17:59] SF: I know you weren't at Shopify during that transition to Google Cloud. But can you comment at all about what was that transition like? Was it essentially – how did they move? How long? And what's sort of the infrastructure look like today? 

[0:18:12] MS: I don't know off-hand a lot of details about sort of the specific role out of it. I mean, I know one of the factors was that Kubernetes had sort of been settled on as being our management, Shopify's management layer for its own computing resources. And Google's support for Kubernetes natively was a big part of that. That made an easier migration I think that we were already running some of these orchestrated systems in a way that we could move a bit to the cloud. 

Now the infra team is wincing as they hear that. Like it's not just – you don't just change the URL in your deployment manifest and it shows up on the cloud. But I think that made it easier from a software architecture perspective. And I think, also, having the monolith, right? You can port that base layer and you don't have to worry about porting the long tail of services that made some assumption about the fact that they're in the same rack, or that they can get a MAC address, or whatever those other pieces are. 

Being that sort of one centralized component already on that orchestration layer I think was something that helped. But none of those kinds of transitions are easy. And those teams had to work for quite – I think that started – sort of announced in 2018. I'm sure the work started well before that. I'm not sure when we shut our last data center rack off. But these days, it's all cloud.

[0:19:17] SF: We've talked a lot about like Shopify as an engineering organization, as a technical company. And that was one of the things that, if I understand correctly, that attracted you to moving to Shopify. But I think for people who maybe are not super familiar with Shopify and you kind of glance at it or don't know a ton about it, it's easy to maybe dismiss it as simply like, "Oh, this is this e-commerce site where SMBs can build –"

[0:19:38] MS: [inaudible 0:19:38] CRED app. How hard can it be? 

[0:19:39] SF: Yeah. Exactly. But in reality, I think that's a little bit like dismissing Amazon is like an online bookstore or something like that where this giant organization today that's running most of the web. Part of this, my understanding is Shopify is really transformed into like a global platform where a lot of engineering actually happens by third parties building applications. Releasing those marketplace. Building businesses essentially on top of Shopify's infrastructure and this platform that you built. Can you talk a little bit about the thoughts, your thoughts on the transition to actually becoming a platform company and kind of what that means? 

[0:20:15] MS: That's always an exciting thing for me. I've worked on a lot of platforms in the past and I love seeing what people are able to enable on top of my work. That certainly had a strong affinity for me. 

The thing about Shopify is that we have an ambition to make commerce great for everyone. And we have that ambition, but we also have a piece of humility with it, which is to say we don't know what everybody needs in all of their commerce. We know an awful lot about commerce. And I think we're moving the industry forward in a lot of valuable ways. And innovating even in areas like checkout, which sort of been settled before. You put your credit card in. You press the button. You get the thing. How hard can it be? 

But there's a huge amount of commerce thinking that happens outside of any given company no matter how robust our platform is. And so, there's a real investment in making those kinds of commerce experiences possible even if they're not things that make sense for us to build for the 80% of our merchants or the 80% of our stores. 

And that ranges from things like APIs. Everybody's got a web API for assembling a card or changing the configuration of your store. And so, people can build tools that – you can build a tool that's especially for flower shops, right? And we're not going to build a flower shop specialization. But somebody can do that and provide some things that are customized for it. 

We also rolled out starting I guess last year what we call the Commerce Component Set, CCS, which is about companies that don't – they've got a much larger e-commerce environment. They want to integrate some of our capabilities but not move on to having us host their web presence. We have hydrogen and oxygen for building headless commerce and then the ability to plug in different parts of Shopify, checkout, order routing, and so forth into that. 

I mean, I think about when I was working on Firefox, I was responsible for that very early extension ecosystem. And in a lot of ways, it was just about having more people thinking about the browser. And in this case, thinking about commerce, right? There are people out there who think about commerce and are never going to build something like Shopify. But they have an idea that they can build now because we give them a big head start that just wouldn't have been viable or possible before. 

And I think that like too small for us to care about as a product specialization is still like enough entrepreneurship for someone to quit their job. And that's, you know, someone can take their lives, take more control over that by being their own boss and pursuing that passion. And they're always going to be more brains outside than inside Shopify. 

A lot of what we do is figure out what parts of commerce need to be a certain way in order for us to make the guarantees we want to make around conversion and the integrity of the commerce process and buyer-merchant experience. And then the rest is like show us what's possible out there. 

And we've got those web APIs. But we've also built things that are much closer to the center. We have a system called functions, which is really running a developers' code in our cloud environment on those servers. So they can make a different commerce decision that we might. And we don't have to anticipate all of them. That's been really well-received. We see people building all kinds of great stuff on it that we don't have. 

An example there, I guess, loyalty and membership programs. There's no Shopify primitive for that. There's just the capability to layer things into your buyer data, your set of product. How it behaves it checkout? Discounts and so forth. That whole commerce capability we made possible. And then we didn't really have to build a version of it ourselves, right? There's an ecosystem that provides that. 

[0:23:11] SF: Mm-hmm. With the functions that you just mentioned, that's basically someone can essentially develop a function. And they're moving compute to actually run on the Shopify infrastructure and then I'm assuming be able to manipulate data there that they have access to through the – shopper that's – or, sorry. The merchant that's actually enabled it. 

Can you take me through sort of how behind-the-scenes some of that stuff works? Or even from essentially the developer standpoint. How they supported with building that function and then how does actually the deployment work to get that running within Shopify? 

[0:23:40] MS: Yeah. And I think if you imagine sort of the world we were in before functions, we had a set of APIs you could call. And people built great apps on top of that. But there was always a limit to like what those extension points could be. Because they were running on someone else's server, and they were over the network and they had to scale in a certain way at Black Friday, Cyber Monday, our infrastructure is ready for it. But not everybody in the world is. 

And so, there was a real question, like we can help them make different commerce decisions in a bunch of spots. But what if we could bring them into where we're making some of these core commerce decisions about discounting, or order routing, or how we're going to combine items into bundles? We can't make a network call-out on every price calculation. I mean, it's just not feasible. And everybody else having to build that infrastructure doesn't make sense. 

We say, "Hey, there's a really small spot here where we can say what would you do here?" And they don't actually directly manipulate the data. These pure functions so that we can scale them properly, and we can run them in parallel, and we can cash them and all the stuff we need to do there. But they basically give us advice. 

We say, "Hey, given this cart, what discounts would you apply?" And then we can go and see if that – maybe more than one app is running and giving us different ideas and we have to decide between them or similar. They provide a web assembly bundle. We use GraphQL for the developer to say what data they need to operate on. And we document those APIS as saying, "Oh, you're going to get called with this data. It'll be in a JSON format. So do what you got to do." 

And then when you spit out your discount recommendations, or your order routing choices, or similar, this is the format that it's in. It's sort of like building a web API. JSON comes in. JSON comes out. We want to reuse the developer brain print of GraphQL to pull in that full breadth of API. But you can use any WebAssembly language for it. 

We have good sort of native support for Rust and JavaScript. But we've seen people build them in Zig, and C and similar because of the portability that WebAssembly provides there. And the safety. We can run this code with a pretty high degree of confidence that there's a limit on what it can do and that it's safe to run in the context of something that's really close to the center of commerce. 

[0:25:30] SF: Mm-hmm. Yeah. And you mentioned one of the values there as a developer is that you can essentially leverage the scalability of Shopify without having to sort of like host and manage that infrastructure yourself and scale up for Black Friday or something like that if whatever you're doing is really taking off. 

I would also think that there's an advantage from a security perspective as well. Because I'm guessing, but I'm sure Shopify has put significant investment into making their systems very secure. And by running essentially that code within the compute environment on Shopify, you're taking advantage or you're getting sort of some of those security features out of the box versus having to kind of build infrastructure that locks that thing down yourself.

[0:26:06] MS: Yeah. And commerce data is very sensitive. And especially when you're dealing with multiple geographies and we want to make it easy for people to do global commerce. Having to think about all of that stuff, right? We have teams that think about it all the time. And they're very expert in it. And they think about it very deeply. We don't want every developer to have to do that and we don't want every merchant to have to wonder about it. 

I think there's going to definitely continue to be a place for hosted apps that run in other services and integrate into them in different ways. I don't mean to say that that's like a scary or inferior way to do it. But, certainly, some of the questions you have to ask yourself as you build those go away when you can just take advantage of Shopify's internal infrastructure and know that you're running in a commerce-safe environment and all of the PII, and payment instrument handling and so forth is all taken care of.

[0:26:44] SF: Yeah. Absolutely. And then you can kind of focus on creating a great experience that you scale and hopefully do really well with. In terms of deciding around making investment in expanding the API or maybe enabling some feature that developers can build upon to create their own experiences, to do something that's net new that maybe Shopify is not doing today versus making that a core feature within Shopify. How do you kind of think through those decisions? Yes, we should enable our community to leverage this. Versus, no, this should be part of the core Shopify experience. And we want to own this end-to-end.

[0:27:17] MS: Increasingly, those decisions about product extension and additional core commerce features come with sort of an extensibility side card to them, right? If we want to build this feature this way, how else might people want to build that feature? 

And being able to use things like functions and metafields as well as our existing you know API extensibility really lets us focus on like what do we think is there for the 80% case? Or what's the basis we need to build? And then what kinds of things are we sort of sanity-checking or scope-checking those extensibility points to say, "How could you do this? How could you do that?" 

And we'll talk to developers in our ecosystem or we'll look at it from the perspective of things Merchants have asked for, "Hey, I want to do bundles." Everybody wants to do bundles differently. Okay. What do we provide out of the box that lets you do some simple bundling? And what surfaces do we provide where someone can do much more complex or much more vertical-specific bundle implementations along the way? 

If you come to our head of core product, Glenn, with a new merchant-facing feature idea, you'd better come with a story for how other people are going to be able to replace or extend it. And we try to use those same technologies internally, right? We'll Implement a feature as a default function implementation so that we know the APIs are rich enough for what we want to do and we know we've got the performance in the right spot.

[0:28:27] SF: Mm-hmm. Okay. That makes sense. We touched on it a couple times, your close working relationship with Google as a partner. And that's actually where my prior history where – and I worked at Google. I also worked with Shopify. So I can kind of speak to it from the other side. And we had a very nice relationship at that time. 

And one of the things that I did while I was there was I built one of the original Shopify prototypes for a product I was working on called Google Business Messages. And it was essentially a proof of concept to show how these two products could kind of live in the same world. 

And one of the key takeaways from that experience that I still like often reference to people I talk to is how good Shopify CLI is. And it blew away anything we had built on my team at the time. I was super impressed and very jealous. And I think people who haven't perhaps built CLIs or worked with many, they might not realize how difficult it is to make a really great CLI with a super seamless, incredible developer experience that you're running maybe on your local host and that you're able to like seamlessly transition that into production. 

First of all, why are this kind of developer experience investments so important to a company that's been primarily known as like this e-commerce platform? And why does it make sense strategically? And then, also, what are your thoughts on sort of the technical challenges of actually creating a great experience like that? 

[0:29:45] MS: I think our CLI is an unsung hero for us in the development ecosystem. Because it provides such an encouraging and fluid experience for a developer both as they start using it. Putting all the right templates in the right spot. Filling stuff in. Giving you good errors. But also, when you're shipping your 15th version of this and you're rolling these things out, and you can be confident that the update's going to go correctly. 

CLI is really hard. Because developers are very picky. And they're picky because they really want to build great stuff and they have a way to do that. And so, when you're building a tool like a CLI, you sort of have to decide if you're going to be the outside or you're going to be the inside. And we're going to say this is what a Shopify development experience looks like. And you should adapt to it. Or we're going to say, "Hey, whatever your experience is, this is where you plug in the Shopify part of it." 

And I think we've done a pretty good job of balancing. You can use us in either way. I think for people who are new to extensibility, we're sort of the outside component and the CLI drives them as they build their templates and their samples, and get all their keys in the right spot and define all their schemas. But it's also really important that it's there and reliable for people who have an existing app and are bringing it in to use some new technology like functions or checkout extensibility. And that the CLI is helping them get their job done. And I think a part of that is increasing their confidence that when they deploy this it's going to work the same way. 

As an example there, in our CLI for functions, we give you a way to run it locally on the same kind of inputs that you would get remotely. And you can find out whether you're going to take too long and be timed out. Or if you're going to give the back stuff in the right format. 

We really want people, when they push it, to be able to – they can't attach a debugger to our infrastructure. That's not a thing we're ever going to let them do. But from their perspective, they can get to high confidence. But I think part of it also is like we're a very engineering-centric company. 

The quality of the CLI there I think is a point of pride not just for the people who are working on it, but the teams who are building the pieces that interact with it. There are a lot of conversations, "Hey, if we add this API or we add this kind of packaging, what's the CLI experience going to be like?" It's not just sort of added in on the end. And we start from that developer experience. 

because making something possible but still too hard or awkward is not really any better than not making it possible. We're not going to see that growth of creativity that we would otherwise. And, yeah, we look at other CLIS and what we can borrow from them. But we think very seriously about that as the primary – that and our Dev docs are how people experience development for Shopify. 

And so, we really want to make sure that that's a great experience and that it's a good tool for bringing them along with us as we add new capabilities or we deprecate them. That it can help them with that journey. 

[0:32:02] SF: And in terms of the APIs, what do you think is hard about creating a great API from an engineering standpoint? 

[0:32:10] MS: The hardest thing is that an API is a promise. I mean, we version our APIs and we can change them. But we don't have a lot of respect for our own sunk cost. 
If we've built the wrong thing, we'll throw it out and build the right thing. But we have a lot of respect for the sunk cost of our merchants and our app developers in the ecosystem, right? We want to make sure that the thing they did, the added value to the Shopify ecosystem that helped Merchants. They're not punished for that with stuff breaking all the time and similar. 

Part of it is that it's a future promise. And it's a promise not just that it'll work, but that it has certain performance characteristics. And it happens in a certain order. People build these dependencies on the finest of the implementation details, which we discovered with the web, for sure. Even things that weren't specified. If that's how Netscape did it, then that was how everybody had to do it. Because stuff-built dependencies on it. 

Keeping in mind not just the explicit part of the API. But what are you implying that people might build dependencies on? And how do you preserve that? But also, commerce is just a really big and complex space. There are a lot of moving parts. And it can be hard to know which piece to grab first, right? 

You've got locations, and products, and variants, and orders, and drafts. And how do those all fit together? And so, I think a big challenge for us is making sure that the APIs represent not how our systems work, but what the semantics of commerce are that we want people to be able to operate on. And I think that's where you'll see our APIs head towards more in the future is more holistic. Get your hands around all of the experience you want. Making sure that is as good as the narrower experiences we provided around specific data manipulations or events. 

[0:33:34] SF: Mm-hmm. How does some of the stuff like in terms of the sort of, I guess, the heart or the root of Shopify being a Commerce experience perhaps change or even define the company's engineering culture in comparison to maybe prior experiences that you've had with like places like Mozilla and Facebook? How does that culture as an engineering organization feel different? Or maybe it doesn't feel different. Maybe it's just we're doing engineering. We're focusing on tech. 

But I would think that the fact that you're focused on this commerce space where it's a two-sided marketplace. You have a lot of different stakeholders and stuff that it kind of informs a lot of the way that you build an engineering and product organization. 

[0:34:15] MS: I think so. I think a big part of it though, in order for an organization like Shopify to be able to scale and provide the stuff we want, is we need to do a lot of work in mapping those commerce problems to engineering problems. And letting them just be solved as engineering problems within the commerce context. But not have to think about all the complexities of commerce, and PCI certification, and data residency and how taxes are – there like 17,000 tax jurisdictions in the United States, which was terrifying for me to learn. But in hindsight, not that surprising. 

But people don't have to think about those things all the time. Building those internal APIs and architectures, not microservice style, but within our code base, is really important so that people can focus on the thing they care about. 

It's sort of interesting and that like the ultimate destination for commerce is checkout, right? I mean, there's stuff that happens post-sales on that around shipping, and around returns, and so forth. But, ultimately, all the people in the ecosystem are really focused on what's the journey to getting to somebody having something they didn't have before. The merchant having the transaction. Everybody being better off for it, right? 

And so, there's that balance of, when I do this, how's it going to affect the merchant experience? How's it going to affect the buyer experience? How's it going to affect our operational ability, right? Is this going to be more fragile or harder to scale when we hit the Super Bowl of commerce at Black Friday?

And I think we've done a good job of building a system that's resilient around that that lets people sort of decompose these things and treat them as engineering problems. But I was in a design review just before we started this taping about functions. And we're talking about how to change some scaling factors and what we want the API to do there. But the real common question is like what do people want to do with commerce? And how are we going to make it possible? 

I have a lot of commerce conversations with engineers. And I think that that's actually really important for keeping us connected to what we're building. It's very easy as an engineer to fall behind, sort of hide behind those abstractions. It's like, "Oh, my component returns the right HTTP response here." It's like, "Yeah. But it does it in this way that interferes with us being able to build great commerce." And that's just not something that people are willing to do here, right? We know we need to fit into that. 

But, also, a lot of people's livelihoods depend on Shopify, right? We are very proud that a lot of people have been able to quit the job they didn't like and run their shop as a way to support themselves and their families. And so, we take that responsibility really seriously. And it's not just are we going to be up and available. It's are we making changes to the merchant experience that's going to be good for someone who's new to commerce? Is it going to be for someone who's doing this one hour a night on the side of their job because it hasn't scaled quite yet? Or maybe this is their whole job and they spend all day in the admin API. What's that experience for a major merchandiser like? 

And those are things that they have design and product implications. But we also think about them from the engineering perspective. How can we design a system that can make this part faster that can surface the right information in these spots? 

And I think it's helpful that we have a very technical product management staff. And we argue about APIs, and storage formats, and how this is going to fit into other development ecosystems and so forth a lot. And sometimes I wish just let me make the call and the engineer. Damn it. But, really, we end up to much better spots because we're thinking about that whole spectrum of experience. 

[0:37:11] SF: How do you keep the engineering organization sort of close to commerce and having like empathy for – at the end of the day, this could be someone who's starting a small business on a side and hoping to turn this into the livelihood. How do you bridge that gap? Especially as an organization gets larger, it's easier to kind of have distance between, I think, the engineering organizations that's actually building a lot of these core experiences, or APIs and so forth versus the people who are ultimately using it. 

[0:37:37] MS: Yeah. I mean, I think the first part is just to value it through our actions and not just – obviously, we would say, we value you understanding the customer, right? Nobody says we really prefer you wouldn't think about your customer. But, also, like there are a lot of people at Shopify and engineering and outside that run their own stores. Some of them have like bought stores from other people that they didn't want to run anymore. It's like, "I'll take that over and run it." 

We get some empathy out of it that way. But it's also very structurally inserted into sort of what happens as you join Shopify, right? You create a store and do these customizations. But you also listen to support calls and say, "How would I answer that?" Or, "What does this tell us about the product?" And we have a feedback we call merchant complaints coming from the support organization through. And we get a sense of like, "Hey, the product isn't quite doing its job here." Or there's a need we hadn't seen or there's too much friction in this part. And those elements make it all the way through to the engineer, right? They don't just hear this API needs to be fast. We also need to return the location ID. The reason for that is always clear and what its impact is on commerce. And I think that's a big part of it. 

I was a little worried actually because I've – some of the best software experiences I've had have been cases where the developers and product managers live in the product, right? We all used Firefox. At Facebook, the whole company was run on Facebook. 

You had a real – I mean, we were expert users, which is only one set of users. But we had a real empathy for it. And if you broke the product or made it feel just a little weird, we knew. And we don't live in Shopify here, right? Naturally. Right? That's not where we put our diffs. It's not where we do our product planning. 

We do try and use it in interesting ways. We have an additions event every six months where we talk about new elements in the Shopify platform. And that site is actually a store. And we use Metafields to drive the content. But it's a Shopify shop. How flexible can commerce be? And we were able to test that out. 

But we have a lot of merchants that come through to our in-house town halls and talk about their experiences. And it's inspiring, but it's also humbling that we're building this stuff and it's like abstract lines of code. But for this person, it's like, "Did they make enough sales that they can quit their job, or they can pay rent, or they can grow in this way?" Right. And are people able to find the stuff they want in these stores in the first place? 

[0:39:32] SF: Yeah. That makes a ton of sense. I mean, I think that you raised a good point around it could be difficult. Or you just need to be sort of more intentional about it when you have a product and engineering organization that's maybe not working day-to-day in the actual product to make sure that they're understanding who actually is using it and the impact that it has on their lives. 

If you look at a company like Twilio, I think they made some good decisions early on in terms of everybody has to answer like 50 support tickets or something like that when they first start. And they have to build something regardless of what functional area you are or the level that you're in on the APIs in like their first week. And they have like shoes of their customers. And so, you get a feeling for walking in their shoes. 

There are things you can intentionally do I think as leaders with an organization and kind of set yourself up for success. So that as you scale, these things are still there and people still feel connected to the end user.

[0:40:18] MS: I think that's true. I think, also, like it goes back even to before the hiring decision, right? The types of interviews we do. And if you're applying at Shopify, you get a document that talks about like why Shopify exists and the trade-offs we make. And we expect you to care about commerce if you're here. 

There are lots of places you can do great technology work, right? And we're very privileged as engineers to have a really broad choice of work that way. But if you're going to be a Shopify, you got to care about commerce at some level, right? If not, it's just not the right place for you. And we're happy to not have that be a job you take. But if you're going to be here, that's got to be a part of it. And that's something we look for in our interviews, but also make really explicit. Like, you're going to have a hard time here if you ultimately don't care about the commerce outcomes that you make possible.

[0:40:57] SF: Yeah. Absolutely. We touched on this a little bit earlier when we kind of dipped our toes in the world of gen AI. But, essentially, the speed of learning and go to market right now. And I think in many ways, it's a wonderful time to be in engineering. 

When you and I started our careers, there was a lot of stuff that just didn't simply exist back then. Like CI/CD might have been someone literally copying files from like one server to another and dropping them in. And there was no public cloud or infrastructure as of service platform or service products where you simply push the Git and have a reasonably scalable system immediately and you can fully focus on the product or something like that. 

Given all the tools we have at our disposal today and the speed teams are now operating at in comparison to 15, 20 years ago, what do you think are the big pressing challenges for engineering teams today? 

[0:41:46] MS: I mean, I think one of the biggest ones is what we talked about earlier, which is like remembering what that outcome is that you want to make possible. And so, maybe you're building something that targets developers and you got to think about what developers and what you're not going to do, right? There's so much possibility what you could build. Am I going to build an LLM to do this? Am I going to do some big data thing? Am I going to make it crowdsourced through a mobile app? 

Choosing what not to do and what parts of the problem to ignore and what you're going to be – that's a hard thing in an environment where there's so much attractive technology. So many different things you could do with it. And that's one thing I love about engineering is if I think about it right and I explain it to a computer right, I can make something real in the world, right? 

I'm not an artist. I can't paint. I would be a terrible carpenter. But if I think about it right and I tell the computer about it, I can do this. And so, keeping that narrowing of, "Okay. But what are the things that are important to me? What are the things where I'm going to care that it's differentially better?" Not just because it's fun. I mean, playing it with computers is fun too. But how is doing this going to make a better outcome for the customer I have? The user that I have? Or for myself if I'm building it. But thinking more about those outcomes rather than how much fun it is. It really is a lot of fun to play with a lot of these technologies and build the LLM for weather reports or whatever. It's like is that actually going to improve how people decide whether they take an umbrella? 

Well, if not, maybe I should just go back sto scraping the NRCan stuff. And it's a great problem to have that we have more solutions than we have problems in some ways. And we have to kind of pick between them. But I think it is a real risk for technology organizations to get captured by the act of engineering rather than captured by the act of producing value for the customer.

[0:43:14] SF: Mm-hmm. Yeah. I mean, I think we can get a little bit of like a shiny penny syndrome where we're essentially want to grasp onto these different things. And engineers like to build. Generally, they like new technology. But I think one of the things that you said earlier on in terms of your responsibilities is sometimes telling people – or like figuring out a way to do something where it doesn't require a whole bunch of engineering. How do you simplify this? How do you distill this down into a simpler course of actions? 

And I certainly see that now. I think both in the data and AI space, we can kind of getting really in love with these like modern complex data stacks where we have tons of different tooling. But it's quite possible that your problem could be solved with very, very minimal amount of code in an Excel spreadsheet depending on what you're trying to do. 

Or in the world of AI, sometimes a simpler, less complicated – you don't always need to jump to deep learning and neural networks. You might be able to solve this with something much, much simpler to implement that's also easier to scale and easier to sort of manage from an infrastructure standpoint. 

And I also think that this comes with a certain level of seniority and experience working in engineering. A lot of it comes down to you have that breadth and depth of experience to be able to take a step back and realize maybe we don't need to do all this stuff. We can simplify. 

What are some of your thoughts around or recommendations for, I guess, making those kinds of decisions or realizing when we shouldn't over-complicate this and kind of start simple? 

[0:44:37] SF: Yeah. And I say sometimes, my job is to keep people from building things, right? That the software we didn't build is the easiest stuff to maintain and scale. 

I think part of it is understanding really where the value and what you're building is going to come from, right? It's very easy to imagine many moves in the future of how this system could evolve. And what if I need to scale it like this? Or what if I want to use a different programming language? And I've certainly been in environments where breadth of applicability and option value were the most important things. 

But for most environments, you really need to be thinking about what's the smallest thing that will get me to the point that I can make a better decision? And are the things that I'm worried about things that map to improved value? Spending two months deciding whether I'm going to deploy on AWS, or Google Cloud, or Azure for my little toy MVP app, that is not time well spent, right? 

For Shopify to spend months thinking about where we're going to host our cloud, that's time well spent. But for most places, it's not. And just like anything will do. And there are a lot of engineering problems that are satisficing problems. Where once you're good enough, being better doesn't matter, right? 

Showering three times a day doesn't make you smell any better. But like falling off to once a week, people are going to notice. And I think it's easy to look at that and say like, "Oh, I could make this even faster." Or I could use this thing that's more highly optimized. Or use this Rust crate and write around it instead of this loop in the browser. It's like, "Yeah. But does that performance actually improve the outcome that you're aiming for?" And do you have to make this decision now is the other sort of question. 

The fewer choices we have to make now, the better. Because, later on, we're going to have more information. And making those decisions in a way that optimize the future information we get is really powerful. What's the thing we could do here? Not necessarily because it's the best thing to do, but that will teach us most about the problem. 

And people do that with experimentation frameworks and we do it a lot internally with prototypes. We're going to try these three things and then we'll know more about what the problem space actually looks like. Or we'll work with a partner to try something out and see, "Oh, no. Actually, we can't build that in a way that's like Shopify-grade right now." It's not the right thing. 

But trying to narrow those pieces down so you can have that confidence that what you're building really matters. And that the incremental brain glucose you're spending on making the problem solved better actually pays off. And those problems do exist, right? For Shopify, a faster checkout is always more valuable, right? And so anything we can do to make that faster is valuable. 

But for a lot of other stuff we do, it's like if it's good enough, right? Whether that email goes out to somebody in one second or three-quarters of a second, that doesn't really affect the commerce outcome, or the merchant or the buyer. That's not a place for us to spend our energy. Even if we could find this super-tuned, hand-assembly email service, that's not a place where we should be taking the complexity or the work.

[0:47:02] SF: I want to transition to talk a little bit about something that I think is very important for engineering, but maybe less technical in nature. I know that an area that you're particularly passionate about outside of purely writing code is mental health and equality in the workplace. First of all, when did this become something important to you? 

[0:47:21] MS: I'd like to say I always cared about it a lot. Because it is a very important part of people's lives. But some of it is just selfish. I have mental health conditions of my own. ADHD and bipolar disorder. And I've worked to manage them. And I like to say I think I'm getting better at managing them all the time. But they still do interfere. And they're sort of an asterisk on everything I do, right? A day doesn't go by that I don't think about some aspect of my mental health. To check myself or make sure I'm doing things that are going to keep me healthy. 

And we do that in a lot of areas of health. People talk about optimizing their diet or going to the gym. And we don't talk that way about mental health a lot. There's a lot of historical stigma there. And I think, for a lot of people, it isn't n safe to talk about mental health conditions in the workplace, right? It will affect the arc of their career. It will affect their relationships with their family and their friends. 

I'm fortunate enough that I'm well-established. I've got a job I love. I've got a family situation that I love. I'm very privileged that way. And so, I feel like I can maybe take some of the stigma out of that. That I can show people that it's possible to be successful managing these conditions and jump-start some of those conversations. 

I do that where I can. I'm not a therapist. People come to me for advice. I'm like my advice is go talk to a therapist. But I can provide empathy and I can help people understand those perspectives a little better. When I get a chance to do that, I always do.

[0:48:29] SF: Yeah. That makes a lot of sense. My father was a psychologist. He's retired now. And he used to always say that, for some reason, there's a stigma around like treating the brain that wasn't when it comes to treating some other organ in your body. Or even treating like yourself physically. 

And I think that we're starting to get to a place where that's less of an issue. And I think a lot of that has to do with people like yourself and others that are like stepping out and making people understand that, "Hey, this is something that can affect anyone." Even if it looks like I'm sort of super successful, it doesn't mean that I'm immune to these potential problems. 

[0:49:02] MS: Yeah. 

[0:49:02] SF: I think there was a lot of challenges I think in particular during the pandemic. Isolation, disconnected from co-workers. I know I have friends, family that struggled with these different things. How do you go about managing your own mental health? You mentioned that you figured out ways of dealing with that. But you've been in a lot of high-pressure roles. How do you kind of personally manage your stress? 

[0:49:23] MS: Yeah. I mean, part of it is that sort awareness, right? That I know it's – the brain is different from the foot and that we're always using our brain, right? And it's your judgment organ. Telling whether you're sick or not. I can tell if my foot hurts. But do I really trust my brain that might be the thing that's sick to tell me whether it's sick? 

I developed some things I keep an eye out for. And how long does it take me to get sort of booted up and into work in the morning? And how long do I put stuff off? Or are there conversations that I'm avoiding? And watch for those kinds of things. But, also, make those investments in myself, right? Hey, I need to take a break. Or this week, I'm kind of depressed. So I'm going to change the kind of work that I do. Or I'm going to tell people, "Hey, I'm going to be a little slower to respond on this." And do that self-advocacy to make space for it. 

At Shopify, we have good benefits and all of that stuff. But also, some really supportive internal communities around ADHD and mental health where some of that's just like, "Oh, my God. My meds aren't working today." Or I'm changing meds. And that always sucks. But some of it's we remind each other every month to file our expenses. Because that's an easy thing to forget when you have ADHD. 

And so, being able to have those conversations and there being a safe place for it, right? I posted recently on our internal workplace, Facebook for businesses, about some challenges I'd had and sort of what I was doing to recover from them. And there were a lot of people that posted about their own experiences and so forth. Some of them very senior. And to say like, "Hey, I've been in this spot. That's not the end of you at Shopify to have a period where you weren't at your best." 

And I think that's true for things other than mental health as well. That's the one that's most significant to me. But you may have another kind of chronic condition that you come out of remission on and you need to take care of your life in a different way. And things you might have been able to do before, you need to do in a different way. 

And I think there's a lot of accommodation for that. Because Shopify really respects spiky people. People who are excellent in one area, but not – that may have other areas where they're not as strong. And the instinct here is not, "Well, you have to get good at those things too." It's how do we make sure this whole package is valuable at Shopify and valued at Shopify? And I think that's a piece that I really appreciate as somebody here who has a different shape of brain health, right? Who has some different needs in terms of how I schedule my day or the kinds of commitments I can take on? But as long as the things that I'm good at, I'm good enough at, then that whole package is welcome here. And I think that's been pretty great. 

I think it's helped a lot also with our transition to remote before I got here. But very early in the pandemic, Shopify said, "That's it. We're just all remote. Forget about it." And we renovated the offices to not be offices anymore and all that kind of stuff. But it's meant to – we've had to really deliberately confront. It's not a temporary thing. It's like, "Well, we'll eventually be back at the office. So don't worry about it." It's like this is how Shopify is going to live and this is how we're going to get human connection. And this is how we're going to have unstructured time together as a team. And I would say we're still working on it. But those are things that are very explicit and structural at Shopify. And that makes it a much healthier place for me to be than I might otherwise be.

[0:52:03] SF: Yeah. I think there's a lot of value – some of this coming from essentially like senior folks within an organization and the leadership team as well. Because I think people want to see some level of like humanness to their leaders. They're not robots. They're not perfect. 

And, again, I think you still need to have, of course, be very excellent in whatever it is that you're supposed to be doing. But I think showing that you're not perfect is valuable to everyone. And it makes people who are maybe struggling with these types of things that are maybe lower down in the organization realize that, "Okay. Well, this is," like you said, "not the end of me." 

[0:52:38] MS: Yeah. And that you can create that. I mean, obviously, I'm privileged. I'm a tall white dude in a very senior spot. 30 years of experience in tech. Not everybody has the opportunities and privileges I have. I'm very aware of that. But I think that there are opportunities for people to advocate for themselves in ways that can be safe and to shape things that they may have more agency over how their work is shaped or how their relationship to work is shaped than they might think. And if I can Inspire somebody to find a way to operate their day a little better or structure it differently that suits them better and helps keep them healthier, then I'd be very proud to contribute to that. 

[0:53:07] SF: Mm-hmm. Diversity is also I think an area that STEM programs, in particular, software engineering, continue to struggle with. Somewhere between 14% and 20%, depending on the status you look at, of all engineers in the US are women, which is pretty stark contrast in comparison to the number of men. And what are some ways or programs that you or Shopify are working on to help with diversity of engineering? What are some things that other organizations should be doing and copying or even individuals could be doing to help with some of that stuff?

[0:53:37] MS: Yeah. And I think every company has to approach this in their own context. I think, at Shopify, we really do value diversity of experience, which can be gender or sexual orientation. It can be national origin. It can be your own professional background. 

I don't have a CS degree. People start talking sometimes in very specific CS terms and I'm like, "Do you mean when we do this? Okay. That's what that means." And so, that's an accommodation and something that's seen as providing value is that we've got another perspective coming to this. 

And what we do with software – and Andreessen said software is eating the world. But what we do with software shapes so much of human society that it's just not acceptable for those decisions to be made without more different humans at the table for them. And I think making that room. And some of it is role modeling showing that people with different backgrounds, or different approaches, or different life contexts can be successful, and be rewarded and highlighted is very valuable. 

But I think some of it also is that a lot of people don't see a software career as available to them because they didn't go to Waterloo and they didn't have top math marks in high school. And they don't write code in their private GitHub on the side, right? They're all hobbyists. They just want to be good at their job. 

And so, some of the things that I've done at Shopify and at previous companies, right? We try to not do take-home homework for interviews. Because if you're taking care of kids, or a parent, or maybe you just have hobbies, which is also a very good thing to do for mental health, that may not be as easy for you as someone who is in a different life circumstance. And it's not a predictor of your success at Shopify. We don't expect people to work around the clock on these things. 

Another piece that I think is important is our Dev degree program where we provide a way for people to get in concert with universities. A bachelor of software development or computer science spending a large portion of their time doing work at Shopify. 

And so, you work with a lot of people who are very earlier in their careers. And for those – and I'd love for more companies to sort of take our role in that so we could expand it. The universities are very eager. You work with people who come from different perspectives. And those people are in the meetings and sharing the questions the things that don't make sense to them or the things that they thought of that we didn't. And when we're selecting those candidates, we do look for people coming from unusual backgrounds who might not have another path into tech. And where tech might not get the benefit of their wisdom, and expertise, and creativity if we don't create another on-ramp for that. 

But as much as a problem of on-ramp is off-ramp. A lot of women go into tech either in a university and switch out of it or they started engineering and they move into another aspect of tech because they don't feel welcome or they don't feel represented there. And I think that's the role of every leader to be looking for those cases where, "Hey, you talked over her." Or, "We need to make sure that all of our examples of users aren't men." Or these other pieces that just make it be more accessible and welcoming. 

And people will talk about that being woke and politically correct. But to me, it's about making sure that we can get the best out of every human that wants to contribute to Shopify's Mission. And that means that it needs to be as natural for them to be in an experience as it is for me.

[0:56:20] SF: Yeah. I mean, I think a lot of it comes down to representation. If you don't see people that look like you in particular roles, or taking particular degrees, or studying certain things, then it's hard to imagine yourself in that scenario. Not to make this too much about myself, but growing up in a really small place in Canada in like the 80s and 90s, there were certain jobs that were just like I might as well be talking about traveling to Mars. They just were completely foreign concept. 

If you do that even at a different level where only single-digit percentages of the entire engineering community maybe looks like you or you're never going to see a professor that looks like you, that has a negative – significantly negative impact. And we see those types of things too when it actually comes to product experiences, too, where because a lot of – historically, even if 80% or 50% of the people are white males making decisions on product, it's going to lead to certain mistakes, intentional or not, around – there are stories about photo recognition software not recognizing people who aren't white. Or classification of different objects within in an AI sense not being able to work because they haven't done the work to essentially have enough variety in the training set and so forth. I think those are missteps that can be fixed if we have the right sort of intention behind it.

[0:57:32] MS: Yeah. I think so. And we're starting to see – I mean, a project that Mozilla did long after I was there, I can't claim any credit for it, whatsoever, is some work on voice recognition where they solicited a lot of very varied content. Not just a lot of it in terms of the size of the corpus. But that it came from people with a lot of languages and people with different speech styles or disabilities to try and build some of these models that are more universal that people can use in ways that might be more inclusive and create more inclusive technology. 

But, yeah. And I think, also, if you use technology and it never feels like it was made for you, it's not going to be very inspiring to get in there. I mean, some people might see that as a – take that as a challenge and go and do that fight. But it shouldn't have to be, right? It should be like, "Hey, I can see how somebody like me might have built this." Or they were thinking about someone like me when they built it. And I think that's a really important aspect of software that touches people. 

And I think commerce is an area where it's super important, right? The economic outcomes can be so valuable and so important to people. We need to not assume that they're all in a certain place, or think in a certain way, or have a certain background in math, or stats, or commerce. Right? We really want this to be an on-ramp for people to commerce for the first time so that they can do something they couldn't do before. And that's not just for people that look like me.

[0:58:39] SF: Mm-hmm. Do you think that as an industry, based on your experience, we're making good strides or steps in the right direction to help solve some of these problems? 

[0:58:48] MS: It's hard to say. Companies don't like to talk about their numbers. And I think that's sort of a good sign and that they like know that they're not quite good enough. But it makes it hard to have really evidence-based conversations about what has worked, right? 

There's been programs like stuff out of a school in Pittsburgh, I forgot what, called Opening the Clubhouse, I think, which was talking about like what are things they did that made the systems more accessible? And some of it was like just they segmented out their first year programming class into people who had programmed and people who hadn't. The people who had taken this up as a hobby because they'd seen role models when they were five of a white dude like them programming didn't intimidate out the people who were now interested in it for the first time, but maybe the first person in their family to go to college or to pursue tech. 

And so, I think there are a lot of opportunities for us to do better there. I don't know if we're doing better in terms of the outcomes yet. But I think we're doing a lot better in terms of it being seen as like an important and legitimate conversation. And that choices that we make as leaders in technology need to be evaluated against a diversity lens along with a commercial lens and an architectural lens. 

And I think that wasn't the case when I started my career 30-odd years ago. And I sort of hope – I've got two daughters. And I hope that if they choose to go into tech that this will be like a weird conversation to them. Why would you ever had to talk about how many people were of which gender or which presentation? Because we're past it. But I just don't know if we're going to get there that fast.

[1:00:02] SF: Yeah. I think a lot of this is a long-term investment too. Basically, you have to make these decisions, make these intentions, have these conversations now so that you can impact, hopefully, the next generation of engineers in a positive way.

[1:00:14] MS: Yeah. And the learning cycle is long, right? You want to look at people at the arc of their career, right? What made them able to start their relationship with a tech career in a way that made it sustainable and got them to a very senior position? Or made it so that they could support their family well on it and be comfortable and participate in that economic miracle of software. But those are – we're an industry that wants to like see feedback next week about the AB test we did, or the benchmark, or an update on a project. And I think being more patient in the social science sense, and looking at these horizontal studies and encouraging that. And I'd like to see more research funding for that come from tech companies as well, I will say. Because I think it is important for the long-term health of the industry.

[1:00:53] SF: Absolutely. And so, I think that's a good place to start to wrap up. But before we say goodbye and thank you for being here, is there anything else you'd like to share? 

[1:01:00] MS: No. I really enjoyed our conversation. And I hope my colleagues at Shopify feel that I've represented them well. Because it is really a very special place. But, yeah, I'm glad to be here. And it's an honor to be part of the podcast.

[1:01:10] SF: Thanks so much for coming on. I really love the conversation as well. It's always great, of course, to connect with a fellow Canadian working in the engineering space. But I think we touched on a lot of stuff. Your history. Some of the decisions that were made at Shopify to become such an engineering-focused organization and transition into a platform. And also touching on some, I think, important socio-economic and technology issues there towards the end. Thank you so much. 

[1:01:33] MS: Thank you.

[END]