标签：#Leadership

A while back I set three targets for my engineering team. Not velocity. Not story points. Not "things shipped." Just three numbers. Together they tell me whether the work is moving the way it should, or whether next week is shaping up to be a fire-fighting week. I check two of them most days. The third I used to watch closely...until we lost the tool that measured it. Here they are, and why they earned their spot. Why these and not just velocity The first metric most engineering managers reach for is velocity. Story points completed, tickets closed, work merged. Velocity is worth watching. It is a lagging indicator...it tells you what already happened...but it still shapes what comes next. When a sprint's work doesn't get finished, it rolls into the following one, and that rollover eats into whatever you had planned. What velocity doesn't tell you is how the work moved...whether it moved in a way that's going to come back and bite you. For that you need numbers that describe the shape and quality of the work, not just the amount of it...ideally ones that flag a problem while there's still time to act. These three do that. 1. Average PR size Target: under 300 lines changed per PR. What it tells me: how well the team is decomposing work. A team consistently shipping oversized PRs isn't producing more... they're producing PRs that no reviewer can read carefully. Big PRs get rubber-stamped. Rubber-stamped PRs are where production bugs hide. The 300-line target isn't magic. It's roughly the size below which most reviewers will actually read every line. I tell my team to aim for under 300 changes and to treat 500 as a hard ceiling, give or take a handful of genuine exceptions. Past 500 changes, I consistently see quality, review time, and thoroughness all drop sharply...the PR stops getting read and starts getting skimmed. When the team's average creeps up over a few weeks, I have an early signal that one of three things is happening: Stories are too coarse. The work does

Engineering managers are almost entirely absent from the AI transformation discourse. There's a structural reason for that, and understanding it is the first step to doing something about it. Engineers write on the internet. C-suite decisions make headlines. Engineering managers absorb pressure from above, complexity from below, and produce outcomes that get credited in both directions. The system doesn't reward the EM voice publicly. But the EM position gives you something that's genuinely hard to replicate: accountability for what happens to the team, combined with proximity to all three layers of the problem at once. That's not a consolation prize. It's a specific kind of leverage, if you decide to use it deliberately. You're accountable for what nobody else fully sees Writers go where the audience is or where the authority sits. EMs are neither, which is why the playbooks keep missing them. Executives get advice that assumes frictionless implementation. Engineers get advice that assumes organizational stability. At the team level, neither holds. The EM isn't the only person with this view. A good Staff or Principal Engineer often has comparable exposure — technical depth, some business context, real influence on architecture decisions. In many organizations, the senior IC has more technical credibility than the EM and less organizational noise to cut through. The difference isn't the view. It's the accountability. When something goes wrong at the team level — delivery slips, quality degrades, an engineer burns out, AI adoption produces incidents instead of velocity — the EM is the one who carries it. That asymmetry is uncomfortable. It's also what makes the EM's perspective structurally different from everyone else's. You don't just see the intersection where the playbooks break down. You're responsible for what happens there. The question isn't whether that position is valuable. It is. The question is whether you're using it actively or just absorbing it quietl