How much Shopify and Atlassian invest in platform work

Abi: Jean-Michel, so excited to chat with you today. Thanks so much for being on the show.

Jean-Michel: Hey, Abi, great to be here. It’s a perfect topic. I always show up for platform conversations.

Definition of platform work

Abi: Well, excited to dive in. We tried something new for this episode where we actually asked the audience for questions ahead of time and we had an overwhelming number of responses. So, a lot of our discussion today is going to be based on those questions. Where I’d like to start is with definitions.

One thing that came up a lot in the discussion threads were 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.

Jean-Michel: Yeah, that’s a good place to start because I think that definition’s 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 or companies that are platform-ey, right? Are Microsoft or Apple, they’re building APIs and STKs.

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 around that platform. I think apart from that word’s evolved over time going actually, if you think about what these platform companies have done with the platform is they’re really built kind of a long-term high value feedback cycle of work that people can plug into.

And I think what you end up doing every company at some point is you’ve got these things that provide kind of outsized long-term benefit to you. So, for the way I’m using it and the way that when I say when 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 the, 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, okay, what do I have any of those? What are they? And then how do I build those?

So, I think for me definition, let’s talk about what they actually are is the infrastructures that you run your stuff on. And that’s what typically people go, “Yeah, that’s what platform is.” And I’m like, “No, there’s a lot more.” And there’s 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 test, etc.

And I think, I mean you guys are experts at providing visibility to that, but that’s part of your platform. And why is that platform work? Well, it provides outsize long-term advantages and then leverage for you. If you can make our develop developers go faster, that’s great, but that’s part of your platform. The system architecture and security, where does the code go and why?

That’s part of your platform decisions, the key technology choices across all those layers, your UI framework, your server, etc. And then your core abstractions, and this is really, really key, your domain model. So, if you’re in commerce and you’re like we have an order and we have a fulfillment, and how you model your domain is… So, it’s kind of like where’s your code go?

Do we have one service or many? And then how do you actually model your database structure and your business model? That’s part of your platform because it powers a lot of things. It’s probably going to make the difference of your medium to longer term velocity. And as I’ll get into a bit later, it deserves a roadmap as much as anything else does and it’s key.

And then obviously all your APIs and STKs. So, 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 chat we’re going to have, that’s what I consider platform.

Abi: 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 the 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 under platform work that focuses on organizational leverage? So, specifically is agile coaching a type of platform work or is it not?

Jean-Michel: Interesting question, I’m not a huge fan of whatever you call it, agile coaches, etc. I think your question is your organizational playbook of how you get work done part of your platform. Absolutely. I almost call that your company operating system. You’re going to decide do we have meetings? How do you organize?

There’s a company operating system that in the article I wrote, I don’t really include in that but I think it’s a really good point. It does provide long term leverage. The way you decide to work together as a team, ignoring agile coaches and whatever methodologies 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 that platform work is actually very customer-centric. And I think this is maybe left out of the conversation with web platform and maybe we can get into some of the caveats about 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.

So, if you don’t do those things that we talked about really well. Your performance sucks, you have no scalability, you probably have really low extensibility, 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 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 work in this area.

Abi: Well that actually got ahead to the next question. And this one came from the audience which was when non-functional aspects of platform product work such as reliability, performance and stability, fall under platform work. And it sounds like you basically just answered that question. But absolutely. Reliance, performance stability are very customer-centric and fall under and also provide leverage to the business.

Jean-Michel: And there’s things you can’t. You can’t kind of growth hack performance or scalability. Listen, there’s maybe people a lot more smarter than I’ve been and the teams I’ve worked 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, like 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, we had… People did everything.

I remember in my early career, I graduated in 95 and you just built shit. There was no product management design, you just built shit. And we’re all on a team and you’ve got to write the docs and write the code and get people and talk to your community in Bugzilla. And I worked in open source for a long time and we did everything. We have to do planning and sort of community what we’re building and we just do everything.

