3.2.2: Governance and Decision Making
- Page ID
- 66020
\( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)
\( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)
\( \newcommand{\dsum}{\displaystyle\sum\limits} \)
\( \newcommand{\dint}{\displaystyle\int\limits} \)
\( \newcommand{\dlim}{\displaystyle\lim\limits} \)
\( \newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\)
( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\)
\( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)
\( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\)
\( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)
\( \newcommand{\Span}{\mathrm{span}}\)
\( \newcommand{\id}{\mathrm{id}}\)
\( \newcommand{\Span}{\mathrm{span}}\)
\( \newcommand{\kernel}{\mathrm{null}\,}\)
\( \newcommand{\range}{\mathrm{range}\,}\)
\( \newcommand{\RealPart}{\mathrm{Re}}\)
\( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)
\( \newcommand{\Argument}{\mathrm{Arg}}\)
\( \newcommand{\norm}[1]{\| #1 \|}\)
\( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)
\( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\AA}{\unicode[.8,0]{x212B}}\)
\( \newcommand{\vectorA}[1]{\vec{#1}} % arrow\)
\( \newcommand{\vectorAt}[1]{\vec{\text{#1}}} % arrow\)
\( \newcommand{\vectorB}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)
\( \newcommand{\vectorC}[1]{\textbf{#1}} \)
\( \newcommand{\vectorD}[1]{\overrightarrow{#1}} \)
\( \newcommand{\vectorDt}[1]{\overrightarrow{\text{#1}}} \)
\( \newcommand{\vectE}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash{\mathbf {#1}}}} \)
\( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)
\(\newcommand{\longvect}{\overrightarrow}\)
\( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)
\(\newcommand{\ket}[1]{\left| #1 \right>}\)
\(\newcommand{\bra}[1]{\left< #1 \right|}\)
\(\newcommand{\braket}[2]{\left< #1 \vphantom{#2} \right| \left. #2 \vphantom{#1} \right>}\)
\(\newcommand{\braopket}[3]{\left< #1 \vphantom{#2}\vphantom{#3} \right| #2 \vphantom{#1}\vphantom{#3} \left| #3 \vphantom{#1}\vphantom{#2} \right>}\)
\(\newcommand{\qmvec}[1]{\mathbf{\vec{#1}}}\)
\(\newcommand{\op}[1]{\hat{\mathbf{#1}}}\)
\(\newcommand{\expect}[1]{\langle #1 \rangle}\)
\(\newcommand{\dfn}[1]{\emph{\textbf{#1}}}\)
Decision-Making Transparency
Governance bodies and RACI charts tell you who has the authority to decide. They don't tell you how a decision actually gets made once that authority is in place, or whether anyone outside the room can see how it happened. A portfolio can have a perfectly clean governance structure and still make bad decisions in the dark. This section is about what happens inside the decision itself, and why the people affected by it need to see the process, not just the verdict.
A Basic Decision-Making Framework
Most sound portfolio decisions follow a similar shape, even when the topic changes. Naming the steps explicitly keeps a decision from becoming a gut call dressed up after the fact as something more rigorous.Table \(\PageIndex{1}\): A Basic Decision-Making Framework lays out the steps a portfolio manager typically works through before a decision is finalized.
| Step | What Happens |
|---|---|
| Define the decision | State plainly what's actually being decided, and by when |
| Gather information | Pull in the data, risks, and stakeholder input needed to decide well |
| Identify options | Lay out the realistic choices, not just the first idea that came up |
| Evaluate trade-offs | Weigh each option against the criteria that actually matter here |
| Decide and document | Make the call, and write down why, not just what was chosen |
| Communicate and review | Tell the people affected, and revisit if new information arrives |
A framework like this doesn't slow decisions down. It usually speeds them up, since a lot of wasted time in real organizations comes from re-litigating a decision that was never clearly defined in the first place.
Some people assume a formal framework like this is only needed for huge, expensive decisions, and that smaller calls can just happen informally in a hallway conversation. In practice, small undocumented decisions are exactly the ones that come back to bite a portfolio manager later. Nobody remembers why a minor scope change was approved eight months ago, and without a record, that small decision becomes a mystery someone has to reconstruct from memory during an audit or a dispute.
Because of this, the framework above matters just as much for routine calls as for major ones. The documentation step doesn't need to be lengthy for a small decision. It just needs to exist.
Why Transparency Matters
Decision-making transparency means the people affected by a decision can see how it was reached, not just what the final answer was. This isn't about holding a public vote on every choice. It's about making sure the reasoning behind a decision is visible enough that someone downstream can trust it, or at least understand it, even if they disagree with it.
Without transparency, people fill the gap with their own explanations, and those explanations are rarely generous. A funding decision that isn't explained gets read as favoritism. A component that gets cut without context gets read as someone's pet project losing a political fight. Transparency doesn't guarantee everyone will be happy with a decision. It does guarantee that dissatisfaction stays about the decision itself, rather than curdling into suspicion about the process.
A common assumption is that transparency means slowing everything down with endless meetings so everyone can weigh in. That's not what transparency requires. A decision can be made quickly by a small group and still be transparent, as long as the reasoning gets shared clearly afterward. Transparency is about visibility into the "why," not about giving every stakeholder a vote on every choice. Confusing the two is often used as an excuse to avoid documenting decisions at all, on the theory that doing so would be too slow.
Treating transparency as a communication step rather than a consensus-building step is what makes it sustainable. A portfolio manager who explains a decision clearly after making it, rather than trying to get unanimous agreement before making it, gets both speed and trust.
Keeping Everyone Aligned on Where a Decision Stands
A decision rarely happens in one instant. It moves through stages, and different stakeholders often assume it's further along than it actually is. Someone in engineering might think a budget request was already approved, while finance still considers it a proposal under review. That mismatch causes real damage, since teams start acting on a decision that hasn't actually been made yet.
A simple fix is keeping a visible, shared status for any decision in flight. Proposed, under review, decided, and implemented are enough stages for most portfolio decisions. The specific labels matter less than making sure everyone is looking at the same label at the same time, rather than each stakeholder carrying their own private guess about where things stand.
A product team once began hiring contractors for a new feature the week after a budget proposal was submitted, assuming approval was a formality. Finance hadn't actually reviewed it yet, and ultimately trimmed the scope to fit a tighter quarter than the product team expected. The contractors had already been engaged by the time the real decision came back. The company ended up paying for work that had to be unwound, not because anyone acted in bad faith, but because nobody had agreed on what stage the decision was actually in.
A shared status tracker would have caught this in minutes rather than weeks. The fix here isn't more meetings. It's a single visible source of truth that both teams check before acting.
The Decision and Outcome Fallacy
Organizations have a strong, natural pull toward judging decisions by how they turned out. A risky call that happens to pay off gets celebrated as bold leadership. The same call, made with the same information, that happens to fail gets labeled reckless. This is the outcome fallacy, and it quietly rewards luck while punishing good judgment that ran into bad timing.
A common assumption is that a good outcome proves a good decision was made. It doesn't. A portfolio manager can make a well-reasoned call based on the best information available at the time and still watch it fail because of something nobody could have predicted. Someone else can make a careless, poorly researched call and get lucky. Judging the decision by the outcome alone teaches people to chase lucky bets instead of sound reasoning.
This distinction matters directly for how a portfolio manager runs reviews. A retrospective on a failed component shouldn't start by assuming the decision was wrong. It should start by asking what information was available at the time, and whether the reasoning was sound given that information. Sometimes the honest answer is that the decision was good and the outcome was simply bad luck. Sometimes it's the reverse: a successful component that was funded on shaky reasoning that happened to work out.
Picture two portfolio managers, each greenlighting a new market expansion with a similar risk profile and similar supporting data. One expansion launches right before a regional economic downturn and underperforms badly. The other launches right before a competitor unexpectedly exits the market and looks brilliant. Judged purely on outcome, one manager gets blamed and the other gets promoted. Judged on the quality of the decision itself, both made a defensible call given what they knew, and the real difference between them was timing neither one controlled.
This matters directly for a portfolio manager, because the temptation to reward outcomes over process runs through most corporate cultures. A portfolio manager's job is to keep the organization's attention on the quality of the decision-making process, documented reasoning, considered alternatives, honest risk assessment, even when a bad outcome makes that process hard to defend in the moment, and even when a lucky outcome makes a sloppy process look smarter than it actually was.
Building a Healthy Decision Culture
None of the structure above works if the culture around it punishes honest disagreement. A decision culture where people nod along in the room and then quietly work against the decision afterward is worse than one with open, difficult debate. That kind of passive resistance is invisible to the people who made the call, which means nobody gets the chance to address the real objection before it does damage. Table \(\PageIndex{2}\): Healthy Versus Unhealthy Decision Culture lays out how the same disagreement plays out differently depending on the culture around it.
| Situation | Unhealthy Response | Healthy Response |
|---|---|---|
| Disagreeing with the proposed direction | Stay quiet in the meeting, complain to peers afterward | Raise the objection directly, in the room, before the call is made |
| The decision goes against your view | Slow-walk execution or quietly withhold effort | Commit fully and execute as if it were your own call |
| A decision later looks wrong | Say "I knew this would fail" after the fact | Point back to the concern you raised at the time, and help fix it |
A healthier approach, sometimes called disagree and commit, asks people to say their disagreement out loud, in the room, before a decision is finalized. Once the decision is made, though, everyone commits to executing it fully, even the people who argued against it. This isn't about silencing dissent. It's about making sure dissent gets voiced where it can actually change the outcome, rather than surfacing later as foot-dragging or quiet sabotage once the decision is already locked in.
Disagree and commit only works if leadership genuinely listens during the disagreement phase. If objections are consistently waved off without real consideration, people stop bothering to raise them, and the culture quietly slides back into passive resistance.
Some people hear "commit" and assume it means disagreement is no longer allowed once a decision is made, or that raising a concern again later is a sign of bad faith. That's not the intent. Committing means executing the decision in good faith and giving it a genuine chance to succeed. It doesn't mean pretending the original concern never existed. If new information surfaces that supports the original objection, revisiting the decision is exactly what a healthy culture should do. Commit means "give this a real shot," not "never speak of your doubts again."
A portfolio manager who builds this kind of culture gets two things at once. Real disagreement surfaces early, when it can still improve the decision. And once a call is made, the whole organization actually moves in the same direction, instead of half of it quietly hoping the decision fails so they can say they were right.

