Creating a Platform Engineering Team 🧱
A guest article by Camille Fournier.
Hey, Luca here! This is the first article we are publishing from our brand new guest author program, where some of the best engineering writers in the world contribute to Refactoring with original pieces.
Today’s article is from Camille Fournier, author of the timeless The Manager’s Path, CTO of Open Athena, and ex Managing Director at JPMorgan Chase.
Hello! I’m Camille, and I recently wrote a long book on Platform Engineering with my co-author Ian Nowland.
Today I’m going to walk through a few ideas from the book to introduce Platform Engineering, why we think it is important, and the foundations you’ll need when starting your own platform organization.
Here is the agenda:
🧱 What is Platform Engineering — a better approach to managing complexity.
🎽 Building the Right Team — a look at the diversity of skills needed by platform teams to execute well.
🎨 Establishing a Product Mindset — and how to view your platform as a product.
➡️ Getting Started — how to start a new platform organization.
📈 Setting Yourself Up Right — how to figure out if you are on the right track.
Let’s dive in!
🧱 What is Platform Engineering
As software teams grow increasingly complex, they face a critical challenge: the traditional solution of centralized infrastructure teams creates bureaucratic bottlenecks, while fully decentralized teams generate a swamp of integration code and custom tooling — what we call "glue".
This glue, which connects various cloud and open source components, accumulates over time and makes system-wide changes increasingly difficult. We saw this clearly during the 2021 Log4Shell vulnerability, when many companies struggled to coordinate security patches across their decentralized teams.
Despite various management strategies from Agile to DevOps to SRE, the industry still lacks an effective solution for managing the shared complexity of these underlying systems.
Enter Platform Engineering. In my most recent book, written with Ian Nowland, we define Platform Engineering as:
[…] the discipline of developing and operating platforms. The goal of this discipline is to manage overall system complexity in order to deliver leverage to the business. It does this by taking a curated product approach to developing platforms as software-based abstractions that serve a broad base of application developers, operating them as foundations of the business.
By building platforms — foundations of self-service APIs, tools, and services curated as an internal product offering — we can not only tackle the problem of growing complexity and the inefficiency of having infrastructure experts inside of every software team, but we can also make the experience of developing and delivering software better for engineers company-wide.
I’ve seen an established platform engineering team handle Log4Shell with ease: a few experts to fix the issue, track down some straggling legacy gaps, and ensure we had completed the rollout, and that was that.
Just as adopting DevOps, SRE, or Agile takes organizational change, creating a successful platform engineering team is more than just naming some existing team “platform” and calling it a day. There are two critical foundations that can’t be skipped:
🎽 Building the right team
🎨 Establishing a strong product mindset
Let’s look at both:
🎽 Building the Right Engineering Team
One of the tricky aspects of platform engineering is the diversity of skills needed by the team in order to execute well.
The platform mindset is a blend of systems operations, software engineering, and product focus. A team that draws from only one of these disciplines will struggle either to build the software that is needed or to operate it well.
It is not enough to just operate systems well or manage costs effectively. In the book we call out some of the downsides to a team that is overly operations-focused:
The code this team actively develops is mostly automation, templating, and one-off tools. They aren’t doing much to build better platform abstractions to manage complexity, or working on a better architecture to solve operational problems for good.
Faced with the flaws of a system they can’t change, they reach for rules and processes, often cataloged in meticulous wikis. Of course, users constantly run afoul of these rules, to the eternal frustration of both sides. To make any progress, the team management heavily leverages project managers, harassing customers’ engineers to do one-off work that the platform team is incapable of streamlining.
Platform engineering needs software engineering and software engineers in order to be successful. But that doesn’t mean you want only software engineers.
Software engineers are great at building new things and thinking big about what can come next, but they have their own downsides: