How much to invest in platform work | Jean-Michel Lemieux (Shopify, Atlassian)

[MUSIC PLAYING] This is the Engineering Enablement Podcast. I'm your host, Avi Noda. My guess this week is John Michel Lemieux, who is formerly the CTO of Shopify and VP of Engineering at Atlassian. John Michel recently published an article saying that 50% of an organization's R&D spend should be spent on platform work. I constantly receive questions from leaders about how much to invest in platform work, so I'm excited to dive into this deeper. For this episode, we tried something new where we asked people on LinkedIn to submit questions for John Michel in advance. We had lots of questions come in, which we tried to touch on in this conversation. We start by talking about what the definition of platform work is and why he thinks 50% is the right amount of investment. We then discuss why John Michel sees platform teams as an anti-pattern, how he suggests advocating for platform work, and how he decides which projects to fund. I hope you enjoyed listening. John Michel, so excited to chat with you today. Thanks so much for being on the show. Hey, Avi, great to be here. It's a perfect topic. I always show up for platform conversations, so. Well, excited to dive in. Where I'd like to start is with definitions. One thing that came up a lot in the discussion threads where what actually is the definition of platform and how do you define what platform work is actually referring to? So would love your take on that. Yeah, that's a good place to start, because I think that definition is actually evolved over time. And I think a lack of shared understanding of what that means means we're probably talking about different things. So historically, you think of a platform company. Your companies that are platform me, right? Are Microsoft or Apple? They're building APIs and SDKs and a big part of their product is actually a developer platform. But I think it's a developer platform and in the media, it's talked a lot about people creating outside communities and around that platform. I think platform like that words evolved over time. Going actually, if you think about what these platform companies have done with the platform is they've really built kind of a long-term high value feedback cycle of work that people can plug into. And I think what you're doing every company at some point is like you've got these things that provide kind of outsized long-term benefit to you. So for the way I'm using it in the way that when I say, I give these numbers out, it's every company I'd say almost like within a year of having a product, you're going to have some parts of that that provide you outside leverage medium to long-term. And I think recognizing what those things are versus the things that give you shorter-term leverage is really important because you work on those things in different ways. In the same way as I'd say, the traditional platform companies, you build platform products a bit differently than you do other kind of products. And I think companies have to internalize that and go, OK, do I have any of those? What are they? And then how did I build those? So I think for me definition, let's talk about what they actually are, is the infrastructure that you run your stuff on. And that's what-- typically, people go, yeah, that's what platform is. They're like, no, there's a lot more. And this a lot more is I think the really, really critical key, the development environments for all the developers that you have to actually build that product, like right tests, et cetera, et cetera. And I think you guys are experts at running visibility to that, but that's part of your platform. And why is it platformer? Well, it provides, you know, outsize long-term advantages and then leverage for you, right? If you can make our developers go fast, that's great. So but that's part of your platform, the system architecture and security. Where does the code go and why? Like that's part of your platform decisions. The key technology choices across all those layers, your UI framework, your server, et cetera, et cetera. And then your core abstractions. And this is really, really key. Like your domain model, you know, so if you're in commerce, you're like, we have an order and we have a fulfillment. And like how you model your domain is, so it's kind of like, where's your code go? Like do we have one service or many? And then how do you actually model your database structure and your business model? Like that's part of your platform. Because it powers a lot of things. It's probably going to make the difference of your like meeting the longer-term velocity. And as I'll get into a bit later, like it deserves a roadmap as much as anything else does. And it's key. And then obviously all your APIs and SDKs. So that's, for me, that's the platform that every company has. And we don't have to agree with it, but at least in the context of our chapter in half, that's why I consider a platform. - Well, I love that definition. And I particularly like the word leverage. So any work that sort of provides leverage to the organization that you can distinguish that type of work from work that provides dollars or direct dollars or direct value to customers or feature work. I have a question kind of going off of your definition. I actually just other day noticed that Spotify has agile coaches as part of their infrastructure and platform organization. And so I'd be curious to ask you, is there a type of team or work that falls on their platform work that focuses on organizational leverage? So specifically is agile coaching a type of platform work or is it not? - Interesting question. I'm not a huge fan of whatever you call it. Like agile coaches, et cetera. Like I think your question is your organizational playbook of how you get work done part of your platform. Like I almost call that your company operating system, right? You're going to decide do you have meetings, how do you organize? Like there's a company operating system that like in the article I wrote, I don't really include in that, but I think it's a really good point. Like it does provide long-term leverage. Like the way you decide to work together as a team, like ignoring agile coaches and whatever methods that all you want to use, but just the way you want to work as a team absolutely gives you long-term leverage. So if you want to apply that to the definition that we just talked about, I think it's also important to realize it. Platform work is actually very customer centric. And I think this is maybe left out of the conversations about platform and maybe we can get into like some of the caveats but why people fail with platform work. But I think if you look at your platform work as being some of the most important customer features that you have, right? So if you don't do those things that we talked about really well, like your performance sucks, you have no scalability, you're probably able really low sensibility. It's probably hard for you to release new features. So your customers aren't unhappy. You're like, why aren't we getting these things fixed? So I think you have to look at platform work as not a black hole of like tech debt and technology things. It's actually probably some of your top three to five customer features are going to be enabled sustainably by why work in this area. Well, that actually got ahead to the next question. And this one came from the audience, which is with non-functional aspects of sort of platform product work, such as reliability, performance and stability fall under platform work. And it sounds like you basically just answer that question, but absolutely, right? Reliance, performance, stability are very customer centric and fall under and also provide leverage to the business. Yeah, and there's things you can't-- you kind of can't growth hack performance or scalability. You know, like listen, maybe people super a lot more smart than I've been and the team they're working with. But to get high scalability are a lot of tweaks in your domain model, in your infrastructure, all these things that you just can't. You're not going to stumble onto it. It has to be pretty-- you have to design this over years. There's some habits of work here. But now I think one of the biggest challenges that I see with engineering leaders out there is we suck at being product managers of the platform. And I think that's one of the biggest problems is over the last 20 years or so we've gone from organizations with people did everything. I remember in my early career, I graduated in '95 and you just built shit. Like, there was no product management because that-- you just built shit. And we're all in a team and you've got to write the docs, write the code, and get people and talk to the community in Big Zill. And I worked in open source for a long time. And you know, we did everything. We had to do planning and short community, what we're building. And you just do everything. And now you've got all these roles. And I think developers are step back. We're like, we just built shit. Someone else has to manage it and metric it. And I'm like, yeah, but you realize if you don't measure these things like uptime and performance and scalability, and you can show the progress as well as a PM is going to show progress of what screens are being used or are getting engagement on those features, then you're not going to work on it. You're not going to care. And I think everything you do has to be-- you have to ask yourself, one question, are we getting better or worse over time? I think platform work also is not-- it's really hard to have a concrete goal. We need this to happen this year in skittability. What I asked team is, do you know if you're getting better or worse your year? If you can ask yourself that and measure it and show it, then I think it's one it's going to be easy to invest in it. And also, it's easy to know when to not invest in it, because it maybe it's fine. But I think those are things that have gotten in the way. I think if us investing in platform work, talking about it, and treating it as one of the most important product features that you have. Yeah, I agree. This is such an important point. And there's a few questions from the audience. We'll get into later on this that relates to product management and advocating for work. But I think the next question I was going to ask you relates to the first step, tying back to the definition. What's your advice for developers or leaders out there who are in organizations, whose leadership maybe doesn't intuitively understand what platform work is or why it matters? What's your advice for having that conversation, perhaps, with less technical stakeholders to get some buy-in for platform work? Yeah. And you didn't ask this yet. But maybe I'm going to ask myself a question in answer, because I think it's related, which is, why the hell do I advocate 50% platform work? I think that was a bit of a controversial point. And I was actually trying to make sure we had a strong conversation about it. I don't know if it's like 45 or whatever, but it's not 10. It's not 20. So I think just to your question, how do you have a conversation about this? I think starting a conversation with-- we think the platform work requires 50% of investment creates a bit of what the hell? There's a conversation that has to happen, because you just brought out a big number that's going to scare the crap out of everyone, and they're going to go, what do you mean? Cool. Let's talk about this. But so for me, that 50% is a tool for engineering leaders to at least spark that conversation and be able to have that and go, actually, here's why. So I think that number for me was a tripwire for having those conversations and a responsibility for that leadership team and to be able to show what that looks like. So I think that's the tool for me to have that conversation. And then if you can't find that kind of work right around core abstractions, technologies, decisions, et cetera, scale work, then maybe it's fine. Maybe you have a year where you've done too much and you've just swinging a lot, but usually I really, really see that with-- especially with companies after they've been around for two to three years. And I guess they're getting to the one-to-end space where they actually want to be around for 10 to 15 years, and they have to start making different bets. So I think that's kind of my biggest advice for folks is spark their conversation. Don't stand back and assume all this is going to happen in the platform. And people are just going to give you money. You're going to go away. You have to be an advocate for it. You need a better plan in any product manager in your company around what to do. Platform work. Because one, it isn't going to take longer. It has a bigger impact. And you have to be better organized than anyone else. I made that mistake in my career where I went through a bit of like a early career. We had to do everything because we had no role defined in this industry too. Oh, there's product managers and there's designers. And I'll just go-- I did that. I personally-- I'll just go build the feature roadmap. And that's great. And then you're like, holy shit, there's all this stuff that like, who was advocating for this? Oh, maybe that was me again. And then you get back to it, right? So I've gone through that ying and ying of taking kind of a strong leadership role of that work. And I can strongly believe you. Like someone has to do this full-time drop in your work. Yeah, I agree. And we're going to definitely chat next about that 50% number because I love the bold approach. And I love the explanation that part of the goal of that number is to provoke conversation. And I daresay, it almost doesn't like put the burden of proof on executives to, you know, why not 50%, right? Not why 50%. So this is a question I get a lot. And a lot of organizations are definitely wrestling with. And like you just alluded to, you've given this concrete number, 50%. You said, 50% of R&D spend should be focused on platform work. And you said, most teams are very off from what it should be. So can you talk about some of the inspiration around the usefulness of that 50% number? But when you say most teams are very off from what it should be in 50%, how are you arriving at this number? Well, I have to pick a number. And it sounded like a good one. But I also pick it because through the last 10 years of jobs that I've had, when I actually go and I look at what would I work on? With the lens that I have as an engineer, an executive of a company. So I see all the feature roadmap. I see all the stuff we've got to build for end features. I see the realities of what's another covers. I try and make bets that are medium-- like short-term medium long term. And I go, oh, we should be updating our order model for this. And I'm like, oh, there's a list like this of things that we could do. If we're really going to do these kinds of features what we're long term, there's less. And I put that together. And I'm like, it's always more than you think it is. And then whenever I go work with engineering orgs and I go, can you show me your platform list and your feature list? I call them the growth list, not features, if they're all features. So it's like a platform list and your growth list. And I say, show me both lists. And I just, like, people have that in their heads and you go talk to developers what's in the platform. They're like, yeah, we have 133 attributes on our order model. And like, every time we have to implement a feature and we can't do this, or we made an assumption about them being mutable, but they should really be mutable because that means we can do this. Like, all that's there organizationally. And I think it's almost like we've created companies where that conversation's not actually happening. Like, it's almost like, oh, that's just engineering stuff. Or that's just, I'll just change it or whatever, you know? But I'm like, that's some of the most important decisions you're going to make are like in those conversations about how it's built. So I think the other thing about like, why is it hard for some people? I think conceptually people see strategy as the why, but not the how. So companies are going to organize the exacts and whatever and they're going to go, we want to go tackle these things, these are objectives. And they're like, I don't clear how it gets built, just get it built. And I'm like, I have a very different philosophy. I think the origins of the word strategy is actually in the how. It's like, how are you going to win? It's like, we have to go over this bridge and we have to do this and that like, that's the how. And I think the how then is how we're going to implement all these things is extremely strategic conversation. And I think, you know, execs and whatever. Like leadership has to vet, understand, and support the how. And unfortunately, a lot of platform work is the how when it gets ignored. Because people feel it's in the weeds. And I think some of those weeds are strategic. Give you a super interesting example. The most strategic decision that Twitch made. So we've all, I don't know, I gave him some time them on Twitch, it's great. In their origin story, you'd think like, what's strategic about Twitch with them? Like, do they build a streaming, like a video streaming server themselves or not, right? That's kind of how it doesn't matter. Like, maybe we can change that. It's like, OK, that's an extremely important platform decision. That was a platform decision in their first 18 months that actually, if you look at the leverage it provided, it means that they could host, they could stream videos at 10X lower costs than anyone else could do. Which means they can do more of it. The basic Twitch is alive today because of that one technical decision they made. They decided to do it, and it changed everything. Like, that's a leverage decision. So I'm like, in your company, are you making any of those kinds of decisions of like, that I'd say get ignored on a lot of companies as being an implementation detail? But platforming that long-term leverage things, the how matters a lot, those conversations aren't happening. And that's why companies are at 10% or 20%. And then they call me and they're screwed. And it takes us three years to avoid it. That's the story of my entire life. Cookie cutter with every organization I'm working with right now. That's really funny. And that was a really interesting story about Twitch. And a really interesting way to think about platforming like what platform decisions were even conversations. You talked about how these conversations don't even happen at a lot of organizations. What conversations and decisions that you're making that could be or are these big areas of leverage? I'm curious in your own work, personal work, leading organizations like Shopify and Atlassian, were they close to that 50% number? Or is that more of an aspirational number? Or should they have been? So it's funny. I think the team that we did the best-- I learned this with and unlearned it. So I was part of the Eclipse platform team, which is an open source kind of idea, blah, blah, blah for quite a while. I think we got that number pretty well. I think a lot of things didn't do well. But I think we bounced that really well. Because we kind of were a platform in some way, like our product was a platform. So I think we had to a bit more. I think at Atlassian, they're pretty early days, starting up, trying to launch three, four new products, doing some M&A. I think it wasn't-- I think I made a mistake. I think they adjusted after at Shopify. I think I came in guns blazing, tried to make it 50%. And I think you can see some of the-- I'd say you'd say I wish we could have done more. But we scaled crazy. And that was all-- that was work from 2014. There's a lot of stuff we did. I think the CEO told me, but actually, but a really good advocate of that as well. So I didn't have to justify it all the time. But I think it was a continual work organizationally. Because I think the shared view and definition of platforms, not there, right? It's like no one's read this book. Everyone's read the Lean Startup, no one's read the platform book. So it's like, you're starting kind of on the back foot. But I think I learned a lot at Shopify about how to champion. And how to kind of coach my team, people would come and complain. Developers complain about some all the time like this. And then I'm like, oh, listen, I was like, if you want to do this kind of work, you need a run map. Like what do you mean? Well, I think great platform run maps, actually, what they do is they're basically a leverage diagram. If we do this, and then there's basically an arrow, we can do this, and this, and this, and they'll enable this, and this, and it's like-- I think some engineers are worried going, well, I don't know. It's like, well, caught like a tofu scale. There's hard things that we know. In a one year, we'll be able to build this thing, reduce this cost, and make this quicker. And then in three years, we think the soft tofu scale, this soft-- we think we'll be able to do this. But so I think that's a really good view of platform work is showing what it enables as a thing, not just a metric going. We want this to be adopted. But what's it going to enable in the future? An example at Shopify was we had to add subscriptions to Shopify. And subscription as a thing means that your order, after it's been generated, has to become mutable now, which is kind of it. When you take a core data model that was immutable, and you make it mutable, there's a lot of side effects of doing that. I think we were scared shitless of doing that, knowing the side effects of doing that. But I think I remember we had a really good strong staff developer, and I was really impressed. I actually put it in very customer center features, going, we're going to make orders mutable in this way. We're going to-- here's about it back with the compatibility. But here's five years of feature roadmap. And we're like, I was like, do you guys want these things? Do you want pre-orders and this? And they're like, yeah, everyone wants that. Cool. This work is going to make that possible. So at that point, it's not even selling this thing. You go, hey, there's these features that we're going to be able to get if we can do this kind of work. And it took us two and a half years. Actually, I'm using one of these new features that I think we started that project three years ago now, that launched for Black Friday this year. And I was like, cool. I remember when we kicked that snowball off the hill. So I think I went through the mistakes. I think Shopify, as it is now, is actually pretty close. And that's, I mean, maybe it's at the end of my career, or not that old, but at, you know, 20 years later, like it took a long time, because there's a lot of pressure. There's a lot of pressure not to do it. There's a lot of misunderstanding about it. So maybe I say I'm a bit late. It should be obvious, but it's hard. And that's what I want to talk about. Yeah. Well, definitely. And for what it's worth, we spoke a few episodes back. We spoke with a leader from Shopify. And we were really impressed with how they're approaching platform work and developer experience. So I think you did well there from what we can tell. We have a question from an audience member. And this is actually a leader at Qualtrix. And it was a couple of questions. But, you know, I don't know the full context. It's, they're probably having internal conversations around, you know, allocation to platform work versus other work. And, you know, one of their questions was the 50% on platform work. Is this about keeping the light on or also the proactive investments in reliability, scalability, platform capabilities? And I think we can sort of answer that question. It sounds like it's all of the above, right? When I think of mistakes that people will make again is not a shared definition going, we just want to fix tech debt because we're slow. That is like, if an engineer says that and it like, and uses that as their pitch for platform, like, that's why they're not getting any support. Like it can't be. But I think you, you have to always champion those non-functional features that might get lost in the mix, right, like scalability, et cetera. But also you have to, like, a big part of that roadmap is enabling of things, right? It has to be enabling of things like Twitch, like, didn't do the video server because they're like, we want streaming to be cheaper so we can do more of it. Like, don't we want more of it? Yes, cool. Okay, like that really clear understanding of where the company's going, where the product's going, has to be part of the pitch and the understanding of that. I think there's some years 80% of your roadmap is platform work. And sometimes, maybe it might be 30. Like, maybe it's like, we've got to get a new product there with the product market fit thing. We're doing, like, we're just going to get it, like, cool. Like, I'm an extreme pragmatist as well. But I'm saying, like, steady state for a company after is going to be 50%. But I think if you take it as a customer feature enabling thing as much as a technical hygiene thing, then I think you're easily fine, 50%. That makes sense. Well, double click on that technical hygiene piece because the second part of this question is actually, let's go with the 50% for overall platform work for this conversation. But let's say what percentage of that would you say would be typically allocated to only the sort of keep the lights on, like the maintenance and uptime, on call, patching, like, what's a good baseline percentage for that type of work? I'd say typically it'd be like, you know, 10 to 20%. That's what people usually see in the platform. Like, we're spending 10% in platform, like, you're just keeping the lights on, you know, of, like, like, gardening. You're weeding, like, you're gardening. You're not planting new things, you're planting new trees, you're preparing for the future. You know, you just gardening. And there's obviously gardening has to happen, right, on teams. And one of the habits I had just to support some of the gardening work is I had a cron script that would, you know, RM-RF of my source directory on my laptop every Monday. And I'd go get my dev environment set up again and go, can I take a bug off the queue and get it fixed in production? And I couldn't, then I don't know. OK, we've got some issues. Or like, some of that, I think, calls for you as a leader, you definitely have to champion and do. But I think you can't pitch platform work is that being all of it. But I don't know, maybe 10 to 20%. Like, it depends what's in that bucket. I'd say, like, developer experience, you know, CI/CD tooling, infrastructure, you know, companies are going to decide, like, how much self-serve you have in your company around people creating things and deploying and managing it. And like, it's probably 10 to 20. And also, like, as part of that work, I would say there's some cohesiveness projects of, hey, we've been doing this thing in five ways, and we're going to pick one. Like, OK, that's like a long-term cohesiveness investment. I think you're going to find some of those here and there that I think that's, that's part of the 20%. Like, that's actually, there's 30%. I'd say I actually way more featured oriented platform work. Yeah. Well, I love that answer. And I really love the gardening analogy. Are you just putting out weeds or are you planting new spruce trees that are going to be beautiful? In a beautiful landscape in 20 years, I want to ask about sort of stage of company. When you think about, we get this feedback a lot, because we speak to a lot of leaders that a lot of these sort of high-soring companies. But most of the companies that there are small businesses or just earlier stage software companies, does this 50% number in your mind mostly apply to large organizations? Does it apply to small organizations? Is there a linear curve as your organization grows? Exponential curve? What's kind of your take on how you think about allocation as it pertains to stage and sides of a company? I think it doesn't, it applies to a one-person company or a 10,000-person company equally. Again, the, just going back to the, what kind of decisions are encompassed in this platform work? I think there's some extremely strategic ones for the long term of any company. I think that one of the bad wraps that platform work has is people just go, it's tech debt or it's infrastructure or things. But it's, I see a lot of problems in core domain models that don't get updated. Like people piggyback, there's a healthcare company you're working with and they're like, you know, like billing for healthcare is complicated and you've got to, and they have five billing models because they want to go fast short-term and now they're like, you know, it's like three years of unwinding and at some point, like I think every year just go, hey, we're doing this three times and we do this way and how, like, I mean, we're going to go from Canada to the US, we're going to have to support all the states and like, so that like that work could have happened in, you know, year one of their existence and I think they pushed it off a lot and I think the Twitch examples and that they're a really good one of, you know, that kind of work, you know, having long-term leverage and not, you know, is there a lean startup world of just like, just throwing all together and you're going to have to rewrite it anyway? Like, maybe like the six months, I don't know, like, let's throw it at a wall and see if anyone will like it. Like, maybe there is and I think you do have to get, you have to get used to rewriting things, which means that like, platform work's not about getting perfection. It's about the habits of yearning for perfection, but not getting it, you know. So, I think that has to start on day one of your company. - Well, you responded the way I thought you would as the question rolled off my tongue, I anticipated, you would say it doesn't matter and I would agree with that. You know, you've touched on this a couple of times. - I've changed my mind on this a lot. So it comes out, but like, this is, I get asked this question a lot and in the early day, like probably two years ago, I would just say, yeah, just ignore this for your first 18 months, just try and survive. But the more companies I work with, the more, I don't think it applies. You know, and let me give you a super concrete example. Okay, so I'm building this thing and I want to, like, you have two, three customers, you think it's gonna work and at some point you're like, shit, we tweeted something and we have 200 and we're like, oh, we didn't automate like the onboarding of this and we can't deploy new service. We need it like, that's gonna kill your company. To not say yes to those companies coming in, but that was kind of scale building work and I kind of didn't need it and so like someone at least, and maybe it's a good problem to have and like, it's good that it broke and you'll fix it, but I just see more and more of that work, the strategic house that, at least that conversation has to happen and that's why I've changed my mind. Like I used to say, yeah, ignore this for a while, it's for big company and I've changed my mind based on just working with more smaller companies in the last two years. - Yeah. - Not just change my mind, like, convince me, like I'm almost like 99.9% sure that it's applicable. - Yeah, well, it sounds like you've seen a lot of organizations sort of get blindsided later and you've touched on this a few times in this conversation already but boiling it down, why do you think it is that platform work is just so consistently underinvested in? Is it that, you know, developers and engineering leaders, we just suck at communicating about these things? Is there just overall lack of awareness? Are leaders just too short-sighted? Like, why is this such a consistent problem? - Man, all of the above, like, I think culturally society wise, we split, we have a lot of specialized roles in companies now and I think there's a power dynamic difference between who decides what work gets done. I think some companies have over-hired, you know, all these, but I think there's a lot of product managers out there that are, like, fantastic and they run a lot of the roadmaps and I think a lot of companies that's kind of how it is and I think that gets in the way. I believe that people don't have a shared, like all the things we talk, I mean, feels like I'm repeating, like, no, share understanding what platform is so you don't know what to put in the bucket. There's a power dynamic difference in companies about who decide what work has to happen and I think engineers are shouldy at communicating long-term. Like, there's a lot of engineers who, we have a lot of burden, which we have to make it work. You know, and I think the platform work you have to make it work and you have to know what it's gonna do and you have to plan it, like, there's a lot of that. So I think, you know, assuming that that's the part-time job to do that, like, it's a lot of work to be a really good product on the road of the platform and I think you want to invest so you don't sell it as well and the story's not good and you're behind and you, so I think all that combined is probably one of the reasons why it's not invested as much as it should. - Yeah. Well, I would agree and all those things make sense. We've talked a lot about how organizations or how much organizations should be devoting to platform work and how to consistently underinvest it in. I want to talk, shift the conversation to talking about, you know, how can developers and leaders actually actualize this or turn this into reality and their organizations and one approach that's been getting a lot of attention across the industry is this notion of a platform team. Like a dedicated platform team. And earlier when we were chatting about this, you shared an interesting take on this. So I'd love to go to that and get your thoughts on that. - Let's ignore the org structure first. And I'll tell you why. Because I think having a platform team could be an anti-pattern because if you, if we agree on, I'd agree, but if you take my definition, my current definition, then there could be tweaks too, but the definition of like the core data models being in there, some technologies, decisions, et cetera, I think there's a platform component of every team. Like if you take every team that's building, like you got three teams and build different parts of your, your product, like they all have a platform component in what they do. And I think taking that view of every team has, you know, 50% platform, 40% features and 10% experiments, then you can't really re-organ go, I've got a platform team, like what? It's actually dangerous to do that. Now, you can have a team that does developer productivity and maybe your specialist on infrastructure and specialist on your data infrastructure. But I think saying that your, that team owns your entire platform roadmap is an anti-pattern. So I think the concept of having a platform roadmap is has to transcend your org structure. And I think you need a leader, you have to go. You're the PM of the platform, like what should we work on? And it should be with the view and the lens of looking at things across the company, right? Of what's going to provide leverage. So I think that's why, I think that's why the platform seems different. And I think what I'd call the other teams is call them what they're actually doing. Because platforms so misunderstood, the minute you're going to develop a platform, what is that again? It's like actually call it maybe a developer accelerator or a team and a hosting team and infrastructure or whatever, like data pipelines team. We've got a build and see it, like, you know, we did have, like I find, it is useful over time to extract some things that you're doing across the company. You go, actually, we're going to do this way. You know, and at Shopify, we had a Rails team. We did have a Rails team and there were a lot, but everyone's doing Rails at Shopify. Yeah, of course, we all are, but there's a team who was like super involved in the open source community, working on the next version of Rails, adopting it for everyone and helping it. But their job was always to be a bit of, like, an accelerator for all the other teams. Because when we adopted a new Rails version, like, every team had to do a bit of work. But this team, these are the experts doing it, enabling everyone else to do it, but they didn't do it for everyone else. Same route, CI, CD, and testing. Like, oh, I mean, you probably know all this stuff. But so that's where, don't call that a platform team, call them what they're actually doing. So we had a Rails infrastructure team and a mobile infrastructure team doing, hey, we have to do react native performance testing. Well, someone has to figure out, I wouldn't share it. So they are, that's cool. But again, that's 10 to 20% of your platform format. There's a lot more. That's what I see typically being a guard. - Yeah, it's funny. When we were chatting earlier and you kind of, you know, blurted that, you thought, platform teams were an anti-pattern. Initially, I was like, what? But now that you're explaining, I think I agree. And in fact, like you just kind of concluded, we've been talking about how platform work is consistently under-invested. And it almost seems like the buzzword of platform team is almost like an easy button for organizations to say, yeah, we do invest in platformer 'cause we have this team called platform team, right? - Oh, that's a good point. Absolutely, yes. It's a get out of jail and tired of like, well, we have a team build platform, but you haven't decided, like, again, probably the wrong scope and wrong mandate for that team. - Yeah. How do you, let's talk about ways, whether you're a platform team or just an engineer on a team that sees the opportunity for platform work. I mean, we've talked about this already a few times, talking about what does this work to enable tofu scale of kind of impact. But I mean, do you have any specific examples of or more detailed advice on, how can these teams really be good product managers, good communicators and like what types of signals or metrics or narrative, like how do they go and advocate for this type of work to leaders? - I think the first thing that any engineer can do is just platform work is triangulating things, like a lot of signals, right? Hey, we're doing this kind of thing a lot, right? I'm seeing these features come down the pipeline and I know that they're all gonna be doing this kind of thing. And realizing it's valuable to explain what you see to others. I would, even as like C2 at Shopify, at some point, I would see things other people didn't see. And what I do, I write a doc, I go, here's what I see. Okay, it looks like we have a couple options here. We're gonna put this code. It's gonna go here, we can hack it here. Like I write these kind of mini brainstorm proposals for platform work because I didn't, also didn't trust my instincts all the time. Like this is hard stuff. Like I got to write this down and I maybe take ownership of like, can I explain this myself? Can I see value of this? I prototype it a bit, write some stuff down and go, platform work is expensive. So I wanna make sure that we understand what we understand here. So I was a big fan of like prototyping. Like, hey, we think there's a way we can do this. It's not the way we thought it is, it's a bit hard, right? It's a bit, listen, like, platform works not that in a week, right? It's gonna be, we're gonna do this thing, we're factoring, we're gonna get ready for this. Like, so I think a prototype and being able to explain yourself in the context of like, again, leverage. Like, why do you think it's worse and what's leveraging to me take ownership of that? I think is, that's kind of like, you do it as a developer. I did it at CTO, like, it's the same thing, right? You just have different signals and doing that. And you know, sometimes it takes a while. Like, you almost have to be more prepared because these are longer conversations and more investments so people are gonna be, you know, pickier about like, why we're doing it. I'd say, there's also an anti-pattern. I think a lot of people, they'll write the RFC that's like 40 pages, which is, I'm like, I don't know, do three, but get a prototype together. I'm just a big fan of prototypes and a bit of a write up 'cause I think the write up is useful because I think you wanna look at different options with platform work. There's usually gonna be more than one path and actually showing it, you see that. You're not just building it the way you're comfortable with, but you're really looking at the long-term means there's gonna be more than one option. So I think that's my biggest tip of people, just getting the habit of having those conversations, prototypes, write-ups, and then from that, that roadmap's gonna develop. And as an organization, you're gonna get a lot of signal of, you know, like I used to get a lot at like, as a CTO, I get like, my entire job was getting these, these signals from the teams going, "Hey, I've seen this show, Michelle. "Like, we're doing this a lot more." And you said to, you know, maybe highlight and write this up and I'm like, absolutely cool. You know, and it wasn't like, we're gonna work on it like, Captain Blasch. Like, I was extremely cynical. I'm like, most of our platform work's gonna be a cluster because it's, but some of it's gonna be 10X. Like, we may as well find, we have to find that and there's no magic person who's got it on their head, but we have to have those conversations. So I think that's my biggest tip is, is prototype, do the write-ups, make sure it's visible, and make sure you take ownership of seeing, and understanding the leverage is gonna provide and show that. - That's great advice. And, you know, one question that came from the audience is kind of the opposite end of everything else that we've been talking about, which is like, you know, have you seen over investment in platform work? And, like, how do you know when a platform team, I know that's an anti-patter, but a platform team or platform investment or initiative is a failure. What are signals of that? And how do you kind of wind that down? - Yes. I was both lucky and maybe unlucky, but IBM bought company I was with a while ago, maybe 20 years ago. And I think the bigger your company get, the more platform work you do because you're like, and platform works great. I can get all this leverage out of it. Like, they've got big because they kind of figured that out. And then it's extremely wasteful. So the two biggest anti-patterns is you have a duplication police who go around going, oh, we're duplicating that. Once we got to go and put that into a shared library. I was like, that is, like, you duplicate until, like, duplication's not the problem. Duplication's way better than having this wrong abstraction that's used all over the place. Like, you've got to duplicate until you actually see things properly. So there's duplication police that go around and get really upset if there's any duplication. Like, that's really, really dangerous. Because, again, platform's hard and you, you need enough signal to even know what to do. And I think that's a mistake. And you'll have all these libraries won't get adopted or it's not worth it the right time 'cause you didn't even know what to do. Like, the maturity curve of the technology also means that it's not, like, we're not ready to remove duplication 'cause we don't know where it's going to go, right? Whether it be like, front end development, like, six years ago, we didn't know. Like, rack, like, kind of, it was, I'd say, front end development, six years ago, some people might say two years ago, but we didn't have enough patterns. And like, I was very hesitant about, like, making it bet on the one thing. And I remember in Shopify, we actually did have a lot of pressure around just, coming out and I was like, it felt like we weren't ready, right? And we had a natural, like, when time comes it's there. So that's the first thing. The second thing is the second anti-pattern. So, duplication police, the second one is building the platform before the features. And that's the one I saw the most, like, the most wasted end of maybe platform astronauts. Yeah, maybe I always like buzzword. So it's like, duplication police and platform astronauts who are building a platform with that context, you know? And my first question for any platform work is, what's the first feature that's going to use this? And it better be shipping in parallel. And maybe like a good visual for this, I think platform work has to start with a vertical team. And people see platform as very horizontal, but I think every new platform piece has to start with a vertical team, which is, they're building a platform and the feature in lockstep. And ideally, even on the same team, you know? So, you know, a simple example of that, maybe just from Shopify times is, yeah, we're doing some really big work on the order model to enable subscriptions. We're gonna ship subscriptions. Cool, okay. Now, over time that team, I think, almost shifts them to a bit more horizontal, but we need that use case. We have to deliver customer value. And it's not because we want money and we need customer, but we have no idea. Like, platform works so hard that we kind of need some anchors to know for even on the right track. And that anchor has to be value, which is customer value. Like, you know, it has, or like scalability has to be like, yeah, we can now support a million orders a second. Like, there has to be one of those anchors. And I see big companies going away and they see the anchors, but they, I'd say they're on paper and they're astronauty because they're theoretical, but they're not shipping in lockstep with those features. And I think that's something. I'm a big fan of putting like platform and feature teams together when they're trying to build a new platform thing. So you can ship the UI, the feature at the same time. And I think, I mean, in a lot of ways, platform has to be extracted from features over time. So, you know, I think IBM and other companies have wasted billions of dollars on too much platform. So don't take me saying everything has to be a platform. I'm not a bit bit, I'm saying, you know, the 50% because I think people go off of that. But I think the bigger you get, there could be more waste and you can, you can do a lot more, right? And as a startup, you can do too much platform. I've met, you know, companies where there's 10 people, they got 20 microservices and they've got the biggest, the best deployment I've ever seen. I'm like, you just wasted time on things that don't matter. - Yeah. Well, and I mean, it's not just about wasting time on platform work in general. I think it's also just about focusing on the wrong type of platform work, right? Like a pre-product market fit start up to your point. If they have these beautiful microservices, probably, you know, wasting their time. In fact, there's probably the wrong platform work all together 'cause it probably slowed them down. Actually, it didn't even accelerate them, right? They're not getting any sort of foreseeable term leverage from that. And this came from the audience as well. That's what I wanted to ask you about next, which is we've talked about ways to kind of advocate for platform work, what platform work is. Within an organization where there's probably a lot of competing platform initiative ideas, you know, if you have $100, how do you decide which initiatives to invest in? And there's a follow up to this, which is this person said, you know, as they understand Shopify has less and less PMs in the platform space. So, you know, how are they even do organizationally? Like, where's the muscle? What's the process for even doing this? And you kind of alluded to it, you said as a CTO, you would just get RFCs all the time. But like, what's the right process? - Hmm, that's a good question. I'm a bit of a hand-to-hand combat kind of person just, you know, making sure you're having these conversations and then you'll do kind of naturally. If your job is just to make sure those different kinds of conversations and people are at the table, then you're gonna see, right? And then you can actually have the debate. Like, for me, it's less about how would I sequence the list? I'm like, a lot of people don't even have the list. You know, so I'm like, if you even have the list and you're actually debating it, then like, you're fine. Like, whatever, right? Now, I think your second part is really interesting, which is if you're in an organization where that list isn't at the table, then it is true. Like, depending on the people you have and their experience and their skill, et cetera. Like, I think, you know, you're gonna get different lists based on the people you have. And I think, you know, Shopify, maybe we're swung the pendulum a bit much to like very feature-oriented product managers, 'cause I mean, it was very domain-specific. Like, the higher developers who knew camera commerce work, like, it was a good thing to do, but I think we'd, you'll see some of the, like, we actually did a bit of a, I guess, refresh education, like, we brought a lot of ex-developers being product managers. Like, the product manager were online store, Vanessa was like phenomenal developer as well, spent, you know, 10, 15 years as a PM. But like, I think, like, she was now pulling that route, like, she knew, right? And I, you know, we had to remind her once in a while, but honestly, like, she was phenomenal. So I think we'd had a bit of a call for a refresh of like the balance of the kinds of PMs we needed across the org and then championing making, and as I said, like, every senior engineering lead is a product manager for their platform work in their area. I just told people, like, your dev manager, I'm like, where's your platform rune maps? Oh, I'll talk to the PMs, like, no, like, what's, like, you need that, right? And like, it's really hard to hire PMs, PMs are really hard roles to fill. There's not a lot of, so we always had less PMs than we wanted to. So we had to be resourceful and you have to, you know, turn people into having that PM mindset, which is about ownership of what should be built and bringing that stuff to the table. So I think that was to your question, a bit of a shift, but I think, like, not super-draft. Like, everyone can do that. It's within reach of everyone, you know? Yeah, well, I love that quote. Just, you know, every senior engineer or team lead is the product manager of platform work for that team. There's another podcast about what we expect of managers. You know, I think we had maybe a pendulum shift of managers job as a shepherd to make sure the team's doing good work, but not response for the work that they're doing. And I think if they're not doing that, then they're not championing, I think, some of the signals they get from the team. And that's why I like the word roadmap, 'cause you know, what do you mean roadmap? We have one, I was like, maybe we have two roadmap. And maybe you should be helping figure out what's on it. And then there's a conversation where you merge them, but you gotta bring it to the table. And you have to, like, if you're not seeing what those things are and you're not championing it, then I think as a manager, just making sure team can ship the roadmap is a colossal failure. So I'd say that as a bit, like I knew it was not natural, given what we expect, I think managers to do now, or leaders to do. And I think it caused people to, I definitely ruffled some feathers going on. Like, what do you mean? And I was like, I just wanna make sure the roadmap we have has all the input into it, put it there. - That makes sense. And so let's say you have this list, is that the conversations are happening, people are bringing ideas to the table, you have a list. You've been in the role of deciding what things on that list are the best things or the things that should actually happen. Generally speaking, I mean, can you kind of walk us through the algorithm and you're like, how do you evaluate these different initiatives as CTO? 'Cause this is the same way I think organizations could potentially approach it, you know, whoever's making those decisions or having those discussions. - I think if you're starting off, like trying to get back to 50%, you have to be pretty timid and humble in recognizing platform works hard. So I try and, like, the last thing you want is to have five things going in parallel. So I'd almost look at the list and going, what's easy platform work meeting, easy platform work in a hard and pick one of each, you know? Like, don't pick two, like, kind of like, start to get some velocities. I know these things were hard and I know that we're gonna pivot and we're gonna have, like, it's gonna take a while. So I'm a huge fan of just doing things in series unless in parallel. And I think, once you start prioritizing it, also try and look at timing of, like, like, can we get the feature team, like, actually shipping the feature at the same time we have the platform? And I think that also dictates timing of when you do this work. I'd say huge amount of waste in companies actually is literally in the bad sequencing of work based on your eyes are way bigger than your stomach. Like, just based on hoping, not on pragmatism, of, like, just knowing there's an ordering of thing that can make it to three X difference in terms of that happening. So I think that's, you've got to bring that lens to, like, the kinds of work that's happening. And then you do have to see also, like, we're gonna be here for three years. So, like, we don't have to get it all done now. You wanna leave some of this for later. So I think, be pretty strict about not doing too much in parallel synchronizing. If you can get a feature team, and I said, there's no platform team, but, like, the feature teams and the, like, just the whole team that we can actually ship the feature at the same time. And that's more, like, people. And it's usually gonna be a bit more people than you want, like, on paper, just 'cause it's a bit harder. Like, I think those two things are really important. And then knowing that, that you've got to throttle it, like, putting something to next year's, like, a good decision to, like, get that hard thing done. And I think I see a lot of people go, you haven't been invested in that hard thing, but they don't slow down any of the other stuff. And then that platform thing takes forever. And then they're like, we're never gonna invest in platform work ever again, 'cause it took five years. And I'm like, no, that's because you saw you can do platform with 10%, and you just went off. And it took five years, 'cause you didn't sequence, you didn't invest in the proper way. - Well, I think that's a helpful response. The, yeah, do things in series, pick some quick wins, smaller things, in addition to some larger opportunities. - It's almost like, when you start platform work, there's a couple of milestones where you can make or break that project. There's a milestone where you're like, so platform work, there's a lot of discovery and it's harder, but there's some point where you have to get kind of an increase in velocity, so that you don't lose. Because it takes longer, like, you need those wins, and you need, so it's like, the ability to, like, not just, like, pick the things you want to work on, but as they get worked on, that you're nimble enough to, like, readjust go, okay, cool. We can leverage that thing now, and let's do that now, you know? And you're like, well, that team's working on this other feature, like, I'd always be tempted to, like, almost make sure we accelerate some of the platform work, 'cause I know that we're gonna get impatient, and we're gonna get, like, you gotta create some culture and energy around these. So it's like, being able to pivot, going, actually, we can get two, three devs to go, let's put it behind a feature flag in the product, and give it to two people right away. It's like, hop up, it's like, so the ability to do that, create some wins, create some velocity, and also you learn really quickly. So that's something where it's not just in the selection of the roadmap, but the execution of it, and making sure that you, you kind of, like, nurture it in the right way, and a lot of that is gonna be by adapting and changing who's on it, and a lot of these platform work is cross text acts as well. Like, it's how we need data, it's pipeline, there's some AI, there's this, and, like, so that your ability to do that, as it advances, can make or break it. Again, like, platform work has a bad rep to begin with. That's why people just wanna invest 10%. So it's like, if you can be a bit creative in how you shepherd it is extremely important as a leader. - That's a good addition to the conversation we were having, and there's this other question. It's a little bit aside from this topic, but, you know, someone has, how did they Shopify decide what use cases they'll build themselves and which ones they'll leave for others to solve? And, you know, it's kind of a build versus buy question, but I'm curious how that kind of, you know, interlaces with platform work, which is, you know, very closely intertwined with things like infrastructure, you know, tooling, things like that. So, curious for your take on that? - So there's two angles to that question that are actually fascinating. So the first one is when you're building something with the platform mindset, usually you're trying to get leveraged, which means that you're building something or someone's gonna build on you. So the first discussion is, like, kind of like, what's in core and what is, you know, and I think that's, we never figured it out, but I think that's a really, really important conversation for platform teams, I think platforms can fail when they try and do everything. They're like, we're gonna implement all the widgets and all the, like, no, like, what's the core primitives here? That you're okay with other people building on you around you. And, you know, for example, that's a typical developer platform, like what's in the app versus what's in the current, you know, and this has been our eternal thing around operating systems, like, what's the core primitives versus what gets added to it? I think there's no answer, but have that conversation and it shouldn't be everything's in core, everything's in that there's a split there that makes sense depending on what you're doing. Your other question is, hey, platform work's really expensive, like, can we just buy stuff off the shelf? Like, is there some of this stuff there? We shouldn't be building. I'm like, yeah, of course, I don't know what it is, but yes, there's some percentages that you should not be reinventing the wheel, 'cause it's hard. I'm a big fan of, like, leveraging platforms that as an example, our open source, right? Like, where else is a platform? And you get more people using it, the better it gets. So there is a danger of a lot of platform work within a company, you don't have enough users. So I think, like, the way I usually look at platform work is if it's non-domain-specific infrastructure, I tend to want to take off the shelf, and off the shelf, like, it's not some enterprise access, open source. I'm gonna use some more to start saying, we're gonna use tailwind, we're not gonna vet our own CSS styling thing or RG. So if it's like non-domain-specific, and if it's domain-specific, then like, it's our crown jewels, like, absolutely, it has to be. It has to be something that we're gonna build. - Really useful advice and useful purchase, and like, that domain-specific distinction and thinking about, you know, off the shelf or open source versus doing it yourself. The last question I have for you is, you're someone who's led a lot of technology organizations, but also overseen a lot of platform work and some maybe platform teams. So in your eyes, what distinguishes a great platform team? And I know we've called that an anti-penance. So what distinguishes a great platform leader from NOK1 and, you know, what are common areas in which you see people trying to lead platform work? It falls short. So I think you need someone who really understands the product, because you can't build a platform in isolation. So it's like, you need a product experts who really, like, really yearns an extremely curious around. The domain you're in and the product and has to be number one. I think number two is, it's like, someone who communicates really well who can actually explain, like, who knows how to explain value, I think, right? And without sugarcoding, like, very, like, a pragmatist value communicator who can go, you know, and then, so that's number two and a number three is, I think you have to spend a lot of time understanding what's there today and what the future is and make sure that you're not creating a false ceiling for yourself, you know, and how do you do that? Is like, you just, you have to be gathering a huge amount of information internally about what's going on, like, this is where, basically, like, on information absorption from every from out on the outside, on the inside, and you're triangulating on this, and you're trying to, you know, articulate and make some bets, some high leverage, I think, doing those things. I think the platform leaders that have failed is if they just, they do one of those things. They're really, really product oriented, but they don't stay in touch or don't care about how the product's built and the ideas aren't there, but they're like, cheer leaders of it without any of the meat, right? And then there's the opposite, which is, you know, your lead architect who knows all the faults and all the shit and just, they get overwhelmed and are pissed with just all the stuff. And they're just like, I just want to fix all the things and they can't explain the value, right? So I think that mix is, is where the magic happens around really good platform leaders. And something to develop, I think you can nurture people, I think you can pull people out of your org, which I think is good, I pull some staff developers out and go, hey, come hang out with me for six months, come to all my meetings and, like, go look across the stacks, go look at what, like, get more visibility into things, I think that helps you kind of triangulate where you're gonna get the most leverage in wine and help teams not have like fake ceilings on what their ambition is. - Well, I really appreciate these insights and John Michele really enjoyed this conversation. I think it's been really entertaining, really valuable, some contrary and opinions here, I think that are valid and really useful for organizations and leaders out there. Thanks so much for coming on the show and speaking with me today. - It was my pleasure, my favorite topic. Thanks for having me. (upbeat music)