One of the most common complaints I hear when speaking to senior leaders is around a lack of empowerment in their teams. More specifically, the leader is trying to empower their people but the people are not responding - "I have told them they are empowered, but they still come to me for every little decision". Empowerment is a tricky thing. Telling people that they are empowered is easy, getting them to behave in an empowered way is a very different matter. The problem here is that we are looking at empowerment the wrong way round. Empowerment is not something you can just give to someone. While the giving of empowerment is important, it's not the only step. Empowerment only works when the receiver accepts it. You can give empowerment all you like, but if the intended recipient doesn't accept that empowerment, nothing will happen.

But why wouldn't someone accept empowerment? Everyone wants to be empowered don't they? Why don't they jump at the chance? Many years ago I worked for a very large engineering company and the management wanted to try out this brand new (It was a long time ago) empowerment thing. So they gave every employee an "empowerment card" with a statement from the CEO on it that said that anyone in the organisation was empowered to make any decision required. The idea was that if you wanted to seize empowerment by the horns and make a decision that was out of your normal role, you could whip out your card, toss it on the table and say "The CEO has empowered me to make this decision", and away you go. Sounds great doesn't it? Trouble is, not one person used it. Out of the 150,000 people in the company, not one person used one. Zero. Why?

Last time we looked at the Advice Process as a simple (in principal) 4 step decision making technique -

• Decide who should decide

• Make a proposal

• Seek advice

• Decide.

While the process itself is very simple, getting it working in most organisations is very tricky because it completely upends a number of pretty baked in cultural conventions - use of hierarchical authority, undermining consensus to get your own way, lack of trust requiring approvals and so on. The existing culture will fight this process every inch of the way. But, if the organisation is really serious, really puts some resources into this and pushes it forward, it can act as a significant catalyst to cultural change. By changing the way decisions are made, the cultural conventions around decision making can be transformed.

Last time we looked at some of the problems organisations face around decision making using traditional top down or consensus based techniques. We also introduced the idea of collaborative non consensus as a decision making technique - where everyone can discuss the decision but not everyone has to agree to the decision for it to be ratified. These can range from fairly simple systems where people can say “yes”, “no” or "can live it it" which allows them to raise an objection but not veto the whole decision, right up to fairly involved systems based around the idea of principles and objections - objections based not on just not liking an idea but on violating some fundamental principle that the organisation lives by.

While principled systems work well for organisations that are deeply in touch with their principles, other organisations may need a more structured approach. One such approach is the Advice Process which was developed at an organisation called AES many years ago and was documented in Frederic Laloux's wonderful book Reinventing Organisations. The Advice process is a simple, structured decision making process that involves 4 steps -

• Deciding who decides

• The Proposal

• Seeking Advice

• The Decision

Decision making is something a lot of organisations struggle with. Particularly when they decide to adopt a more agile way of doing things. Traditionally, organisations were geared around top down decision making - people asked their boss to make a decision, they would ask their boss and so on until it reached a level in the hierarchy where someone had the right level of authority and a decision was made. Or the request got lost somewhere on the way and nothing happened. Or it got misinterpreted and the wrong thing happened. And if a decision was made, it was generally made in the absence of any real, on the ground information.

This isn't new knowledge. People have known the problems with a top down decision making model for a long time now. Organisations have been trying to move to a more decentralised model but unfortunately, what had replaced top down decisions is consensus decision making. This sounds lovely - we bring everyone together, we discuss the issue and we all agree on what to do. Consensus decision making works really well in small groups - families, villages, small organisations. It doesn't scale well though. Have you ever tried to get a group of more than two or three people to agree on where to go for dinner? Then starved to death for the next few hours while the argument goes round and round in circles? Now imagine that in an organisation of thousands of people. That's how badly consensus decision making doesn't scale.

Probably the least understood (or most misunderstood) lean principle is "decide as late as possible". I have seen it used to justify all sorts of weird decision-making policies that generally involve never making decisions, because surely as late as possible means leaving it until the absolute last possible moment, or even later. I have seldom, if ever, seen it applied correctly. So let's take a look at this principle and see what it really means.

