As an engineering leader, mentioning that you track lines of code (LOC) is often met with immediate pushback. "We deliver so much more value that producing code!” "Lines of code don't measure quality!" "You'll incentivize bloated code!" "The best engineers delete code!" “Outcomes over outputs!”. All valid comments in some contexts, but they miss a crucial point: quantitative metrics, when used appropriately alongside qualitative data, provide valuable insights into team performance and health.

Here's why I track LOC, despite the controversy:

First, LOC serves as a proxy for team velocity and engagement.

When I see a dramatic drop in LOC over several sprints, it often signals deeper issues: team members might be stuck, spending too much time in meetings, or dealing with technical debt. Similarly, unusual spikes can indicate either a productive breakthrough or potential technical debt being created.

Second, coding is still the primary output of engineering teams.

While not all contributions are equal, and some of the most valuable work involves deleting or refactoring code, sustained periods of low code changes usually mean we're not shipping enough value to users. Most significant features or improvements require writing some code.

But here's the key: LOC is just one data point in a broader performance evaluation framework.

I look at it alongside:

• Project completion rates and milestone achievements
• Code review feedback and quality metrics (mentoring)
• Customer impact and business outcomes
• Team collaboration and knowledge sharing
• Technical debt reduction efforts
• Operational ownership and impact (oncall, handling incidents and proactive operational improvements)

The goal isn't to maximize lines of code – it's to maintain a holistic view of team performance that includes both quantitative and qualitative metrics. By deliberately including some quantitative metrics in our evaluation process, we make better, more data-informed decisions about team health and performance.

Remember: It's not about tracking LOC in isolation, but about acknowledging that meaningful engineering work usually involves writing code, and dramatic deviations from normal patterns deserve investigation.

The industry should instead focus less on the taboo of measuring code output, and more on ensuring that individual and team performance is looked at as a whole, and in the context that it exists.

This last part is crucial – ensuring that team leads, managers and HR seek as much data about engineering team performance, and assess overall impact and growth using this combined picture.