Platform Engineering

by Camille Fournier

Core to the value of platform engineering is the concept of leverage—meaning, the work of a few engineers on a platform team reduces the work of the greater organization. Platforms achieve leverage in two ways: making applications engineers more productive as they go about their jobs creating business value, and making the engineering organization more efficient by eliminating duplicate work across application engineering teams.

Platform engineering is 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.

Whether you’re offering an internal billing platform or an infrastructure-level compute platform, platform engineering creates leverage by using software logic developed in-house to abstract underlying systems. Put another way: without that abstraction, you are not creating platforms that manage complexity; you are vending infrastructure and passing all the complexity on to users.

However, as usage broadens in terms of users and use cases, you need to move from just developing features to also developing capabilities that make the system cheaper, safer, and easier to use. These include:

All of this means that user support is an important part of platform engineering, not just in terms of support practices but also in terms of creating a customer empathy culture across the entire team.

If you’re not doing any software engineering, you’re just doing operations with a high level of customer empathy. If you are building for only a small set of application teams, you’re not really building a scaled platform. And without operational maturity, no one will trust your offerings.

The best roadmaps are meaningless if delivering on them takes so much time that some customers decide they are better off standing up their own shadow platforms.

No matter what “globally right” optimization you achieve, for certain leaders of application teams, if you haven’t delivered exactly what their teams need, you’ve done a bad job.

So, you’ll have customers with rose-colored glasses remembering when they could open pull requests on the platform codebase at will, and insisting that any process is just “big company ideas” brought in by problematic newcomers or “process for process’s sake.” This can be well-intentioned, but in our experience, some of them will never stop complaining about change, even when their own management begs them to cool it.

when you are creating your platform engineering team, be careful about hiring senior engineers and engineering managers from very big tech companies. It’s tempting to hire such people because they have seen the next order of magnitude of scale. But while they may have experience with equivalent platforms at greater scale, they probably didn’t work on the equivalent to your platform at the scale you are at today.

You need to hire people who can work without strict guardrails or well-established processes and who won’t just spend their first year trying to re-create those processes.

Because of those technical details, it is important to keep integration platform teams aligned to the core platforms, even if they don’t sit under the same organization chart as the core/infrastructure platform team.

We understand that it’s hard to manage all the incoming requests for your teams, but keeping a close eye on how you provide support, what your response time is for questions, and how you triage incoming issues is critical to this transition.

If you only promote people who solve big technical problems, you’re going to have a hard time retaining the people who do the work to smooth out the usability edges, actively listen to the customer teams, and adjust their work priorities to fix the stuff that is causing the most pain.

But over time, the work produced should be better, as measured by customer surveys, adoption, migration timelines, and, eventually, engineering productivity.

They have a strong desire to understand the interaction of their code and the systems the code runs on top of. They’re not just interested in completing a feature for an end user, but think carefully about how their code fits into the ecosystem of software, hardware, and networking that it runs within, seeking a deeper understanding of the browser, the operating system, distributed systems, databases/storage, or whatever else is relevant.

We once witnessed a developer tools team made up of version control experts: instead of focusing on the lack of user-friendly tooling, they spent all their time refining interfaces to the version control system. Such work can be important, but when it isn’t the current problem, an overspecialized team can end up ignoring the bigger picture of what’s needed.

Because all of these roles are primarily about software development, we have found the sanest path is keeping all of them together on a single ladder. To make this work, you will need to specify level criteria in terms of outcomes achieved, as opposed to overly relying on methods used.

Handling difficult users while supporting a system you did not create takes maturity and empathy to hold your temper, build bridges, educate the user, and solve the problem. Not everyone can manage it.

After all, a business would never just make customers use its product, so why would we expect to take that approach with our internal systems?

Platform products also suffer from the problem that some engineers always think they could build something better, if only they had the time, so you likely have a customer segment that seems to never be satisfied no matter how hard you work.

Staying ahead of what they need and making it clear to them that it’s better to occasionally wait for your team to provide a solution than for them to rush ahead and build their own is part of the difficulty of working with this customer base.

The reality is that when the usability of the system really matters (which is the case in many, if not all, developer platforms), success requires you to identify the customers’ revealed preferences, meaning the way people actually use the systems and the tasks they perform, rather than the things they say they need or want.

Without a clear strategy for showing impact and value, you’ll end up overlooked and understaffed, and no amount of cool new technology will solve that problem.