And now you’ve got all these roles and I think developers are stepped back and 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 go show progress of what screens are being used or what are you getting engagement in 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 scalability. What I ask team is just do you know if you’re getting better or worse year over 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 easy to know when to not invest in it because maybe it’s fine. But I think those are things that have gotten in the way I think of us investing in platform work, talking about it and treating it as one of the most important product features that you have.

Investing 50% of R&D spend in platform work

Abi: Yeah, I agree. This is such an important point and something 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 sort of 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?

Jean-Michel: And you didn’t ask this yet, but maybe I’m going to ask myself a question and answer it because I think it’s really, which is why the hell do I advocate 50% platform work? I think that was a bit of the 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?”

You’re like, “Cool, let’s talk about this.” So, it’s 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. And so I think that number for me was a trip wire 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 around core abstractions, technology decisions, etc. scale work, then maybe it’s fine. Maybe you have a year where you’ve done too much and you’re swinging a lot. But usually I rarely 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’re actually, they 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 the 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 than any product manager in your company around what to do platform work. Because one, it is 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 a early career, we had to do everything because we had no role defined in this industry to there’s product managers and there’s designers and then I’ll just go in. I did that. I personally was like, I’ll just go build a feature roadmap.

And I that’s great and then you’re like holy shit, there’s all this stuff that… Who was advocating for this? And oh maybe that was me again. And then you get back to it. So, I gone through that yin and yang of taking a strong leadership role at that work. And I strongly believe that someone has to do this full-time job in your work.

How Jean-Michel arrived at 50%

Abi: Yeah, I agree. And we’re going to get 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 dare say it almost put the burden of proof on executives to why not 50%, not why 50%? So, this is a question I get a lot and a lot of organizations are definitely wrestling with.

And 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. And we’ve talked 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 and 50%, how are you arriving at this number?

Jean-Michel: 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 n features. I see the realities of what’s under the covers.

I try and make bets that are short term, medium long term. And then I go, “Oh we should be updating our order model for this.” And I’m like, “Oh, there’s a list this of things that we could do.” If we’re really going to do these kinds of feature for, we’re long term, there’s a list. 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 because they’re all features. So, it’s like a platform list and your growth list. And I’m like, “Show them me both lists.” And people have that in their heads and you go talk to developers in the platform, they’re like, "Yeah we have 133 attributes on our order model.

And every time we have to implement a feature, we can’t do this. Or we made an assumption about them being mutable but they should really be immutable because that means we can do this." All that’s there organizationally. And I think it’s almost like we’ve created companies where that conversation’s not actually happening. It’s almost like, oh that’s just engineering stuff or just change it or whatever.

But I’m like, that’s some of the most important decisions you’re going to make are in those conversations about how it’s built. So, I think the other thing about 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, they have the execs and whatever.

And they’re going to go, “We want to go tackle these things, these are our objectives.” And they’re like, “I don’t care 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 are you going to win? It’s like we have to go over this bridge and we have to do this and that. That’s the how. And I think how then is how are we’re going to implement all these things is extremely strategic conversation. And I think execs and whatever, leadership has to vet, understand and support the how.

And unfortunately, a lot of platform work is 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 only, I don’t know, I game sometimes I’m on Twitch, it’s great. In their origin story you’d think what’s strategic about Twitch?

With them, do they build a video streaming server themselves or not? That’s kind of like the how. It doesn’t matter, maybe we can change that. It’s like okay, 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 mean 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. That’s a leverage decision. So, I’m like, in your company, are you making any of those kinds of decisions of that I’d say get ignored in a lot of companies as being an implementation detail. But platforming it long-term leverage things, the how matters a lot.

Those conversations are 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 unwind it. That’s a story of my entire life, like cookie cutter with every organization I’m working with right now.

Experiences with different levels of investment in platform work

Abi: That’s really funny. And that was a really interesting story about Twitch and a really interesting way to think about platform of what platform decisions or even conversations. You talked about how these conversations don’t even happen at a lot of organizations. What conversations and decisions are you 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?

