I recently listened to this podcast about Platform Engineering with Camille Fournier. Camille is the author of the acclaimed “The Manager’s Path,” which provides guidance for engineering leaders, and recently published a new book on Platform Engineering, drawing on her extensive experience in the field.

While most of what she said in the podcast resonated with me, there were a few points that I was either unsure of or disagreed with. I discussed some of them with a friend (with a business/product background) who had sent me the link initially. In discussing those points, I concluded that these are complex topics at the intersection of organizational design, developer experience, cognitive load, etc., requiring careful thought. I tend to think better when I write, so here is a post about the subject.

Disclaimer: I was part of a Platform Engineering team for 2 years in a previous job and also had the opportunity to build and lead one at my last gig. While this doesn’t make me an expert, it means I was “forced” to think about these things for a long while.

It all started with Team Topologies

Manuel Pais and Matthew Skelton published their influential “Team Topologies: Organizing Business and Technology Teams for Fast Flow” book in 2019. The focus of the book was how to structure organizations and teams to optimize software delivery (i.e., flow) and proposed four types of teams:

• Stream-Aligned Teams: Focused on a specific area of the business, often a customer-facing product or value stream, to deliver and evolve functionality independently. In other words, a superset of what traditionally had been called “Product Teams”.
• Enabling Teams: Teams of experts or mentors, helping other teams build their capabilities in specific technical or domain areas, often temporarily embedded within other teams. Think of your Architecture or DevOps teams (in organizations where they decentralize them).
• Complicated-Subsystem Teams: Specialized in managing complex or high-risk subsystems that require deep expertise. Another version is your heroic “legacy team” that deals with the oldest stuff and puts a nice API in front so you don’t have to deal with the horrors.
• Platform Teams: A grouping of other team types that provide a compelling internal product to accelerate delivery by stream-aligned teams.

This (and other sources) laid the groundwork for an increased interest in Platform Engineering, as Google Trends reflect.

What is Platform Engineering?

Many people think Platform Engineering is about building a platform—specifically, an internal developer platform, meaning that:

• It will only be offered as a product to company employees (hence internal).
• It will be used by the developers (and not other employees like product or marketing staff).

If we take this idea of the internal developer platform, we find some interesting definitions like this one from Evan Bottcher (emphasis mine):

“A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced coordination.”

I think the last sentences hit the nail on the head. We have created a whole new discipline (Platform Engineering), sent some of our (best) engineers to Platform Teams, and implicitly communicated that “building a platform” is why they are in the company.

This is incorrect. The platform isn’t a goal in itself; it’s just one of many ways to achieve the actual objective: to speed up product teams and their delivery rates. The business logic is simple: if you are not building features that bring revenue, you should build capabilities that speed up building those features.

Call Me Enabling Engineering (maybe)

Why does this all matter? Because if we clearly root the Platform Team into the idea that it exists to enable and support product/stream-aligned teams to deliver software, we clarify some of its principles:

• It has a clear set of customers: the company developers.
• It has a clear mission: help them deliver.
• It should apply a product mindset to this mission, prioritizing low-cost, high-impact actions.
• It succeeds when developers do and fails when they don’t.

In this context, building a complex self-serving API-driven platform is neither better nor worse than a collection of Wiki pages; the right answer will be based on the overall engineering team size, cost of automation, regulatory/compliance pressure, etc. In other words, we allow solutions that aren’t “building a platform” to be part of the menu because the platform isn’t the end, it is just one of the possible means.

Sam Newman (a pioneer of microservices) summarizes it in his post “Don’t call it a platform” as follows:

“Whenever you come across a team which is named after a specific tool or technology, you have a potential problem. The API Gateway Team. The Enterprise Service Bus Team. And yes, The Platform Team.”

Everything is ‘Shifting Left’

‘Shifting left‘ in software refers to the practice of moving tasks, such as testing and quality checks, earlier in the development process to identify issues sooner and reduce costs.

In the last couple of years, the Software Industry has shifted multiple areas of software development “to the left”. A few examples:

• Operations, which led to the creation of the DevOps movement and empowering development teams to deliver and maintain software in production without passing it off to an Operations team.
• Security, with the advent of DevSecOps, integrating security and secure software practices as early in the development cycle as possible.
• Data, with movements like the Data Mesh aiming to dismantle the “dedicated” Data Engineering team and bringing data awareness directly into the development teams
• Financials, most commonly called FinOps, with the aim to bring awareness of cost/benefit for software architecture choices and their implementation in production systems.

On one side, every time we “shift something left”, we are breaking down silos, which is great. On the other hand, every time we shift, we increase the development team’s cognitive overhead, with one more concern to deal with. There is also a vast corpus of knowledge associated with it.

This approach is unsustainable unless we find better, higher abstractions that, once again, free up developer time to focus on what brings revenue to the organisation, while all other non-functional concerns are handled by specialized teams or automated solutions.

This is the biggest reason for companies to invest in Platform Engineering in whatever forms it adopts in your organisation.

Your Billing Team isn’t a Platform Team

I want to finish with a contrarian view to something that Camille shared in the podcast. She mentioned a Billing Team as an example of a potential Platform Team.

I imagine this would be in the context of a wider engineering organization with multiple teams where some of them would require billing capabilities. In this context, instead of having each one of those teams build their own, custom billing capability, there should be a dedicated Billing Team building this capability (and exposing it via APIs, etc.) to all other teams.

There is no doubt that avoiding this repetition is crucial, so indeed, there should be a billing team. However, we would be mistaken if we took every piece of (internally) reusable software (billing, notifications, payments) and shoved it under the Platform Engineering umbrella.

There is a somewhat weak argument to be made here: if Platform Engineering is about accelerating delivery and taking away “billing responsibilities” from one or more teams would help them all deliver faster, isn’t that Platform Engineering? The reason why this argument is weak is because this approach is effectively how software is built efficiently, by avoiding duplication of efforts. It can be at the class level (reusing methods), service level (reusing libraries or other services), or organizational level (off-the-shelf products, SaaS APIs). None of these things fall under the Platform Engineering category if they are not purposefully designed to help engineers build and release software faster.

In the context of Team Topologies categorization, your Billing Team is either a value stream-aligned team or a complicated subsystem team, depending on the reasons why they have spun off as an independent team.