Open Decision-Making (2014)
web.stanford.edu
web.stanford.edu
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.
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.
When there's internal conflicts, as much as possible it's better to let the market/users decide.
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.
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?
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.
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.
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.
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)
Yeah, and by “consensus” it usually means “tell the subordinates what the boss wants no questions allowed”
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.
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.
[1] https://hn.algolia.com/?q=a+philosophy+of+software+design
Just my 2 cents
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
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.
“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 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."
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.
“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.
Open Decision-Making - https://news.ycombinator.com/item?id=10828326 - Jan 2016 (1 comment)