Developer Productivity is Overrated

Productivity. It is not just a buzzword; it is the driving force behind a deluge of NYT bestsellers. Echoed relentlessly by every blogger, YouTuber and entrepreneurial grifter that have forced their way into our gaze for what seems like the past decade. Even the workplace has not escaped the trend with bosses eyeing increased productivity to bring them their bonuses year after year and squeeze ever more from their “Human resources”.

The focus on productivity at all costs, especially when looking at developers is flawed. I believe that with a focus on joy, we not only create more content teams but we also create high performing, productive teams.

There are many measures of developer productivity, all of which are flawed; however, this doesn’t seem to stop the Scrum crowd trying to measure the success of teams with a small number of imperfect metrics.

Gene Kim’s The Unicorn Project espouses the five ideals, one of which is focus, flow and joy and there is also a growing body of evidence in the tech community that the focus on productivity has run its course and the throngs of burned out engineers are ready for a different approach.

Let’s take a look at some of the common metrics that get measured to improve productivity and what we could instead do, to get similar results but keep out engineers happy in their work.

Velocity

Ah, yes! Velocity, the siren song of Scrum masters the world over. The focus on moving ever faster misses the point entirely. Imagine thinking that you could measure success by the speed of travel. Moving at 100mph towards London is useless if the goal is to get to Glasgow. Instead, focus on providing challenging, meaningful work that has a business impact and productivity will take care of itself.

Commits

Commits, PRs, deployment frequency, resolved Jira issues. All of these can be measured yet they tell us absolutely nothing of the impact that work is having. That is not to say that those things are without merit entirely but they are not measures we should be using to tell us about how good or not a team is. For a reasonable look at how some of these metrics can be used as indicators of team health, see the DORA metrics

Again, the focus should be on doing the right work rather than doing busy work. Optimise for impact.

Take away

I firmly believe that attempting to measure and enhance productivity is misguided. Instead, prioritizing the cultivation of happy, impactful teams that feel both challenged and appreciated will naturally result in increased productivity as a positive outcome.

I draw a parallel to the rationale behind my preference for Vim as my editor of choice (cue the Vim evangelism once again). My choice isn’t driven by a quest for productivity gains; in fact, some tasks may be less efficient in Vim compared to certain modern IDEs. Instead, I opt for Vim because it brings me joy and boasts a rich, intriguing history with an endless learning curve. This, in turn, sustains my interest and fuels my desire to enhance my proficiency. For me, that intrinsic motivation alone is sufficient to boost my productivity.