Jean-Michel: 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 id blah blah blah for quite a while. I think we got that number pretty well. I think a lot of things we didn’t do well but I think we bounced that really well because we kind of were a platform in some way. Our product was a platform.

So, I think we had to a bit more. I think at Atlassian, they’re pretty early days, startupy trying to launch three, four new products, doing some m and a. I think I made a mistake. I think they adjusted. After at Shopify, I think I came in gun and blazing, tried to make it 50%. And I think you can see some of the… I think you’d say, I wish we could have done more but we scaled crazy.

And that was work from 2014. That was not us… There’s a lot of stuff we did, I think a CEO to was actually a bit really good advocate of that as well. So, it was good to… 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 platform’s not there, 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 coach my team. Because people would come and complain, developers complain about stuff all something like this and that. I’m like, well listen. I was like if you want to do this kind of work, you need roadmap. They’re like, what do you mean?

Well I think great platform roadmaps 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 it’ll enable this and this. And I think some engineers are worried going, well I don’t know. It’s like well caught 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 this soft tofu scale of this soft, we think we’ll be able to do this. 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 have to add subscriptions to Shopify. And subscriptions is a thing means that your order after it’s been generated has to become mutable now. Which is kind of when you take a core data wall that was immutable and you make it mutable, there’s a lot of side effects to doing that. I think we were scared shitless a bit about 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. Actually put it in very customer centered features going, we’re going to make orders mutable in this way.

We’re going to… Here’s about backwards and compatibility, but here’s five years of feature roadmap. I was like, do you guys want these things? Do you want pre-orders and this? And they’re like, oh yeah, everyone wants that. Cool. This works. Going to make that possible. So, at that point there’s no… You’re not even selling this thing, you’re going, 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 I mean maybe it was at the end of my career or not. I’m not that old, but at 20 years later 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 sound a bit like it should be obvious but it’s hard and that’s why I want to talk about it.

Abi: 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 number and this is actually a leader at Qualtrics. And it was a couple questions but I don’t know the full context.

They’re probably having internal conversations around allocation to platform work versus other work. And one of their questions was the 50% on platform work, is this about keeping the lights on or also the proactive investments in reliability, scalability, platform capabilities? And then I think we can sort of answer that question. It sounds like it’s all of the above.

Jean-Michel: And I think a mistake 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 uses that as their pitch for platform, that’s why they’re not getting any support. It can’t be. But I think you have to always champion those non-functional features that might get lost in the mix like, scalability, etc.

But also you have to, a big part of that roadmap is enabling of things. It has to be enabling of thing. Twitch didn’t do this video server because they’re like, we want streaming to be cheaper so we can do more of it. Do we want more of it? Yes, cool. 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.

Maybe it’s like we have to get a new product out there, it’s a product market fit thing we’re doing… We’re just going to get it. Cool. I’m an extreme pragmatist as well, but I’m saying steady site 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%.

Funding “keep the lights on” work

Abi: That makes sense. Want to double click on that technical hygiene piece. Because the second part of this question was 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, the maintenance and uptime on-call patching? What’s a good baseline percentage for that type of work?

Jean-Michel:

I’d say typically it’d be 10 to 20%. That’s what people usually see a platform. We’re spending 10% on platform. You’re just keeping the lights on of like, gardening, you’re weeding, you’re gardening. You’re not planting new things, you’re planting new trees or preparing for the future. You’re just gardening. And 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 crans script that would RM minus RF of my source directory in my laptop every Monday. And I’d go get my dev environment set up again and go, “Can I take a bug off to Q and get it fixed in production?” And if I couldn’t then I know okay we’ve, we’ve got some issues. Some of that I think culturally 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%. It depends what’s in that bucket. I’d say developer experience, CICD, tooling, infrastructure companies are going to decide how much self-served you have in your company around people creating things and deploying and managing it. And it’s probably 10 to 20.