The other way to express this principle is "defer decisions until the last responsible moment". There are two points of confusion here. The first is what is the last responsible moment? The other is what exactly do we mean by deferring decisions? Let's look at the last responsible moment. What is the last responsible moment? Does it mean the absolute last minute? Do we leave all decisions until we are absolutely forced to make one because otherwise the whole endeavour will fall flat? No. That makes no sense at all. Leaving decisions until they are forced upon you is hardly being responsible. Does it mean making decisions early because that's the responsible thing to do? Again, no. Making decisions early isn't using the last responsible moment. The last responsible moment is a really hard thing to define, so let's not try. Let's re-word it instead. The intent of the last responsible moment is to make decisions with the maximum possible information.

"We need to harden this process...make it more robust. Too many things are slipping through the cracks". How many times have you heard statements like that? Things that don't fit the process take extra time to resolve, so we make sure that the process covers as much as possible. As issues arise, we tighten the process still further. Spell out the entry criteria. Map the process steps in great detail. The problem is, of course, that no matter how much detail we have in the process, things still don't always fit so we document and harden even more.

We create processes and because we are humans working with incomplete information, there are gaps. Our natural instinct then is to fill in the gaps. Tighten the process. Specify, document, enforce. The problem is that this simply doesn't work. The real world conspires against us. Customers don't always want the standard product. You may have a carefully documented 30 day SLA but that doesn't help a bit when a key customer rings up and says "We know it's usually 30 days but we really need it in 10, can you please help? If not, your competitor has said they can do it in 10 days." You may only sell in lots of 100 but what happens if a good customer rings up and asks for an extra 35 because they have had a spike in sales but don't have the space to store another full hundred? The more rigid we make our processes the more often they break down.

Time to close out our series on common traps with a look at probably the most common trap organisations fall into. I don't think I have ever worked for an organisation that wasn't caught to some extent in this trap. What I'm talking about today is the cost trap. You get into this trap by having the wrong sort of conversations - conversations about cost. "How much will this cost?" That question has lead most organisations astray. Why is that? Surely how much it costs is an important question. And indeed it is. The problem occurs when that's the only question you ask. Cost is important, but there is something else you need in order to make a good decision. There is half the information missing. That other half is value. "What will I get in return?"

Let me put it this way, if I were to ask you "would you rather I took $10 from you or $50?" I suspect most of you would chose $10 (and for those who wouldn't, you are very generous, please leave your name in the comments below...). If, on the other hand, I asked "Would you rather I took $10 and gave you back $50 or took $50 and gave you back $500?" I'm guessing most of you would pick the $50. Just focusing on the cost would drastically lower your return. But this is what most organisations do. To be fair, most organisations do consider value, particularly at the top levels of the organisation. Every idea starts with a cost/value decision. ROI is a key consideration. But as work moves down the organisation, the discussion starts to become less and less about value and more and more about cost. The point at which the organisation falls into the cost trap is the point where the value part of the discussion vanishes and the discussion becomes entirely about cost. Often, this is where an idea becomes a project and is handed over for delivery.

Continuing on with our series on common traps that organisations can fall into, it's time to look at the Urgency Trap. What's that? It's a particularly common trap and unlike most of the other traps where agile techniques tend to help avoid them, the urgency trap is one that agile teams can fall into even more easily than traditional teams. It's also a particularly dangerous trap because it can lead otherwise great teams into other traps, like the rebuild trap we looked at last time.

But what is it? Take a look at your current backlog. Now take a look at your team's long term goal. How much stuff at the top of the backlog is stuff that is strategic and aligned to your long term goal. How much is stuff that's short term, tactical and is at the top of the backlog, not because it gets you closer to your goal but because it's urgent? That bug fix. That urgent tweak to a feature that someone demanded. That urgent update to the terms and conditions because someone in legal found a problem. What's the ratio? More than 50% long term and strategic? Trend is steady? You are probably OK. Less than 50%? Percentage of urgent work is creeping up and displacing more and more strategic work? Welcome to the urgency trap.