The Engineering Metrics That Actually Matter Come From Your Issue History
By Fahad Ijaz · · 7 min read
Most engineering dashboards measure motion. Story points closed, PRs merged, tickets moved right. They look precise and tell you almost nothing about whether the team is spending its time well, where work keeps getting stuck, or who your organization quietly depends on. The information that answers those questions is already sitting in your issue history — you've just never been able to read it as one coherent picture.
One Picture Across Every Tracker
The first problem is that the history is scattered. Some teams live in GitHub Issues, others in Linear, others in Jira, and most real organizations use more than one at once. That fragmentation is why nobody has a straight answer to 'what did we actually work on last quarter?' The fix is to treat every source as one dataset: issues by source, side by side, so a cross-stack organization finally sees the whole board instead of three partial ones.
Work Mix: Where the Time Really Went
Once the history is unified, the most revealing chart is the simplest: what kind of work was this? Features, bugs, chores, docs — as a mix, and as a mix that shifts quarter over quarter. A team that believes it's building new things but is actually spending 60% of its issues on bug fixes is running a maintenance shop that thinks it's a product team. You can't have that conversation honestly until you can see the ratio and watch it move over time.
Throughput and Blockers: Where It Gets Stuck
Opened versus resolved per quarter tells you whether you're keeping up or falling behind — a resolved line that keeps dipping under the opened bars is a backlog quietly growing. But the more actionable view is blockers: what most often held work up. When the same reason shows up quarter after quarter — waiting on review, missing owner, external dependency — that's not bad luck, it's a process leak you can actually fix.
Ownership and Concentration Risk
Aggregate the history by who drove the work and a quieter truth appears: how concentrated your delivery is. If one person accounts for a large share of resolved issues, that's not a gold star — it's a single point of failure wearing a cape. Surfacing the concentration as a risk signal, with a clear healthy-to-danger band, turns 'we'd be in trouble if they left' from a hallway anxiety into a number you can act on before it becomes a resignation letter.
The Narrative, Grounded in the Numbers
Charts still need a reader. The last step is a written executive summary over the exact same data — scoped to a quarter or to the whole history — plus a 'what shipped' digest built from real git history rather than from whatever people remembered to write in release notes. That's the difference between a board deck that says 'we made progress' and one that says what progress, in which areas, and where the risk moved.
The Takeaway
Your issue tracker is a multi-year record of how your team actually spends itself, and almost nobody reads it. Unify it across your tools, look at work mix, throughput, blockers, ownership, and concentration together, and you stop guessing at the health of your engineering org. The data was always there. The point is finally being able to see it.