LONDON — Last hired, first fired remains the law of the land. For platform engineering teams, most fewer than 5 years old, it may be fair too. So many struggle to make the case for themselves.

Platform teams are feeling the pressure to connect their technical delivery to business goals, but most are measuring the wrong things, if anything at all. This has somewhere between 60 and 70% of platform projects failing to leave impact, with almost half of platform teams disbanded or restructured within 18 months.

Much of this year’s Fast Flow Conf, Team Topologies’ flagship event, focused on getting platform adoption up — and why adoption isn’t the only thing platform engineers should be focusing on.

Matthew Meckes, senior containers specialist at Amazon Web Services (AWS), spoke at Fast Flow this month about how to measure the maturity of your platform so it will get top-down investment. He explained how to empower internal developer platform teams with metrics that just might save their jobs.

What’s Holding Platform Teams Back?

Even though it’s not working great yet, there’s no denying that platform engineering is following its respective predecessors of agile, DevOps and cloud native — both in becoming a tech industry standard and in struggling to gain widespread adoption after years of trying.

Gartner predicts that 80% of large software engineering organizations will have platform engineering teams by 2026, up from 45% four years earlier. But the tech industry doesn’t need more 18-month investments that ultimately get cut. Platform teams have to find a way to make long-term impact in the short term now.

Why do platform teams fail? According to Meckes, it’s usually a mix of:

• Lack of product mindset: Treating internal development platforms (IDPs) as technical artifacts, not services for developer customers to consume.
• Overcomplicating things: The opposite of the previous point — saying yes to everything and trying to support every workload, rather than focusing on what benefits 80% of engineering teams.
• Misalignment with stakeholders: Platform engineers who think they know what’s best for developers, and then ignore product managers and leadership completely.
• Cultural and organizational barriers: Failing to introduce continuous improvement and to market value-added to encourage platform adoption.
• Poor metrics: Maybe the team uses DORA metrics for throughput and stability, but fails to connect them to business goals.

But, if you aren’t mature enough in your platform journey, Meckes said, you aren’t releasing faster while maintaining stability. He quoted Dave Farley, co-author of the book “Continuous Delivery”: “There is no trade-off between speed and quality. If you want high-quality systems, you must build them quickly.”

The Importance of a Fast Feedback Loop and Iteration

Just as the dev teams they serve do, platform teams need to have a cycle of smaller releases and faster feedback. So how can you cut down the time to become a mature platform engineering team? Not, Meckes said, by repeating the same mistakes.

“We can make brand new, novel mistakes, which can be really exciting, but hopefully won’t make the same mistakes that we see over and over again,” he said.

“If we’ve got really, really good platform fundamentals, and look at how great our operation is, but it still really has only impacted one or two workloads within the organization,” he added, your IDP might be good on paper, but it’s not a product with users. In other words, it’s a waste.

To find that point where in-house customers are attracted to the platform, rather than being pushed there, he said, platform teams must truly commit to a platform-as-a-product model and prioritize feedback from all stakeholders

“We have to establish a measurement framework that’s aligned to the KPIs of the business, so we can continue to justify repeated investment,” Meckes said. “And we’re really, really focused on developer experience.”

That means, for example, at a massive financial services organization, there can’t be just one platform team serving everyone.

“We’ve really got to hone in to a couple of business units who are really going to go invest in modern, continuous delivery and build something that’s going to suit their use case, that we can really demonstrate value, that we can then scale across the rest of the world.”

How to Measure Your Platform’s Maturity

An axiom of science — and engineering is a science — is that you can’t improve what you don’t measure.

This is why the Cloud Native Computing Foundation app development working group created the Platform Maturity Model, covering five areas of platform investment:

• Team: Who is on the platform team and how it’s funded.
• Adoption: User onboarding and internal marketing.
• Interfaces: APIs, tools, chatbots, portals.
• Operations: Life cycle management, including the retirement of features.
• Measurement: Of the platform program’s value.

“How do we measure the value in a way the business actually cares about, that we can communicate?” Meckes said. “So we can ask for more money, more headcount, more investment, year after year, as we start to unlock value from our expanding platform.”

The four levels of platform maturity are:

1. Provisional: Ad-hoc, ticket-based, limited capabilities.
2. Operational: Repeatable pathways, foundational tooling.
3. Scalable: Fully self-service.
4. Optimizing: Measuring every step.

Understanding the CNCF Platform Maturity Model

The CNCF app development working group just released its pilot Platform Engineering Maturity Model Assessment to help organizations reflect on these metrics. While it’s a quick online quiz, you can print out, discuss and take notes — answers may not be as straightforward as a yes or no. Use it to create an artifact that explains and measures your platform team.

Meckes recommends carving out a few hours for the first assessment, but once you’ve got it down, subsequent assessments should take about an hour. Hopefully, with this exercise, you can build an achievable roadmap for the next quarter or two.

Real-World Examples of Platform Maturity Assessments

He gave a couple of examples of where platform teams showed maturity in some areas but lacked it in others.

Example 1: Fairly Provisional

Measuring DORA metrics for the platform team, but not for the development team you’re serving. Next steps were to:

• Build on operational excellence to make sure the platform is better than what developers had before.
• Establish measurements attached to organizational KPIs to justify repeated investment.
• Focus on developer experience, with self-service tooling and investment in business units that want to do modern continuous delivery.

Example 2: More Sophisticated

This company was a couple of years into its platform journey and had built a robust Kubernetes ecosystem with a comprehensive measurement framework. However only 20% of workloads had been moved onto the IDP. As Meckes said, “They’ve got this amazing thing, and it’s not getting traction.”

This team realized through this assessment that it needed a dedicated product manager and a more centralized onboarding process for new users. It also had to reckon with limited integration with the rest of the software development life cycle.

“For them, it’s about, ‘How do we go and build that close feedback loop so we can iterate on self-service capabilities, start to book community engagement and drive adoption beyond those early adopters?’” Meckes said.

Driving Adoption and Securing Top-Down Investment

The key, he said, to top-down investment and communication: “We want to go and do this thing: To go and get the most out of the cloud. Then moving on to building the operations: How can we build sustainable processes automation? And then it’s where it starts to get sticky.”

Because, he argued, no matter how good your operations gets, it’s never going to drive adoption alone. Platform teams need to support adaptive change.

“How do we build for these complex, ambiguous problems? How do we help people learn?” Meckes asked. “This is where we’re going to think about adapting our platform culture, transferring to a DevOps mindset and finally going to bring developers and operations together in a way to collaborate, building developer-centric organizations where our developers are close to the product.”

TRENDING STORIES