The number one metric is the outcome. Ship the product. Cut the latency. Lower the cost. That's the thing we're actually trying to move, and it's the only number the business genuinely cares about.
Everything else engineering managers love to track, velocity, cycle time, PR counts, sprint burndown, does not get you to that outcome. Watching cycle time does not ship the product. So the honest question is: if these metrics don't move the goal, why track them at all?
Because they're not delivery tools. They're planning tools. And planning is most of the job.
Planning and resourcing
This is where the numbers earn their keep. Do I have the right staffing to finish this project inside the quarter, or am I a person short? Am I spending too much engineering time and money to shave off a small amount of cost, and is the ROI even there? How fast are we delivering, and what's our rollback rate while we do it? A high rollback rate next to fast delivery usually means we're moving too fast for our own good. That pairing is the point. I never look at a speed number without a quality number stapled next to it, because any throughput metric on its own is trivially easy to game by cutting a corner you won't see until later. None of this ships anything. All of it tells me whether the plan is realistic.
Team health
Sprint health is the one I use here. Are we stretching enough, or coasting? Do we have enough work pointed at the milestones that actually matter? And is there a good mix, some big pieces and some small ones, so momentum feels natural instead of forced? A sprint that's all epics feels like wading through mud. A sprint that's all tiny tickets feels busy but goes nowhere. The mix is the signal.
Where the time goes
PR ratio and cycle time are the interesting ones, because they show where the team is actually spending its hours. Is the time going into reviews? Or is someone blasting through a stack of small tickets early and then babysitting twenty open PRs for the rest of the sprint? I watch these to keep delivery and review in balance, and to spread the accountability around so the work and the ownership don't pool in one person.
The AI wrinkle
AI changed what these numbers mean. It writes a big chunk of the first draft now, so diffs and PR counts climb fast and the team looks more productive than it has ever been. But the code still has to be read, understood, and owned by a human, and that part did not get faster. So the throughput numbers inflate while the review load quietly balloons onto whoever is actually doing the reviewing. This is exactly why I watch PR ratio harder than I used to. When someone is generating twice the code they were a year ago and reviewing half as much, that is not a productivity win. It is debt I will pay for later.
So are any of these good for judging how well an individual engineer is doing? Not really. That's not what they're for, and using them that way is how you teach people to game the number instead of do the work.
What they're actually good for is telling a story about the team, and giving the manager enough of the picture to make an informed call: adjust here, staff up there, slow down before the rollbacks pile up. The metrics don't hit the goal. They're how you decide what to do next.