Evaluating SW development productivity solely by code output may seem like an intriguing academic exercise.

However, it fails to capture the diverse activities and responsibilities of engineers.

Simply put, relying on this metric is both naïve and misleading.

​

Example 1: The Guru

To maximize SW development productivity and quality while building robust

architectures and products, the most technically skilled engineers,

often referred to as "gurus, act as force multipliers.

Rather than focusing on code development themselves, they amplify team output by:

• Designing architecture and products

• Scoping and sizing projects

• Reviewing and improving others’ code

• Mentoring and training engineers

• Anticipating technical challenges and mitigating risk

• Presenting at conferences and developing white papers

Their value lies in strategic contributions and elevating the team's overall effectiveness, which cannot be measured by their own commit counts.

​

Example 2: The hands-on manager

In organizations with flat hierarchies, managers frequently wear two hats: they serve as both people managers and individual contributors.

A hands-on manager allocates substantial time to leadership responsibilities, including:

• Hiring and developing teammates

• Organizing processes and software methodologies

• Facilitating communication and team alignment

As a result, their coding time, and corresponding commit count, is understandably lower than that of individual contributors.

Judging their productivity by code output overlooks their critical contributions to people and processes.

​

Example 3: The lab engineer

Lab engineers, often working in a rotational capacity, focus on driving innovation. Their role involves:

• Exploring new ideas

• Developing proofs of concept

• Creating customer-facing demos

Although this work is critical for innovation and securing the company’s future, it rarely translates directly into measurable monthly code commits. Discounting this contribution due to low commit counts undermines the strategic importance of research and innovation.

​

Yes, they are poor performers in SW engineering!

Some engineers underperform due to a lack of capability, aptitude, or motivation.

It is the role of their managers to fix it … and not by merely tracking code output.

Effective people managers

1. Set realistic, outcome-driven goals: productivity should be evaluated based on goals, and how the goals are achieved.

       The goals are rarely just “monthly commits”.

   2. Enable and support engineers: provide resources, clarity, and coaching to help teams achieve their potential. Recognize and celebrate success.

   3. Address performance issues: actively manage underperforming engineers, toward improvement (ideally) or transitioning them out.

 

SW development productivity is a complex concept.

Measuring it through commit counts alone (the “ghost engineers” concept) is an easy but inaccurate reality of SW development.

It is the outcomes, not the raw output of monthly commits, that truly matter.

​