Make Fewer Decisions?

An interesting programmer I followed on X tweeted this:

My goal as a leader is to make as few decisions as possible. Instead empower the team to make decisions and spend time giving feedback on the process & quality of those decisions. Decisions are better since made by most knowledgeable about the problem and faster to boot.

This kind of advice gets me fired up. It’s true enough to be interesting but just off target enough to be easily misinterpreted.

Opinions and guidance on management practices are a dime a dozen. We’ve been doing management for 100’s of thousands of years, ever since the first time some small group tried to achieve more as a group than they could as individuals.

The nature of the work and effort being managed can vary in endless ways, but there are some core consistencies in the dimensions along which the work varies and the framework in which it is done.

• How clear is the goal?
• How much variation is there in the size and complexity of tasks?
• How much variation is there in the resources available to apply to those tasks?
• How much uncertainty is there in how to measure either resources or tasks?

So move this pile of bricks 100 feet, from here to there, within the next hour, given these five laborers all of consistent strength and ability. The goal is clear, the resources are all well-defined and consistent and the sub-tasks are identical. The management problem is easy.

The general management challenge has a flavor of the Knapsack Problem. You have a set of items of different weights and of different value (with value independent of weight). You want to load up the backpack to some weight limit and maximize the value.

This algorithmic analogy provides some insight because we know that the solution to the knapsack problem is both computationally hard (NP-complete) but that there are effective techniques for solving the problem in practice when you can apply certain constraints and simplifications.

Different management approaches and advice tend to ignore that their applicability is highly dependent on those constraints and simplifications. That’s why you see so many management books that have “solved” the problem without the insight about the actual domain they have solved for.

Software development tends to have the characteristic that there is wide variability in the resources (talents) available, wide variability in the size and complexity of tasks and there is quite a bit of uncertainty in how to measure both of these. If the problem is to knock-out the same storefront web site that you’ve done 30 times before, you can nail the estimate pretty well. When the problem is less well-defined and repeatable, things get more challenging.

The complexity and variability of the problem space means that you want the people who have done the closest analysis of their sub-problem and the possible solutions to make decisions about how to proceed with the least amount of management overhead. So the quote above resonates.

But the other part of this is that there are certain decisions that can only be made by the leader. Resource allocation is the biggest part of this. If you are the leader and haven’t intentionally allocated resources in order to maximize the value you are trying to produce, you’ve ignored one of your most important functions. Anyone who thinks they can solve this with some kind of “swarm” distributed intelligence is probably operating in a very simplified problem space (you’re just moving a pile of bricks a hundred feet). But that doesn’t look like most complex software development that I’m familiar with.

After resource allocation, the biggest leadership failures that I have seen is when leadership fails to establish consistent constraints about how their teams should be making all those local decisions. This can mean something as basic as a consistent ship date or other constraints around engineering dependencies, processes and standards where there is huge value in the whole team making a single consistent decision. Whether the leader makes the decision or just enforces the singularity of the decision is less important than the fact that there is a singular decision.

This may end up feeling like “just a few decisions” but a good leader better not be shy about making them.