Platform engineering: How to optimize for a product

Deciding to build an internal engineering platform is, in large part, a response to the challenges and shortcomings of your enterprise’s current setup. Your current setup results from your current organizational structures, how decisions are made, and the overall engineering culture. 

As a platform engineer, how do you know which aspects of your organizational structures contribute to engineering and product quality and which detract? There isn’t an easy answer. However, after building engineering platforms in dozens of national and multinational enterprises, three key practices have repeatedly been demonstrated as leading indicators. 

• Is the entire end-to-end process for building, delivering, and operating software being assessed and engineered for quality and success against the product strategy? 
• Are all features or capabilities of the product delivered as a service interface first? 
• Are commitments to architectural and product experience decisions made based on results of actual implementations and observations of customer usage?

Chart depicts all the activities, from ideation to operations, and assess engineering quality and impacts from organization or architectural decisions. This Developer Activity model is inspired by Yrjö Engeström’s human activity model.

The developer activity model shown above provides an effective means of determining the engineering platform’s actual impact and, therefore, the scope of the assessment for end-to-end engineering effectiveness. The goal is to fully empower independent, domain-focused development teams. 

These teams will come up with and try out ideas specific to their domain. They’ll build and test software to create measurable experiences and value. Then, they’ll release the software to their customers and manage it, ensuring quality user experiences while keeping an eye on the results. 

• Are customers using the product as expected?
• Is it delivering the intended value? 
• Is it resilient and performant? 

This range of activities outlines what the development teams need to do. They must handle these tasks efficiently and with minimal delays, focusing on actions that directly support these goals. This entire set of activities defines what the teams need to be enabled to do. They must excel at these tasks and minimize time spent on anything not optimized for achieving these goals.

Regardless of how much the engineering platform handles at any given time, quality and results should be measured against this entire scope. In other words, design quality should be evaluated from the start, considering the whole workflow. 

Historically, IT organizations have been structured around functional tasks. When optimizations happen, they occur within these functional silos, each with its own measures of success, budgets, management values, and working methods. 

What might seem like an optimization within a silo can actually increase the overall time and reduce quality when you look at the development process as a whole. This means there must be a willingness to change organizational structures, decision-making methods, engineering culture, and anything else needed to support effective product delivery. 

If you don’t change the organization, then you can’t expect to get different results. 

Service interface first

All features of an engineering platform should be designed, built, and delivered as service interfaces (APIs) first. You’ll include additional user touchpoints, like CLIs and UIs, as part of the overall user experience. But no matter the type or number of touchpoints, the core capability is accessed through an API.

This architectural choice is the key to ensuring product flexibility, quality, and longevity. 

Base architecture and technology commitments within the platform on real-life experimentation

Commitment here means the final decision to build and release a production feature or capability. These commitments should only be made after experimenting with the architecture or technology options in a real-world setting. 

This doesn’t always have to mean live production, although that often gives the best results. It can also involve working proofs of concept where platform customers test things out with their actual use cases. And in every case, include observations of how real customers use the feature. 

Customers routinely use features in ways we cannot anticipate or overestimate the importance of a feature before it is available. 

However logical this may sound, in practice you simply cannot anticipate future requirements — bloated, do-everything technologies underperform and are routinely more costly than a handful of smaller, optimized solutions 

An engineering platform needs to evolve based on actual customer usage from the very start. In product development terms, this means identifying the minimum valuable version of the product and releasing that first. It’s not always clear what functionality the first version needs for customers to find it valuable, and opinions within your team or company may vary. 

Whatever you initially decide on, treat it like a hypothesis. Carefully analyze the behavior of early adopters, look for evidence that shows whether the initial features are effective, and be ready to change priorities if the evidence doesn’t support your initial ideas. 

This approach applies to both the MVP and every new feature you release. Probably everyone working in or around software development is familiar with the Minimum Viable Product (MVP) delivery diagram. It starts with a skateboard, which evolves into a bicycle, then to a motorcycle, and finally a car. 

This physical-object analogy, however, can be confusing from a user’s perspective. Sure, a motorcycle is more useful than a skateboard, but if I believe I need a car, how do these steps help me? Here’s an alternative way to think about it. Here is an alternative way of thinking about it.

The figure above shows the Progression of an MVP delivery process. A fully functional product does not need to be delivered at the start, but all phases should deliver some incremental value to the customer.

Imagine you need to move goods from your factory out to your customers. Suppose the solution progresses from hand trucks to a forklift to loading cargo containers onto flatbed trucks, with each stage being an additional component. In that case, you can see how each offers value and expands the capabilities. 

This model works well for an engineering platform because the platform team isn’t usually the direct developer of most capabilities; they integrate various capabilities and services. 

There will be many evolutionary stages to cover the full scope of developer activities. You can start with the smallest valuable element and keep expanding until you achieve complete coverage. Each new feature will go through the same process of experimentation, proof of concept, and real-world usage before it’s fully implemented in the platform. 

This approach will exemplify the idea that every capability in the platform is built with a product mindset and a product lifecycle, ensuring easy replaceability and maintainability. 

Gall’s insights really hit home when you look at engineering platforms. He pointed out something crucial, especially true for a platform: to build something complex and mature, you have to start with something simple that works and provides measurable value to at least a small set of users. 

That starting point is the MVP. We normally recommend that this initial offering be built by a single team and architected for a future roadmap where many teams are involved in delivering the Platform. However the absolute requirement is for a single, unified architecture roadmap and a single TPO maintaining this unified product vision. 

Over time, if you need to speed things up, you can go from one delivery team to several, each with its own product owner but all reporting back to the single, top-level TPO. What does this evolution of teams look like? There is no single evolutionary path that will fit every enterprise situation. However, more than once, we have seen the following progression: 

The figure above shows the evolutionary path of platform development teams. Often, while an EP starts as an effort driven by a single team, multiple teams spin up over time to handle specific aspects of platform functions, with all development efforts under a top-level product owner.

Starting with a single team allows a platform to start quickly, with a high-quality architectural design, and on a small scale to prove the functionality and value that could be generated. Over time, certain capabilities are so heavily used and have such broad impact that a dedicated team can be justified to manage it. 

Developer-experience teams are a common area, as is identity and DevSecOps. These areas quickly become important enough that a single team cannot manage those areas and at the same time continue to develop new capabilities for the platform as a whole. 

Eventually, even the core EP team begins to split as globalization is introduced, requiring dynamic routing between clusters to be supported by a dedicated effort.