I have been looking recently at some of the common traps organisations can get into. Today it's time for the efficiency trap. "Hang on", I hear you say. "What's wrong with efficiency? Efficiency is a good thing...right?" Well, yes, but exactly what are you efficient at? Are you efficient at delivering things or efficient at achieving business goals? "But wait?" you say. "Aren't they the same thing? Don't we achieve business goals by delivering things?"

The answer there is "not always". It's really easy to deliver things that don't actually deliver business outcomes. Features that no one uses. Products that don't sell. Or at a smaller scale, designs that never get implemented. Business cases that never get funded, and so on. This is where the efficiency trap gets us. We fall into the trap of thinking that the more stuff we produce, the better. We mistake efficiency at producing outputs with efficiency at producing outcomes.

 Most organisations fall into this trap. It's probably the most common trap there is. It's all down to the way we tend to think - give someone a problem and they will quickly start to look for solutions. Great. But what if the problem is complex and they don't really, fully, understand it? Or what about when the problem changes halfway through the solution? That's what business is like. It's trying to solve a problem that keeps changing itself in the middle of the solution.

The mistake we make is never stopping and checking that the solution to the original problem is still the solution to the new problem. To put it another way, we come up with a list of stuff that will solve the business problems we have now, get started on producing that list of stuff and never stop to check whether those business problems are still the problems we need to solve.

We get fixated on delivering the stuff we we have come up with. We focus our energy on making sure that we deliver that stuff efficiently. Can we deliver faster? 5 months instead of 6? 4 months? 3? How efficiently can we deliver our stuff? Can agile delivery help us deliver more efficiently? What about Devops? What else can we do to deliver faster?

Without going back and checking that the stuff we are producing is still the stuff we should be producing, we end up becoming very efficient at producing the wrong things. We have a very efficient production line frantically churning out stuff that no one wants. Stuff that doesn't deliver a business outcome. This is the efficiency trap.

The fundamental mistake here is that delivery isn't about producing stuff. It's about producing outcomes. Which is more efficient - a team that produces 6 features in a year, only one of which succeeds in the market, or a team that produces two successful features in a year? One produced 3 times more stuff but only half the market success. Three times the output, half the outcome (actually less than half because they wasted a bunch of extra money producing the 5 failed features, so market success was lower and costs were higher - two bad outcomes for the price of one).

We need to focus on producing outcomes, not on producing outputs. That's where the real efficiency is. How do we do that?

We start by not building a long list of stuff to build. Look at the one or two things you think will give you the biggest outcome. What assumptions did you just make? List them. Now let's see if they hold up. What's the smallest thing we can to to prove or disprove the key assumption? Now do that small experiment. It may not involve building anything. It may be market research, customer surveys, asking people in the hallway. Anything. Now, does our assumption hold up? Yes? Great. Do it again. Prove or disprove another assumption. No? Also great. Idea failed. Awesome. We failed really fast and didn't spend a lot of money building something that didn't work. Back to the drawing board. Let's come up with a different solution now that we know that the first one was flawed. And even better, we now know more about the problem so the next solution will be better.

Each of these assumptions gives us a Pivot point - Persevere, Pivot or Kill. Assumption holds, great. Persevere. Assumption doesn't hold, also great. Pivot. Change the solution based on your new knowledge. Assumption really doesn't hold, your whole idea is in ruins, great. Kill. Stop. Go back to the start and try something different.

Eventually we will have proven enough assumptions to know that this idea is going to work so let's build it (if we haven't already while proving assumptions). Once we have built it, let's see how it goes. Did it work as well as we expected? Did it achieve the outcome we wanted? Better? Worse? Great. More knowledge.

Back to the business outcome. Is it still valid? Have conditions changed? Do we need to focus somewhere else? What's the one biggest thing we could do to get closer to our new business outcomes? And through the cycle we go again.

Efficiency is absolutely a great thing. But it's efficiency at building the right thing that is important. If you build the right things, no matter how inefficiently you build them, you're still moving ahead. If you build the wrong things, no matter how efficiently you build them, you are going backwards. Outcomes efficiency has to come first. Delivery efficiency comes second.

As Peter F Drucker once said, "There is nothing quite so useless, as doing with great efficiency, something that should not be done at all.”