Platform Engineering Maturity Is Not About How Much You Have Built

Plenty of organisations now have a Platform Engineering team. Many of them also have Kubernetes, Infrastructure as Code, CI/CD pipelines, a service catalogue, a developer portal, and automated provisioning.

On paper, that looks like real maturity.

But there's a problem with judging Platform Engineering purely by what the platform team has built: a sophisticated platform can still be a genuinely frustrating place to work.

So the question worth asking isn't "how advanced is our platform?" It's "how much friction has the platform actually removed?"

Automating infrastructure doesn't automatically remove dependency

Here's a situation that plays out constantly.

An organisation rolls out an internal developer platform. Provisioning gets automated. Deployment templates get standardised. The platform team builds solid documentation and a portal. On paper, that's real progress.

And yet developers still have to:

• open tickets for changes
• wait on platform engineers
• understand infrastructure details they shouldn't need to care about
• coordinate manually across teams
• request exceptions
• solve operational problems that fall outside the golden path

The technology moved forward. The dependency model didn't.

That gap matters. Platform Engineering isn't just about centralising infrastructure behind a nicer interface. A good platform should let engineering teams move with more autonomy while still meeting the organisation's bar for security, reliability, governance, and cost. If every bump in developer activity creates a proportional bump in platform team work, something's off. The platform itself may have quietly become the bottleneck.

Adoption isn't the same thing as maturity

Adoption numbers can be just as misleading.

A company might proudly report that 80% of its engineering teams use the platform. Sounds great on a slide. But usage by itself doesn't tell you much. The more useful questions look like this:

• Are teams using the platform because it's genuinely the easiest path to shipping software, or because they're told to?
• Do developers still find workarounds outside the platform?
• How many manual interventions does provisioning actually require?
• How long does it take to spin up a new service?
• How much specialist infrastructure knowledge do product teams still need?
• How often does the platform team get pulled in to unblock something?

Those questions paint a very different picture than an adoption percentage. A platform everyone technically uses can still generate a lot of friction underneath.

A good platform removes decisions, not just work

One useful lens for maturity is to look at how many decisions developers actually have to make.

Every engineering org has to deal with networking, security, deployment, observability, infrastructure, compliance, and reliability. Without a platform, individual teams end up solving the same problems over and over, often slightly differently each time. A good platform captures that organisational knowledge and turns it into something reusable, so developers don't have to understand every implementation detail underneath. The sensible default is just there, ready to use.

This is roughly where the idea of "golden paths" earns its keep. Not because every team has to follow the exact same architecture, but because common problems shouldn't need solving from scratch each time. A mature platform cuts down on unnecessary choice while still leaving room for flexibility where it genuinely matters.

Friction might be the real metric

All of this suggests platform adoption shouldn't be the only number that matters. A few others worth tracking:

These get much closer to what Platform Engineering is actually supposed to do: make engineering easier, not just more centralised.

A platform is really an operating model

There's an organisational side to this too. Platform Engineering isn't only a technical architecture choice, it reshapes the relationship between infrastructure teams and product teams. Platform teams effectively become internal product providers, and product teams become their customers. That means understanding users, prioritising demand, managing adoption, and evolving the interface over time, the same discipline any product team would need.

The strongest platform teams tend to think less like an internal support function and more like a product organisation. Their guiding question becomes "what's stopping engineering teams from delivering effectively?" rather than "what technology should we add next?"

That shift sounds subtle, but it changes almost everything in practice. The most mature platform isn't necessarily the one with the biggest technology stack. It might just be the one developers barely have to think about.

How does your organisation actually measure Platform Engineering maturity: by what the platform team has built, or by the friction it has removed?