Measuring a Platform Team Without Measuring the Wrong Thing

Platform engineering has become mainstream: Gartner's forecast was that 80% of large engineering organisations would run platform teams by 2026, up from 45% in 2022. Most of those teams get measured with tooling designed for product teams, and the numbers come out meaningless.

The reason is structural. A platform team's output is other teams' ability to ship. Point DORA at the platform team's own repositories and you measure their internal cadence, which is close to irrelevant. Point it at the organisation and you measure their customers.

What goes wrong with standard metrics

Deployment frequency measures the wrong repositories. A platform team might deploy infrastructure changes weekly while enabling hundreds of deployments a day elsewhere. Their own number says nothing about their impact.

Lead time is dominated by change type. Platform work skews toward large, risky, infrequent changes — a Kubernetes upgrade is not a feature. Comparing it against product team lead time compares two different kinds of work.

Activity metrics are worst here. Much of the highest-value platform work is deletion, consolidation and prevention. Removing a service that three teams were maintaining separately is a large win recorded as negative activity.

Attribution runs backwards. When product delivery improves after a platform investment, the product teams' metrics move. The platform team's don't.

What to measure instead

Four categories, roughly in order of usefulness.

1. Adoption

Are people using it, voluntarily?

Percentage of services on the golden path. Number of teams onboarded. Share of deployments going through the platform rather than around it. Time from a new team's first day to their first production deploy.

Adoption is the closest thing platform teams have to revenue. A platform nobody adopts is a rewrite of infrastructure other people were already managing, and voluntary adoption is the honest version — mandated adoption measures the mandate.

2. Friction removed

This is where DevEx applies more directly than anywhere else in an engineering organisation, because the platform team's job description is essentially the DevEx dimensions.

Feedback loops — build times, test suite duration, deployment duration, time from commit to feedback.

Cognitive load — how much a developer must know to ship. Number of steps in the golden path, size of the required mental model, documentation adequacy.

Flow — interruptions caused by infrastructure, time lost to environment problems, support requests per week.

Median build time and median deployment duration across the organisation are two of the most honest platform metrics available, and both are cheap to collect.

3. Delivery metrics, at the organisation level

DORA applied to the whole organisation rather than to the platform team is legitimate — that's the outcome the platform exists to influence.

The caveat is attribution. Organisation-wide delivery metrics move for many reasons, and claiming them as platform outcomes requires either a controlled comparison — teams on the platform versus teams not yet migrated — or honesty about the uncertainty.

The migration window is the opportunity here. While some teams are on the golden path and some aren't, you have a natural comparison that disappears once migration completes. Measure during it.

4. Reliability of the platform itself

The platform is a product with users, and it has an availability story. Error budgets, incident counts attributable to platform components, and time to restore. Standard SRE practice applied inward.

Where the metrics live

One practical note, because it determines whether any of this gets used.

The historical pattern for platform teams was to stand up Apache DevLake, build Grafana dashboards, write per-team SQL, wire authentication, and then discover developers don't open Grafana — leading to embedded iframes or a custom developer portal plugin, all of it maintenance surface.

That got cheaper in 2026. A DevLake-to-DORA backend module contributed to Backstage's community plugins bridges DevLake's metrics API into the standard DORA plugin and puts a card with deployment frequency, lead time, change failure rate and recovery time on every service's catalog page.

If you already run Backstage — and adoption is substantial, with over 3,400 adopters and a place in the Adopt tier of the Q1 2026 CNCF Technology Radar — the metrics surface where developers already are. That's usually the difference between a dashboard that informs decisions and one that nobody opens.

The trap

The tempting metric for a platform team is engineering hours saved. It's compelling to executives and almost always fabricated: it requires a counterfactual you don't have, multiplied by an hourly rate that isn't real.

The defensible version is narrower and stronger. State what the platform changed — build time down from X to Y across N services, onboarding from two weeks to two days — and let the reader do the multiplication if they want to. A number you can source beats a number you calculated from assumptions, especially when someone asks how you got it.

Frequently asked

Should platform teams track their own DORA metrics? Internally, as a health check, fine. As a performance measure, no — it describes their release cadence, not their impact.

How do we show ROI on platform investment? Adoption plus friction removed plus a controlled comparison during migration. Avoid hours-saved arithmetic; it doesn't survive scrutiny.

What if adoption is mandated? Then adoption measures compliance rather than value. Track support requests and satisfaction instead — those still tell you whether the platform is good.

Is DevEx the right framework here? It's the closest fit of the three. The platform team's job is essentially reducing feedback loop latency and cognitive load, which is what DevEx measures directly.