The No.1 Productivity Measure No One is Talking About...

Welcome back to The Modern Software Developer. In this month’s issue, I’m talking to software development leaders, new and old. I’m shining a light on the practice of trying to measure software developer productivity and the detrimental impact it might be having on your team’s wellbeing and performance.

Our Sponsor:

Before we get started, I’d like to thank Plato for sponsoring this issue:

On the 7th and 8th of November, they are hosting Elevate 2023 - An in-person, NO-BS Conference for engineering leaders in San Francisco.

They have provided me with just a few more free tickets, which you can apply for here.

With sessions from the likes of Amazon, Microsoft, Notion, Gusto, Netflix and more… it’s definitely not one to be missed, and if you miss out on a free ticket, there’ll be a sizable discount as a backup.

Okay, let’s get into this latest issue…

The Traditional Route

For years, software development teams have relied on conventional productivity metrics to attempt to measure their success.

👉 Test Coverage Targets

👉 Sprint Velocity

👉 Features per quarter

👉 And many other similar metrics…

These have largely been an attempt to give those higher-ups a sense of control and confidence in the impact of their software development team - usually to try and justify their cost.

The measures themselves are not entirely useless… it’s what we do with them that is often the problem… Enter Godhart’s Law:

When a measure becomes a target, it ceases to be a good measure.

Probably the number one mistake being made the world over when it comes to measuring…

It worsens when those higher-ups want to try and measure individual developer productivity.

👉 How many commits did they make per day?

👉 How many points did they deliver this sprint?

👉 How many lines of code did they commit per day?

Even with the best intentions, these metrics tend to encourage developers to find ways of gaming the system, often with undesirable consequences. What does that mean for the metrics…

They simply don’t measure what those people who put them in place think is being measured…

The Marshmallow Experiment

Have you heard of the famous Marshmallow Experiment conducted by psychologist Walter Mischel?

Children were given a choice: eat one marshmallow immediately or wait for a while and receive two marshmallows as a reward.

The experiment was originally designed to test children's ability to resist instant gratification and demonstrate delayed gratification, often seen as an indicator of self-control and discipline.

👉 OK - Stay with me here… 👈

What if this experiment doesn't measure what we think it does?

What if, instead of measuring a child's self-control and discipline, it's actually measuring the trust the child has in the adults conducting the experiment…?

If a child thinks the adult might not keep their promise of providing two marshmallows later (perhaps based on prior experience of adults not keeping their promises…), they may choose to eat the one marshmallow in front of them. That has nothing to do with instant or delayed gratification or self-control…

I often wonder if we find ourselves in exactly the same situation when trying to measure developer productivity.

Like my speculation on the Marshmallow Experiment, are these metrics capturing what we truly believe they capture?

Or are they inadvertently measuring something entirely different… and, worse yet, producing the exact opposite result to what we want?

Sacrificing Wellbeing in Pursuit of Productivity

In the quest for productivity, the software development landscape has seen a troubling trend—a willingness to make sacrifices. The sacrifices in question, however, are not in the name of noble productivity gains but in the name of often compromising the wellbeing of software development teams…

The Trade-Off:

Many development teams, eager to meet predefined productivity goals, have unknowingly entered into a trade-off. They have come to accept that achieving higher numbers on the productivity scoreboard may require sacrifices in software quality, not to mention team wellbeing.

When the trade-offs involve sacrificing the psychological safety, job satisfaction, and work-life balance of the developers, it’s clear to me that the balance has been completely lost, and we can’t, in all honesty, claim these metrics are helping measure productivity.

Developers may feel anxious at the thought of “being watched” and feel the pressure to prioritise quantity over quality. The primary focus becomes meeting arbitrary metrics, which can erode software quality and innovation.

The Pressure Cooker Environment:

In this environment, the development process can morph into an anxiety-inducing pressure cooker. Team members work tirelessly, often stretching their limits to meet predefined goals.

The fear of falling short of these metrics can stifle creativity, discourage open communication, and thwart the expression of new ideas.

The relentless focus on metrics creates an atmosphere where team members are more concerned about meeting individual numbers than collaborating and creating valuable software.

The Cost of Compromised Wellbeing:

This trade-off comes at a great cost. Sacrificing wellbeing can lead to a plethora of negative outcomes, both for the individuals and the collective.

As the pressure builds, team members may become susceptible to stress, burnout, and reduced job satisfaction. These consequences not only affect the individuals' wellbeing, but can also lead to a decrease in overall team satisfaction and productivity.

On top of that, you can expect your reputation to take a hit. Your best developers will leave, costing you a fortune. Getting good developers through the door again will be difficult once word gets out.

Ditch Traditional Metrics - Focus on Team Wellbeing

Focusing too much on productivity often seems to impact individual and team wellbeing negatively, and yet, if we switch our focus to wellbeing, we might just get the productivity we are looking for as a by-product…

When a software development team prioritises wellbeing, it experiences a profound transformation in its functioning. Team members who feel content, psychologically safe, and well-balanced in their work and personal lives foster a productive and harmonious environment.

Let's explore the intricate relationship between wellbeing and various aspects of team functioning:

You'll find the rest of this article over at Substack: Here

Along with details of my Team Wellbeing Health Check: