Yesterday's article measured developer productivity within teams already using the platform. Today's question is different and, in a specific way, prior to it: are teams using the platform at all? A platform product manager (Day 36) can have excellent DORA metrics from the early-adopter teams and still be failing, if those numbers describe ten enthusiastic teams out of a hundred, and the other ninety are quietly maintaining their own infrastructure exactly as before Day 19's platform engineering ever started.
Note
Adoption metrics tell you if developers are using the platform — and getting value from it. Both halves of that sentence matter: a platform can be used under duress (mandated, with no real alternative) without developers getting real value from it, and that gap shows up in satisfaction scores even when raw usage numbers look fine.
The core numbers a platform team should actually track
| Metric | What good looks like |
|---|---|
| Platform adoption rate | Teams actively using the platform |
| Self-service rate | Provisioning done via self-service, not manual requests |
| Golden path usage | Workloads built using the paved road, not one-offs |
| Platform API usage | API calls per day relative to total possible |
| Active developers | Developers actually using the platform, not just onboarded |
| Time to production | How fast a new service goes from idea to live traffic |
| Deployment frequency | How often teams ship through the platform |
| Change failure rate | Lower is better — guardrails from Day 26 doing their job |
| Developer satisfaction | Self-reported happiness with the platform |
Time to production deserves particular attention because it's the metric most directly comparable to life before the platform existed — "2.3 days, down 40% from before" is a number leadership and developers both immediately understand, unlike a more abstract API call count.
Where the data comes from, and the maturity model behind it
Platform portal analytics · GitHub/GitLab · CI/CD tools ·
Observability stack (Day 32) · Kubernetes & cloud usage ·
Surveys & feedback (NPS, CSAT) · Internal tools & API telemetry
MATURITY MODEL:
1 Initial (just getting started)
2 Exploring (early adoption, limited usage)
3 Growing (increasing usage, early traction)
4 Widely adopted (high usage across teams)
5 Optimized (platform is the default way to build)That five-level model is worth using deliberately rather than treating adoption as a single pass/fail number — a platform team at level 2 needs a completely different set of actions (more outreach, more golden paths, fixing friction reported by early adopters) than one at level 4 trying to reach level 5 (closing the remaining gaps that keep a few teams on the old way by choice, not necessity).
The scenario this whole metric exists to prevent
Without adoption metrics:
"Is the platform working?" → "I don't know... feels like nobody uses it."
With adoption metrics:
"Is the platform working?" → "78% adoption. Developers love it.
Let's double down."The difference between those two answers isn't just confidence — it's actionability. "Feels like nobody uses it" gives a platform team nothing to act on. "78% adoption, but golden path usage is only 40%" tells them exactly where the gap is: teams are on the platform but avoiding the paved road specifically, which points at a golden-path problem (Day 25), not a platform-wide one.
Make it actionable, not just visible
Define adoption goals and target metrics up front. Instrument and collect the right data. Visualize it on a dashboard everyone can see — not a report that goes to one director. Review it regularly and share insights honestly, including the uncomfortable ones. Act, iterate, and improve based on what the data actually says, not what the roadmap already assumed.
Why adoption is the metric that keeps everything else honest
Real-world impact — developers shipping faster leading to higher deployment frequency, less manual work leading to lower toil and fewer tickets, consistent standards leading to a lower failure rate, better developer experience leading to more innovation and happiness — all of it is downstream of adoption actually being real and broad, not concentrated in a handful of teams who would have been fine either way. A platform team that only ever talks to its power users will always hear that the platform is great, because the teams who found it frustrating enough to avoid aren't in that conversation.
Tomorrow's article moves to a decision every platform team eventually faces once adoption is real and the platform needs to grow: build versus buy, and why "there is no one-size-fits-all" is the correct answer rather than a cop-out.
