// 01

Why Maturity Models Matter

Most platform teams measure themselves by uptime and ticket count. Neither tells you if you're building the right thing. Uptime measures reliability. Ticket count measures demand. Neither measures whether the platform is actually accelerating product engineering or silently slowing it down.

A maturity model gives you a shared language to describe where you are, where you're going, and what the next investment should be. It turns vague conversations about 'improving the platform' into specific conversations about which capabilities to build next and why.

// 02

The 5 Levels

Each level represents a distinct mode of operation — not just a different set of tools, but a different relationship between the platform team and the engineers who use it.

// platform state

No platform team. Shared scripts, tribal knowledge, heroics. Every engineer has their own way of deploying. The bus factor is high.

// who runs it

Operations teams firefighting incidents. Whoever built the original infrastructure and left comments in a Confluence page nobody reads.

// what this looks like

Deployments take days, sometimes weeks
Every incident is a surprise
Engineers spend more time on infrastructure than on product
Onboarding a new engineer takes weeks

// what to do next

Hire or designate a platform engineering function. Start with CI/CD standardisation. Pick the two biggest friction points from a developer survey and fix them. Don't try to build an IDP yet — the foundations aren't there to support it.

// platform state

Shared CI/CD pipelines. Some standardisation. Still a lot of one-off requests. A platform team exists but it spends most of its time on requests, not on building reusable infrastructure.

// who runs it

A platform team exists, but it's mostly reactive — working through a backlog of tickets rather than proactively reducing developer friction.

// what this looks like

Deployments are faster but inconsistent
The platform team has a backlog that never shrinks
Standard tooling exists but documentation is patchy
Teams use the platform differently from each other

// what to do next

Build your first golden path. Define what 'done' means for a new service. Create a service template that covers 80% of use cases — containerised, with CI/CD wired, logging configured. Measure time-to-first-deployment as your primary metric.

// platform state

Golden paths exist. Self-service for common tasks. An internal developer portal is emerging — developers can provision environments, create services, and check compliance status without raising a ticket.

// who runs it

Platform team proactively builds for product engineering. They have a roadmap, not just a backlog. They interview developers to understand friction before building solutions.

// what this looks like

New services can be production-ready in under a day
Platform team is no longer the bottleneck for standard tasks
Developers can provision environments without tickets
Observability is consistent across services

// what to do next

Invest in observability and SLOs. Start measuring developer experience, not just uptime. Build an internal developer portal with a service catalogue. Begin treating the platform as a product with its own roadmap and user research.

// platform state

IDP with full self-service. Platform has SLOs. Developer experience is measured quarterly. The platform team has a clear product identity — they know their users, their friction points, and their NPS.

// who runs it

Platform team runs the platform like a product — with a product manager, a roadmap, user interviews, and quarterly developer experience reviews.

// what this looks like

Product teams rarely need to talk to the platform team
Platform has a roadmap and a backlog of user-requested features
Developer NPS is tracked and improving quarter-over-quarter
Time-to-first-deployment for new engineers is under 2 hours

// what to do next

Invest in FinOps integration. Start measuring cost per deployment. Build for multi-cloud portability. Document golden paths so they survive team turnover. Consider open-sourcing components to attract engineering talent.

// platform state

Platform enables the business to move faster than competitors. Cloud-agnostic. FinOps embedded. The platform is a reason engineers join the company — it's part of the employer brand.

// who runs it

Platform as a competitive advantage. The team has engineers who give talks at conferences, contributes to open source, and sets internal standards that influence the wider industry.

// what this looks like

Time-to-market for new products is measured in weeks, not quarters
Engineering costs are predictable and optimised
Platform attracts engineering talent — it's a selling point
The platform has a public reputation: talks, open source contributions

// what to do next

You're here. Focus on knowledge transfer, documentation, and making sure Level 5 survives team turnover. Consider contributing components to the community. The risk at Level 5 is complacency — keep measuring, keep interviewing, keep improving.

// 03

How to Move Up a Level

Every level transition requires a different type of investment. The mistake most organisations make is trying to jump two levels at once.

// common mistake

Trying to jump two levels at once.

Each level builds the foundation for the next. Skipping Level 2 means your Level 3 collapses under its own weight. A team that tries to build an IDP before they have consistent CI/CD will build an IDP nobody uses — because the fundamentals aren't there to support it.

// fastest path

The 6-month sprint from Level 1 to Level 3.

The fastest path from Level 1 to Level 3 is a focused 6-month engagement with a clear mandate. Not a 3-year transformation programme. Fix CI/CD in month one. Build the first golden path in months two and three. Self-service environments by month five. Observability by month six.

// the right target

You don't need to reach Level 5.

You need to reach the level where your platform stops being a bottleneck and starts being a multiplier. For most enterprise teams, that's Level 3 or Level 4. Level 5 is a competitive strategy choice, not a requirement for a healthy engineering organisation.

// 04

Where Most Enterprise Teams Are

Based on our platform assessments across European enterprise clients in 2024:

Level 1 — Reactive
12%
Level 2 — Repeatable
41% most common
Level 3 — Scalable
33%
Level 4 — Product-Minded
11%
Level 5 — Strategic
3%

Most teams are stuck at Level 2 — they have a platform team, but no golden paths. That's the most addressable gap in platform engineering today. The investment required to reach Level 3 is smaller than most organisations expect: one golden path, well built, closes the gap.