#27 - Monitor Inefficiencies
The best way to measure productivity is monitoring inefficiencies
“Yes, you can measure software developer productivity”
That’s the latest announcement from McKinsey. Within a few weeks, the software industry had already divided into camps, with proponents and opponents of this idea.
A company wants to see it grow sustainably and improve productivity across the board. Measuring software development has always been challenging, primarily because you're often starting something entirely new from scratch. Each feature is a unique development.
And yet, managers are looking for metrics and measurements for various reasons - identify top talent, the weakest link, project future output and outcomes, and more.
To find a solution, I observed my team and asked, 'How do you determine if service A is operating correctly and efficiently?'"
After several times I did that, I noticed a pattern - I got the best answers when the service wasn’t working correctly -
“Here you can see the CPU is 90%, that’s not a good place”
“We have a spike in errors, something isn’t working as expected”
“We have failed tests, this service is not stable”
We all have a negativity bias - our brains tend to find and give more attention to things that are not working correctly. I suggest using it to our advantage.
As I wrote in the past about waste, instead of optimizing productivity, a more realistic goal is to prioritize efficiency. To do that, just like my team found “negative metrics” that had spikes, we can look at negative experiences from the software world and work to reduce them.
Such activities can include -
Scope of tech debt that slows down delivery - refers to areas in the code that hinder delivery due to inadequate maintenance.
Context switches between tasks - have an estimated 40% impact on our mental abilities, focus, and productivity.
Changes in allocation and staffing - changing the team members or their ownership comes with the cost of a learning curve and changes team dynamics.
Low-value work - bug fixes, manual support, and other tasks that don’t provide long-term value
Time spent in meetings
And much more
One can establish a 'health score' that measures team inefficiencies by aggregating the results using a specific formula. While I have not yet found the ideal tool for this, surveys combined with reports from the ticketing system make a lot of sense.
One case I remember is when my team invested over 30% of the time for low-value work from a specific domain with deep tech debt. We decided to invest almost a year in refactoring this area and stabilize it. We didn’t optimize productivity measured story points, velocity, or time to close a PR. We did measure open bugs, time allocation for low-value work, and the reduction of tech debt.
Like my team, when monitoring failed services, the best answer to “how efficient team A is” would be “I’m not sure; I’m not aware of critical inefficiencies.”
So, as we shift our gaze from optimizing productivity to spotlighting inefficiencies, consider this: What hidden opportunities lie within your team's challenges and bottlenecks? And how might the pursuit of efficiency become the driving force in shaping the future of software development?
Image by vectorjuice on Freepik