Metric trees for engineering teams

Software engineering resists simple measurement in ways that other functions do not. A sales team can point to revenue closed. A marketing team can show pipeline generated. Engineering output is harder to quantify because the relationship between effort and outcome is indirect, non-linear, and often delayed by months.

The temptation is to measure what is easy to count: lines of code, commits per day, tickets closed, story points burned. These proxy metrics are seductive because they are abundant and precise. But precision is not accuracy. A developer who refactors a critical module, deleting two thousand lines of code while making the system faster and more maintainable, looks unproductive by every activity metric. A developer who ships a thousand lines of poorly tested, tightly coupled code looks highly productive by the same measures. The activity metrics get the story exactly backwards.

This is not just a measurement problem. It is a behavioural one. When engineering teams are evaluated on activity metrics, they optimise for activity. Pull requests get split into smaller pieces to inflate counts. Story points get inflated so velocity looks good. Code reviews become rubber stamps because the incentive is throughput, not quality. The metrics that were supposed to improve performance actively degrade it. This pattern, known as Goodhart's Law, is especially dangerous in engineering because the feedback loop between bad code and business consequences can take months or years to surface.

The solution is not to give up on measurement. It is to measure differently. Instead of counting outputs, you measure the properties of the engineering system: how quickly changes flow from idea to production, how often those changes cause problems, how fast the team recovers when things break, and how the humans doing the work experience their environment. These are system-level properties that resist gaming because they are interconnected. You cannot improve deployment frequency by shipping broken code because change failure rate will catch you. You cannot reduce cycle time by skipping reviews because defect rates will rise. A metric tree makes these connections explicit.

An engineering metric tree should start from a concept that connects engineering to the broader business: engineering effectiveness. This is not a single number but a composite idea that decomposes into the dimensions through which engineering creates value. A well-structured tree typically branches into four pillars: delivery speed, quality, reliability, and developer experience.

Delivery speed captures how quickly the team turns ideas into working software in the hands of users. Quality captures how well that software works and how few defects reach production. Reliability captures how consistently the system performs and how quickly the team responds when it does not. Developer experience captures the health of the environment in which engineers work, because sustainable performance depends on sustainable working conditions.

The tree below shows a representative engineering metric tree. Your specific tree will differ based on your architecture, team structure, and business model, but the structural pattern applies broadly.

Notice that the four DORA metrics, deployment frequency, lead time for changes (captured here as cycle time), change failure rate, and time to restore service (MTTR), appear naturally across different branches of this tree. DORA metrics are not a separate framework that competes with a metric tree. They are nodes within it. The tree gives them context by showing how they relate to each other and to the broader dimensions of engineering effectiveness.

The tree also includes metrics that DORA does not cover. Developer satisfaction, build time, focus time ratio, and on-call burden are all dimensions of the engineering system that influence the DORA metrics but are not captured by them directly. A team with poor developer experience will eventually show declining delivery speed and quality, but by the time DORA metrics reflect that decline, the damage is already done. The broader tree catches the leading indicators.

The most common criticism engineering leaders face in executive conversations is some variation of "we spend forty per cent of our budget on engineering and we cannot tell what we are getting for it." This is not an engineering failure. It is a communication failure caused by a missing link between engineering metrics and business metrics.

A metric tree solves this by making the connection explicit. Engineering effectiveness does not exist in isolation. It feeds into business outcomes through specific, traceable paths. Delivery speed determines time to market for new features and products, which directly affects revenue growth and competitive positioning. Quality determines how much rework and support burden the business carries, which affects gross margin and customer satisfaction. Reliability determines whether customers can depend on the product, which affects retention and brand reputation. Developer experience determines whether the organisation can attract and retain the talent it needs, which affects hiring costs, onboarding time, and long-term capacity.

These are not vague correlations. They are structural relationships that can be modelled in a metric tree. When an engineering leader can show that improving cycle time by thirty per cent led to shipping a critical feature two months earlier, which contributed to closing a specific enterprise deal, the "what are we getting for our engineering spend" question has a concrete answer.

In KPI Tree, you can build a single tree that spans from business-level metrics like revenue and retention down through product and engineering metrics to the operational levers that individual teams control. This makes the connection between engineering work and business outcomes navigable rather than abstract. When a board member asks why the company should invest in reducing technical debt, the tree shows exactly how that investment flows through build time, cycle time, and delivery speed to affect time to market and revenue.

The DORA metrics, developed by the DevOps Research and Assessment team and validated by research across more than thirty-two thousand engineering professionals, have become the closest thing engineering has to a standard performance framework. They measure four properties of the software delivery process that consistently separate high-performing teams from the rest.

The critical insight from DORA research is that high-performing teams do not trade speed for stability. They excel at both simultaneously. This is counterintuitive but well-supported by data. Teams that deploy more frequently tend to have lower change failure rates because smaller deployments are easier to test, easier to review, and easier to roll back. Teams that invest in fast recovery tend to deploy more confidently because the cost of a failure is lower.

A metric tree captures this interdependence naturally. Delivery speed and quality are not competing branches. They are connected branches that reinforce each other when the engineering system is healthy and undermine each other when it is not. If your tree shows deployment frequency increasing while change failure rate is also increasing, that is a signal that the team is shipping faster but cutting corners on quality. The tree makes that trade-off visible before it becomes a crisis.

