Platform Engineering: The Path to DevOps Success

This is part of a series of contributed articles leading up to KubeCon + CloudNativeCon in October.

Companies are required to move faster than ever to deliver value to their customers. The continued rise of cloud, SaaS and always-on services means that customers expect new features, fewer bugs and 99.99% (or higher) uptime.

To keep up with these demands, many organizations try to adopt DevOps, but adopting DevOps practices is easier said than done. The book “Team Topologies” describes the leading approach to organizing business and technology teams for fast flow, providing a practical, step-by-step, adaptive model for organizational design and team interaction. The platform team is one building block outlined in the book.

The 2021 “State of DevOps” report by Puppet mentions this specific type of team and clearly notes that the level of DevOps maturity relates to the use of platforms built by platform teams and their crucial role in scaling up high-growth engineering organizations.

The common thread in everything a platform team does is:

• enabling developer self-service across the organization and
• keeping systems reliable and maintainable
• without compromising developers’ (end users’) experience of working with the infrastructure.

Many organizations are on their journey to build platform teams and are struggling with it, some because of organizational and cultural topics, which aren’t tackled in this post. Others have a more common problem: How many engineers should be working on “the platform”?

As the underlying idea of a cloud native platform is that it will make developers more effective, we can use the model created by Peter Seibel (tech lead for Twitter’s Engineering Effectiveness Group). Seibel describes the following model:

where E is the total effectiveness, ee is the total number of platform engineers, b is the effectiveness boost for the first platform member and s is the scaling of the boost. The units for effectiveness are FTEs.

In your organization, the number of engineers is given. The interesting parameters to this model are the scaling factor, s, and the boost, b. For his model, Seibel uses 0.7 for s and 2% per FTE for b.

If these parameters are right, for a thousand-person engineering organization, we should devote over a quarter of our engineers — 255 — to engineering effectiveness, which is a big part of platform engineering. This yields a total effectiveness equivalent to 1,465 engineers for the price of 1,000.

Success comes with scale, which requires optimizing not for the individual and not for the team, but for the wider organization. Using the previous example of a thousand-person engineering organization, if the platform is only used by a hundred, 100 is the relevant number, not 1,000.

This is obviously a very simple model, and like all models, it is wrong. But that doesn’t make it less useful. It shows that investing in platforms and platform engineering pays off. For platform engineers to be able to boost effectiveness across all of engineering, things need to be standardized.

Platform teams need to create a cloud native platform consisting of high-quality building blocks that offer a paved path for development teams while still allowing those teams to deploy and operate their own application, which is what DevOps is about.

The platform empowers your teams to concentrate on solving real business problems by abstracting away organizational complexities and toil. This makes it easy for your teams to build, deploy and operate products. This, in turn, will allow your organization to accelerate its time to market, increase revenue, reduce costs and create innovative products for your customers.

Another aspect is that the workers will become happier as their cognitive load lower. Platforms abstract away the usual infrastructure concerns, which leads to reduced onboarding times for new joiners, a mover between teams, a leaver or the onboarding of a new development team. It will also become easier to attract new talent as your organization will have time to stay up to date on technology, which will encourage talented engineers to join your organization and which will create more recruitment options.

Concentrating specialized skills in platform teams means recruitment efforts for development teams can focus on developers, testers, etc., without requiring more costly, specialized cloud or platform skills.

The Puppet survey results show that platform teams can be a building block of becoming a high-performing DevOps organization, but it’s critical to note that success requires more than simply restructuring departments. It should also focus on how they work together.

In the same way platform teams prevent developer teams from reinventing the wheel through the paved path, platform teams should avoid falling into the same fallacy. Platform teams should focus on the specific needs of their organization and make use of off-the-shelf solutions.

The value of a platform team doesn’t only come from the platform itself, but also from the support and adoption support the team provides to the development organization.

Platform teams are essential because this type of team acts as a major building block for enabling development teams; their role is unique and crucial to the rest of the organization’s success. If you’ve been thinking of building a platform team, ensure that you adequately understand that success requires more than restructuring engineering and allocating people to the platform team.

The focus areas need to be the interaction between the teams and the optimization of flow. If you decide that a platform team is right for you, let the team work to understand recurring pain points and empower your team by providing them with space to create and innovate. Your developers and your bottom line will thank you.