People talk a lot about agile processes, but it’s the agile decisions that really count.
How does your organisation make decisions?
This is a dangerous question. I’ve asked it a lot recently, and got some unprintable replies.
“We don’t,” is common. People then describe a catalogue of prevarication and delay. Meetings to discuss the situation. More meetings to discuss who should be at those meetings. Debate about objectives. Arguments about quality standards. Actually making the decision gets lost along the way.
Other people focus on hierarchy. They sketch out trees of steering groups and committees and advisory boards. Decisions wend their way up one branch and along another and across to a third. Eventually they find their way back down to the roots, where someone acts on them.
Other places bury their decisions in bureaucracy. Throw enough rules and policies at a decision, they reckon, and it’ll eventually give up and make itself.
And some places have the reverse problem – decisions are made too quickly. Machismo-laden executives vie with each other to appear more decisive. They fire off dozens of decisions at each sitting. Whether they’re grounded in any sort of reality, whether anyone has any will or ability to execute them – that’s someone else’s problem.
Not a pretty picture.
This matters. We can’t design good products without making decisions. We can’t execute projects. We can’t deliver successful campaigns. Decision-making is at the core of any business.
I’ve been doing some research into organisational decision-making. I’m particularly interested in different people’s perceptions of who is responsible for key decisions. Who prioritises projects, for example? Who decides whether a site is ready for launch?
I use decision matrixes to get at those perceptions. We run workshops where people draw up big tables with decisions across the top, and decision-makers down the side. Then they dot vote on who is empowered to make which decision.
Four common patterns emerge from these matrixes:
Decision vacuums. These happen when two groups each think the other is responsible for a decision. For example, project managers think that product managers decide when to schedule a release, while product managers think that’s a project management decision. Net result: no-one makes the decision.
Decision stand-offs. In this case, two groups each think they own the decision. That can lead to infighting – people expend more effort arguing about decision rights than making the decision. Or they each make their own decision, leading to inconsistency and confusion. Lots of websites show signs that this has happened
Misplaced empowerment. Senior people think they have devolved decisions to their subordinates, but those subordinates don’t recognise this. Executives often think they have “empowered” their project teams, for example, while those teams feel pretty powerless. Micro-management often undermines “empowerment”.
Abdication. People recognise that someone senior is responsible for a decision, but that person (or group) never actually makes the decision. This is like a vacuum, only more insidious – vacuums eventually come to light when people push their peers for a decision. It’s a lot harder to talk about abdication.
Recognise any of those?
Many organisations have policies that address these issues. For example, they have process models that contain extensive charts of RACI (Responsible-Accountable-Consulted-Informed) tables that set out who is responsible for each decision.
But people ignore these. Maybe they never read them. Maybe they forgot about them as they got caught up in the details of their projects.
Maybe they read different parts of the manual and hence got tangled in its ambiguities and inconsistencies. Practices often differ wildly to official policy.
Nonetheless, it’s worth doing some upfront thinking about how you will make decisions Agree in advance, and you’ll avoid a lot of pain on each decision.
Start from one of the four basic models:
Monarchy. A single person or group makes the decision, on behalf of the entire organisation.
Federation. Representatives from each affected department or team come together and decide by some sort of voting mechanism.
Feudal. Each department makes its own decision, without reference to anyone else.
Anarchy. Every person makes their own decision. (Anarchy sounds scary, but it works well for some types of decision. Why sweat the minor decisions, for example?)
You don’t have to use the same model for all decisions. (There’s probably something wrong if you’re trying to do this.) And you can combine the models in a various ways – consult widely via a federal model, but make the final decision monarchically, for example.
The key here is to keep it fairly simple, and be prepared to be flexible. Plan, but expect your plans to change when you run into messy reality.
Above all, keep thinking about how you will make decisions – bureaucracies and tangled hierarchies emerge because no-one is tending the organisational decision making processes.
Decisions are critical to our success. In a rapidly changing world, we need to constantly take in new information and use it to adjust our course and steer towards our goals. People talk a lot about agile processes, but it’s the agile decisions that really count.