The Efficiency Trap

Overcoming the Halo of Effectiveness

This article is part of Maarten’s summer guest writer series. During my summer break from writing, I want to shine a spotlight on great content written by others.

---

“What’s causing delays in delivering new reporting functionality on time?”

“Can we add more developers to deliver the new payment option sooner?”

“Why did we only complete 20 story points instead of the usual 30 in this sprint?

Do these kinds of questions sound familiar?

If you work in software development, they probably do. Concerns over the timelines and speed of delivery fill the communication channels. Sure, those are good questions to ask, but how often do you hear them compared to these questions?

“Does the new document workflow really reduce the time our customers spend on entering data?”

“Did our revenue increase after introducing the new communication channel?”

“Did our conversion increase after launching the new payment workflows?”

Hearing these kinds of questions is much more rare, while the previous set of questions often gets brought up over and over again.

At first glance, it looks like a typical dilemma of outputs over outcomes. The real question, however, is why the first type of delivery-focused inquiries dominate the discussions, while the second type, which relates to the difference our solutions are making, is asked far less frequently, if at all.

To answer this question, let’s first understand the difference between efficiency and effectiveness. Efficiency is concerned with such things as speed of delivery, quality, and throughput. Efficiency is regularly scrutinized and demanded. With laser-like focus we continue to obsess over making our way of working more efficient. Effectiveness, on the other hand, is concerned with the actual impact that the product or feature is making in the customer world and on the business. Effectiveness is often neglected and assumed to be guaranteed as long as the engineering team can deliver the features on time, within budget, and with high quality—as envisioned, estimated, and committed to.

Why do we naturally tend to focus on improving our efficiency while we take effectiveness for granted? In other words, why do we get stuck in the efficiency trap?

What Drives This Imbalance of Attention?

The reason is actually very simple - efficiency is right there in front of our eyes. It’s very easily perceived by anyone - either features are being delivered “as discussed”, or they are missing the mark.

For example, in the first question we started this article with, “What’s causing delays in delivering new reporting functionality on time?” there were clear expectations of when the reporting would be delivered, and everyone could quickly and easily assess if the deadline was met or not.

Effectiveness, on the other hand, is elusive. It needs to be defined as a goal beforehand, based on data and insight, in order to be able to measure the success (or lack thereof). Again, for the reporting functionality example, can we easily assess the difference the new reports are making in our customers lives? No, because measuring effectiveness is much more nebulous and fuzzy.

Do we see an uptake in usage? By how much? And how much is a good enough uptake? Is the uptake due to the new functionality, or is it seasonal? Those are hard questions to ask. They require deep analysis and perhaps even anecdotal insight—they are not self-evident compared to the assessment of efficiency.

Requested features are typically pushed forward with the halo of an “effectiveness guarantee” - at the end of the day, we wouldn't ask for something to be built if we didn't believe it would solve the problem.

To make matters worse, it takes 5 minutes to assess efficiency, while effectiveness is a whole different beast. It can take days, weeks, and months to assess effectiveness, but no one has time for that when there are another 857 items in the backlog, with an “effectiveness guarantee”.

Fixating on efficiency is particularly prevalent in organizations where the overall strategy is ill-defined. This results in a mishmash of a roadmap where everything is deemed urgent and important. As a result, the company is moving inches deep on a spectrum of issues that is miles wide, all the while blaming the development teams for being slow.

Simply optimizing for efficiency can make teams twice as productive at creating waste, while optimizing for effectiveness drives real value.

How Can We Overcome the Efficiency Trap?

While everyone knows what efficiency looks like, in reality, no one really knows what will and will not be effective. We can only guess what may work. To take the guesswork out of the equation, teams need to be empowered and equipped with the necessary tools to experiment, validate, verify, falsify, prove, and disprove many assumptions that are made in product development.

Teams need fewer visionaries and more scientists. Less control and more empowerment. Less fixation on efficiency and more accountability for effectiveness.

Therefore, in delivering value, those asked to be efficient should also be responsible for ensuring effectiveness. Why? Because only then can they efficiently find what is effective and what is not.

And let’s be frank: what’s the point of being more efficient at being ineffective?