And also 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. 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 part of the 20%. There’s 30% I’d say are actually way more feature-oriented platform work.

Whether the allocation changes at different company stages

Abi: Yeah, well I love that answer and I really love the gardening analogy. Are you just putting out weeds or you planting noose spruce trees that are going to grow into 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 at a lot of these sort of high soaring companies.

But most of the companies out 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 size of a company?

Jean-Michel: I think it applies to a one-person company or a 10,000-person company equally. Again, just going back to 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 I see a lot of problems in core domain models that don’t get updated.

People piggyback. There’s a healthcare company you’re working with and they’re like billing for healthcare is complicated and they have five billing models because they want to go fast short term and now, they’re like three years of unwinding. And at some point, I think every year just go hey we’re doing this three times and we do this way. And how hey we’re going to go from Canada to the US. We’re going to have to support all the states.

So, that work could have happened in year one of their existence. And I think they pushed it off a lot. And I think the Twitch example’s another really good one of that kind of work, having long-term leverage or not. Is there a lean startup world of just throw it all together and you’re going to have to rewrite it anyway?

Maybe the six months, I don’t know, let’s throw it at a wall and see if anyone will likes it. Maybe there is. And I think you do have to get used to rewriting things. Which means that platform work’s not about getting perfection, it’s about the habits of yearning for perfection but not getting it. So, I think that has to start on day one of your company.

Abi: 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’ve touched on this a couple of times.

Jean-Michel: I’ve changed my mind on this a lot. So, it comes out, but I get asked this question a lot. And in the early day, probably two years ago I would’ve said, “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. And let me give you a super concrete example.

So, I’m doing this thing and I want to… You have two, three customers, you think it’s going to 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 the onboarding of this and we can’t deploy new service and we like… That’s going to kill your company to not say yes to those companies coming in.

But that was kind of scalability work and you kind of didn’t need it. And so someone at least… And maybe it’s a good problem to have and it’s good that it broke and you’ll fix it. But I just see more and more of that word, the strategic house, that at least that conversation has to happen. And that’s why I’ve changed my mind. I used to say, yeah, ignore this for a while for a big company. And I’ve changed my mind based on just working with more smaller companies in the last two years.

Not just change my mind like convince me. I’m almost like 99.9% sure that it’s applicable.

Why platform work is consistently underinvested in

Abi: 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 developers and engineering leaders, we just suck at communicating about these things? Is there just overall lack of awareness? Are leaders just too shortsighted? Why is this such a consistent problem?

Jean-Michel: Man, all of the above. I think culturally 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, all these… And I think there’s a lot of product managers out there that are fantastic and they run a lot of the roadmaps. And I think a lot of the 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… All the things we talked, it feels like I’m repeating. No shared understanding what platform is so you don’t know what to put in a bucket. There’s a power dynamic difference in companies about who decide what work has to happen. And I think engineers are shitty at communicating long-term…

There’s a lot of engineers who… We have a lot of burden which we have to make it work. And I think with platform work you have to make it work and you have to know what it’s going to do and you have to plan. There’s a lot of that. So, I think assuming that that’s a part-time job to do that, it’s a lot of work to be a really good product owner of the platform.

And I think you underinvested, you don’t sell it as well and your story’s not good and you’re behind. So, I think all that combined is probably one of the reasons why it’s not investment as much as it should.

Why having a platform team could be an anti-pattern

Abi: 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 it’s consistently underinvested in. I want to shift the conversation and talking about how can developers and leaders actually actualize this or turn this into reality in their organizations. And one approach that’s been gaining 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.

Jean-Michel: 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 we agree on the, not to agree, but if you take my current definition and there could be tweaks too. But the definition of the core data models being in there, some technology decisions etc. I think there’s a platform component of every team.

If you take every team that’s building, you’ve got three teams that build different parts of your product. They all have a platform component in what they do. And I think taking that view of every team has 50% platform, 40% features and 10% experiments, then you can’t really reorg and go, I’ve got a platform team. It’s actually dangerous to do that.

