the platform engineering maturity model, without the slide deck

Every consultancy has a platform engineering maturity model, and every one of them is presented as a ladder on a single slide, with a logo where the fifth rung should be. I have built exactly zero platforms by looking at a ladder. What I have found useful, in the room, is a flatter description: four stages that describe what teams actually do, one anti-pattern most teams are in, and the question that moves you from one stage to the next.

stage 0: there is no platform

Every product team provisions its own infrastructure. Patterns exist as tribal knowledge. The fastest path to shipping a new service is to copy the nearest existing one and modify it; the fastest path to failing is the same, because whatever you copied carries five years of accidental decisions.

At this stage the question "do we have a platform?" answers itself by inventory. If your new-service bootstrap takes a week and three Slack threads, you do not have a platform.

stage 1: the paved road is a folder of examples

Someone — usually a senior engineer on the busiest product team — got tired and created a template. The template lives in a repository called service-template or starter-service and is maintained by consensus. It works on the day it was created. It is not tested. It drifts.

Teams in stage 1 often believe they are in stage 2, because the template exists. The tell is simple: ask when the template was last updated, and ask how often teams actually use it without modification. Stage 1 templates are used with modification, which means they are not templates; they are suggestions.

stage 2: the paved road is a supported product

A platform team exists. The paved road is a generated service bootstrap, a CI/CD pipeline, a set of observability defaults, and an SLO for the platform itself. Product teams use the paved road without modification because the platform team treats the paved road as a product, with a backlog, a roadmap, and users it talks to.

Stage 2 is the first stage at which you can meaningfully measure platform quality. The metrics are boring: how long from first commit to a production deploy for a brand-new service; what fraction of service outages are caused by platform issues versus product issues; what fraction of product engineers can name two people on the platform team. If you cannot answer those, you are not at stage 2.

stage 3: the paved road is the only road

At stage 3, the question "should I go off-road?" does not come up, not because it is forbidden but because off-road is observably worse. Off-road services do not get the shared observability, the shared security posture, or the shared cost controls. They also do not get the platform team's attention when they break.

Teams often resist naming this stage because it sounds coercive. It is not. It is the natural outcome of a platform team that has built something clearly better than the alternatives. If your platform is genuinely better, engineers choose it; if they do not, your platform is not as good as you think.

the anti-pattern: platform as a barrier

The most common failure mode we see is stage 1.5 — a platform team has been hired, but the paved road is still a folder of examples plus a review process. Every new service has to be "approved" by the platform team. The platform team enforces standards through meetings.

This is not platform engineering. It is architectural review with a new budget line. The tell is that the platform team's output is documents and approvals rather than paved roads and SDKs. The fix is almost always the same: force the platform team to build the thing product teams were previously asking permission to build. If the new-service bootstrap is slow, build a better bootstrap. If services are drifting from standards, build the standard into the bootstrap so drift requires deliberate effort.

the single question that moves you forward

For any stage, the question that moves you toward the next is: what is the shortest, most rewarding default path for a product engineer?

• If the default path is "read this Confluence page," you are at stage 0.
• If the default path is "copy this repository," you are at stage 1.
• If the default path is "run this command," you are at stage 2.
• If the default path is the only path anyone uses, you are at stage 3.

Everything else — your SLOs, your cost dashboards, your compliance postures — follows from that default. The platform team's job is to make the easiest thing to do also the right thing to do. Every other metric is downstream of that commitment.

the one thing nobody tells you

A mature platform is genuinely less work for the platform team than an immature one. Platform teams that are always overwhelmed are usually in stage 1.5 — still gate-keeping, still responding ad-hoc, still being pulled into incidents that a paved road would have prevented. The shift to stage 2 is painful for a quarter and relieving for a year. The shift to stage 3 feels like quietude. If your platform team has been on fire for three consecutive quarters, you are not investing too little in the platform. You are investing too little in the paved road.