Stop Measuring Commits

Most engineering managers are tracking metrics that make their developers want to quit. If you are looking at lines of code, commit frequency, or 'impact scores,' you are measuring noise.

You aren't running a factory. You're managing a complex system of state machines and human egos.

We’ve seen thousands of repositories at git11. The teams that ship the most aren't the ones with the most green squares on GitHub. They are the ones with the least amount of friction between an idea and a production environment.

The Jira Fallacy

Tickets are not progress. Closing a Jira task feels good, but it’s often just administrative overhead disguised as work.

We worked with a Series B startup last year that bragged about their 98% sprint completion rate. Their actual product hadn't seen a significant feature update in four months. They were experts at moving cards from 'To Do' to 'Done,' but they were terrified of their own codebase.

Velocity is a fake metric. If you double your velocity but your code is unmaintainable, you've just doubled the speed at which you're driving toward a cliff.

Stop rewarding 'busy-ness.' Reward the engineer who deletes 500 lines of dead code in src/legacy/utils.ts. That person did more for your long-term output than the guy who opened six PRs for button color changes.

The Reality of PR Latency

If you want to know why your team is slow, look at the time a PR spends in 'Review Required.'

This is the biggest silent killer in engineering. A developer finishes a feature, opens a PR, and waits. Their mental context begins to decay immediately.

By the time a peer reviews it three days later, the original author has moved on to something else. Now they have to context-switch back, remember why they chose that specific implementation in api_v2/handlers.go, and fix the merge conflicts that cropped up in the meantime.

We’ve found that teams with a p90 PR turnaround time of over 24 hours are 4x more likely to ship bugs. Context switching isn't free. It’s a tax that compounds daily.

Tooling as a Force Multiplier

High-performing teams don't have 'better' developers. They have better defaults.

If your CI takes 20 minutes to run, your engineers will stop running tests locally. They will push to a branch, go get coffee, check Slack, and get distracted. You just lost 30 minutes of deep work because your docker-compose setup is bloated.

Your CI should be under 5 minutes. If it’s not, drop everything and fix it. Delete the flakey tests. Cache your dependencies. Use esbuild instead of whatever legacy webpack mess you’re clinging to.

Automation isn't about being fancy. It's about reducing the cognitive load required to do the right thing. If npm run lint isn't a pre-commit hook, don't be surprised when your PRs are full of formatting arguments.

Knowledge Silos and the 'Bus Factor'

We see it in the data constantly: one or two engineers own 80% of the core logic. When they go on vacation, everything stops.

This is often misidentified as a 'seniority' issue. It’s actually a documentation and review issue. If your senior engineers are the only ones who can touch auth/token_provider.go, you don't have a leadership team; you have a bottleneck.

Force your seniors to review, not just do. If a junior can't understand the PR, the code is too clever. Clever code is a liability.

The Value of 'Boring' Tech

Choosing a New Shiny Framework™ is almost always a mistake for productivity.

We see teams spend months migrating from React to Svelte or plain CSS to Tailwind. Unless that migration solves a specific, measurable bottleneck in your cycle time, you are just playing with toys on the company's dime.

The most productive teams we analyze use stable, boring stacks. They use Postgres. They use Go or TypeScript. They don't spend their Fridays debugging the alpha build of a new build tool.

Productivity is found in the lack of surprises. Boring tech means fewer surprises.

What to Measure Instead

If you must look at a dashboard, look at these three things:

1. Lead Time for Changes: How long does it take from the first commit to it running in production? 2.

Change Failure Rate: How often do you have to push a hotfix because you broke something? 3. Recovery Time: When it breaks, how fast can you get it back up?

Everything else is theater. If your Lead Time is low and your Change Failure Rate is low, you are winning.

You don't need a more complex Jira workflow. You need a faster build, smaller PRs, and the courage to delete code that doesn't matter anymore.

Stop looking at the keyboard. Look at the pipeline.