Measure paved road adoption with a handful of ratios: how many services use the supported template and pipeline, how many teams keep using it over time, how long a new service takes to reach a secured pipeline, and how many exceptions are open. Pair those numbers with a short developer survey.
Start from the platform research
Both DORA and the CNCF platforms white paper treat an internal platform as a product, and both suggest measuring it like one. DORA points to the H.E.A.R.T. framework for adoption and retention: the rate at which new teams onboard and the rate at which they keep using the platform. The CNCF paper lists active users and retention, satisfaction surveys, and efficiency measures such as the latency to build and deploy a brand new service and the time for a new user to submit first code changes.
Security teams can borrow all of that and add a few controls specific measures.
A starter metric set
| Metric | Definition | Why it matters |
|---|---|---|
| Coverage | Services using the shared pipeline divided by all active services | Shows how much of the estate the road reaches |
| Retention | Teams still on the road after a set period divided by teams that joined | Shows whether teams stay by choice |
| Time to secured | Hours from creating a service to its first green security check | Shows setup friction |
| Open exceptions | Count of active exceptions, with owner and end date | Shows where the road does not fit |
| Developer satisfaction | A short survey score from road users | Shows how the road feels |
These definitions are suggestions, not a standard. Write yours down so the numbers mean the same thing next quarter.
How to collect the numbers
You do not need new tooling to begin. DORA and CNCF both advise using the smallest viable effort to gather feedback, and CNCF notes that simple surveys and analysis of user behaviour may be most valuable at first.
- Keep a service inventory. A list of repositories with an owner and a template or pipeline tag is enough.
- Read pipeline configuration. Whether a repo calls the shared pipeline is a fact you can check by search.
- Log exceptions in one place. A single file or tracker beats scattered chat messages.
- Run a three question survey. Ask whether the road saved time, what annoyed people, and what is missing.
Watch for misleading numbers
High coverage can hide a hollow road if teams call the shared pipeline but turn every check to warn without blocking. Track the share of checks in blocking mode alongside coverage. Likewise, low exception counts may mean the process is too painful to use, not that the road fits everyone. Compare against the survey.
DORA also cautions that platforms can sometimes decrease throughput and change stability if not carefully managed, so keep delivery measures such as lead time and change failure rate on the same page as your security numbers.
Try it yourself
Adoption is easier to sustain when monitoring is continuous rather than a quarterly review.
Click through it at your own pace, or open it full screen. Notice how a change in one service becomes visible without waiting for a scheduled report.
Where Safeguard fits
Safeguard's asset discovery and dependency scanning help you keep an accurate inventory of what exists and what each service depends on, which is the denominator for any coverage figure. You can try a free scan at gold.safeguard.sh/scan.
Quick check
What is a good adoption target?
There is no universal number. Pick a target tied to risk, for example full coverage of internet facing services first, and review it with the teams affected.
Should adoption be a performance metric for developers?
It is better as a platform team metric. Judging developers on it invites box ticking, while judging the road on it pushes the platform team to improve it.
Sources
Last reviewed: 19 October 2026.
