One night many years ago, I was a second-year medical resident on duty in the emergency room. It was about 3 a.m. and things had finally slowed down after a very busy evening. Abruptly, I was jolted wide awake from an exhausted half-slumber. A nurse in the next room had shouted, “code”. That meant that a patient’s heart had stopped.
I rushed into the room, and as the first doctor on the scene, I started “running the code”: assessing the patient, calling for medicines, checking the chest compressions, and getting the paddles ready to shock. Nurses and other personnel were streaming in. In a code, the person running the code is in charge, and everyone follows his or her orders. There is no time for discussion.
I ordered the proper medicines to be administered. We shocked him. Once, twice, thrice. At 200 joules. At 300 joules. At 360 joules. His heart didn’t respond.
In a code, there is a very specific, defined protocol you follow. How much medicine to give, what kind of medicine, when to shock. We followed the algorithm exactly. He should have responded. He didn’t. There was something wrong.
We kept on shocking, and still no response. He was dying.
So, I did something not in the algorithm. He was going to die otherwise. I called for higher power on the paddles. I shocked him at a very high-power level. It was something that was not in my training. It was something that, had I consulted others, might have led to objections. But as the code leader, it was my call and others followed my lead.
And it worked. The young man regained his heartbeat. He survived.
Soon afterwards, his chest X-ray arrived. I put it up on the light-box and cocked my head. Something wasn’t right. Flipping the X-ray back and forth, I realized what was out of place. His heart was on the right side of his chest. He had dextrocardia. (1)
So how does this relate to business?
In a code there is no time for debate. Only one person makes the decision. I don’t know if I could have convinced everyone that we should step outside the protocol and increase the power on the paddles. I don’t think I could have. That patient lived because we didn’t run the code with consensus decision-making.
Similarly, while there are many issues in business that require consensus decision-making, there are some challenges that can’t be addressed with it. Sometimes you need one decision maker, someone who will step forward and take a risk. Innovation is one such example. Innovation by committee is virtually impossible. (2)
At many large companies, decisions are made by consensus. Every person on the team, and there can be twenty or more people on a team, has to agree before the project can move forward. And, for each of them to agree, their functions (their bosses) have to agree.
This practice can reach extreme forms. For example, when Lou Gerstner arrived at IBM in 1993 to save the storied company from near-certain demise, he learned a new word: non-concurrence. If one person non-concurred at IBM, the entire project would grind to a halt. There was an entire formal system of non-concurrences, with non-concurrence coordinators, non-concurrence schedules, and non-concurrence resolution processes. You can imagine how that was affecting IBM’s competitive advantage.
The reason why consensus decision making doesn’t work in an innovation-based industry like pharmaceuticals is that when 90% to 95% of drugs fail, you must take calculated risks to be successful. If you rely on consensus decisions, you usually end up with the decision that the most conservative person on the team is comfortable with. This means that the decisions default to the lowest common denominator: the least risky decision.
I can’t tell you where on the spectrum of risk any given decision should sit, but what I can tell you is that in an innovation-driven industry, the least risky decision is almost never the right one. The only way to have no failures is to have no successes.
In addition, in a consensus decision-making system, the decision often ends up such that it’s a compromise between two functions. The functions often horse trade, so that the decision that is the least painful to every function is adopted, and pain of the decision is relatively equally distributed.
Once again, I can’t tell you where on the spectrum the right decision is, but what I can tell you is that the right decision is almost never at the halfway point between what two functions want. Usually, the right decision is beneficial to one function at the cost of another one. A claim for the drug, for example, may be so valuable from a commercial standpoint that the clinical group needs to conduct a difficult study. Or stability may be so fickle for a drug from a CMC standpoint that marketing needs to accept a painfully short shelf life.
In addition, because everyone is responsible for the decision, no one is. Sometimes, a decision never even gets made because no one is responsible for the “team” decision and you end up with decision paralysis. Our CSO calls this “passing the ball.” Everyone is passing the basketball and no one is taking the shot.
And it gets worse.
In many large companies, not only do you need horizontal consensus across team members, but then you have to obtain vertical consensus. You have to go up through several layers of approval up the chain of command. And once again, I can’t tell you what the right decision is, but if six people up the chain of command all agree with the decision, it is almost never the right decision because only the least risky decision will pass muster.
If twenty people on a team agree horizontally and six people up the chain of command agree vertically that a decision is innovative, then in all likelihood the exact opposite is the case.
A Single Decision Maker
How do you avoid death by consensus? Let’s turn to the Genentech model. Genentech during the 2000’s had a run of successes. Its success rate in drug development was about 80%, which is more than an order of magnitude higher than the standard 5%-10%.
One of the keys to Genentech’s success was its decision-making process. While there were several components of the process, perhaps the most salient aspect of the decision-making process was the single decision maker model. (3)
Unlike many other companies, Genentech always had one final decision maker. Usually, but not always, the team leader had that responsibility. In some cases, the vote would be twenty to one, but if the one vote was from the decision maker, that single vote carried the day. The team leader had the authority and the responsibility to make the final decision, after listening to and weighing all arguments and data. The team members all had an opportunity to make their case. (4)
Making one person responsible for the decision accomplishes three things. First, it allows calculated risk taking. Second, it removes the burden from the other team members, removing the incentive for them to protect themselves from the consequences of the decision by being overly risk-averse. Third, it designates one person to shoot the basketball, and prevents decision paralysis.
Get Out of the Team’s Way
Does this mean that the decisions should always be made at the top?
No. The exact opposite.
I’ve tried to incorporate the Genentech decision-making philosophy wherever I go. In addition, I’ve extended the model to remove vertical consensus.
At KindredBio, the project teams know that they don’t have to obtain vertical consensus. For example, I don’t have to agree with their decisions. I only have to understand it and be satisfied that it is thoughtful. If we’ve hired the right team, and provided the right corporate context for the decision, then in cases where the team and I don’t agree on a decision, they should be right most of the time. The team spends every day thinking about the program while I spend a few hours a month thinking about the program. If I can come to a higher quality decision than they can, there is something very wrong. (5)
Most of the time, when I have supported the team leader’s decision over my own, the team leader has been right, and the projects have been great successes. In fact, I have found that if the team and I always agree on decisions, it is usually a sign that we are not taking enough risk, and not innovating enough.
Fostering innovation requires enough managerial courage to support team decisions that the senior management thinks is wrong, and enough confidence in the team to trust that they’re producing better ideas than senior management can.
(1) Dextrocardia is rare. I’ve only seen two cases of it, including this patient. You sometimes see it in identical twins because sometimes they are mirror images of each other. One might have larger right eye and the other might have larger left eye, etc.
(2) Now, don’t get me wrong. Consensus is an excellent decision-making model for many situations. Social policy-setting. Decision-making in a low innovation business. Decision in a zero-risk tolerance business. Just not for innovation.
(3) Some of the other aspects include data-driven rather than opinion-driven decisions and a focus on good decisions rather than right decisions. I will write about these in future LinkedIn articles.
(4) And, once a decision was made, all the functions lined up behind the decision. (In a healthy corporate culture, this happens. In an unhealthy one, there is a lot of foot dragging and passive aggressive behavior after a decision is made. Sometimes this leads to consensus decision making solely to ensure that foot dragging is avoided.)
(5) To do this successfully, you have to be very transparent and push down information as well. The teams can’t make the right decisions if you are not providing them with the right information. I provide the context and the constraints, such as the budget, time envelope and success criteria, and then I push decision-making down.