9 comments

[ 2.9 ms ] story [ 31.1 ms ] thread
Does anyone else feel the need to just shake their head in disbelief that some execs need an acronym and a whole system to just make a fucking decision?

I feel like I'm in Dilbert land here.

The more people there are involved in a decision, the longer that decision takes to be made. If you're in a large company, everyone has an opinion.

This framework is useful to explicitly determine who is and isn't in the decision making process.

In other words, it's a good way to nicely say... "Back the F off!" to people that don't need to be involved.

I often find it's also correlated with the number of people affected. If you start making decisions for the entire organization (as though that ever works) everybody has to be involved, because anybody no involved will see this new policy wielded as a weapon by the people who were involved.

I believe making decisions fast is much less about cutting down the number of deciders, and way more about cutting down the impact. Essentially, make local decisions.

There are methods to force a decision through, even with large/uninteresting groups. For example, putting a default course of action on the table up front and asking if there are objections or better alternatives. Another example is highlighting the cost of not making a decision via organizational communication (“X is still blocked on a decision” etc, and repeat that weekly).
Peter Drucker's 1971 classic article "What we can learn from Japanese management" would prove to be an interesting read to think more thoroughly about the subject: https://hbr.org/1971/03/what-we-can-learn-from-japanese-mana...

It provides a very different perspective on what it means to take (effective) decisions in a participatory manner (depending on the scale/scope of the decision), while being organizationally agile in translating those decisions into action, with a natural harmony between the two.

It is interesting to compare/contrast with Amazon's obsession with "high velocity decision-making making", for example :-)

This is useful, even if it seems "manager-y". TL;DR: Let's say we need to decide on tabs vs spaces. Assign roles to people in the team/organization making the decision:

- (R)ecommend: ensures everyone sticks to their role.

- (A)gree: same as I, but can approve/disapprove the decision.

- (P)erform: changes the code to tabs or spaces after the decision is made.

- (I)input: gives input, consults, but has no say in the decision making.

- (D)ecide: this person tells the P's whether it's gonna be tabs or spaces.

Let's see it in action:

Roger: "Should we use tabs or spaces?"

Alice: "Tabs are better because..."

Igor: "I use spaces, they are nice because..."

Ivan: "I use tabs, they are nice because..."

Derek: "Alright, let's use spaces"

Alice: "Well, actually..."

Derek: "Ok, well, tabs it is!"

Roger: "Alright, looks like we have the decision: it's tabs!"

Patrick: "<re-indents the code with tabs>"

In reality, Patrick reindents with spaces and everyone else forgets because most decisions are not meaningful decisions in the company.

I'd say about 95% of the decisions companies make do not move the needle, do not aggregate into moving the needle, and are easily determinable to not move the needle.

Agreed. Based on experience, unless decisions of this type is automated via a script or post build, people will resume what they are accustomed to.
While you're right for things like this, I meant that more broadly.

I suspect that it applies to build systems, languages, product development, etc.