Do you “run a tight ship?” Does “cutting the bottom line” boost your self-esteem? Are you obsessed with getting “more for less”—or the “maximum outcome for the minimum investment?” If you answered “yes” to any of these questions, then you might be suffering from a severe case of “efficiency” addiction.
But wait—aren’t projects, initiatives and development teams supposed to be efficient? Well, maybe not.
These efficiency-related terms get thrown around a lot in the business world, usually to bestow praise rather than point out a problem. But maybe we should take a deeper look at what it actually means to be efficient.
This article is published in . Agile NXT is the magazine full of inspiration for professionals on the emerging Agile journey. Theme of #2: New Insights for Agile Performance Management.
According to the Merriam Webster Dictionary, efficient describes “a capability to produce desired results with little or no waste (as in time or materials).” So efficiency is all about how we do things, in terms of resources, (aka money). Getting from a known point (our initial state) to a desired point (our target state) in the minimum amount of time, or with the smallest investment possible sounds like a good plan, especially when it comes to doing business, right?
But let’s contrast this against another perspective: effectiveness.
Merriam defines effective as “producing a decided, decisive, or desired effect.” In other words, effectiveness is about producing the desired outcomes, irrespective of the investment made to get there.
Already we see a distinct difference here. While efficient is about input, effective is about the outcome. Efficiency is about doing the same for less, effectiveness is about achieving more with the same input. In other words (Dan North’s words, to be exact), “If you focus on efficiency… you get better at being increasingly less effective.”
And when we extend that logic, another limitation of the “efficiency addiction” rears its ugly head: the benefits of efficiency are bounded.
“Huh?” Okay, let’s break that one down with an example:
Suppose I have managed to become 20% more efficient. I usually spend $200 to earn $300, for a net return of $100, but now I spend $160 for a $300 return, netting me $140 — a comfortable gain of $40.
Not too bad, right? Well, not so fast.
What if my 20% improvement was in effectiveness instead? This would result in earning $360, instead of $300, for my same $200 investment— a net result of $160 instead of $100. Compared to the original situation, my “improvement” is $60, which is 50% more than when we focused on efficiency. And the fun doesn’t stop there; the effects of efficiency and effectiveness are exponential in both directions:
So, a further 20% increase in efficiency (while even harder to achieve) will bring us even less than our initial efficiency gain (from $160 down to $132, and an improvement of $28). While the same 20% gain in effectiveness brings us even more than the first time ($360 going up to $432, for a $72 improvement).
Over the long run, effectiveness will beat efficiency every single time. It’s the law of diminishing returns versus compound interest.
And we haven’t even gotten to the impact on your customer yet. So you tell me, which would you prefer:
A more efficient train service, that maintains the same level of delays and canceled trains? Or a more effective service, that runs on time while costing slightly more? An efficient surgeon and team, that focusing on doing more surgeries in the same amount of time, or an effective one, focused on a higher success rate? I don’t know about you, but my choice would be clear.
So should we always avoid efficiency? It’s not that black and white, of course. If the process is straightforward, results are repeatable, and the customers’ wishes do not change, a focus on efficiency can be the right choice. But the number of businesses operating in that domain are increasingly few and far between.
In which case, it’s a good idea to keep your efficiency-addiction in check—or better yet, kick the habit altogether.
The next time you want to measure your team’s velocity, measure their impact on customers instead.
The next time you want to measure the time spent per support request, focus on the problems structurally solved for your clients instead.
The next time you want to count how many commits or deployments your team made, ask their stakeholders what they think of the product instead.
You might be surprised by the outcomes.