Platform Engineering

by Camille Fournier

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

platforms constrain the amount of glue needed by implementing the concepts of abstraction and encapsulation and creating interfaces that protect users from underlying complexity (including the complexity of an implementation that needs to change).

A product approach without curation leads to great customer responsiveness but no coherent strategy, turning your teams into service centers. And curation imposed without a product mindset creates rigid offerings for application teams that may not meet their actual needs.

if you don’t need to write software yet, you may not be ready to embark on “platform engineering.” If a wiki with pointers to the approved cloud provider offerings and instructions on how to onboard is a sufficient platform investment for your engineering team today, that’s great! It’s not what we consider “platform engineering,”

have you made their productivity higher, or have you just made things easier for the platform team to manage?

To scalably support a large set of customers, self-service is a key part of a platform offering. If every new customer onboarding requires the platform team to do manual work, or worse, requires multiple parts of the team to do manual and coordinated work, you will lose your leverage.

Platform engineering teams must operate the full platform, not just the software developed in-house

Without opinions about what’s in scope, you’ll fail to manage the overall complexity, and without a customer-centric product approach, you’ll probably build the wrong systems. 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.

You burn goodwill with costly migrations

your reasoning for creating a new platform offering needs to be about leverage rather than just efficiency.

Do you really have to have only one caching solution? Does every team need to use the same standardized web framework? Make sure a standard platform will bring leverage—outsized value that is hard to replicate.

if this system requires a large team to build and maintain, and it can support multiple teams without significant configuration or logic changes for each team, it’s a good candidate for solving once. But if it has a small cost to build and maintain, and especially if each application wants to configure or extend its logic, it’s probably not a great candidate for centralizing.

when you are creating your platform engineering team, be careful about hiring senior engineers and engineering managers from very big tech companies.

Your early senior engineers and engineering managers need to set the tone for communicating with customers with product focus that the team needs to keep as it grows. If you bring in a product manager too soon, this will be offloaded to them, and your engineers will never have firsthand customer empathy.

naming your billing platform “Glengarry” instead of “Billing Platform” does not help your discoverability problem.

Start with a name that makes sense. Write documentation that is searchable on the company intranet. Send out email announcements, run learning sessions, or speak at company meetings to drive knowledge and awareness of your platform. It doesn’t matter how you decide to do it; it just matters that you do it. Without a plan for getting the word out, you’re likely to get lost in the shuffle.

The ticket system black hole is a great way to make your customers feel more like a burden than a focus.

Your senior folks will not build the kinds of humane products that you need if they are incapable of interacting with the users in a polite and helpful way, no matter how brilliant they might seem.

If your migrations are so painful that both your team and your customer teams need project managers to understand where all the dependencies lie and track what’s happening, you are not taking ownership of the user experience of your software.

There’s no way to shortcut the product mindset transition for your engineering team. As we explained earlier, you can’t just add a product manager or a customer advisory board meeting once a quarter and call it a day.

Product management is not about making the most important person happy. Product management is about figuring out what the company actually needs, based on a deep understanding of current circumstances and future demands, and shaping the product features and offerings to meet those needs effectively, in measurable ways.

A product culture means that everyone has some responsibility for engaging with users to make sure that the best products are being built.

A good platform takes on and gets rid of common tasks for many customers, rather than providing bespoke implementations for a few.

Platform engineering teams are usually not on the cutting edge of innovation, but rather play the role of settlers and town planners, taking ideas that have been successfully pioneered by smaller groups and expanding them to broad usefulness

How much migration overhead time do you impose? (Cost of using the platform) How much time or money are you saving platform users? (Benefit of adopting the platform) What percentage of the potential user base is voluntarily adopting this platform? (Customer demand) What’s the CSAT score for the platform? (Customer opinion about the platform)

A strategy requires an impact theory, which means a hypothesis about cause-and-effect relationships.

if your change is anything less than a must-have, you are likely to experience slow adoption.

both engineers and product managers mistake novelty as the most important offering their platforms can provide, and they forget that stability is often at least as important, if not more so.

If you ask your platform team leaders to spend time on things that don’t have any bearing on their situation, you are making them spend less time on things that would have an actual impact on the platform operations.

start small, partner with a few select customers, and make sure you’re building something that has broad utility for your customer base through incremental delivery.

balance investments in KTLO work and new features with system improvements to enhance operational efficiency, scalability, security,

Things to track include: Who is using the platform Which applications are using the platform, and which parts of it they are using Who owns those applications

A good platform team makes the experience of migration as painless as possible for their customers through careful planning and automation. A bad platform team, on the other hand, exposes developers to a great deal of churn and pain with updates and migrations that require significant work and planning on the part of the engineering teams themselves.

one of the basic requirements for any team attempting to become a modern platform team: you must plan for and take on the bulk of the work for customer migrations if you want to claim this role.

If you can, have other platform teams go through the migration process as alpha testers. Using your own platforms during development is a useful, if incomplete, test of their suitability and usability. Once you’re ready, approach your advanced customers who may want to be early adopters to get access to new features.

The first step is to tell customers about migrations as soon as you know that they are coming

Strategically planning migrations as part of other important work is usually more effective than annoying your customers with random unscheduled mandatory work that doesn’t seem to have any alignment with the other random unscheduled mandatory work coming at them.

platform teams should take care to avoid using the mandate approach too often, as this can create a culture in which it seems like the application engineers only exist to make the platform team’s projects happen, as opposed to serving the business.

Product management is about building the right things for your customers; stakeholder management is about convincing their leaders you made the right choices.

If you want to ensure that your team has enough cover to build the platforms they need to build without getting thrashed by other leadership or engineering teams, managing stakeholder relationships is a must.

Your platforms are aligned. Your platforms are trusted. Your platforms manage complexity. Your platforms are loved.

The risk of using adoption metrics when you are targeting a captive or nearly captive audience is forgetting to build what people want, and instead building what you think they should want and then forcing them to use it.

you dilute your leverage every time your platform team generates work for its customers.

We must design for the way people behave, not for how we would wish them to behave. Donald A. Norman, Living with Complexity

What is the problem to be solved? The rapid increase of complexity in technology is slowing application engineering teams down, and the business is getting less value per developer over time. Why do we need platform engineering? Because it takes a holistic approach to the problem of complexity, allowing a team of software and systems experts to reduce the drag of complexity on the application teams.

Platforms generate leverage by effectively managing complexity, not eliminating it; as a leader of a platform team you must become very comfortable addressing complexity in everything you do.

we expect most innovation to come from the application teams building what they need, not the platform team itself.

We know a head of platform product management who boils his key metrics down to “simpler, faster, cheaper, and your users love it.”