How would you measure whether a self-service CI/CD platform is actually succeeding, beyond just "teams are using it"?

Track deploy frequency and lead time (are teams actually shipping faster than before the platform existed), change failure rate and time-to-restore (is the platform's safety tooling actually catching problems, not just adding process), and platform-team support burden per onboarded team (is the platform genuinely self-service, or is the central team still a bottleneck teams route through) — these directly measure the platform's stated goals (velocity, safety, reduced central-team bottleneck) rather than the proxy metric of raw adoption count.

DORA-style delivery metrics (deploy frequency, lead time for changes): comparing these before and after platform adoption, per team, directly measures whether the platform is actually delivering its core promise of faster shipping — a platform with high adoption but no meaningful improvement in these numbers isn't actually achieving its purpose, regardless of how many teams are technically using it.

Change failure rate and time-to-restore: the platform's safety tooling (deploy gating, automated rollback, canary analysis) should show up as a measurable improvement in these numbers — fewer bad deploys reaching production, and faster recovery when they do — compared to before the platform existed. If these numbers haven't improved despite adoption, the platform's safety mechanisms aren't actually working as intended, even if teams are nominally using them.

Platform-team support burden per onboarded team, over time: the whole point of "self-service" is that a team, once onboarded, shouldn't need routine hand-holding from the central platform team for normal operations. Tracking support ticket volume per onboarded team, and specifically whether it trends down over time as a team gets more experienced with the platform, directly measures whether the platform is genuinely self-service or whether the central team remains a de facto bottleneck teams still route through for things that should be self-serve.

Time-to-first-deploy for a new team/service: how long does it take a brand new team or service to go from "onboarding" to "first successful production deploy through the platform" — a fast, smooth number here reflects genuine self-service maturity; a slow one suggests the platform's onboarding experience itself is a bottleneck, regardless of how good the platform is once a team is fully set up.

Adoption alone as an insufficient, misleading metric: as with the golden-path measurement question generally, adoption percentage can be high purely because the platform is mandated, without confirming any of the above actually improved — the CI/CD-platform-specific version of this principle is that "100% of teams use the platform" tells you nothing about whether they're actually shipping faster, safer, or with less central-team dependency, which are the platform's actual reasons for existing.

• DORA-style deploy frequency and lead time, measured before/after adoption, directly test whether the platform is achieving its core velocity promise.
• Change failure rate and time-to-restore test whether the platform's safety tooling is genuinely working, not just present.
• Declining platform-team support burden per team over time is the direct signal of genuine self-service, versus the central team remaining a bottleneck.
• Adoption percentage alone doesn't confirm any of these outcomes and can be high purely due to mandate, independent of actual platform success.

• DORA: DevOps Research and Assessment — Four Keys metrics
• Team Topologies: Platform Teams