DORA metrics are powerful but not complete. They focus on the software delivery process and do not directly measure code quality, developer experience, or the alignment of engineering work with business priorities. That is why they belong in a broader metric tree rather than standing alone.

Not all engineering teams ship features to end users. Platform teams, infrastructure teams, and developer tooling teams create value by making other teams more effective. Their metrics belong in the engineering metric tree, but the decomposition looks different because their "customer" is another engineering team rather than an external user.

Platform teams should measure the developer experience they provide. Build time, CI pipeline duration, deployment pipeline reliability, environment provisioning time, and documentation quality all reflect how well the platform serves its internal customers. These metrics feed directly into the delivery speed and developer experience branches of the broader engineering tree. When the CI pipeline takes forty-five minutes, every product team is slower. When environment provisioning is manual and takes two days, the entire organisation pays a tax on experimentation.

Infrastructure teams should measure cost efficiency alongside reliability. Cloud spend per unit of business output (per request, per user, per transaction) is the infrastructure equivalent of gross margin. It connects directly to the cost structure of the business. A metric tree that includes infrastructure cost decomposition helps engineering leaders have informed conversations with finance about where infrastructure investment is paying off and where it is not.

1. 1

   Measure internal customer satisfaction

   Run a short quarterly survey asking product teams to rate the platform on reliability, speed, documentation, and support. This is the platform equivalent of NPS and provides a leading indicator of whether the platform is enabling or hindering the teams it serves.

2. 2

   Track self-service adoption

   Measure the percentage of common tasks (creating a new service, provisioning an environment, updating a configuration) that teams can complete without filing a ticket or waiting for platform team assistance. High self-service rates indicate a well-designed platform.

3. 3

   Monitor infrastructure unit costs

   Track cloud and infrastructure costs normalised to a business unit: cost per request, cost per active user, or cost per transaction. This metric belongs in both the engineering tree and the finance tree, bridging the two functions.

4. 4

   Decompose CI/CD pipeline time

   Break pipeline duration into its components: checkout, build, unit tests, integration tests, security scans, and deployment. This decomposition reveals which stage is the bottleneck and focuses optimisation effort where it will have the most impact.

The challenge for platform and infrastructure teams is that their impact is felt indirectly. A platform improvement that shaves ten minutes off every deployment does not show up as a line item in a financial report. But when you trace it through the metric tree, from pipeline duration to cycle time to delivery speed to time to market, the business impact becomes quantifiable. The tree provides the causal chain that justifies platform investment.

Engineering metrics are especially vulnerable to gaming because software development involves many degrees of freedom. A developer can satisfy almost any single metric by adjusting their behaviour in ways that harm the system overall. Split a pull request into ten trivial pieces to boost deployment frequency. Skip integration tests to reduce pipeline time. Close tickets as "won't fix" to improve resolution rates. Every metric, taken in isolation, can be gamed.

The structural advantage of a metric tree is that it makes gaming visible. Metrics in a tree are interconnected: improving one while degrading another creates a detectable anomaly. If deployment frequency spikes but change failure rate also rises, the tree reveals that the improvement is illusory. If cycle time drops but defect escape rate increases, the tree shows that speed came at the expense of quality. Gaming one branch creates a signal in another branch.

Building an engineering metric tree is not an exercise you complete in a single workshop. It is an iterative process that starts simple and becomes more detailed as the organisation's measurement maturity grows. Start with the four pillars described in this guide, delivery speed, quality, reliability, and developer experience, and populate each with two or three metrics you can already measure. You do not need perfect data coverage to start. You need a structure that makes your current understanding explicit and highlights the gaps worth filling.

1. 1

   Start with DORA as your baseline

   The four DORA metrics give you a proven starting point with well-established benchmarks. Measure deployment frequency, lead time for changes, change failure rate, and time to restore service. Place each in the appropriate branch of your tree.

2. 2

   Add developer experience metrics

   DORA covers the delivery pipeline but not the humans operating it. Add build time, CI pipeline duration, focus time ratio, and a regular developer satisfaction survey. These are leading indicators that predict future changes in your DORA metrics.

3. 3

   Connect upward to business metrics

   Work with product and business stakeholders to make the link between engineering effectiveness and business outcomes explicit. Map delivery speed to time to market. Map quality to support cost and customer satisfaction. Map reliability to retention and SLA compliance.

4. 4

   Decompose where you find bottlenecks

   If cycle time is your biggest problem, decompose it into coding time, review time, CI time, and deployment wait time. If reliability is the issue, decompose MTTR into detection, diagnosis, and remediation time. Go deeper only where the investigation demands it.

5. 5

   Assign ownership at the leaf level

   Every metric at the bottom of your tree should have a named owner: a team or individual who monitors it and is empowered to investigate when it moves. Without ownership, the tree is a diagram. With it, the tree is an operating system.

The most important principle is to resist the urge to measure everything from the start. A tree with fifty leaf metrics and no data behind half of them creates the illusion of rigour without the substance. Start with five to ten metrics you can actually instrument and track. Add more as your tooling matures and as specific questions arise that the current tree cannot answer.

KPI Tree is designed for exactly this kind of iterative construction. You can start with a simple tree, connect it to your existing data sources, and expand it over time. The visual tree structure makes it easy for engineering leaders to communicate with executives, for team leads to understand their scope of ownership, and for everyone to see how individual work connects to the organisation's goals.