[What DORA Doesn't Measure, and What We Did About It: A CTO's Perspective]

Important note before we start:

My team uses Enji in production; the examples in this article are based on that setup.

I'm a CTO with a complicated relationship with DORA metrics because they consistently answer a different question than the one I actually need answered.

To be clear: I'm not dismissing them. Deployment frequency, lead time for changes, change failure rate, time to restore service, and (in the updated framework) reliability are legitimate indicators of pipeline health. They measure how efficiently the delivery machinery is running. For years, they were the closest thing engineering leadership had to an objective view of team performance, and in many organizations, they still are.

The problem I kept running into was that a team can show excellent DORA numbers, while quietly accumulating the kind of structural problems that don't surface until a senior engineer leaves, a client escalates, or a release that should have taken two weeks takes nine.

DORA tells you how fast the water is flowing. It doesn't tell you how much sediment is building up in the pipe.

The distinction I've come to draw is between pipeline health and delivery health. Pipeline health is what DORA measures: the speed and reliability of the path from code commit to production. Delivery health is something broader: it encompasses everything that determines whether the engineering team is actually delivering value sustainably over time.

Pipeline health can be strong even as delivery health deteriorates. The signals that indicate this divergence are rarely captured in standard dashboards:

• Estimation accuracy is declining across quarters, not per sprint, which is where the trend actually lives.
• Rework rate is creeping up, particularly concentrated in specific modules or workstreams, a diagnostic signal that DORA has no category for.
• Cycle time variance widening in particular domains, revealing friction that the average cycle time completely obscures.
• Bug-to-feature ratio shifting as maintenance work starts crowding out development capacity.
• Review depth compresses as volume increases, and reviewers start triaging rather than genuinely reviewing.

None of these are captured by deployment frequency or lead time. A team shipping frequently to production can still be in serious trouble on all five dimensions simultaneously. I've seen it. The dashboards looked fine until they didn't.

The gap between pipeline health and delivery health is where most engineering teams' blind spots live, and closing it required a different category of tooling than what I'd been using.

The framing I've settled on:

DORA metrics are lagging indicators of pipeline performance.

What Enji calls delivery intelligence is the practice of maintaining leading indicators of team health, signals that tell you where you're headed before the destination becomes unavoidable.

In practice, this means tracking a different set of questions alongside the standard pipeline metrics.

Where is time actually going, versus where we planned for it to go? Estimation accuracy, trended across sprints, reveals whether the codebase is becoming more resistant over time, something velocity numbers will never catch until it's too late.

Which workstreams are generating disproportionate rework? Rework that clusters around specific modules is diagnostic. Those modules are where technical debt is concentrated, and they're rarely the ones that look problematic in a sprint review.

What does the collaboration pattern look like across the team? Declining engagement, shifts in communication frequency, and changes in how work moves between team members are early signals that often precede delivery problems by weeks. By the time they show up in output data, the underlying issue is already entrenched.

What is the financial cost of the work being done? Connecting engineering activity to project economics: cost per feature, margin by workstream, and budget burn rate against scope completion turns a technical conversation into one a CFO can engage with directly. A board doesn't need a translator in the room if the data already speaks their language.

Delivery intelligence extends DORA into a territory that pipeline metrics were never designed to cover.

The specific tool that shifted my routine most substantially was Enji's AI Activity Dashboard.

Before, my first pass at understanding team health was qualitative: standup notes, Slack tone, occasional one-on-ones where I tried to read between the lines. It worked, in the way that human pattern recognition always works: imperfectly, with significant lag, and with blind spots shaped by whose signals happened to reach me.

The AI Activity Dashboard gave me a quantitative layer underneath that. It tracks work activity across connected platforms, like commits, pull requests, code reviews, task updates, standup submissions, meeting participation, and communication patterns. It also compiles those signals into Productivity and Involvement scores for each team member, adapted for their role.

The role adaptation matters more than it might seem. An engineer spending 80% of their time on code contributions should score very differently from a delivery manager spending 70% in meetings and planning, and a system that doesn't account for that produces scores that actively mislead. The dashboard weights activities by function, which means the scores reflect actual performance patterns rather than the implicit assumption that everyone's job looks the same.

What I actually use it for is catching the two leading indicators that pipeline metrics never flag early enough: collaboration pattern and time allocation. I've had it flag a senior engineer's involvement dropping for two weeks running, and the conversation revealed he was deep in an architecture decision that wasn't tracked in Jira at all, not disengaging, but focusing on something that didn't show up as activity. The score was right about the pattern and wrong about the cause.