Now you can have a team that does developer productivity and maybe your specialist on infrastructure specialist on your data infrastructure. But I think saying that team owns your entire platform roadmap is an anti-pattern. So, I think the concept of having a platform roadmap has to transcend your org structure. And I think you need a leader, you have to go, you’re the PM of the platform, what should we work on?

And it should be with the view and the lens of looking at things across the company of what’s going to provide leverage. So, 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 platform’s so misunderstood. The minute you’re going to call the platform you go, what is that again?

It’s like actually call maybe a developer accelerated team and a hosting team infrastructure, whatever data pipelines team. We’ve got a build and… I find it is useful over time to extract some things that you’re doing across the company and go, actually we’re going to do it this way. And at Shopify we had a rails team, we did have a rails team.

And they’re like, but everyone’s doing rails at Shopify. Yeah, of course we all are. But there’s a team who was super involved in the open-source community working on the next version of rail, adopting it for everyone and helping it. But their job was always to be a bit of an accelerator for all the other teams. Because when we adopted a new rails version, every team had to do a bit of work. But this team, these were the experts doing it, enabling everyone else to do it but they didn’t do it for everyone else.

Same route CICD and testing. I mean you probably know all this stuff. 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.

Someone has to figure it out and share to the org. That’s cool. But again that’s 10 to 20% of your platform roadmap. There’s a lot more. That’s what I see typically being ignored.

Abi: Yeah, it’s funny when we were chatting earlier and you kind of blurted that you thought platform teams were an anti-pattern initially, I was like what? But now that I think I agree and in fact we’ve been talk, you just kind of concluded we’ve been talking about how platform work is consistently underinvested in. 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 platform work because we have this team called platform team.

Jean-Michel: Oh that’s a good point. Absolutely, yes. It’s a get out of jail card of like oh we have a team call platform. But you haven’t decided. Again, probably the wrong scope and the wrong mandate for that team.

How to advocate for platform work to leaders

Abi: Yeah. 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 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 what types of signals or metrics or narrative, how do they go and advocate for this type of work to leaders?

Jean-Michel: I think the first thing that any engineer can do is just… Platform work is triangulating things like a lot of signal, hey we’re doing this kind of thing a lot or I’m seeing these features come down the pipeline. And I know that they’re all going to be doing this kind of thing. And realizing it’s valuable to explain what you see to others. Even as CTO at Shopify at some point I would see things other people didn’t see.

And what I do, I write a doc, I’d go, here’s what I see. It looks like we have a couple options here where we’re going to put this code. It’s going to go here, we can hack it here, there. I’d write these kind of mini brainstorm proposals for platform because I didn’t also didn’t trust my instincts all the time. This is hard stuff. I got to write this down and I maybe take ownership of can I explain it to myself?

Can I see value of this? I prototype it a bit, write some stuff down and go, platform work is expensive so I want to make sure that we understand what we understand here. So, I was a big fan of prototyping. Going hey, we think there’s a way we can do this. It’s not the way we thought is it’s a bit harder, it’s a bit…

Listen, platform work’s not done in a week. It’s going to do this thing, we’re factoring, we’re going to get ready for this. So, I think a prototype and being able to explain yourself in the context of again leverage. Why do you think this is worse? And what’s leveraging to me take ownership of that I think is, that’s kind of like you do that as a developer, I did it at CTO.

It’s the same thing. You just have different signals and doing that. And sometimes it takes a while. You almost have to be more prepared because these are longer conversations and more investments. So, people are going to be pickier about 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 unlike, I don’t know do three but get a prototype together.

I’m just big fan of prototypes and a bit of a writeup. Because I think the writeup’s useful because I think you want to look at different options with platform work. There’s usually going to be more than one path and actually showing that you see that. You’re not just building it the way you’re comfortable with but you’re really looking at the long term. It means there’s going to be more than one option.

