Platform engineering maturity: how to use the CNCF model without fooling yourself

The model in brief

The model describes five aspects of platform engineering, each with four levels: provisional, operational, scalable and optimising¹.

Two points from the authors matter most. Lower levels are more tactical and higher levels more strategic. And teams shouldn't be sorted into a single level: each aspect is assessed on its own, and a team may show traits of several levels at once¹².

Where platforms usually stall

A CNCF post in September 2026 focused on the interfaces aspect and argued that many teams stall at the operational level, with each level reflecting how much the platform team still has to be in the loop for things to happen³. That matches the symptom above. If creating a database still needs a ticket that a platform engineer fulfils, you have a service desk with Kubernetes, not a self-service platform.

How I use it

1. Assess each aspect separately, with evidence: interviews with product teams, ticket data, usage metrics. Not a self-assessment by the platform team alone.
2. Pick one or two aspects to move in the next two quarters. Trying to raise all five at once spreads the team thin.
3. Start with interfaces and adoption. Self-service paths for the most common requests usually unlock more value than new capabilities.
4. Measure developer outcomes: time to first deploy for a new service, lead time and change failure rate, using the delivery metrics in DORA metrics in the AI era.
5. Fund it as a product. A platform needs a product owner, a roadmap built from user research and a way to say no.

Why it matters more with AI

DORA's AI Capabilities Model lists quality internal platforms among the practices that amplify the benefits of AI⁴. That's intuitive: AI coding tools produce more changes, and a good platform turns more changes into safe deployments rather than more incidents. Platforms are also where AI-specific capabilities belong: approved model gateways, GPU scheduling as in Kubernetes gang scheduling, evaluation pipelines and cost visibility.

A warning about scores

Maturity models attract vanity. A slide reading "Level 3 across the board" is easy to produce and says little. The model's authors take a better view, citing Martin Fowler's point that the value of a maturity model lies in the list of things you need to work on, not the level itself¹. I'd rather see an honest "provisional on measurement, here is our plan" than an inflated score.

How I can help

I assess platform engineering in technical due diligence and help companies turn platforms into products developers choose to use. As a fractional CTO I can lead that work. Or analyse your challenge and bring the result to a call.