How Engineering Managers Should Measure Team Performance
If you measure an engineering team wrong, you will get exactly what you asked for – and destroy what you actually wanted. Counting tickets closed gets you more tickets closed. Counting lines of code gets you more lines of code. Neither tells you if you are building the right thing, building it well, or building a team that can keep doing it next year.
Good measurement is not about surveillance. It is about creating a feedback loop for the system you lead. This guide shows how high-performing managers combine DORA and SPACE into a balanced scorecard, track delivery, quality and team health as trends, and roll it out without creating a surveillance culture.
Activity is not productivity
The instinct to measure individual output – tickets closed, commits, lines of code – comes from a manufacturing mindset applied to knowledge work. A single well-placed architectural decision can save a team months; a thousand lines of code can be a net negative if they add complexity the team pays for later.
Any metric an individual can directly control becomes a target the moment it is tied to evaluation – and once it is a target, it stops measuring what you actually wanted. This is Goodhart’s Law, and engineering orgs rediscover it constantly: measure lines of code and you get bloated diffs; measure tickets closed and you get tickets split into slivers; measure velocity and you get story point inflation. None of this is engineers being dishonest – it is rational behavior in response to a badly designed incentive.
In regulated banking environments the distinction matters twice: data collected for compliance – change-approval logs, audit trails – proves you followed process. It says nothing about whether the team is fast, healthy, or improving. Do not confuse the regulator’s evidence trail with your management dashboard.
Separate system, team, and individual
Most measurement failures come from collapsing three layers into one number. Keep them separate – they answer different questions, for different audiences, on different cadences.
The moment you rank individuals using metrics designed for system or team health, you break both the metric and the trust. System and team metrics are collective signals – no single person owns them, and no single person should be judged by them.
DORA + SPACE – use one inside the other
Do not invent a framework from scratch. The industry has already done the research. Use DORA to see delivery health and SPACE to see whether that health is sustainable.
Together these provide a baseline and clues about where to improve. By focusing on all four, you get actionable insights into how teams deliver value. Elite teams optimize for all metrics, not just speed – shipping daily does not help if a third of deploys roll back.
A four-layer dashboard you can review every two weeks
You need all four. Teams that only track delivery become fast but burnt out. Teams that only track health feel good but do not ship. Review trends, not snapshots – one bad sprint is noise, three quarters of rising cycle time is signal.
What not to measure – ever
Velocity is an introspective planning tool, not a performance target. As Stack Overflow’s engineering leadership notes, it can diagnose a team but it is not business impact. DX lists it among flawed productivity metrics precisely because teams inflate it.
Watch for gaming – pair every metric
If velocity is high but change failure rate is also high, both numbers are telling you something. Do not celebrate one and ignore the other. More than five to seven metrics per team creates noise, not signal.
How to implement without creating a surveillance culture
A practical rollout: 30–60–90 days
Audit and baseline
Kill pure vanity metrics – raw commit counts, lines of code, story points used for cross-team comparison. Wire up baseline DORA metrics from CI/CD and incident tooling you already have. Run a DORA Quick Check assessment.
Introduce the scorecard openly
Decide weighting with the team in the room. Launch a minimal dashboard with pre-built integrations rather than a custom pipeline. Track deployment frequency, lead time, and change failure rate at team level. Run the first monthly review as a working session, not a report-out.
Add health and decouple from reviews
Add a brief monthly survey – three to five questions on satisfaction and perceived productivity – keep it anonymous. Pair the scorecard with growth conversations as context, not scoring input, and confirm with leadership that compensation is explicitly decoupled from the team dashboard.
Startup vs enterprise – weight differently
Do not compare metrics across teams with different contexts – a team on a legacy monolith will naturally have different lead time than a greenfield microservices team. Compare each team to its own baseline over time.
Popular questions about measuring team performance
Q1Should I measure individual developer productivity by commits or pull requests?
No. These are activity counts, not outcome measures, and they are trivially gamed the moment someone knows they are being watched. Use them at most as a private sanity check, never in a review or scorecard. Individual evaluation should stay qualitative – 1:1s, peer feedback, and observation over time.
Q2What if senior leadership demands individual output metrics?
Push back with the scorecard’s business-impact and quality dimensions instead – they answer the same underlying question “is this investment paying off?” without creating perverse incentives. If you are overridden, at minimum make sure the team understands the limits of what is being measured.
Q3Is velocity a good performance metric?
No – it is a planning tool. Velocity can diagnose a team introspectively, but as a target it invites inflation and punishes collaboration. Use throughput of items per week if you need a flow signal, and never compare velocity across teams.
Q4How is this different from just adopting DORA?
DORA is necessary but not sufficient – it measures the delivery system, not team health or individual growth. Treat it as one quadrant of a broader scorecard that also covers quality, people, and business impact.
Q5How often should the scorecard change?
Review weighting at most quarterly, and only when context genuinely shifts – for example new system criticality or a major incident. Changing it too often makes trends impossible to read. Keep the set small, five to seven metrics per team at most.
Q6What is a good starting stack if we measure nothing today?
Pick four: throughput – items per week – for trends, cycle time by stage for bottlenecks, change failure rate for quality, and a quarterly team health survey for sustainability. Review them together monthly and tie every anomaly to a conversation about process.
Q7How do we avoid Goodhart’s Law?
Never use metrics for individual performance reviews, present them as diagnostics not scorecards, limit the number tracked, automate collection, and review them in retros where the first question is always “what is this telling us about the system?” rather than “who is underperforming?”
Q8Do we need an elaborate dashboard from day one?
No. Start with conversations rather than infrastructure – the DORA team recommends a Quick Check assessment first. Use pre-built integrations and avoid building custom pipelines until the value is proven. The goal is learning, not reporting.
Measure the system. Improve the system. Trust the people in it.
The best engineering managers do not measure to judge. They measure to learn. If after three months you can answer “are we shipping faster and safer than last quarter?” “is quality improving with less rework?” “does the team have enough focus and safety?” and “can we connect our work to a real customer outcome?” – you are winning.
Start small, pick one or two metrics from the delivery flow dimension, get a baseline, and have a conversation with your team about what the numbers mean. Make one improvement. Measure again. Repeat. That is how measurement becomes a shared tool rather than surveillance imposed on them.