So, I think that’s my biggest tip of people just get in the habit of having those conversations prototypes, writeups. And then from that, that roadmap’s going to develop. And as an organization you’re getting a lot of signal of… I used to get a lot of, as a CTO, my entire job was getting these signals from the teams going, “Hey you’ve seen this job Michel, we’re doing this a lot more. And you said to maybe highlight and write this up.”

And I’m like absolutely cool. And it wasn’t a we’re going to work on it carte blanche. I was extremely cynical. Most of our platform work’s going to be a cluster, but some of it’s going to be 10 x we might as well find… We have to find that and there’s no magic person who’s got it all in their head but we have to have those conversations.

So, I think that’s my biggest tip is prototype. Do the write-ups, make sure it’s visible. And make sure you take ownership of seeing and understanding the leverage that’s going to provide and share that.

What it looks like to over-invest in platform work

Abi: That’s great advice. And one question that came from the audience is kind of the opposite end of everything else that we’ve been talking about which is have you seen over-investment in platform work. And how do you know when a platform team, I know that’s an anti-pattern, but a platform team or platform investment or initiative is a failure. What are signal those of that and how do you kind of wind that down?

Jean-Michel: 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 you get the more platform work you do because you’re like man platform works great. I can get all this leverage out of it. 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 duplication police who go around going, oh we’re duplicating that once we got to go and put that into a shared library. Or I was like, you duplicate until duplication’s not the problem. Duplication’s way better than having this wrong abstraction to choose all over the place. You’ve got a duplicate until you actually see things properly.

So, there’s duplication police that go around and get really upset if there’s any duplication. That’s really, really dangerous because again, platform’s hard and 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 wasn’t the right time because you didn’t even know what…

The maturity curve of a technology also means that it’s not, we’re not ready to remove duplication because we don’t know where it’s going to go. Whether it be front end development. Six years ago we didn’t know rack… I’d say front end development six years ago, some people might say two years ago. But we didn’t have enough patterns and I was very hesitant about making a bet on the one thing.

And I remember at Shopify we actually did have a lot of pressure around just coming. And I was like, it felt we weren’t ready and we had a natural, 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 waste in of maybe platform astronauts. I always like buzzwords. So, it’s duplication police and platform astronauts who are building a platform without context. 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 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. So, 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 going to ship subscriptions. Cool. Now over time that team I think almost shifts into a bit more horizontal.

But we need that use case. We have to have deliver customer value. And it’s not because we want money and we need customer, but we have no idea… Platform works so hard that we need some anchors to know for even on the right track. And that anchor has to be valued, which is customer value or scalability has to be like, yeah, we can now support a million orders a second.

There has to be one of those anchors. And I see big companies going away. And they see the anchors but I’d say they’re on paper and they’re astronautty 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 platform and feature teams together when they’re trying to build a new platform thing so you can ship DUI the feature at the same time.

And I think in a lot of ways platform has to be extracted from features over time. So, 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. But I’m saying the 50% because I think people go off of that. But I think the bigger you get there can be more waste and you can do a lot more. And as a startup you can do too much platform.

I’ve met companies where there’s 10 people, they’ve got 20 microservices and they’ve got the biggest, best deployment I’ve ever seen. I’m like, you just wasted time on things that don’t matter.

How to decide which initiatives to invest in

Abi: 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, a pre-product market fit startup. To your point, if they have these beautiful microservices probably wasting their time. In fact, there’s probably the wrong platform work altogether because it probably slowed them down actually.

It didn’t even accelerate them. They’re not getting any sort of for 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 advocate for platform work, what platform work is. Within an organization where there’s probably a lot of competing platform initiative ideas, if you have $100, how do you decide which initiatives to invest in?

And there’s a followup to this which is this person said as they understand Shopify has less and less PMs in the platform space. So, are they even doing it organizationally, where’s the muscle, what’s the process for even doing this? And you kind of alluded to it, you said as a CTL you would just get RFCs all the time. But what’s the right process?

