Measuring What Platform Teams Actually Produce
Platform teams have a measurement problem. They don't ship features that customers see, so traditional product metrics don't apply. They can't easily attribute revenue to a faster CI pipeline. And counting tickets resolved or PRs merged tells you about activity, not impact. The wrong metrics incentivize the wrong behavior — I've watched platform teams optimize for ticket velocity while their actual customers (the engineering org) grew increasingly frustrated.
The DORA Framework as a Starting Point
DORA metrics (deployment frequency, lead time for changes, change failure rate, time to restore) measure software delivery performance. They're a reasonable starting point for platform teams because they capture outcomes that platform work directly influences. If the platform team improves the CI pipeline, lead time should decrease. If they improve deployment tooling, deployment frequency should increase.
But DORA metrics measure the engineering org's performance, not the platform team's performance specifically. A drop in deployment frequency might reflect a product prioritization decision, not a platform problem. Using DORA as the sole metric for the platform team creates misaligned incentives — the team starts pushing for more frequent deployments regardless of whether the org benefits from them.
Use DORA metrics as a health indicator for the organization, and supplement them with metrics that specifically measure platform team output and adoption.
Platform Adoption Metrics
The clearest signal of a platform team's effectiveness is adoption. If you build a self-service deployment tool and nobody uses it, the tool failed regardless of how well it's engineered. Track adoption at multiple levels:
Active usage rate — what percentage of eligible teams use the platform's tools each week? "Eligible" matters here because not all teams should use every platform feature. A team that deploys monthly doesn't need your continuous deployment pipeline.
Migration completion — when you ship a new platform feature that replaces an old workflow (like migrating from Jenkins to GitHub Actions), track the percentage of teams that have completed the migration. Slow migration rates usually indicate missing features, poor documentation, or insufficient migration support rather than team laziness.
Self-service success rate — when a developer uses a self-service action (provision a database, create a new service, set up a staging environment), how often does it succeed without platform team intervention? A success rate below 85% means the self-service flow has rough edges that need attention.
Developer Satisfaction Surveys
Quarterly surveys are the most direct way to measure developer experience. Keep them short — five questions maximum — and focus on satisfaction with specific platform capabilities rather than overall sentiment. A question like "How satisfied are you with the time it takes to deploy to production?" is actionable. "How do you feel about the platform team?" isn't.
The Net Promoter Score approach works surprisingly well for internal platform teams. "Would you recommend [platform tool] to a colleague joining the company?" captures both satisfaction and perceived utility. Track NPS per tool, not per team, so you can identify which parts of the platform need investment.
Survey Design Mistakes
Don't survey about things you're not willing to change. Asking about pain points and then not addressing them for six months destroys trust in the survey process. Better to ask about fewer topics and act on them than to survey everything and act on nothing.
Avoid leading questions. "How much has the new deployment tool improved your productivity?" assumes it improved productivity. "How has the new deployment tool affected your workflow?" is neutral and will surface both positive and negative feedback.
Operational Metrics for Platform Reliability
The platform itself needs SLOs. If the CI system is down, developers can't merge code. If the deployment pipeline is broken, nobody ships. These aren't edge cases — CI outages are one of the most common sources of developer frustration at scale.
Track availability and latency for each platform component. CI pipeline availability (percentage of time developers can trigger builds), median and P95 build times, deployment pipeline availability, and infrastructure provisioning latency. Set SLOs against these metrics and report on them the same way product teams report on their SLOs.
# Example platform SLO definitions
platform_slos:
ci_pipeline:
availability:
target: 99.5%
window: 30d
metric: ci_system_available_minutes / total_minutes
build_time_p95:
target: 15m
window: 7d
metric: percentile(build_duration, 0.95)
deployment_pipeline:
availability:
target: 99.9%
window: 30d
deploy_time_p95:
target: 10m
window: 7d
infrastructure_provisioning:
success_rate:
target: 95%
window: 30d
provisioning_time_p95:
target: 5m
window: 7dToil Reduction Metrics
Platform teams exist to eliminate toil for the rest of the engineering org. Measuring toil reduction directly ties platform work to its purpose.
Track the number of manual infrastructure requests (tickets, Slack messages) per month. This number should decrease as self-service capabilities improve. If it isn't decreasing, either the self-service tools aren't covering the right use cases or developers don't know they exist.
Mean time to onboard a new service is another toil indicator. How long does it take from "we need a new microservice" to "it's deployed with monitoring, logging, and a CI pipeline"? If this takes more than a day, there's platform work to do. The best platform teams get this under an hour through service templates and automated provisioning.
Communicating Metrics to Leadership
Executive stakeholders care about three things: are we shipping faster, are we spending less, and are developers happy. Frame your platform metrics in these terms. "CI build time decreased from 18 minutes to 7 minutes" is a data point. "Developers save 22 minutes per PR, which across 400 PRs per week gives back 147 engineering hours monthly" is an argument.
Cost metrics are straightforward if you track them. Infrastructure spend per deployment, cost per CI minute, and cloud cost trends attributed to platform optimization efforts. Don't overclaim savings — if cloud costs dropped because product teams shut down services, that's not a platform win. Only attribute savings from platform-driven changes like right-sizing automation, spot instance adoption, or build cache improvements.
Avoiding Vanity Metrics
Some metrics look impressive in presentations but don't indicate platform health. "Number of deployments this month" is a vanity metric if it includes automated dependency updates that don't represent human effort. "Number of services in the catalog" doesn't mean anything if half of them are stale registrations that nobody maintains.
The test for a useful metric: if this number changes, will we do something differently? If deployment frequency doubles but change failure rate also doubles, the platform is shipping broken code faster, not improving delivery. If catalog coverage reaches 100% but scorecards show most entries are incomplete, you've got checklist compliance, not real adoption.
Pair every activity metric with an outcome metric. Deployments per day paired with change failure rate. Services registered paired with percentage with active ownership. Self-service actions executed paired with success rate without escalation. The ratio between the pair tells you if you're moving in the right direction or just moving.
Benchmarking Against Industry Standards
DORA's State of DevOps report provides industry benchmarks for deployment frequency, lead time, change failure rate, and time to restore. Your platform metrics should track where your organization falls — elite, high, medium, or low performance. But don't treat the benchmark as a goal. An organization that's "elite" on deployment frequency but "low" on change failure rate has optimized the wrong thing. Use benchmarks to identify the metric that's lagging furthest behind, and focus platform investment there.
Internal benchmarking between teams is often more actionable than industry benchmarking. If one team deploys 10x per day and another deploys weekly, the gap isn't necessarily a problem — they might have different risk profiles or deployment strategies. But if two teams with similar workloads have dramatically different lead times, the slower team likely has a platform friction that's worth investigating. The platform team's job isn't to make all teams look the same — it's to remove the friction that holds some teams back.