Why a maturity model
Platform engineering decisions need a baseline. Where are you today, where do you need to be, what’s the gap. Without baseline, investment decisions are guess.
Five stages
- Pre-platform — each team owns infra; tooling fragmented; ad-hoc shared services
- Shared infrastructure — central team owns shared infrastructure; ticket-driven
- Self-service primitives — central team exposes APIs / IaC modules; limited golden paths
- Internal developer platform — opinionated platform with golden paths; self-service for most operations
- Mature platform engineering — platform is a coherent product; SLOs; internal product management
Most organizations sit at stage 2-3.
Eight dimensions to score
- Workload portability — can workloads run on multiple substrates without rewrite?
- GitOps adoption — fraction of changes via PR-driven Git workflow
- Observability unification — single observability stack; SLOs defined per service
- Secrets handling — centralized; rotated; audited
- Identity model — federated workforce-to-workload identity
- Multi-tenancy — namespace / project / Tenant CRD model
- Disaster-recovery posture — RTO/RPO documented and tested
- Self-service depth — golden paths covering 80% of common requests
For each, 5-stage rubric (matching overall stages).
How to use the maturity assessment
- Download the PDF
- Walk through with engineering leadership and platform team (separately)
- Compare answers — disagreement = real signal
- Identify priority dimensions (lowest scores or highest leverage)
- Build remediation roadmap
What “good” looks like
For mid-large engineering organization (200+ engineers, multiple product teams):
- Target stage 4 across all 8 dimensions within 18-24 months
- Mature stage 5 typically takes 3-5 years
Smaller organizations (under 100 engineers): stage 3 may be sufficient; stage 4-5 is over-engineering.
Engagement
For structured assessment with an external lens see Platform Readiness Assessment.
Test yourself: PE maturity model
5 questions · ~2 min
Question 1 / 5
How many maturity stages does the model define?
Why: Five stages: pre-platform → shared infrastructure → self-service primitives → internal developer platform → mature platform engineering. Most organizations sit at stage 2-3.
Question 2 / 5
How many dimensions does each platform get scored on?
Why: Eight dimensions: workload portability, GitOps adoption, observability unification, secrets handling, identity model, multi-tenancy, disaster-recovery posture, self-service depth. Each scored on a 5-stage rubric matching overall stages.
Question 3 / 5
For a mid-large engineering organisation (200+ engineers), what target stage does the article recommend within 18-24 months?
Why: For 200+ engineers, multiple product teams: target stage 4 across all 8 dimensions within 18-24 months. Mature stage 5 typically takes 3-5 years. Smaller orgs (<100 engineers) — stage 3 may be sufficient; stage 4-5 is over-engineering.
Question 4 / 5
Why does the article say to walk through the assessment with engineering leadership and platform team SEPARATELY?
Why: Walk through separately, then compare answers — disagreement = real signal. Where engineering leadership and platform team disagree on the maturity score, you've found a gap in shared understanding that's worth surfacing.
Question 5 / 5
Which dimension is "self-service depth" specifically about?
Why: Self-service depth = golden paths covering 80% of common requests. The other 20% need escape hatches (real conversation with platform team), but a mature platform absorbs the bulk of the volume through opinionated paths.
0 / 5