Open Decision-Making (2014)(web.stanford.edu)
web.stanford.edu
Open Decision-Making (2014)
https://web.stanford.edu/~ouster/cgi-bin/decisions.php
39 comments
Ya there are some decisions that are best taken from the top like “what is the overall direction for the company”, “who is our real customer”.
We should absolutely listen to the views of anyone in the company who has an opinion but some questions require a lot more knowledge and maturity than individual departments may have.
In many of these questions, there are several right answers so we only need to decide the answer that we are most driven by. The people who are most invested in the company are the ones to whom such answers must appeal.
We should absolutely listen to the views of anyone in the company who has an opinion but some questions require a lot more knowledge and maturity than individual departments may have.
In many of these questions, there are several right answers so we only need to decide the answer that we are most driven by. The people who are most invested in the company are the ones to whom such answers must appeal.
There are usually approaches to "validate" a decision before you make it into something that reaches the market. Employee testing, User testing and many other kind of tools that will provides cues if you are on the right track or not.
When there's internal conflicts, as much as possible it's better to let the market/users decide.
When there's internal conflicts, as much as possible it's better to let the market/users decide.
It's not practical in a lot of organizations, but something I like to do, when possible, in the face of a non-consensus decision is simply to wait.
That might seem inconceivably frustrating for people who like to make continuous changes - especially if the delay is weeks, months or even years. But sometimes a good idea or answer will develop during that time.
If a good solution doesn't emerge, then sure, it's possible that outside pressure may make it necessary to select one of the options anyway. But I think that's rarer than people expect.
That might seem inconceivably frustrating for people who like to make continuous changes - especially if the delay is weeks, months or even years. But sometimes a good idea or answer will develop during that time.
If a good solution doesn't emerge, then sure, it's possible that outside pressure may make it necessary to select one of the options anyway. But I think that's rarer than people expect.
That seems like good advice at first pass but now i’m sitting here thinking about entropy and chaos. If we choose “wait” - is that not an illusion?
E.g. should we go in direction A or B with our product?
Wait.
Ok - but still our market share is continuing to change, it’s just we’re no longer trying to influence it?
E.g. should we go in direction A or B with our product?
Wait.
Ok - but still our market share is continuing to change, it’s just we’re no longer trying to influence it?
It's best applied in situations where both direction A and direction B lead to significant downsides, I think.
Instead of choosing one of those and getting stuck with (and having to justify) the consequences, wait until the downsides can be reduced, or an option C becomes available.
Instead of choosing one of those and getting stuck with (and having to justify) the consequences, wait until the downsides can be reduced, or an option C becomes available.
Lots of interesting pearls of wisdom. I really enjoyed reading this and found it useful.
Perhaps it’s me, but it almost feels like the author perceives that managing a company is the same as making a stack of decisions, and the piece covers well how the CEO relates to other employees in the decision-making process.
While making decisions is certainly an important part of what a CEO does, managing a company also involves managing how decision making happens within the organization: that often means helping decision making happen with less and less direct involvement of the CEO.
Indeed, as an organization grows, the number of decisions to be taken grows too, and so an important aspect of any framework for effective decision making involves managing people, and designing the organization, in such a way that decisions are moved away from the CEO.
In this sense, it would have been interesting to read more about when and how a CEO should let others take over the process for certain decisions, how a CEO should pick which decisions to be involved in and which should be delegated, or how a CEO should evaluate the performance of the organization’s decision making capabilities.
Perhaps it’s me, but it almost feels like the author perceives that managing a company is the same as making a stack of decisions, and the piece covers well how the CEO relates to other employees in the decision-making process.
While making decisions is certainly an important part of what a CEO does, managing a company also involves managing how decision making happens within the organization: that often means helping decision making happen with less and less direct involvement of the CEO.
Indeed, as an organization grows, the number of decisions to be taken grows too, and so an important aspect of any framework for effective decision making involves managing people, and designing the organization, in such a way that decisions are moved away from the CEO.
In this sense, it would have been interesting to read more about when and how a CEO should let others take over the process for certain decisions, how a CEO should pick which decisions to be involved in and which should be delegated, or how a CEO should evaluate the performance of the organization’s decision making capabilities.
“Oh Concensus - The process of abandoning all beliefs, principles, values, and policies in search of something in which no one believes, but to which no one objects; the process of avoiding the very issues that have to be solved, merely because you cannot get agreement on the way ahead. What great cause would have been fought and won under the banner: ‘I stand for consensus?'” - Margaret Thatcher
Performatively resolute as always, Maggie!
This assumes that consensus is achieved by cutting or subtracting from the original idea rather than adding/enhancing it.
That sounds much more like a description of compromise rather than consensus.
How ironic!
When explained the way decisions are made in Japan, I encountered a notion that I wish was more considered: the idea that taking a decision is a separate process than applying the decision.
Since then, I have wondered why no companies tried to make the processes separate, like we do in democratic countries by separating legislative, judiciary and executive branches.
Since then, I have wondered why no companies tried to make the processes separate, like we do in democratic countries by separating legislative, judiciary and executive branches.
Could you elaborate on this? How does the distinction between taking and applying affect the decision making process?
Not parent, but I have similar encounters.
Japanese decision making (especially in big orgs) is consensus driven. Multiple stakeholders are consulted, various options considered, all opinions weighed (in theory). This process is, consequently, not very agile and the more stakeholders the more time a big decision will take. Not until everyone is happy is a final decision put down.
But part of this is because once a decision is made, Japanese companies will full-send commit to its execution. And those designated as having the power to execute will execute fully at all possible speed. Attempts to reverse or change course mid-execution are discouraged — partially because decisions on how or what to do in response will take a similar amount of time.
The result is really, really committing to making sure everyone buys into the idea because once the horse leaves the stable there is no turning back.
The drawback to this is twofold: half-baked plans that are forced to be made due to schedule pressure, or decision paralysis that results in maintaining status quos (for better or for worse)
Japanese decision making (especially in big orgs) is consensus driven. Multiple stakeholders are consulted, various options considered, all opinions weighed (in theory). This process is, consequently, not very agile and the more stakeholders the more time a big decision will take. Not until everyone is happy is a final decision put down.
But part of this is because once a decision is made, Japanese companies will full-send commit to its execution. And those designated as having the power to execute will execute fully at all possible speed. Attempts to reverse or change course mid-execution are discouraged — partially because decisions on how or what to do in response will take a similar amount of time.
The result is really, really committing to making sure everyone buys into the idea because once the horse leaves the stable there is no turning back.
The drawback to this is twofold: half-baked plans that are forced to be made due to schedule pressure, or decision paralysis that results in maintaining status quos (for better or for worse)
Problem in Japan with that approach is that decision making is more often than not guts-based and driven by seniority/authority than an "open decision" like described in this article.
flashbacks to my days in Japanese corps
Yeah, and by “consensus” it usually means “tell the subordinates what the boss wants no questions allowed”
Yeah, and by “consensus” it usually means “tell the subordinates what the boss wants no questions allowed”
Not sure if this is what the OP intended. But Toyota famously distribute the decision making process in a process they call Nemawashi[1] which only after they know they have 100% buyin do they officially make the decision.
[1] https://en.wikipedia.org/wiki/Nemawashi
[1] https://en.wikipedia.org/wiki/Nemawashi
This week's 99% Invisible talks about this in the context of the Hanko, the personal stamps used in Japan for signing contracts and recording Nemawashi consensus. It talks about how one may join the 100% consensus, but still not be 100% bought in, which may be what Iv was getting at.
https://99percentinvisible.org/episode/hanko/
https://99percentinvisible.org/episode/hanko/
Some companies definitely do this, having seperate "strategy" and "execution" functions for example and often the results aren't great because the strategy part just gets to think "blue sky" thoughts and doesn't need to commit to actually making anything work because they aren't involved in the actual implementation once the decision is made. This can be even worse when consultants do the strategy part as they get to drop slideware and leave others to do the dirty work. Often the slideware is even just ideas taken from the people on the execution side, furthering resentment.
What can work well is simply being more deliberately thoughtful about decision-making processes. For example Bridgewater Associates (the hedge fund) has internal principles that rather than trying to solve a particular problem, you should imagine you are designing a machine to solve the problem, and also that rather than just doing a particular thing, you think about yourself directing a movie of the thing. This allows you to compare what you're seeing to the "script of the movie" (your plan) you developed beforehand, to assess your outcomes.
The basic idea is that there is almost always value in investing in the "second order" thing (the design of the process, including decision-making processes) over and above the value of just achieving the outcome of the process (ie getting a decision).
If you're interested in the above, it's worth reading "Principles" by Ray Dalio.
Edit: added note about strategy consultants.
What can work well is simply being more deliberately thoughtful about decision-making processes. For example Bridgewater Associates (the hedge fund) has internal principles that rather than trying to solve a particular problem, you should imagine you are designing a machine to solve the problem, and also that rather than just doing a particular thing, you think about yourself directing a movie of the thing. This allows you to compare what you're seeing to the "script of the movie" (your plan) you developed beforehand, to assess your outcomes.
The basic idea is that there is almost always value in investing in the "second order" thing (the design of the process, including decision-making processes) over and above the value of just achieving the outcome of the process (ie getting a decision).
If you're interested in the above, it's worth reading "Principles" by Ray Dalio.
Edit: added note about strategy consultants.
This article completely jives with my own experiences using democracy in the workplace.
My misc Yes and:
I've always struggled to articulate my ideas, experiences. Workplace democracy is a hard sell. I've only successfully used it when I had full control, like a benevolent dictator. Supremely ironic.
Focus on good structures and processes and the outcomes will take care of themselves. h/t Luke Hohmann and The Journey of the Software Professional.
Workplace democracy is about both empowerment and responsibility. I hired really good people. The answers we need are right here. The trick is creating the environment where the team can find and flesh out their answers. Together! Maybe this is called nurture.
My team members have always owned their processes and structures, and therefore they earned their outcomes. Using democracy instills emotional involvement and commitment.
My primary involvement was adjudicator, enforcer. If a team made a joint decision, I held them to it. No sniping, sabotage, withholding, backstabbing, and all those other icky personal political BS details. If someone wanted to, needed to, revise a team's decision, then it was handled democratically. So be prepared to be the asshole.
Democracy feels slower, more painful. That's only because the heartache is front loaded. It's one of those "go slower to move faster" things. If you stick to the process, there's much less rework, relitigation.
Trust is key. In that "disagree and commit" sort of way. In owning and learning from mistakes. In demonstrating that team decisions will not be capriciously or casually disregarded or overruled.
Like a magpie, I cobbled together goofy ideas from every where. Joint Application Development (JAD) for brainstorming, project planning. Approval voting for triage. Roman evaluation for hiring. Balance of powers between roles (Marketing, Engineering, QA) for governance. Streamlining from Goldratt's theory of constraints. Etc, etc. Books like Innovation Games are good sources.
Democracy is hard. Requires commitment. It gets A LOT easier once the culture is established (eg storming, forming, norming, performing).
Major caveat: Once you experience democracy, a high trust environment, it kinda ruins you for the rest. It's really, really hard to suspend disbelief.
My misc Yes and:
I've always struggled to articulate my ideas, experiences. Workplace democracy is a hard sell. I've only successfully used it when I had full control, like a benevolent dictator. Supremely ironic.
Focus on good structures and processes and the outcomes will take care of themselves. h/t Luke Hohmann and The Journey of the Software Professional.
Workplace democracy is about both empowerment and responsibility. I hired really good people. The answers we need are right here. The trick is creating the environment where the team can find and flesh out their answers. Together! Maybe this is called nurture.
My team members have always owned their processes and structures, and therefore they earned their outcomes. Using democracy instills emotional involvement and commitment.
My primary involvement was adjudicator, enforcer. If a team made a joint decision, I held them to it. No sniping, sabotage, withholding, backstabbing, and all those other icky personal political BS details. If someone wanted to, needed to, revise a team's decision, then it was handled democratically. So be prepared to be the asshole.
Democracy feels slower, more painful. That's only because the heartache is front loaded. It's one of those "go slower to move faster" things. If you stick to the process, there's much less rework, relitigation.
Trust is key. In that "disagree and commit" sort of way. In owning and learning from mistakes. In demonstrating that team decisions will not be capriciously or casually disregarded or overruled.
Like a magpie, I cobbled together goofy ideas from every where. Joint Application Development (JAD) for brainstorming, project planning. Approval voting for triage. Roman evaluation for hiring. Balance of powers between roles (Marketing, Engineering, QA) for governance. Streamlining from Goldratt's theory of constraints. Etc, etc. Books like Innovation Games are good sources.
Democracy is hard. Requires commitment. It gets A LOT easier once the culture is established (eg storming, forming, norming, performing).
Major caveat: Once you experience democracy, a high trust environment, it kinda ruins you for the rest. It's really, really hard to suspend disbelief.
Interesting article. FWIW, although unrelated, this is by John Ousterhout, the author of "A philosophy of software design"
[1] https://hn.algolia.com/?q=a+philosophy+of+software+design
[1] https://hn.algolia.com/?q=a+philosophy+of+software+design
In my experience, lack of consensus is always due to people who have strong opinions and potentially a lot of knowledge in a general area, however the specifics/particulars of the problem are not known or understood by them, hence they are effectively “trying to solve the previous problem, not the current problem”. The metaphor often used is “they were fighting the old war” and I think that makes sense: people who get into high management positions think that they know everything, and they do, but about “old stuff”. New problems, or problems in a slightly different subarea come about and they are suddenly finding themselves unqualified, so they try to re-establish dominance through pulling rank.
Just my 2 cents
Just my 2 cents
I'm not sure if it's a stylistic choice or a badge of 90s hackerdom, but this and the next top HN personal blog post right now
have no scaling or view metas and are impossible to read on a phone. I feel like open decision-making isn't working well if it hasn't reached a consensus yet about mobile readability. (I'm just being snarky because I'm in the middle of rewriting a ton of ancient mobile-unfriendly code, but, really I would polish up my presentation before I put something on HN).
> [Works best in environments with] general agreement on the organization's overall goals, so that people can agree on how to choose among alternatives.
Something I would add to the process is an early exploration of the organisational outcomes relevant to the decision. Goals and measures of success first (hopefully including some leading measures), solutions last.
Sometimes those are enough - solutions can be left to those closest to the problem. Hence OKR, 4DX, Tight-Loose-Tight, etc
Something I would add to the process is an early exploration of the organisational outcomes relevant to the decision. Goals and measures of success first (hopefully including some leading measures), solutions last.
Sometimes those are enough - solutions can be left to those closest to the problem. Hence OKR, 4DX, Tight-Loose-Tight, etc
I read the article and while the approach seems reasonable, in real life it doesn't always work.
My colleague tried a similar method recently and the result was a total disaster. In stage I, collecting the inputs, he gathered everybody's opinions. In stage II, consensus, everybody was happy. Why? Because person A said we should do A, person B said, "Fine, but we should also do B", person C said, "that's perfect, but we must also do C". The result was a huge monster that everybody thought was possible to realize, except person Z who was responsible for QA and knew very well it's going to fail. Now, in phase III, obviously problems started to pile up. Person Z was overworked and in the end he left the company.
So, basically you need to be smart and know when it makes sense to use the methodology and when it makes no sense. As a rule of thumb, if you work with a small group of smart people who also have a rough idea of what others are doing, it's worth taking the risk.
My colleague tried a similar method recently and the result was a total disaster. In stage I, collecting the inputs, he gathered everybody's opinions. In stage II, consensus, everybody was happy. Why? Because person A said we should do A, person B said, "Fine, but we should also do B", person C said, "that's perfect, but we must also do C". The result was a huge monster that everybody thought was possible to realize, except person Z who was responsible for QA and knew very well it's going to fail. Now, in phase III, obviously problems started to pile up. Person Z was overworked and in the end he left the company.
So, basically you need to be smart and know when it makes sense to use the methodology and when it makes no sense. As a rule of thumb, if you work with a small group of smart people who also have a rough idea of what others are doing, it's worth taking the risk.
In your example there is no consensus as Ousterhout would define it. From the article:
“The second possible outcome is that the poll did not produce a clear consensus. For example, an 80-20 split is a fairly clear consensus, but 60-40 is not a consensus. A 5-2 vote seems on the surface like a consensus, but if all of the votes in the majority were from the Engineering team and both of the votes in the minority were from Marketing then there is no consensus: there's a departmental conflict. If the consensus isn't clear to everyone in the room, it's better to follow the steps below than to pretend that there was a consensus.“
QA, in your example, hasn’t consented. Therefore no consensus.
It’s important to distinguish between consensus and majority rule. They are not the same concepts, though seemingly similar.
“The second possible outcome is that the poll did not produce a clear consensus. For example, an 80-20 split is a fairly clear consensus, but 60-40 is not a consensus. A 5-2 vote seems on the surface like a consensus, but if all of the votes in the majority were from the Engineering team and both of the votes in the minority were from Marketing then there is no consensus: there's a departmental conflict. If the consensus isn't clear to everyone in the room, it's better to follow the steps below than to pretend that there was a consensus.“
QA, in your example, hasn’t consented. Therefore no consensus.
It’s important to distinguish between consensus and majority rule. They are not the same concepts, though seemingly similar.
I'm not sure. There was just one representative from each department/team, and there were around 20 of them. Only one objected. So if "80-20 split is a fairly clear consensus", 95-5 is even more so.
I remember this story as the approach seemed quite reasonable to me initially. However, the weak point in this case was that people cared only about only a limited set of items, mostly related to their work, and were unable to grasp how the aggregation of everything agreed upon would influence the outcome.
That's the point where a good manager should step in and say something like, "B and C, I agree that what you propose is important, but we can't possibly realize everything everybody is asking for. Therefore we will have to consider your requests on another occasion."
I remember this story as the approach seemed quite reasonable to me initially. However, the weak point in this case was that people cared only about only a limited set of items, mostly related to their work, and were unable to grasp how the aggregation of everything agreed upon would influence the outcome.
That's the point where a good manager should step in and say something like, "B and C, I agree that what you propose is important, but we can't possibly realize everything everybody is asking for. Therefore we will have to consider your requests on another occasion."
> if all of the votes in the majority were from the Engineering team and both of the votes in the minority were from Marketing then there is no consensus
This is the critical part. If the QA objects there is no consensus. Doesn’t mean management won’t decide in favor of the others, but no consensus has happened if a major group objects.
This is the critical part. If the QA objects there is no consensus. Doesn’t mean management won’t decide in favor of the others, but no consensus has happened if a major group objects.
Somehow this brought to mind the Netscape Lore of their CEO issuing the edict:
“If you see a snake, kill it. Don’t play with dead snakes. And everything looks like a snake at first.”
I think it was intended in a different context to decision making, perhaps more ideas in general. But it came to mind non-the-less.
“If you see a snake, kill it. Don’t play with dead snakes. And everything looks like a snake at first.”
I think it was intended in a different context to decision making, perhaps more ideas in general. But it came to mind non-the-less.
A bit from 2016:
Open Decision-Making - https://news.ycombinator.com/item?id=10828326 - Jan 2016 (1 comment)
Open Decision-Making - https://news.ycombinator.com/item?id=10828326 - Jan 2016 (1 comment)
I'm only here to say I'm digging the cgi-bin subdirectory whether or not the site is actually running CGI.
https://en.wikipedia.org/wiki/Common_Gateway_Interface
https://en.wikipedia.org/wiki/Common_Gateway_Interface
Interesting subject, disappointing article. I wish the author would provide a bit of the historical context of their approach within the field of management science.
I was disappointed this wasn’t dug into deeper. All the examples given seem easy: picking a logo or hiring someone. But the harder ones are around things like “what is the overall direction for the company”, “who is our real customer”, “what is the main value prop of our product”, etc. In these discussions there can be die hard commitment on different sides from different departments. I don’t see a poll helping in this situation, and the author admits that too, which kind of makes the whole approach for simple decisions only.