Software.com
Leading Indicators
The metric that tells you where your delivery process is stuck — and what to fix first.
The Leading Indicators dashboard — delivery bottlenecks surfaced by stage, sorted by where work is accumulating and where it's taking the longest.
Context
Software.com already gave engineering leaders a detailed view of productivity metrics — commits, PR cycle times, deployment frequency. But having data isn't the same as knowing what to do with it. Teams could see that delivery was slower than it should be, but not where the slowdown was coming from — whether work was accumulating in code review, whether CI was the bottleneck, or whether the issue was something further upstream. The metrics were there. The diagnosis wasn't.
The Problem
The theory of constraints says that in any system, there's always exactly one constraint limiting throughput — and optimizing anything other than that constraint doesn't move the needle. For software delivery, this means that improving deployment frequency doesn't help if code review is the bottleneck, and speeding up code review doesn't help if the issue is further upstream in planning or development.
The challenge was designing a product that could surface the actual constraint rather than presenting a list of metrics with equal weight. Engineering leaders didn't need more dashboards — they needed a clear answer to a specific question: where in the process is the work getting stuck, and what's the one thing to fix first?
The Approach
We mapped the software development lifecycle into discrete stages — development, review, merge, deployment — and built metrics for each. The key design decision was how to sort and prioritize them. Rather than displaying all stages equally, we surfaced the ones where the most work was accumulating and where it was taking the longest. Those two signals together — volume and duration — pointed to the constraint most worth addressing, and made it the obvious place to start.
The Solution
Stage Breakdown
The main dashboard sorted stages by the combination of accumulation and slowness that indicated a real constraint — so a stage with hundreds of PRs sitting in review appeared ahead of one with faster throughput. The goal was to give engineering leaders a clear starting point rather than a list of things to monitor simultaneously.
PR Drawer
Clicking into any stage opened a detailed view of the work items stuck there. For a review bottleneck, this showed exactly which PRs had been waiting longest, who the reviewers were, and what the work involved. Managers got the context to act, not just the signal that something was wrong.
Metric Drill-Down
Any metric could be broken down further — by team or sub-group, by repo, and by individual contributor. Objectives could be set and tracked over time, turning the bottleneck signal into an active goal: here's where we are, here's where we're trying to get, here's who and what is contributing to the gap.
The Outcome
Leading Indicators turned the “we're slow” problem into something specific and actionable: this stage, these PRs, this team. The one-constraint-at-a-time framing gave engineering leaders a clear place to start rather than a list of things to worry about simultaneously — and the drill-down path from stage to PR to contributor meant that the same tool that identified the problem also pointed to where to look for the fix.