
Rapid Decision-Making: What it is, why we like it, how to get the most out of it - bobbiechen
https://www.bridgespan.org/insights/library/organizational-effectiveness/rapid-decision-making
======
ssivark
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...](https://hbr.org/1971/03/what-we-can-learn-from-japanese-management)

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 :-)

------
pmoriarty
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.

~~~
Johnie
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.

~~~
delusional
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.

------
lxe
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>"

~~~
scarejunba
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.

~~~
richardxlin
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.

~~~
scarejunba
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.

