Making Autocratic Decisions
When I started off as an associate product manager at Veritas back in 2007 I dreamed of the day when I might be in charge and make decisions without needing wasteful meetings. I later learned that decision making has all the same problems at any level of an organization whether you formally manage a team or not. I also realized that most decision making is actually decision facilitation. There’s always a process (or lack of), there are always stakeholders (with strong opinions), and there seems to be a weird relationship among the number of meetings and how big the decision is. As if better decisions come from having more meetings.
Considering the framework I previously wrote about, I think this brings up the first legitimate motivation for a meeting: Making A Decision. Do we build this feature? Is this design mockup approved? Should we fire Milton? Somebody decide!
In my experience, decision making (the motivation) can be broken into three general structures:
- Autocratic decisions
- Democratic decisions
- Consensus decisions
I’ll explore autocratic decisions here and follow up in the future with the other 2 types.
Autocratic Decisions
Even though autocratic decisions seem easy, they require some prep work to successfully execute. Things can go sideways quickly if it’s unclear how to run them.
The first challenge: identifying the decision maker. You would be shocked how common it is that an organization isn’t sure who the autocrat should be on a given issue. Is it the direct line level manager? The cross-functional team lead? Do they need confirmation from the COO? Does the CEO have to decide everything? Most organizations, big and small, suffer from a lack of clarity on this front and it has to be clear before getting into the actual decision and structure. An autocrat can’t make an effective decision if it’s overruled later by another leader in the organization.
Once the decision maker is known and it’s in the bounds of what the organization wants them to decide it’s all about getting them to the decision point the most efficient way possible. The first structure I use is a fixed timeline to influence the autocrat. The influence window is borrowed from a best practice in agile product discovery that you need a fixed window of time to do research and discovery before a sprint begins. It prescribes that you set a finite amount of time — 1 week, 1 month etc and after that, you commit to being done with that phase. You can always spend infinite time researching so by bounding an infinite problem with a finite timeline you avoid parkinson’s law.
In practice, the influence window might include two or three meetings where people are asked to bring whatever information the various constituents would like to present to influence the autocrat. At the onset of the first meeting it’s called out that, at the end of the 3rd meeting, the autocrat will be called upon to make the decision. If someone doesn’t agree, they disagree and commit (a common practice made popular by Jeff Bezos/Amazon).
So to recap, the autocratic decision structure looks something like this:
- First, identify the decision maker
- Establishing an influence window with firm number of intervening meetings and hard deadlines
- Hold a series of influence meetings to have people present
- Make the decision!
Once you get good at this structure it’s provocative to start thinking…do you still need meetings to do this? Or could this be done asynchronously with tight communication over a series of emails, Slacks or wiki pages.
