The productivity delusion

Over the past decade, research has dramatically shaped how organizations view software delivery. While there were studies before this, the relationship between organizations building software and the researchers looking at the industry has grown closer.

Teams and organizations have developed the skill to assess research and apply the findings to their practice, and they are taking a more experimental approach to their improvement process.

However, one huge stumbling block has become the most common wrong turn in the modern software delivery era: Productivity.

Productivity is a collective delusion

Productivity isn’t a tangible thing. It’s not something you can, or even should, measure. The lack of tangible meaning with the word productivity is why it’s such a marketing default. If you don’t know the concrete benefits of your product or service, you can skip the hard work and say it “increases productivity”.

We can think of productivity like an anamorphic sculpture, a technique used in the perceptual art movement. When artists create an anamorphic sculpture, they design it to show different forms when viewed from specific angles. Brooklyn sculptor Michael Murphy creates three-dimensional art installations that fill a whole room, such as perceptual shift, which looks like a cone made from spheres of various sizes, but when viewed from just the right place, it’s a pop-art style eye.

When you use the term “productivity”, everyone in the room imagines a different picture because they all view productivity from a different perspective. This makes the term dangerously unspecific for discussing the real world.

It’s sometimes valid to talk about whether you feel productive. The term is a proxy for some beneficial things, like whether you could work on the right things and complete tasks without unnecessary interruptions. But feeling productive is a measure of your personal experience, not a measure of any tangible benefit to your team or organization.

In fact, feeling productive turns out to be a poor indicator of being productive.

Feeling versus being productive

The best way of exploring the relationship between feeling and being productive is to look at a myth that researchers busted about multitasking.

Traditionally, people believed multitasking was a skill. They listed it as a requirement on job listings and often bragged about their multitasking ability. This illusion crumbled when psychologists studied the impact of multitasking and task switching.

The research found that multitasking directly damaged the speed, accuracy, and quality of work. On top of this, they found that the people who thought they were great at multitasking performed the worst in real life. This inverse relationship between perceptions of productivity and the reality of specific measures is crucial because we lean on this feeling when we judge new tools and techniques.

The only cure to this perceptual error is to measure, and the only way to measure productivity is to convert it into concrete expectations.

How to measure productivity

The answer to measuring productivity is already starting to become clear. You must reach into the mists of vagueness and pull out the concrete measures you want to impact.

The process of converting productivity into meaningful measures is contextual. That means you must ask, “What do we mean by productivity?” You may find a single thing or many things that complete your picture of productivity, but the process will clarify your goals.

Say you plan to introduce a tech tool that automatically scans your code for vulnerabilities. It’s tempting to say it will make the team more productive. You’ll iterate towards a meaningful picture by repeatedly asking what productivity means in the context of a code scanning tool.

The most common first step in translating productivity into measures is “speed”. However, you shouldn’t settle for this unless you’re wholly convinced that you’re working on your end-to-end value stream’s constraint. For the code scanning example, the tool will likely do something you’re not doing now. That means it won’t make things faster; it will, in fact, marginally slow your build pipeline.

So what is the benefit? You’ll likely increase the frequency of this type of check from “never” or “once a year” to every time you run the software build process. You may increase quality and reduce rework later on. Or, the tool might detect vulnerabilities that you were previously missing when you relied solely on code reviews.

So, let’s say you measure the frequency of security scans, the number of vulnerabilities identified (and, hopefully, fixed), and the time between the introduction and remediation of a vulnerability. This paints a vivid picture of real progress. This might be what you meant by “productivity”, in which case, you’ve improved the clarity of the goals and aligned everyone’s expectations. More commonly, you’ll realize it’s not productivity you wanted when you asked for the tool.

There’s no need to type faster

There’s an industry obsession with speeding up developers, which wasn’t helped by some of the Agile strap-lines, like “twice the work in half the time”. I firmly believe successful teams have an alternative strategy that’s far better, which I call:

Twice the impact with half the work

To achieve this, you have to stop myopically fixating on programming speed. Instead, you need to observe how work gets all the way from idea to value. Imagine you just realized how to create a feature that would disrupt your market and bring crowds of customers to your organization. How long would it be before you started working on this idea?

In many organizations, the answer is weeks or months. They are sitting on an idea that could dramatically increase their market share, but lack the mechanism to re-plan. So, they deliver a sequence of old ideas that won’t move the needle.

When you compare these systemic delays, they outweigh programming time by orders of magnitude. Yet organizations are still obsessed with making developers type faster.

The reality is that most developer tools aren’t about speeding up development. Auto-complete tools likely speed up coding, but their real benefit is reducing the low-value information developers need to keep in their heads. The same goes for learning how to touch type, using test automation, or using an AI assistant.

The speed gain from these tools and techniques is modest at best, but it’s also not the measurable benefit you should seek, because these localized speed improvements don’t roll up to the value stream.

This makes it crucial for you to consider the real benefits you want by adopting a technique or a tool, because we know that we need to understand our goals to be able to measure, and we need to measure to avoid the perception trap.

Happy deployments!

Related posts