Jean-Michel: That’s a good question. I’m a bit of a hand-to-hand combat kind of person of just making sure you’re having these conversations and then you’ll 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 going to see and you can actually have the debate. 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. So, I’m like if you even have the list and you’re actually debating it, then you’re fine, whatever. 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. Depending on the people you have and their experience and their skill, etc. I think you’re going to get different lists based on the people you have.

And I think at Shopify maybe we swung the pendulum a bit much to very feature-oriented product managers. Because I mean it was very domain specific. The higher developers who knew commerce were… It was a good thing to do, but I think we, you’ll see some of the… We actually did a bit of a, I guess refresh education. We brought a lot of developers being product managers, the product manager of our online store.

Vanessa was phenomenal developer as well, spent 10, 15 years as a PM. But I think she was now pulling that… She knew and. We had to remind her once in a while. But honestly, she was phenomenal. So, I think we’d had a bit of a cultural refresh of a balance of the kinds of PMs we needed across the org and then championing making…

And as I said, every senior engineering lead is a product manager for their platform working in their area. I just told people, your dev manager, I’m like where’s your platform roadmap? Oh well I’ll talk to the PMs. No, what’s like… You need that. And 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 turn people into having that PM mindset which is about ownership, about 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 not super draft, everyone can do that. It’s within reach of everyone.

Abi: Yeah, well I love that quote, just every senior engineer or team lead is the product manager of platform work for that team.

Jean-Michel: There’s another podcast about what we expect of managers. I think we had maybe a pendulum shift of manager’s job as the shepherd to make sure the team’s doing good work but not responsible 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 I get from the team. And that’s why I like the word roadmap because they’re like, what do you mean roadmap?

We have one. And I was like, maybe we have two roadmaps and maybe you should be helping figure out what’s on it. And then there’s a conversation where you merge them. But you got to bring it to the table and you have to… If you’re not seeing what those things are and you’re not championing it, then I think as a manager, just making sure your team can ship the roadmap is a colossal failure.

So, I’d say that as a bit… 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 ruffle some feathers going on, what do you mean? And I was like, I just want to make sure the roadmap we have has all the input into it. Put it that way.

Abi: 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 in how do evaluate these different initiatives as CTO? Because this is the same way I think organizations could potentially approach it whoever’s making those decisions or having those discussions.

Jean-Michel: I think if you’re starting off trying to get back to 50% and you have to be pretty timid and humble in recognizing platform works hard. So, I try and… The last thing you want is to have five things going in parallel. So, I almost look at the list and going what’s easy platform work, medium easy platform and hard and pick one of each. Don’t pick two. Kind of start to get some velocity.

I know these things were hard and I know that we’re going to pivot and we’re going to have a… It’s going to take a while. So, I’m a huge fan of just doing things in series and less in parallel. And I think once you start prioritizing, I’d also try and look at timing of can we get the feature team 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. Just based on hoping not on pragmatism of just knowing there’s an ordering of thing that can make a two to three x difference in terms of that happening. So, I think you got to bring that lens to the kinds of work that’s happening. And then you do have to see also we’re going to be here for three years. So, we don’t have to get it all done now, you want to 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 the feature teams and 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 going to be a bit more people than you want on paper just because it’s a bit harder. I think those two things are really important.

And then knowing that that you’ve got to throttle it, putting something to next year’s a good decision to get that hard thing done. And I think I see a lot of people going, yeah, we’re going to invest 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 going to invest in platform work ever again because it took five years.

I’m like, no that’s because you thought you can do platform with 10% and you just went off and it took five years because you didn’t sequence, you didn’t invest in the proper way.

Abi: Well I think that’s a helpful response. Do things in series, pick some quick wins, smaller things in addition to some larger opportunities.

Jean-Michel: 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, you need those wins and you need…