That's a distinction I've learned not to skip. Focus time shifting toward communications for a team that's starting to fragment, or someone's activity timeline showing consistent work outside normal hours; those are the signals I now catch early enough to act on rather than explain after the fact.

The second tool that changed how I work is PM Agent, and the specific problem it solves is one I'd underestimated for years: the cost of context assembly.

Every meaningful engineering decision requires reconstructing the current state of multiple projects from data scattered across task trackers, code repositories, communication platforms, and calendars. Before I could escalate a risk, approve a scope change, push back on a timeline, or flag a resource problem, I needed to understand what was actually happening. That understanding took thirty minutes on a good day. On a complex day, it took longer, and by the time I had the picture, conditions had often already shifted.

PM Agent cuts that to under a minute. I can ask, "What's the current state of the authentication module refactor, and what are the blockers?" and receive an answer assembled from Jira tickets, recent commits, PR comments, and standup logs, in plain language, with source references, in under a minute.

This is where the rework and estimation accuracy signals become actionable in practice. Knowing that rework is clustering around a specific module is useful data in a dashboard. Being able to ask, "What changed in the authentication module in the last two sprints, and what came back for rework?" and get a coherent answer from across four tools, that's what turns the signal into a decision. The same applies to estimation accuracy: PM Agent can tell me not just that estimates are drifting but also which workstreams are generating the drift and what the likely cause is, assembled from the same data I'd otherwise spend thirty minutes gathering manually.

The practical impact: I now check project state daily instead of twice a week, which means I'm catching scope drift a week earlier on average.

What PM Agent doesn't replace is judgment. I still decide what the information means, what to prioritize, and what to escalate. The synthesis is automated, but the decision-making is still mine.

The shift that mattered most at the organizational level wasn't internal. It was in how I present engineering health to the board and to client stakeholders.

Before delivery intelligence tooling, my board presentations were engineering presentations: DORA metrics, sprint completion rates, and output trends. Technically accurate, largely meaningless to a non-technical audience, and structurally incapable of answering the questions boards actually care about: are we on track, are we spending efficiently, and where are the risks?

What changed was the availability of business-language metrics produced directly from engineering data. Project Margins (cost incurred against value delivered, tracked in real time) closes the loop on the fifth indicator: the financial cost of the work being done. It answers the budget question in terms any CFO can evaluate, and it does so continuously rather than at the point when someone assembles a report. Delivery predictability answers the timeline question in terms that translate directly to client trust. Rework rate and bug-to-feature ratio: the workstream-level signals that reveal where technical debt is concentrated answer the risk question in terms that connect engineering decisions to business outcomes, which is the translation that board conversations require.

These are the same underlying data, rendered through Enji's Project Margins view and PM Agent's cross-tool synthesis, in a form that doesn't require me to translate in the room.

The board conversation changed because the data changed: not the engineering data itself, but the business-language rendering of it, available continuously rather than assembled manually for each presentation.

The involvement score case I mentioned earlier is the clearest example of the line I've had to learn to hold. 

A few months ago, PM Agent flagged a consistent drop in involvement score for one of our senior engineers across three consecutive weeks. The data was accurate, and the pattern was real. The interpretation the tool offered, declining engagement, and possible overload, was wrong.

The engineer had deliberately stepped back from ticket-level activity to focus on an architecture decision that wasn't tracked in Jira at all. From the outside, it looked like disengagement. From the inside, it was the most important work happening on the project that month.

I would have acted on that flag incorrectly if I hadn't had the conversation first. The tool gave me the signal, but it couldn't give me the context.

That's the line I've learned to hold consistently:

• Pattern visible in the data → tool's job. Flagging the drop, surfacing the anomaly, and quantifying the deviation from baseline.
• What the pattern means → my job. The conversation, the judgment call, the decision about whether to escalate or absorb.
• Estimates from historical data → a useful starting point. Confident wrong numbers are more dangerous than acknowledged uncertainty. PM Agent's scope risk models are directionally reliable; I don't treat them as authoritative.
• Cross-tool synthesis → verify before it reaches a client. Portfolio-level patterns hold up. Individual ticket-level details get spot-checked before anything goes into a report.

The value of delivery intelligence tooling isn't that it replaces engineering judgment. It's that it removes enough mechanical overhead, the data gathering, the synthesis, the status compilation, so that judgment can operate at the level it's supposed to.