The case for investing 50% of R&D spend in platform engineering work

Platform engineering work is seriously under-resourced in many organizations, in part due to the lack of a universal definition of what platform engineering is and the difficulty in communicating the reasons for different investments to business stakeholders.

Jean-Michel Lemieux, former CTO of Shopify and VP of Engineering at Atlassian, has strong opinions on platform work—and equally strong strategies for elevating it. In this interview he explains how to advocate for serious investment in platform work to leverage long-term business impact.

How do you define platform work?

Jean-Michel: That definition has actually evolved over time—and a lack of shared understanding of what that means, means we probably talk about different things.

Historically, you think of platform companies like Microsoft or Apple that are building APIs and STKs. If you think about what these platform companies have done, they’ve built a long-term high-value feedback cycle of work that people can plug into. 

Every company, I’d say within a year of having a product, has some parts of platform work that could provide outsized long-term advantages. Recognizing what those things are versus the things that give you shorter-term leverage is really important. You work on those things in different ways.

The platform is more than the infrastructure that you run your stuff on. A lot more. The “lot more” is key, and includes everything that helps developers go faster:         the development environments, the tests, etc.

That includes your platform decisions, the technology choices across all those layers, your UI framework, your server, so on. Then your core abstractions, and—this is important—your domain model. Where does your code go? Do you have one service or many? 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.

At least in the context of our chat we’re having, that’s what I consider platform work.

I like that definition: any work that provides leverage to the organization, that you can distinguish from feature work providing direct dollars or direct value to customers. How can we think of platform work organizationally? Is it somehow distinct from feature work?

Jean-Michel: Your organizational playbook of how you get work done is part of your platform. I call that your company operating system. The way you decide to work together as a team gives you long-term leverage.

If you want to apply that to the definition that we just talked about, it’s also important to realize that platform work is actually very customer-centric. Look at your platform work as being some of the most important customer features that you have.

If your performance sucks and 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 have to look at platform work not as a black hole of tech debt. Some of your top customer features are going to be enabled sustainably by work in this area.

What’s your advice for getting buy-in for platform work from less technical stakeholders, who may not intuitively understand what platform work is or why it matters?

Jean-Michel: I advocate for 50% platform work. It’s a bit of a controversial point, but starting a conversation with that creates a bit of “what-the-hell.” Now a conversation has to happen because you just brought out a big number that scares the crap out of everyone. 

So, my biggest advice for folks is to spark the conversation. That 50% is a tool for engineering leaders to start conversations. You have to be an advocate for resources. You need a better plan than any product manager in your company, and you have to be better organized than anyone else.

I dare say it almost puts the burden of proof on executives to answer why not 50%, rather than on you to answer why 50%? But still, most teams are far off from that 50% of R&D spend focused on platform work. How do you arrive at this number?

Jean-Michel: Well, I picked that number partly because it sparks a conversation. But I also pick it because, through the last ten years of jobs that I’ve had, as an engineer, as an executive, I see the realities of what’s under the covers.

We’ve created companies where, organizationally, conversations aren’t actually happening. It’s almost like those long-term issues are dismissed as “just engineering stuff.” But some of the most important decisions you’re going to make as a company are about how the platform is built.

​​​​I think, conceptually, people see strategy as the why but not the how. Execs are going to go, “We want to go tackle these things, these are our objectives. I don’t care how it gets built, just get it built.” I have a very different philosophy. I think the origins of the word strategy are actually in the how.

How then becomes how are we going to implement all these things, and that is an extremely strategic conversation. Leadership has to vet, understand and support the how. But platform work gets ignored because people feel it’s in the weeds. I think some of those weeds are strategic.

I’ll give you a super interesting example. The most strategic decision that Twitch made was, do they build a video streaming server themselves or not? That was an extremely important platform decision in their first 18 months.

The leverage it provided meant that they could stream videos at 10x lower costs than anyone else. Which means they can do more of it. Twitch is alive today because of that one technical decision. They decided to do it and it changed everything. That’s a leverage decision.

In your company, are you making any of those kinds of decisions that get ignored as being an implementation detail, when the how matters a lot? That’s why companies are at 10% or 20% platform work. They call me and it takes us three years to unwind it. That’s the story with every organization I’m working with right now.

Does this 50% number in your mind apply mostly to large organizations? Does it apply to small organizations? What’s your take on how you think about how allocation pertains to stage and size of a company?

Jean-Michel: The rule of thumb to invest 50% of R&D into platform work applies to one-person companies and 10,000-person companies. Extremely strategic decisions for any company in the long term are encompassed in platform work. It has the bad rap of being tech debt or just infrastructure, but I see a lot of problems in core domain models that don’t get updated.

People piggyback. They want to go fast short-term and they end up with three years of unwinding. That work could have happened in year one of their existence, but companies push it off.

There’s a lean startup way of “just throw it all together, we’re going to have to rewrite it anyway. Throw it at a wall and see if anyone likes it.” 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. That has to start on day one of your company. 

You’ve seen a lot of organizations get blindsided later. Yet we all know on some level that this platform work is essential. So why do you think it is so consistently underinvested in? 

Jean-Michel: Culturally, we split. We have a lot of specialized roles in companies now. There’s a power dynamic difference between who decides what work gets done. There’s a lot of product managers out there that are fantastic, and they run a lot of the roadmaps. At a lot of companies, that’s just how it is.

And I think that gets in the way. I believe that people don’t have a shared understanding what platform is, so you don’t know what to put in a bucket. It’s a lot of work to be a really good product owner of the platform. It’s a part-time job. And I think engineers are shitty at communicating that long-term. They don’t sell it well, and their story’s not good, and they fall behind.

All that combined is probably one of the reasons why platform work is not an investment as much as it should be.

I want to ask about how developers and leaders can actualize fully supported platform work in their organizations. One approach gaining a lot of attention across the industry is this notion of a dedicated platform team. What are your thoughts on that?

Jean-Michel: Let’s ignore the org structure first. I think having a platform team could be an anti-pattern, because I think there’s a platform component of every team.

Every team that’s building parts of your product has a platform component in what they do. If every team has 50% platform, 40% features and 10% experiments, then you can’t really reorg and create a platform team. It’s actually dangerous to do that.

Now you can have a team that does developer productivity and maybe a specialist on data infrastructure. But saying that the platform team owns your entire platform roadmap is an anti-pattern. So the concept of having a platform roadmap has to transcend your org structure.

And you need a leader, a PM of the platform, who decides what to work on, with a view across the company of what’s going to provide leverage. Platform is so misunderstood, I’d call the other teams what they’re actually doing.

I find it is useful over time to extract some things that you’re doing across the company. At Shopify we had a Rails team. Everyone’s doing Rails at Shopify. But there was a team, super involved in the open-source community, working on the next version of Rail. Their job was always to be an accelerator for all the other teams. When we adopted a new Rails version, every team had to do a bit of work. But these were the experts enabling everyone else to do it, without doing it for everyone else. 

So don’t call that a platform team. Call them what they’re actually doing. Developer acceleration team, hosting team infrastructure, data pipelines team, whatever the mandate is for that team.