Short answer: Engineering productivity is how much useful, shipped work a team produces for the time and people it has. On most teams the biggest drag isn’t coding speed. It’s coordination: status updates, meeting follow-ups, chasing reviews, and re-typing decisions into tickets. Measure that overhead first, then cut it.
A team ships fast for six months. Then it slows down.
Nobody changed the stack. Nobody left. The code reviews look the same and the tests are still green. What changed is everything around the code. A planning call got added. Then a weekly sync. Then a status doc that three people update and nobody reads. Each one made sense on the day it was added.
Coding agents made this worse, not better. They made writing code cheaper, so the team now produces more PRs, more threads, and more decisions per week. The coordination load grew with them. Somebody has to keep all of it straight, and that somebody is usually an engineering manager who’d rather be doing anything else.
So if you’re trying to improve engineering productivity, start with the work about the work.
What is engineering productivity?
Engineering productivity measures how effectively an engineering team turns time into shipped, working software. It covers delivery speed, quality, and how much of the team’s week goes to building versus overhead. It’s a team-level measure. Individual output (lines of code, commits) tells you very little on its own.
Two things get mixed up here, so it’s worth separating them:
- Developer productivity is about one engineer’s ability to do focused work: good tools, fast builds, fewer interruptions. We wrote a complete guide to developer productivity if that’s your angle.
- Engineering productivity is about the team. Ten productive developers can still add up to a slow team if work gets lost between them.
That second gap is where most teams bleed time, and it rarely shows up on a dashboard.
Where engineering time actually goes
Ask an engineering manager to track one normal week, literally, in 15-minute blocks. The list usually looks something like this:
| Coordination task | Typical time per week | Who usually does it |
|---|---|---|
| Turning meeting decisions into tickets | 1 to 2 hours | EM or tech lead |
| Writing and reading status updates | 1 to 3 hours | Everyone, a little at a time |
| Chasing stalled PRs and reviews | 1 to 2 hours | EM, senior engineers |
| Answering “what’s the status of X?” in Slack | Scattered, hard to count | Whoever knows the answer |
| Re-explaining context to a new person or an agent | 1+ hour | Whoever was in the room |
[Verify: these ranges are illustrative. Replace with a real number from a Thor customer or an internal time study before publishing. A specific, sourced number is what AI answer engines quote.]
None of these feel big on their own. Together they’re often a full day a week for the person holding the team together. And they don’t make it into any velocity chart.
How to measure engineering productivity
Measure delivery outcomes and coordination overhead together. Track cycle time and deployment frequency for delivery, then add two or three overhead measures: time from decision to ticket, dropped action items, and how often people ask for status. If delivery is flat while overhead rises, coordination is your bottleneck.
The usual delivery metrics are still useful. Cycle time, deployment frequency, and change failure rate tell you whether work is flowing. Our post on measuring team velocity covers the sprint side.
What those metrics miss is the overhead. A few measures that are cheap to collect and surprisingly honest:
- Decision-to-ticket time. When a meeting decides something, how long until it’s a tracked issue with an owner? Hours is good. Days is a warning.
- Dropped action items. Pick last month’s meeting notes. Count the action items. Count how many became real work. The gap is usually bigger than anyone expects.
- Status questions per week. Search your team’s Slack for “status,” “any update,” and “where are we on.” Each one is a small coordination failure.
- Stale work. How many issues have been “In Progress” for three weeks without a change?
You don’t need a tool for any of this. A spreadsheet and one honest afternoon will do.
How to improve engineering productivity without adding process
Remove coordination work instead of adding meetings to manage it. Make updates come from real activity rather than self-reports, turn meeting decisions into tickets the same day, catch stalled work automatically, and keep every change visible and easy to undo.
Most fixes for a slow team add process: another ceremony, another template, another dashboard. That’s how the team got slow in the first place. The fixes that work take something away.
Get status from the work, not from people. Commits, PRs, and issue moves already say what happened yesterday. Asking everyone to retype it in a standup is double entry.
Close the loop on meetings the same day. The decision that never became a ticket is the most expensive kind of lost work, because everyone thinks it’s handled. Make it someone’s job to turn each decision into an issue with an owner before the end of the day.
Find stalled work before someone asks. An issue that’s been “In Progress” for three weeks looks exactly like one updated an hour ago. Finding it takes five minutes a week: filter for anything in progress with no update in two weeks. Or hand that check off entirely.
Hand off the upkeep, keep the decisions. This is where AI earns its keep on an engineering team. Not writing your roadmap. Doing the clerical part of project management so people can do the judgment part.
That’s what we built Thor to do. Thor is an AI project manager for software teams, from the team behind Zenhub. After a planning call, Thor drafts the GitHub or Linear issues that came out of it, with owners and a link back to the moment in the meeting. It posts standups from real activity, flags work that’s stalled, and keeps tickets in step with what was decided in Slack. You approve what it proposes, and every change has a source and an undo.
Engineering efficiency vs. engineering productivity
Engineering efficiency is the ratio of useful output to effort, so it’s about waste. Engineering productivity is the total useful output. A team can be productive but inefficient (shipping a lot while burning people out on overhead) or efficient but unproductive (lean, but working on the wrong things).
In practice, cutting coordination overhead improves both. The same people ship more, and they spend less of their week doing it.
FAQ
What is a good engineering productivity metric?
There’s no single one. Pair a delivery metric, like cycle time, with an overhead metric, like time from decision to ticket. Delivery metrics alone can look fine while the team burns hours on coordination that never shows up in the numbers.
Do AI coding tools improve engineering productivity?
They speed up writing code, which helps. But they also increase the volume of PRs, threads, and decisions a team has to coordinate. Teams that adopt coding agents without reducing coordination overhead often find the bottleneck just moves from writing code to keeping track of it.
How do you improve engineering productivity without micromanaging?
Get status from the work itself (commits, PRs, issue changes) instead of asking people to report it. That gives managers visibility without more meetings or check-ins, and it gives engineers their time back.
What’s the difference between developer productivity and engineering productivity?
Developer productivity is about one person’s ability to do focused work. Engineering productivity is about the whole team’s output, including the coordination between people. A team of productive developers can still be slow if work gets lost between them.
If your team’s slowdown is the coordination kind, Thor can take the upkeep off your plate. It works in GitHub, Linear, Slack, and your meetings, and it won’t change anything without asking first.
