Manager asks: "How productive is our team?" How do you answer? Lines of code? PRs merged? Tasks completed?

These metrics are wrong. A developer who wrote 100 lines of bad code that others have to debug is less productive than a developer who deleted 200 lines of unnecessary complexity. A developer who shipped a complete feature that solves customer problems is more productive than a developer who shipped 10 small features nobody uses.

Measuring developer productivity is hard. What actually correlates with real output?

Bad Metrics and Why They're Misleading

Lines of Code (LOC): Encourages verbose code. "If I refactor to remove 50 lines, I'm less productive?" Wrong.

Number of PRs: Encourages small PRs that don't complete features. A developer who merges 20 tiny PRs might be less productive than a developer with 2 comprehensive PRs.

Hours worked: Correlation with results is weak. An engineer doing focused work 5 hours might outperform someone in the office 10 hours.

Bugs fixed: Encourages creating bugs to fix them. Also ignores the fact that senior engineers prevent bugs while juniors fix them.

Better Metrics

Features shipped (that users use): Ask customers: which features matter? Measure shipped features that move the needle. A feature used by 1% of users is less productive than one used by 50%.

Code review efficiency: Time from PR open to merge. Long review times = work sitting idle. Time from PR feedback to addressing it = are developers responsive? Both matter.

Deployment frequency and lead time: How often does code reach production? How long between writing code and it being live? More frequent deployments with shorter lead times = higher productivity.

Customer-reported issues: Does code you write cause customer problems? More problems = less productive (you created work for others). Fewer problems = more productive (you write quality code).

Knowledge transfer: How much do you help the team? Mentoring juniors, writing documentation, helping on questions = high productivity. Working in isolation, leaving code others can't understand = low productivity.

Measuring Productivity Thoughtfully

Avoid surveillance and surveillance vibes: Monitoring every keystroke or log is counterproductive. Engineers resent it and it doesn't measure what matters.

Focus on outcomes, not activities: "This quarter we shipped three customer-requested features, each used by 40%+ of users" = productivity. Not "we coded 150 hours."

Use team metrics, not individual metrics: Team metrics measure the system. Individual metrics incentivize wrong behavior. Measure team velocity, team deployment frequency, team customer satisfaction.

Account for context: Onboarding period is naturally lower productivity. Refactoring technical debt has short-term productivity drop but long-term gains. Context matters.

Improving Productivity

You want higher productivity? Remove friction:

• Slow CI/CD pipeline? Fix it. Developers spend 30% of their time waiting for builds.
• Unclear requirements? Spend time on clarity upfront. Prevents rework.
• No local development environment? Set it up. Developers shouldn't be blocked by setup.
• Excessive meetings? Cut them. Protect deep work time.
• Technical debt piling up? Allocate time to pay it down. Faster development when code is clean.

The Real Metric: Is the Customer Happy?

Ultimately, developer productivity means: we built what customers wanted, shipped it quickly, it works reliably, and the code is maintainable.

Measure that. Everything else is details.