A deep exploration of why engineering teams default to ticket counts, how Goodhart's Law corrupts the signal, and how to move toward meaningful measurement.
Software engineering work is invisible until it ships. Issue trackers were invented to make that invisible work legible to teams and managers — a coordination tool that gradually became a performance measurement instrument.
Unlike manufacturing, engineering work-in-progress is invisible. Managers can't walk the factory floor and see what's happening. Issue trackers emerged as a way to make the work legible — a reasonable solution to a real problem.
Making work visible is not the same as measuring productivity. Ticket data is operationally useful for coordination and bottleneck detection. The mistake is treating ticket throughput as a signal of engineering productivity.
In many organizations, ticket metrics serve a social function: signaling to management that engineers are working and money is being spent productively. This social role makes them sticky even when everyone acknowledges they're imperfect.
Ticket data is always available and auto-generated. It requires no instrumentation investment. It produces daily updates. Alternative metrics — DORA, outcome signals — take time and infrastructure to build. Convenience wins by default.
The moment ticket count becomes a performance target, Goodhart's Law kicks in and the metric stops measuring what it was designed to measure.
The root confusion underlying ticket metrics: conflating what engineers produce (output) with what users and the business experience as a result (outcome). Organizations that optimize for output systematically underinvest in quality.
The four DORA (DevOps Research and Assessment) metrics are empirically validated predictors of software delivery performance and organizational outcomes — developed through multi-year research by Google. Unlike ticket counts, they measure the full delivery pipeline and are hard to game because they reflect real system behavior.
Metric choices powerfully shape engineering culture. What you measure is what you value. What you value is what your team optimizes for.
Transitioning to better measurement is an organizational change project, not just a tooling change. These steps are designed to be sequential — each builds on the trust established by the previous one.
Inventory all metrics your team tracks in your issue tracker. For each metric, ask: what decision does this inform? What behavior does it incentivize? This audit surfaces which metrics coordinate work and which substitute for trust.
Name the underlying question before choosing new metrics. 'Is the team productive?' is too vague. Better: 'How quickly do we deliver value?' · 'How often does our software fail?' · 'How fast do we recover?' Metrics are only meaningful when tied to an explicit question.
Set up data pipelines for all four DORA metrics: Deployment Frequency, Lead Time for Changes, Change Failure Rate, and MTTR. These require CI/CD integration and incident tracking but are highly resistant to gaming because they reflect actual system behavior.
Partner with product and data to identify user-facing outcome metrics you can connect to engineering work. Even imperfect outcome signals reframe the conversation from 'how many tickets did we close?' to 'what changed for users?'
Have explicit conversations about how data will — and will not — be used. Commit to treating problems revealed by metrics as systemic opportunities, not individual failures. Without this foundation, any metric will be gamed or hidden. Psychological safety is a prerequisite.
Use new metrics in stakeholder updates alongside existing ones. Narrate the story: 'We shipped X features. Our lead time improved by Y days. Our change failure rate is Z%.' Prove that new metrics are richer and more actionable before asking stakeholders to give up the familiar velocity chart.
No metric system is permanent. Schedule quarterly reviews: Are our metrics still answering the right questions? Are any being gamed? Have we introduced new work types needing new measurement? Healthy metric systems evolve as organizations and products mature.
Tickets are visible and countable. In the absence of clear outcome signals, managers reach for whatever data is readily available — and issue-tracking systems produce a continuous stream of quantifiable events: tickets opened, tickets closed, points completed. This makes them tempting as productivity proxies even when they don't accurately capture the value engineering is delivering.
Goodhart's Law states that when a measure becomes a target, it ceases to be a good measure. When ticket count or velocity is used as a performance target, engineers naturally (and rationally) optimize for closing tickets rather than solving underlying problems. This corrupts the metric and creates perverse incentives that reduce actual engineering effectiveness.
Teams exhibit metric gaming behaviors: splitting large tickets into many small ones, avoiding hard problems that don't resolve quickly, inflating story-point estimates, closing tickets prematurely, and investing in low-impact but easily ticketed work over high-impact architectural improvements that are difficult to represent in a tracker.
DORA metrics — Deployment Frequency, Lead Time for Changes, Change Failure Rate, and MTTR — were developed through multi-year research by Google's DevOps Research and Assessment team. They are empirically validated predictors of software delivery performance and organizational outcomes. Unlike ticket counts, they measure the full delivery pipeline and are harder to game because they reflect real system behavior.
Sustained ticket metrics as performance signals cultivates cultures of busyness over impact. Engineers learn to look busy rather than be impactful. It discourages investment in quality, documentation, testing, and architectural work. It also creates incentives to hide complexity and avoid honest conversations about what's actually hard.
Yes — ticket data is valuable for operational coordination, identifying bottlenecks in workflow, and capacity planning. The problem is not the data itself but using ticket throughput as a performance target. Descriptive use is fine; prescriptive use creates dysfunction.
Outcome metrics measure what users or the business actually experience as a result of engineering work: error rates, feature adoption, retention, latency, revenue impact. They are harder to collect and lag the work that caused them, but they are resistant to gaming because they reflect reality in the world rather than activity inside the team's tooling.
Lead time measures from when work is requested until it ships; cycle time measures from when active development begins until it ships. Lead time captures queue and prioritization delays; cycle time isolates execution speed. Together they reveal where bottlenecks live — in the backlog or in delivery.
It's a prerequisite. In low-safety environments, metrics become weapons. Engineers hide problems, avoid surfacing risk, and game whatever is being measured to avoid punishment. Better metrics only work in contexts where engineers trust that honest reporting about difficulty, failure, or slowness will be met with curiosity rather than blame.
Ticket metrics are cheap to collect and produce daily updates. Executives feel pressure to demonstrate accountability through numbers. Velocity charts provide a reassuring (if misleading) sense of control. Changing metrics means changing the implicit accountability contract — uncomfortable even when clearly justified.
Start by being transparent about why current metrics are being used and what question they're actually answering. Introduce complementary metrics alongside ticket data rather than replacing it overnight. Build the data infrastructure. Tell a story with the new metrics before retiring the old ones. Earn organizational trust in the new system gradually.
'Integrated by Design' explores how engineering organizations can be structured to deliver effectively through platform thinking, clear ownership, and aligned incentives. Its lens on organizational design is directly relevant: you cannot measure your way to good outcomes without first designing the system in which measurement will live.