Much and more has been written about how technical managers should not impose control on their teams, but instead act as facilitator and coach to the team, whilst the team makes its own decisions, some of which will, inevitably, be wrong.

Having worked at organisations where “autonomy” meant “any way you like, so long as it’s the way I would have done it”, which, given that this ethos came down from the highest echelons, effectively rendered all senior and middle managers irrelevant since all they could do was relay orders, I can wholeheartedly endorse this theory. The more knowledge, control and motivation you have at the lower levels of your people stack, the better the machine will work in aggregate. Put simply, if you made the decision, you are more likely to care about it; the more you care about a decision, the more work you will put in, and the better your quality of decision making.

However, the one thing that is often left out of these writings is the Dark Side of this equation:

Freedom to make decisions is beneficial so long as those making the decisions are exposed to the consequences

Take a lumbering corporate command-and-control behemoth, and try giving the team freedom to make decisions. Said team has been used to mushroom management for so long that they don’t even know who the clients are, let alone what the point of their product actually is. Given them decisions to make, and they’ll make decisions that make their life easier, because that’s the only set of requirements that they understand. When the project crashes and burns, it’ll be the layer above them that takes the consequences. This may filter down to the team, but more likely their boss will be sacked, and the team will go back to being ignored.

Now, take this team, and put them in actual control – make them talk to the clients, have them make the promises, put them on the phones when things go wrong. A developer who implements an ill-thought-out spec from a bit of paper can understandably make a half-arsed job of it, but if said developer is on speaking terms with the client who requested said feature, and knows that the feature will make this client’s life that much easier, then empathy kicks in, and the developer starts to care about their work.

Managers should shield technical teams from the minutiae of detail that will just get in their way otherwise, but if the team is granted the freedom to decide their own destiny, then the team should also know and understand that the freedom to succeed is also the freedom to fail.

How they cope with that failure is perhaps the most important decision that they can make.