Why is Measuring Developer Productivity hard? Can we do it better? In this post I read / react to The Pragmatic Engineer's Measuring developer productivity? A response to McKinsey

Measuring Developer Productivity

The post summarizes the software cycle into four parts:

• Effort - The amount of inputs a person gives (hours, thinking, doing)
• Output - The individual artifacts they create (code, tickets, features)
• Outcome - The effects of those outputs (users see a blue button -> red button)
• Impact - The effects those outputs have on the customers / business (maybe they buy more / less)

The problem with most Developer Productivity measurements is that they over index on measuring Effort and Output. While these are relatively easy to measure, they aren't that good at measuring anything the business actually cares about.

A counterexample is measuring effort / output in the form of lines of code (LoC).

• 0 lines of code landed - No impact
• 1 million lines of code landed - Impact is unclear, might be zero impact

Because total lines of code landed has no discernible correlation with impact (its positive effect on the business), it's not a very good measure to care about.

Measuring Developer Productivity better

The authors propose that focusing on the last two stages (Outcome and Impact) are better as they're closer aligned to what we actually want - to have productive people improving the business.

• Outcome - In the form of milestones and measurable improvements in their area
• Impact - In the form of movements to company-level goals (like profit)

These are better goals and thus measurements because it's much clearer that if you have high scores there, it will have a positive impact on the business as a whole.

Tips for improving Developer Productivity

The authors offer two tips to improve productivity:

• Producing at least one customer-facing thing per team, per week -> I like this but would even encourage ICs to try to hit 3 pieces of impact a week, one a day.
• Delivering business impact committed to by the team -> Yes, if you're not planning like this then your team is likely not effective

Next

My tips for being a more effective Software Engineer are similar but slightly different:

• Focus on Impact
• Simple Scalable Systems
• Be Positive

Read more about these in 3 Tips to become a better Software Engineer