Quick take
Platform engineering maturity has five real levels: ad hoc, standardized, self-service, product-minded, and optimized. Most enterprises I consult for are stuck between levels 1 and 2. The fix isn’t more tools. It’s treating the platform as a product with actual users, feedback loops, and a definition of “done” that includes developer happiness. Stop building catalogs. Start removing ticket queues.
I’ve assessed platform maturity at about a dozen enterprises over the past two years. The pattern is depressingly consistent. There’s a “platform team” somewhere in the org chart. They have built some Terraform modules. Maybe a Jenkins pipeline or two. Possibly a Backstage instance that three people use.
Meanwhile, developers still open Jira tickets to get a database provisioned. Lead time from “I need an environment” to “I have an environment” is measured in days. Sometimes weeks.
The platform team is busy. They are just busy building the wrong thing.
The Five Levels (Honest Version)
I use a maturity model when I assess platform teams. Not because I love frameworks, but because it gives me and clients a shared language for “here’s where you are” and “here’s where the payoff is.”
Level 1: Ad hoc. Everything is manual. Knowledge lives in people’s heads. Getting a new environment means finding the one person who knows how. Deployments happen on Tuesdays because that’s when the ops team has capacity. This is where most startups are and where some surprisingly large companies still live.
Level 2: Standardized. Infrastructure as code exists. CI pipelines exist. But the platform team gates everything. Developers can build, but they can’t deploy or provision without filing a request. The automation is real, but the bottleneck just moved.
Level 3: Self-service. Developers can provision environments, deploy services, and roll back on their own – within guardrails. This is where the platform starts paying for itself. Wait time drops. Consistency improves. The platform team stops being a ticket queue and starts being an enablement function.
Level 4: Product-minded. The platform has a roadmap based on user feedback. There are golden paths for common service types. An internal CLI or portal handles the 80% case. Progressive delivery is standard. The platform team runs NPS surveys and actually reads them.
Level 5: Optimized. Data drives changes to platform defaults. Automated remediation handles known failure modes. Cost, reliability, and security metrics improve continuously. This is rare. I’ve seen maybe two organizations genuinely here.
Where Most Enterprises Actually Are
Based on what I’ve seen in Verizon- and AT&T-scale organizations, most enterprises are at Level 2. Some pockets are at Level 3. Almost nobody is at Level 4.
The gap between Level 2 and Level 3 is the most expensive gap in enterprise software delivery. It’s the difference between “we have automation” and “developers can actually use it without waiting.” Every day a developer spends waiting for provisioning is a day they aren’t shipping features. Multiply that by hundreds of developers and the cost is staggering.
Why Platform Teams Get Stuck
Three patterns I see repeatedly:
Building tools instead of workflows. A team builds a slick Terraform module for spinning up EKS clusters. Great. But developers still need to file a ticket to get the module run for them. The tool exists. The self-service doesn’t. The developer experience didn’t actually change.
Centralizing instead of enabling. The platform team takes on more ownership instead of giving ownership away safely. They become the bottleneck for every infrastructure change. They are drowning in operational work and have no time to build the self-service layer that would free them.
Ignoring their users. Platform teams that never talk to developers build platforms that developers avoid. I’ve walked into organizations where three competing shadow platforms exist because the official one didn’t solve actual problems.
How to Move Up
Level 1 to 2: Document and automate the basics
Write down how to get from code to production. Adopt infrastructure as code for core services. Get CI pipelines running. Define standard environments. This isn’t glamorous work, but it’s the foundation.
Level 2 to 3: Kill the ticket queue
This is the most impactful transition. Give developers templates and modules they can run themselves. Automate deployments with guardrails – not gates that require human approval for every change. Bake observability in by default so developers don’t have to think about it. Clarify who owns what.
The goal is simple: a developer should be able to go from “I want to deploy” to “it’s deployed” in minutes, not days.
Level 3 to 4: Treat it like a product
Build an internal CLI or portal around the most common workflows. Publish golden paths and reduce unnecessary choices. Measure developer satisfaction. Run feedback sessions. Build a roadmap based on what developers actually need, not what the platform team thinks is interesting.
Level 4 to 5: Let data drive
Automate remediations for known incident types. Tune platform defaults based on real usage patterns. Track cost and performance per service. This is continuous improvement territory – it never ends.
The Assessment
When I assess a client, I score six dimensions independently:
- Infrastructure provisioning and environment consistency
- Delivery workflows and release safety
- Observability and operational feedback
- Security controls and policy enforcement
- Developer experience and self-service
- Platform team operating model and ownership
Each one gets a 1-5. I don’t average them. I look at the lowest two scores because that’s where the biggest drag on delivery lives. A platform with great CI/CD but terrible provisioning still has developers waiting.
What Actually Matters
Forget vanity metrics. These tell you if your platform is working:
- Lead time from commit to production. If this is longer than an hour for most services, something is broken.
- Time to provision a new environment. If this takes more than a day, your self-service isn’t actually self-service.
- Deployment frequency. Teams that trust their platform deploy more often.
- Developer satisfaction. Ask them. Regularly. Act on what they say.
The best platform I’ve seen wasn’t the one with the most tools. It was the one where a new developer could deploy their first change to production on day one. Everything else followed from that principle.
The Uncomfortable Part
Most platform immaturity isn’t a technology problem. It’s an organizational problem. The platform team doesn’t have a mandate to remove ticket queues. Leadership doesn’t treat developer experience as a first-class investment. The team is understaffed for the scope they’re expected to cover.
If you’re a platform engineer reading this and nodding, show this to your VP of Engineering. The conversation needs to happen at the level where headcount and priorities are decided. No amount of Terraform modules fixes a staffing problem.