We have all seen the dashboards: velocity charts, commit counts, ticket throughput.
They make for tidy reports. They look great in an executive update. But let’s be honest, do they actually tell us if our teams are building the right things, in the right way, at the right time?
A recent Hacker News discussion, “Let’s stop pretending that managers and executives care about productivity”, hit a nerve. It pointed out a hard truth: too often, “productivity” is measured by what is easy to count rather than what actually matters. For technology leaders, this raises a critical question: are we optimizing for activity or for impact?
Before we can improve how we measure productivity, we first need to understand why so many traditional metrics fall short. Many organisations start with good intentions, tracking indicators that seem logical on the surface. Over time, these measures can drift away from reflecting real business value and instead become targets in their own right. This is where the gap emerges between looking productive and actually creating outcomes that matter.
We have seen this play out in practice. Atlassian warns on relying heavily on raw JIRA velocity scores when they realized it encouraged teams to inflate story point estimates rather than improve delivery outcomes. Google’s engineering teams have spoken about the risk of “metric gaming” and have stressed the importance of pairing speed indicators with measures of impact and reliability.
Why Shallow Metrics Fail
Several years ago, I was in a leadership meeting where a project was declared a success because the team had delivered 30% more story points than the previous quarter. On paper, it was an impressive jump. In reality, those features did not move the needle on adoption, customer satisfaction, or revenue. We had measured output, not outcome.
High-functioning teams do not just ship more. They deliver meaningful business value. That is where our measurement frameworks need to evolve.
DORA Metrics: A Better Starting Point
The DevOps Research and Assessment (DORA) group has done extensive research to identify four key metrics that balance speed and stability:
- Deployment Frequency – How often you deploy code to production.
- Lead Time for Changes – How quickly a change moves from code commit to production.
- Change Failure Rate – How often deployments cause a failure in production.
- Mean Time to Recovery (MTTR) – How fast you recover from a failure.
These are powerful because they connect process efficiency with system reliability. For example, I joined a project that was deploying only once a quarter. While this schedule reduced change risk, it also created long lead times for customer-facing features and made responding to feedback painfully slow. Over the course of six months, we incrementally improved our processes, automated more of our testing, and streamlined our release management. The result was moving to a two-week deployment cycle, which allowed the team to deliver value faster, respond to market needs more effectively, and reduce the risk of large-scale release failures by making changes smaller and more manageable.
The caution: if you treat DORA as a leaderboard, you will get teams “optimizing” metrics in ways that undermine quality. Used correctly, they are a diagnostic tool, not a performance scorecard.
Connecting DORA to Business Outcomes
For technology leaders, DORA metrics should not exist in isolation. They are most valuable when they are tied to business results that the board cares about.
- Deployment Frequency is not just about speed, it is about how quickly you can respond to market shifts, regulatory changes, or customer feedback.
- Lead Time for Changes impacts time-to-revenue for new features and directly affects competitive advantage.
- Change Failure Rate affects customer trust and brand reputation, both of which have measurable financial consequences.
- MTTR influences client retention, contractual SLAs, and the ability to contain operational risk.
When framed this way, engineering leaders can make the case that improving DORA scores is not just a technical goal, but a growth and risk mitigation strategy. This connection between delivery performance and commercial outcomes is what elevates technology from a support function to a strategic driver.
Innovative Metrics to Watch
Forward-thinking companies are experimenting with new ways to measure productivity:
- Diff Authoring Time (DAT) – Used at Meta, this tracks how long engineers spend authoring a change. In one experiment, compiler optimisations improved DAT by 33%, freeing up engineering cycles for higher-value work.
- Return on Time Invested (ROTI) – A simple but powerful concept: for every hour spent, what is the measurable return? This is especially useful in evaluating internal meetings, process reviews, or new tool adoption.
The Pitfalls of Over-Measurement
There is a dark side to metrics. Wired recently called out the “toxic” productivity obsession in tech where every keystroke is tracked and performance is reduced to a spreadsheet. It is a quick path to burnout, attrition, and short-term thinking.
As leaders, our job is not to watch the clock. It is to create an environment where talented people can do their best work, sustainably.
Takeaway
Productivity in product development is not about being busy. It is about delivering lasting value.
Use DORA as a starting point, augment it with reliability, developer experience, and business outcome metrics, and experiment with emerging measures like DAT and ROTI. But always remember: metrics are there to inform, not to define, your team’s worth.
Thoughts
The best technology organizations measure what matters, discard vanity metrics, and connect engineering performance directly to business value. Metrics like DORA, when used thoughtfully, help teams identify bottlenecks and improve delivery. Innovative measures such as DAT and ROTI push our understanding of productivity further, but they only work in cultures that value trust and sustainability. As technology leaders, our challenge is to ensure that our measurement practices inspire better work rather than simply more work.
bencoding 