Power Mapping Before Intervention¶
Why It Matters¶
Many change efforts fail not because the ideas are bad but because change agents don't understand or navigate the power structure. They propose changes that threaten powerful stakeholders without realizing it, ignore informal power holders who can quietly kill initiatives, or fail to build coalitions strong enough to overcome resistance. Power is uncomfortable to discuss explicitly—it feels political rather than meritocratic. But ignoring power doesn't make it disappear; it just ensures you'll be blindsided by it. Organizations are political systems, not pure meritocracies. Effective change requires understanding power distribution and working with (or around) it.
The Key Move¶
Before proposing change, map: Who controls budget allocation? Who has veto power formal or informal? Who has high status or credibility that makes their endorsement valuable? Who benefits from current state and would lose from change? Who are the informal influencers whose opposition would kill the initiative? Then strategize: Can you get powerful stakeholders on board early? Can you design the change to avoid threatening key power holders? If powerful stakeholders will oppose, do you have coalition strong enough to prevail? If not, can you pilot the change in low-stakes environment first? Don't launch change without understanding power landscape.
Classic Application¶
Kotter's research on change leadership. He identified that most failed change efforts shared a pattern: insufficient coalition-building. Change agents convinced themselves and a small group of supporters, then announced change. Powerful stakeholders who weren't consulted resisted. Informal influencers spread skepticism. Mid-level managers who would have to implement change weren't bought in. The change died in implementation. Successful changes followed different pattern: change agents spent months building "guiding coalition" of people with power (formal and informal), credibility, and diverse perspectives. Change was co-designed with coalition members. Launch had momentum because powerful stakeholders were already committed. The difference wasn't quality of ideas—it was navigation of power structure.
Surprising Application¶
Architecture changes in software engineering. An engineer identifies that the system's architecture is causing problems and proposes a rewrite or significant refactoring. They prepare a thorough technical case with diagrams, benchmarks, and migration plans. The proposal is rejected or deprioritized. Why? They didn't map power. The current architecture was championed by a senior engineer who would lose status if it's replaced. The proposal requires resources from a team whose manager has competing priorities and controls budget allocation. The CTO values stability over improvement and has veto power. Technical merit is necessary but insufficient. The successful approach: first, get the senior engineer involved in diagnosing problems (protecting their status as expert rather than positioning change as indictment of their work). Second, frame the change in terms of the CTO's priority (stability, reduced incidents). Third, negotiate resource allocation with the manager by offering something they value. Power mapping enables navigation.
Failure Modes¶
Becoming purely Machiavellian—political navigation doesn't mean abandoning ethics or substance. Assuming all resistance is illegitimate power protection—sometimes power holders have legitimate objections. Over-investing in coalition-building at expense of action—paralysis from trying to get everyone on board. Ignoring that power structures can and should sometimes be challenged—some changes require confronting power, not accommodating it. Using power mapping to manipulate rather than navigate—there's a difference between building genuine coalition and manufacturing false consent.
Go Deeper¶
Kotter, "Power, Dependence, and Effective Management," Harvard Business Review 55(4), 1977; Pfeffer, Power: Why Some People Have It and Others Don't (2010).