Before you even get to a decision meeting, how do you figure out which stakeholders' priorities you actually need to reconcile on an architecture decision, out of everyone who has an opinion?

## More opinions than can be reconciled An architecture decision of any real size attracts more opinions than an architect can or should reconcile one by one - a data model change might draw input from the team that owns the database, a security reviewer, a product manager worried about timeline, a finance stakeholder worried about licensing cost, and engineers who just want to weigh in. Treating every voice as equally important is a recipe for decision paralysis: either the architect spends unsustainable time in individual conversations trying to satisfy everyone, or the loudest voice in the room drives the decision regardless of real stake or authority. **Stakeholder mapping** is the mechanism for sorting this out deliberately, before the decision meeting, rather than reactively during it. ## The power-interest grid The most common version is the **power-interest grid**: one axis is power - how much formal or informal authority someone has over whether the decision proceeds, such as budget approval, veto rights, or organizational seniority - the other is interest, how much the outcome actually affects them day to day. Plotting stakeholders on this grid produces four rough engagement strategies. 1. **High power, high interest** - like a VP of Engineering who both cares deeply and can block the decision - get direct, ongoing engagement; these are the people whose conflicting priorities actually need reconciling in the room, because a decision that leaves one of them unaddressed will get overturned or blocked later. 2. **High power, low interest** - an executive sponsor with budget authority but not tracking details day to day - need concise, well-timed updates; the risk with this group isn't disagreement, it's being blindsided by a decision they weren't shown early enough and objecting late, after everyone else already aligned. 3. **Low power, high interest** - engineers who'll implement the decision and care a great deal but lack veto authority - need to be kept genuinely informed and heard, both because their operational knowledge often surfaces real risks higher-power stakeholders miss, and because ignoring them creates resentment and passive resistance during implementation even after formal sign-off. 4. **Low power, low interest** gets minimal, efficient communication. ## Why the allocation matters This exists because architecture alignment effort is a finite, expensive resource, and misallocating it is a common reason decisions stall or unravel. An architect who spends equal time with everyone either burns out satisfying people whose objections don't matter to the outcome, or fails to notice a high-power stakeholder's unaddressed concern because it got lost among lower-stakes conversations, only to have that stakeholder block or reverse the decision at the most expensive moment. ## The trade-off The trade-off is that stakeholder mapping requires the architect to make a judgment call about who actually matters, and getting it wrong has real cost. - **Under-estimating someone's power** - assuming a technical lead has no influence when they in fact have the CTO's ear - means their objection surfaces late and expensively. - **Over-estimating someone's interest** and spending disproportionate time on a stakeholder who turns out not to care creates its own opportunity cost. The map also isn't static: power and interest shift as a project moves from proposal to build to rollout, and a mapping done once at kickoff can go stale. ## A concrete failure mode A concrete failure mode: an architect who focuses engagement entirely on vocal engineers in daily standups (low power, high interest) while assuming a quiet, senior finance stakeholder (high power, low interest, easy to forget since they never show up to technical meetings) will simply rubber-stamp a licensing-cost-heavy decision. When that stakeholder finally reviews the numbers at final sign-off, they raise a blocking objection a five-minute early conversation could have surfaced months earlier - and now the timeline absorbs the cost of a late redesign. ## Where it shows up Structured stakeholder mapping - power-interest grids, or the related RACI framing of who's Responsible, Accountable, Consulted, and Informed - shows up across enterprise architecture practice, including as a formal part of frameworks like TOGAF's stakeholder management approach, precisely because architecture decisions routinely involve more interested parties than can be reconciled by instinct alone, and getting the engagement plan wrong is expensive to fix after the fact.