So, it’s the ability to not just pick the things you want to work on, but as they get worked on that you’re nimble enough to readjust. Okay cool, we can leverage that thing now and let’s do that now. And you’re like, “Wow, that team’s working on this other feature.” I’d always be tempted to almost make sure we accelerate some of the platform work. Because I know that we’re going to get impatient and we’re going to get…

You got to create some culture and energy around these. So, it’s like being able to pivot, going actually when we 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, ah, wow. 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 kind of nurture it in the right way. And a lot of that is going to be by adapting and changing who’s on it. And a lot of these platform work is cross tech stacks as well. It’s how we need data, it’s pipeline, there’s some AI, there’s this.

So, that your ability to do that as it advances can make or break it. Again, platform work has a bad rep to begin with. That’s why people just want to invest 10%. So, it’s like if you can be a bit creative in how you shepherd it is extremely important as a leader.

Making build vs buy decisions in platform work

Abi: 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 someone asks, how do they, Shopify, decide what use cases they’ll build themselves and which ones they’ll lead for others to solve?

And it’s kind of a build verse buy question. But I’m curious how that kind of interlaces with platform work. Which is very closely intertwined with things like infrastructure, tooling, things like that. So, curious for your take on that.

Jean-Michel: So, there’s two angles to that question that are actually fascinating. So, the first one is when you’re building something with a platform mindset, usually you’re trying to get leverage, which means that you’re building something that someone’s going to build on you. So, the first discussion is kind of what’s in core and what isn’t? And I think that’s a…

We never figured it out, but I think that’s a really, really important conversation for platform teams. So, I think platforms can fail when they try and do everything. They’re like, we’re going to implement all the widgets and all that. No, you’re like, what’s the core primitives here that you’re okay with other people building on you, around you.

And for example, that’s a typical developer platform. What’s in the app versus what’s in the kernel? And this is been our internal thing around operating systems. 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. There’s a split there that makes sense depending on what you’re doing.

Your other question is, hey, platform works really expensive, can we just buy stuff off the shelf? Is there some of the 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 because it’s hard. I’m a big fan of leveraging platforms that, as an example, are open source.

Rails 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 the way I usually looked at platform work is if it’s non-domain specific infrastructure, I tend to want to take off the shelf. And off the shelf, it’s not some enterprise as open source.

I’m going to use some enterprise and we’re going to use tailwind. We’re not going to invent our own CSS styling thing or. So, if it’s non-domain specific and if it’s domain specific, then it’s our crown jewel. Absolutely. It has to be something that we’re going to build

What distinguishes a great platform leader

Abi: Really useful advice and useful purchase. And I like that domain specific distinction in thinking about 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 overseeing 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-pattern. So, what distinguishes a great platform leader from an okay one? And what are common areas in which you see people trying to lead platform work short?

Jean-Michel: 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 expert who really, really yearns and extremely curious around the domain you’re in and the product and has to be number one. I think number two is someone who communicates really well, who can actually explain, who knows I explain value I think and without sugarcoating. A pragmatist value communicator, who can go…

So, that’s number two. And then 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. And how do you do that? Is you have to be gathering a huge amount of information internally about what’s going on. This is where basically on information absorption from out on the outside, on the inside.

And you’re triangulating all this and you’re trying to articulate and make some bets, some high leverage. So, I think doing those things. I think the platform leaders that have failed is if 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, then the ideas aren’t there. But they’re cheerleaders of it without any of the meat.

And then there’s the opposite, which is your lead architect who knows all the faults and all the shit. And they get overwhelmed and are 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. So, I think that mix 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’d pull some staff developers out and go, “Hey, come hang out with me for six months. Come to all my meetings and go look across the stacks.” Go look at what… Get more visibility into things. I think that helps you kind of triangulate where you’re going to get the most leverage and why and help teams not have fake ceilings on what their ambition is.

Abi: Well, really appreciate these insights and, Jean-Michel, really enjoyed this conversation. I think it’s been really entertaining, really viable, 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.

Jean-Michel: It was my pleasure. My favorite topic. Thanks for having me.

‍