> Markdown version of [/videos/1131-metrics-handle-with-care-the-paradox-of-measuring-team-performance](https://www.wearedevelopers.com/videos/1131-metrics-handle-with-care-the-paradox-of-measuring-team-performance). Every page supports `.md` or `Accept: text/markdown`. Links point to the HTML versions so they work for humans too. Agent guide: [/agents.md](https://www.wearedevelopers.com/agents.md).

---

# Metrics Handle with Care: The Paradox of Measuring Team Performance

You get exactly what you measure. Tracking individual numbers breeds disjointed individuals, not cohesive teams. Discover how to leverage product-level data that drives true user value.

- **Speakers:** [Volker Zoepfel](https://www.wearedevelopers.com/@volker-zoepfel)
- **Event:** World Congress 2024
- **Published:** August 20, 2024
- **Duration:** 17:56
- **URL:** https://www.wearedevelopers.com/videos/1131-metrics-handle-with-care-the-paradox-of-measuring-team-performance

## Summary

The paradox of measuring software engineering productivity often stems from a fundamental lack of trust by disconnected management. Because software development is inherently "invisible" compared to physical manufacturing, nervous managers frequently attempt to quantify team output using superficial data points like Lines of Code (LoC), ticket completion volume, or sprint estimation accuracy. However, this creates a toxic metric environment. As the speaker warns, "you get what you measure." Incentivizing LoC results in bloated, bug-prone codebases; counting tickets leads to "ticket spawning" overhead; and demanding perfect estimates merely causes developers to pad their timelines. Ultimately, managing by individual numbers breeds individuals, not cohesive teams.

To escape this trap, technical leadership must actively bridge the gap by integrating with the team, building psychological safety, and establishing a culture where failure is a functional part of learning. Metrics should pivot from tools of external punishment to internal diagnostic instruments owned by the team itself. For example, tracking the ratio of "in-progress" or "in-review" tickets relative to the number of active developers quickly surfaces process bottlenecks and over-utilization without pointing fingers.

Crucially, context reframes how data is utilized. While LoC makes a terrible individual productivity target, it provides highly valuable insight into a team's growing maintenance burden. True competitive assessment should never happen at the individual developer level; instead, metrics should be evaluated entirely at the product level. Measuring software quality, system availability, and the cost of usage ensures that tracking aligns directly with actual value delivered to the end user.

**Keywords:** software engineering productivity, team performance metrics, lines of code evaluation, ticket spawning overhead, agile estimation padding, developer trust building, toxic metric environments, codebase maintenance burden, pull review bottlenecks, engineering psychological safety, product value measurement, software availability metrics, cost of usage tracking, developer utilization tracking, invisible software effort

## Chapters

1. **Common management complaints about team performance** (00:03) — Managers often look to metrics when they feel developers are too slow or lazy.
1. **Why measuring lines of code reduces software quality** (01:01) — Incentivizing lines of code leads to code bloat, increased maintenance, and more bugs instead of better products.
1. **The overhead of measuring solved tickets and features** (02:20) — Rewarding ticket closure encourages developers to artificially split tasks and creates unnecessary administrative overhead.
1. **Padding timelines to meet estimation accuracy targets** (04:05) — Measuring estimation accuracy guarantees that developers will overestimate tasks to safely keep their promises.
1. **Invisibility of software and the absence of trust** (05:49) — Management often relies on metrics because they do not understand the invisible, time-consuming nature of software development.
1. **Building a collaborative environment to eliminate toxic metrics** (08:57) — Managers should integrate with teams and cultivate psychological safety to replace toxic environments with collaboration.
1. **Internal metrics for workload and bottleneck evaluation** (11:03) — Tracking in-progress work and pending reviews helps teams internally identify bottlenecks without triggering external oversight.
1. **Shifting focus from team comparison to product value** (14:33) — Instead of assessing individual output, organizations should evaluate software success through overall product value and quality.

## Related Moments

- [Rethinking how teams measure developer productivity](https://www.wearedevelopers.com/videos/613-how-sparking-developer-joy-unlocks-developer-productivity) (from "How Sparking Developer Joy Unlocks Developer Productivity")
- [Principles for balancing multiple software engineering health metrics](https://www.wearedevelopers.com/videos/100317-measuring-the-wrong-things-faster-than-ever) (from "Measuring the Wrong Things Faster Than Ever")
- [Measuring actual productivity gains in modern software development](https://www.wearedevelopers.com/videos/1097-collaborative-intelligence-the-human-ai-partnership) (from "Collaborative Intelligence: The Human & AI Partnership")
- [Avoiding harmful team comparisons and metric incentivization](https://www.wearedevelopers.com/videos/1025-do-you-know-how-fast-you-were-developing) (from "Do you know how fast you were developing?")
- [Overcoming review fatigue and measuring true engineering productivity](https://www.wearedevelopers.com/videos/1706-the-ai-ready-stack-rethinking-the-engineering-org-of-the-future) (from "The AI-Ready Stack: Rethinking the Engineering Org of the Future")
- [Measuring engineering productivity beyond pull request volume](https://www.wearedevelopers.com/videos/1352-wearedevelopers-live-did-ai-or-js-break-the-web-finding-gems-in-the-days-of-ai-and-one-thing-developers-really-need-to-know) (from "WeAreDevelopers LIVE - Did AI or JS break the web?, Finding gems in the days of AI and One thing developers really need to know ")

## Related Articles

- [Now is the time for industrialized software development](https://www.wearedevelopers.com/magazine/601-now-is-the-time-for-industrialized-software-development)
- [Ignore the Hype: How to Avoid Being Deceived by Technological Trends](https://www.wearedevelopers.com/magazine/528-ignore-the-hype-how-to-avoid-being-deceived-by-technological-trends)
- [The Importance of "Not Done"](https://www.wearedevelopers.com/magazine/529-the-importance-of-not-done)
- [Stop Wasting Time: How to Lead a Stand-Up Meeting & Get Results](https://www.wearedevelopers.com/magazine/414-stop-wasting-time-how-to-lead-a-stand-up-meeting-get-results)

## Related Jobs

- [Tribe Lead - ( Software) Engineering Centre of Excllence](https://www.wearedevelopers.com/jobs/ext/1475530-tribe-lead-software-engineering-centre-of-excllence) at **SD Worx**
- [Staff Software Engineer, Database Infrastructure](https://www.wearedevelopers.com/jobs/ext/1470125-staff-software-engineer-database-infrastructure) at **GitHub**
- [Principal Software Engineer, Database Infrastructure](https://www.wearedevelopers.com/jobs/ext/1465908-principal-software-engineer-database-infrastructure) at **GitHub**
- [Senior Software Engineer](https://www.wearedevelopers.com/jobs/ext/15942-senior-software-engineer) at **GitHub**
- [Staff Software Engineer, Copilot Experiences](https://www.wearedevelopers.com/jobs/ext/164361-staff-software-engineer-copilot-experiences) at **GitHub**
- [Lead Software Engineer (f/m/d)](https://www.wearedevelopers.com/jobs/48296-lead-software-engineer-f-m-d) at **Personio SE & Co. KG**