Issue No.74: Who Decides When Stakeholders Disagree?
The Signal
You can’t influence people you haven’t identified and don’t understand. This keeps surfacing in conversations across high-performance environments - practitioners, founders, executives all struggling with the same challenge: they’re trying to execute without mapping who actually matters.
Stakeholder mapping seems straightforward. Four questions:
Who has POWER?
Who has URGENCY?
Who has LEGITIMACY?
Are they INTERNAL or EXTERNAL to the organisation?
These questions identify stakeholders and categorise them.
Power determines who can impose their will - control resources, block decisions, grant access. Legitimacy determines whose claim is appropriate - formal authority, expertise, or affected status gives them right to be involved. Urgency determines whose need is time-critical - who faces immediate consequences if this isn’t resolved.
The intersection of these attributes determines stakeholder priority:
Definitive stakeholders (all three) demand immediate attention
Dominant stakeholders (power + legitimacy) shape strategic decisions
Dependent stakeholders (urgency + legitimacy) need advocacy
Dangerous stakeholders (power + urgency) can force short-term action
Demanding stakeholders (urgency only) are loud but limited influence
Discretionary stakeholders (legitimacy only) receive attention as resources allow
Dormant stakeholders (power only) monitor but don’t currently act
This categorisation helps practitioners prioritise who to engage and how.
But it doesn’t clarify who decides when these stakeholders disagree.
Where Stakeholder Mapping Stops
Stakeholder mapping identifies who matters, categorises their importance, and develops engagement strategies to secure support. The implicit assumption is: if we map stakeholders correctly and influence them effectively, execution will follow.
However, if a trade-off emerges - priorities conflict, resources are constrained, time pressure forces choices - who decides? It is important to clarify who has final authority, as well as who owns outcomes when things go wrong. Most organisations have mapped their stakeholders. Few have designed their decision architecture.
What Decision Architecture Adds
Stakeholder influence and decision architecture both matter but stakeholder influence without decision architecture creates meetings where everyone talks and nothing gets decided.
In high performance environments this distinction is critical.
For example, Medical team says athlete isn't ready. Coach says team needs them. Performance data is borderline. Athlete wants to play. Who decides? Without decision architecture, this becomes a 90-minute meeting where everyone talks, nothing gets decided, and the athlete remains in limbo while stakeholders negotiate.
On a commercial level, a product team may want feature expansion. Sales team wants faster delivery. Finance team worries about cost. Customer has specific requirements. Who decides? Without decision architecture, product team gets conflicting directives, every sprint and execution velocity drops because nobody knows whose priority actually wins.
In each case, stakeholder identification and influence are necessary. But decision architecture determines whether execution happens when trade-offs emerge.
This process can feel uncomfortable. Making authority explicit reveals power structures. Specifying accountability creates exposure. Acknowledging that some stakeholders’ priorities trump others challenges consensus culture.
So organisations avoid designing decision architecture explicitly. They map stakeholders, develop engagement strategies, build alignment - then discover when trade-offs emerge that nobody knows who actually decides.
Making It Operational
Translating stakeholder mapping into decision architecture requires explicit frameworks.
RACI Framework: Responsible, Accountable, Consulted, Informed
Responsible: Who does the work to make it happen
Accountable: Who has final authority and owns the outcome
Consulted: Who provides input that must be considered
Informed: Who needs to know after the decision is made
The critical element: only one person is Accountable. Everyone else has defined role but not final authority.
Stakeholder mapping creates the conditions for alignment. Decision architecture creates the structure for execution when alignment breaks down.
The Takeaway
Stakeholder mapping is necessary. Decision architecture makes it actionable.
Organisations that map stakeholders without designing decision architecture create the appearance of sophistication while leaving execution capability ambiguous.
Individual contributors and practitioners can start to map who has power, urgency, legitimacy. Then map decision architecture: whose authority is final in different contexts? Understanding this lets you navigate effectively even without formal authority.
For founders and executives, using for example, RACI framework allows you to clarify who’s Accountable vs Consulted. This provides operational clarity and enables execution under real-world constraint, not just alignment under ideal conditions.
Stakeholder mapping asks: Who matters and what do they want?
Decision architecture asks: Who decides when what they want conflicts?
Both questions matter. But execution depends on the second question being answered explicitly, not left to emerge under pressure.
You can’t influence people you haven’t identified. But you also can’t execute effectively if you haven’t clarified who carries consequence when trade-offs force choices and alignment breaks down.
We need to stop assuming stakeholder alignment means execution will follow. Start designing decision architecture that works when alignment doesn’t.
Stakeholder mapping tells you who's in the room. Decision architecture tells you who makes the call.
I would love to know your thoughts on this Issue by commenting below.
Thanks for reading! Nic x

