What this tier actually looks like.
You have Backstage (or Cortex, or Port). Maybe a service catalogue, partly populated. One or two paved-path templates exist. Some teams use them. Some teams don’t. The platform team is busy shipping new capabilities; nobody’s tracking whether any of them are adopted.
You probably have:
- A developer portal (Backstage / Cortex / OpsLevel / Port) with a service catalogue.
- 1–3 paved-path templates that have varying adoption.
- Self-service for some non-production needs; production still needs tickets.
- Observability inconsistent across services — depends on what the team remembered to add.
- Platform team funded as a cost-centre; renegotiated annually.
- No regular developer survey.
Why most teams get stuck here.
Emerging-tier platforms stall because the platform team optimises for shipping capabilities, not for adoption. Three patterns that keep teams here:
- Building what’s asked for, not what changes the routing-around behaviour. Surveys reveal the gap; platform teams that don’t survey are guessing.
- Cognitive load growing with capabilities. Every new platform feature adds surface for engineers to learn. Without sunset rituals, the platform becomes the cognitive-load problem it was meant to solve.
- Funded as cost-centre, not product. The funding shape determines what gets prioritised. Cost-centre funding optimises for “keep the lights on”; product funding optimises for adoption-tied outcomes.
The three substrate moves to the next tier.
1. Survey 10 developers. Ask what they route around.
The single highest-leverage move. DX research consistently shows developer-survey signal predicts delivery performance. Whatever 7+ of 10 developers route around is your next investment — not what the platform roadmap currently says.
2. Observability + ownership defaults inherited.
Make logs + metrics + traces inherited from the golden path. Make ownership annotations required. Stop relying on team-by-team memory. OpenTelemetry defaults; Backstage Scorecards surface posture.
3. Move from ticket-driven to product-driven.
Run a discovery cycle: which 3 capabilities, if removed, would users miss most? Which 3 capabilities, if added, would they pay for? Sunset the bottom-quartile-adoption capabilities. Funding shifts to outcome-tied (delivery speed, change-fail rate, developer NPS).
What changes when you cross.
- Developer NPS moves from -10 to +20+. The cognitive-load discipline shows up in the survey.
- Adoption replaces shipped-capability as the headline metric. Platform team optimises for what teams actually use.
- The platform becomes the default for new services. Routing around becomes the exception, not the norm.
- Funding stabilises. Outcome-tied investment is defensible to the board; cost-centre funding isn’t.
This is the Established tier (CNCF Scalable). The next jump — to Productised (Optimizing) — is platform-as-a-product with proper measurement, sunset rituals, and auto-migration tooling. See the Platform Engineering IDP reference architecture.
Run the diagnostic.
To find out whether your team scores at this tier or another, run Platform Engineering Readiness. It takes 2–4 minutes and surfaces both your overall tier and the capability breakdown that shows you where the move starts.
For the bigger picture: the compound diagnostic takes results from all six diagnostics and shows you the substrate gap that bounds your overall delivery, not the per-discipline symptom.