Quick Navigation
- Start here — Why politics is an architecture concern
- Stakeholder mapping
- Managing conflicting priorities
- Difficult stakeholders
- Decision deadlocks
- Executive alignment
- Organisational resistance
- Putting it all together
- Cheat sheet
Before we start — the one thing to hold onto
Architecture decisions are made by humans in organisations with competing priorities, limited budgets, and conflicting agendas. The best technical recommendation fails without stakeholder alignment — not because it's wrong, but because the people who need to approve, fund, and implement it are pulling in different directions. I've seen architects believe their job is purely technical — make the right recommendation, present the evidence, and let the "right" decision win. It doesn't work that way.
Navigating organisational reality is as important as making the right technical decision. Conflicting priorities are normal. Resistance is almost always rational from the resistor's point of view. Executive alignment must be built deliberately — not assumed.
Architects who ignore politics get surprised. Architects who understand politics anticipate resistance, build alliances, and resolve conflicts before they block decisions. This isn't manipulation — it's understanding the human system behind the technical system.
Keep it in mind.
1. Why politics is an architecture concern — The human system behind the technical system
Architects often believe their job is purely technical — make the right recommendation, present the evidence, and let the "right" decision win. But in organisations, decisions are made by people with competing incentives, limited information, and different levels of authority. Ignoring this reality means your recommendations get overruled, delayed, or quietly ignored.
Every architecture decision exists within two systems — the technical system (what's the right design?) and the human system (who wants what, who decides, who's affected?). Architects must navigate both.
flowchart TD
ARCH["🏗️ Architecture Decision"] --> TECH["🔧 Technical System\nWhat is the right design?\nPatterns · Trade-offs · Evidence"]
ARCH --> HUMAN["👥 Human System\nWho wants what?\nWho decides? Who is affected?"]
TECH --> RIGHT["✅ Technically correct\nrecommendation"]
HUMAN --> ALIGN["🤝 Stakeholder alignment\napproval and adoption"]
RIGHT --> VALUE["🎯 Value created"]
ALIGN --> VALUE
What "politics" means in this context: Not backstabbing, manipulation, or power games. Yes understanding incentives, building relationships, resolving conflicts, and navigating authority. Politics is the process through which groups of people make decisions when they have different interests.
The organisational systems every architect must understand: Formal authority — who has the title and the approval right. Know the RACI; go to the right person. Informal influence — who people actually listen to. Build relationships with influencers. Incentive structure — what people are measured on and rewarded for. Align recommendations with incentives. Information flow — who knows what, and when. Pre-align to control the narrative. History — what's been tried before and failed. Learn the context; don't repeat mistakes.
Common political dynamics in architecture: Tribal loyalty — "We don't use technology from that team." Technical choices become political. Empire building — "My team should own this capability." Scope decisions become territorial. Sunk cost — "We already invested in this; we can't change." Rationalisation blocked by attachment. Vendor relationship — "Our account rep promised us this." Technology choices constrained by politics. Risk aversion — "We tried that before and it failed." Innovation blocked by history.
Architecture exists in two systems — technical and human. Navigating both is the architect's job.
Try it yourself — The two systems check
Think of your last architecture recommendation that didn't get approved.
| Question | Your answer |
|---|---|
| Was it technically sound? | |
| Did you map the stakeholders? | |
| Did you understand their incentives? | |
| Did you pre-align before the formal meeting? |
If the answer to the first is "yes" and the others are "no," the human system blocked the technical system.
2. Stakeholder mapping — Identifying who influences, who decides, and who is affected
Without stakeholder mapping, architects communicate randomly — presenting to whoever shows up in the meeting. But the people in the meeting are rarely the people who decide. Decision-makers often delegate attendance to someone else.
Stakeholder mapping identifies four categories for every architecture decision:
flowchart TD
MAP["🗺️ Stakeholder Map"] --> DECIDE["🎯 Decision-Makers\nAuthority to approve or reject"]
MAP --> INFLUENCE["💡 Influencers\nShape the decision-maker's view"]
MAP --> AFFECTED["👥 Affected\nImpacted by the decision"]
MAP --> INFORMED["📢 Informed\nNeed to know but do not decide"]
DECIDE --> ACTION_1["Action: Present to them\ndirectly"]
INFLUENCE --> ACTION_2["Action: Pre-align with them\nbefore the formal meeting"]
AFFECTED --> ACTION_3["Action: Consult with them\naddress their concerns"]
INFORMED --> ACTION_4["Action: Notify after the\ndecision is made"]
The stakeholder map template:
| Stakeholder | Role | Interest | Influence | Stance | Action |
|---|---|---|---|---|---|
| CTO | Decision-maker | Technology direction | High | Supportive | Present directly |
| VP Engineering | Decision-maker | Delivery speed | High | Cautious | Pre-align on trade-offs |
| Security lead | Influencer | Compliance | Medium | Concerned | Consult and address concerns |
| Team lead | Affected | Implementation burden | Low | Resistant | Engage early, address concerns |
| Product director | Influencer | Feature velocity | Medium | Neutral | Present speed implications |
The power/interest grid: High power, high interest — manage closely. Full engagement, pre-align. High power, low interest — keep satisfied. Minimal effort, don't irritate. Low power, high interest — keep informed. Consult, address concerns. Low power, low interest — monitor. Inform, don't overwhelm.
Building the map — the exercise: List all stakeholders — who's involved, affected, or can block this decision? Classify by role — decision-maker, influencer, affected, informed. Assess interest — how much do they care about this decision? Assess power — how much authority do they have over the outcome? Determine stance — supportive, neutral, cautious, resistant, hostile. Plan action — what engagement does each stakeholder need?
Map decision-makers, influencers, affected, and informed — then act differently for each.
Try it yourself — The map exercise
Take your next architecture decision. Map the stakeholders:
| Stakeholder | Role | Power | Interest | Stance | Action needed |
|---|---|---|---|---|---|
If you haven't mapped them, you're communicating randomly.
3. Managing conflicting priorities — When stakeholders want incompatible things
Stakeholders will want incompatible things. Product wants speed. Security wants rigour. Engineering wants clean architecture. Finance wants cost reduction. These aren't problems to be solved — they're tensions to be managed.
The architect's job isn't to pick a side. It's to surface the conflict, make the trade-offs explicit, and help stakeholders understand what each priority costs.
flowchart TD
CONFLICT["⚔️ Conflicting Priorities"] --> SPEED["⚡ Product\n'Faster delivery'"]
CONFLICT --> SECURE["🔒 Security\n'Stronger controls'"]
CONFLICT --> CLEAN["📐 Engineering\n'Cleaner architecture'"]
CONFLICT --> COST["💰 Finance\n'Lower cost'"]
SPEED --> TRADEOFF["🎯 Trade-off Surfaced\n'This speed costs us X\nin security/quality/cost'"]
SECURE --> TRADEOFF
CLEAN --> TRADEOFF
COST --> TRADEOFF
TRADEOFF --> DECIDE["Decision-Maker Decides\nWith full information"]
The architect's role in conflicts: Surface the conflict — don't let it stay hidden. Make trade-offs explicit — "if we prioritise speed, we sacrifice X." Present options with costs — not just "we could do A or B" but "A costs X, B costs Y." Escalate when needed — don't try to resolve conflicts you don't have authority to resolve. Document the decision — so the trade-off is understood, not forgotten.
Common architecture conflicts: Speed vs quality — product vs engineering. Quantify the cost of each — "speed now costs us X weeks of rework." Innovation vs stability — business vs operations. Present risk and reward — "innovation has Y% chance of Z impact." Centralisation vs autonomy — enterprise architecture vs domain teams. Apply the consistency/autonomy framework. Build vs buy — engineering vs procurement. Evaluate differentiation vs commodity. Short-term vs long-term — product vs architecture. Present the interest rate — "delay costs X per quarter."
The conflict resolution process: Detect (conflict identified) → Understand (what does each stakeholder want and why?) → Frame (make the trade-off explicit) → Options (present choices with costs) → Authority to decide? Yes → Decide. No → Escalate to decision-maker → Decide.
Conflicts are tensions to be managed, not problems to be solved — surface them, make trade-offs explicit, let decision-makers decide.
Try it yourself — The conflict surface
What conflicting priorities exist in your current project?
| Stakeholder | What they want | What it costs | Trade-off surfaced? |
|---|---|---|---|
If the trade-off isn't surfaced, the conflict is hidden — and it will block you later.
4. Difficult stakeholders — Resistance, scepticism, and how to engage rather than override
Some stakeholders resist architecture — not because they're unreasonable, but because they have rational reasons for their position. Overriding resistance creates resentment. Understanding and engaging it creates alignment.
Resistance usually has a root cause. The architect's job is to find it and address it — not to push through it.
flowchart TD
RESIST["😤 Resistance"] --> WHY{"Why are they\nresisting?"}
WHY -->|"Threatened"| THREAT["😰 Feels threatened\nArchitecture changes their\nrole, team, or power"]
WHY -->|"Burned"| BURNED["🔥 Burned before\nPast architecture initiative\nfailed or caused pain"]
WHY -->|"Incentivised"| INCENTIVE["📊 Wrong incentives\nTheir metrics do not\nalign with architecture goals"]
WHY -->|"Uninformed"| INFO["❓ Does not understand\nLack of information\nabout the rationale"]
WHY -->|"Legitimate"| LEGIT["⚖️ Legitimate concern\nThey see a real risk\nthe architect missed"]
THREAT --> ENGAGE["🤝 Engage\nAddress the root cause"]
BURNED --> ENGAGE
INCENTIVE --> ENGAGE
INFO --> ENGAGE
LEGIT --> ENGAGE
ENGAGE --> ALIGN["✅ Alignment\nNot forced compliance"]
The engagement playbook:
| Resistance type | Root cause | Engagement approach |
|---|---|---|
| Threatened | Feels their role/team/power is at risk | Involve them in the design; give them ownership |
| Burned | Past initiative failed or caused pain | Acknowledge the history; show what's different now |
| Wrong incentives | Metrics don't align | Escalate the incentive misalignment; don't blame the person |
| Uninformed | Doesn't understand the rationale | Invest in education; don't assume malice |
| Legitimate concern | Sees a real risk you missed | Listen and adapt — they may be right |
The empathy map for resistant stakeholders: What do they say? — what are their stated objections? What do they think? — what are their real concerns — stated and unstated? What do they feel? — are they threatened, frustrated, confused, or legitimately concerned? What do they do? — are they blocking, ignoring, going around, or engaging?
Anti-patterns — what NOT to do: Override — "The architecture board has decided." Creates resentment; resistance grows underground. Ignore — "They'll come around." Resistance festers; builds alliances against you. Condescend — "They just don't understand." Dismisses legitimate concerns; loses credibility. Capitulate — "Fine, we'll do it their way." Architecture loses credibility; precedent set.
Resistance is usually rational from the resistor's perspective — find the root cause and address it.
Try it yourself — The resistance diagnosis
Who's resisting your architecture recommendations?
| Stakeholder | Resistance type | Root cause | Engagement approach |
|---|---|---|---|
If you're overriding instead of engaging, you're creating resentment.
5. Decision deadlocks — Diagnosing why decisions stall and how to unblock them
Some architecture decisions simply stall. Weeks pass. Nothing moves. The meeting is rescheduled. The decision is deferred. Everyone agrees a decision is needed but nobody makes one.
Deadlocks have root causes. Diagnosing the cause determines the unblocking strategy.
flowchart TD
DEADLOCK["🔒 Decision Deadlock"] --> DIAGNOSE{"Why is it\nstuck?"}
DIAGNOSE -->|"Authority"| AUTH["Unclear authority\nNobody knows who decides"]
DIAGNOSE -->|"Information"| INFO_M["Missing information\nCannot decide without data"]
DIAGNOSE -->|"Conflict"| CONFLICT_D["Unresolved conflict\nStakeholders disagree"]
DIAGNOSE -->|"Incentive"| INCENT_D["Competing incentives\nNo one benefits from deciding"]
DIAGNOSE -->|"Fear"| FEAR["Fear of being wrong\nNobody wants to own it"]
AUTH --> UNBLOCK_1["Fix: Clarify authority\ndefine who decides"]
INFO_M --> UNBLOCK_2["Fix: Get the data\nremove the blocker"]
CONFLICT_D --> UNBLOCK_3["Fix: Surface the conflict\nescalate to authority"]
INCENT_D --> UNBLOCK_4["Fix: Align incentives\nmake deciding rewarding"]
FEAR --> UNBLOCK_5["Fix: Reduce risk\nsmaller decisions, reversibility"]
The unblocking toolkit:
| Root cause | Diagnostic question | Unblocking action |
|---|---|---|
| Unclear authority | "Who has the right to decide this?" | Define and publish the decision rights matrix |
| Missing information | "What data is blocking this decision?" | Commission the analysis; set a deadline |
| Unresolved conflict | "What are the conflicting positions?" | Surface the trade-off; escalate to authority |
| Competing incentives | "Who benefits from not deciding?" | Align incentives; make the cost of delay visible |
| Fear of being wrong | "What makes this decision scary?" | Make it reversible; start with a pilot |
The deadlock diagnostic process: Decision stalled → Who has authority to decide? Nobody → Authority gap: define and assign. Someone → Are they willing to decide? No → Why not? Conflict → Unresolved conflict: surface and escalate. Information → Missing data: commission analysis. Fear → Risk aversion: reduce scope, make reversible. Incentive → Misaligned incentives: align or escalate.
The cost of delay — making inaction visible: "This decision has been pending for 6 weeks. During that time: 2 teams are blocked — can't proceed without the decision. The cost of delay is £X per week in idle capacity. The technology deadline (vendor EOL) is in 4 months. If we don't decide by [date], we lose the migration window."
Deadlocks have root causes — diagnose before trying to unblock. The fix depends on the cause.
Try it yourself — The deadlock check
What decisions are currently stalled?
| Decision | Root cause | Unblocking action | Owner |
|---|---|---|---|
If you haven't diagnosed the root cause, you're treating symptoms.
6. Executive alignment — Building relationships before you need them
Architects often approach executives only when they need something — approval, budget, authority. By then, it's too late. Executive alignment must be built before you need it — through regular, low-stakes engagement that builds trust and understanding.
Executive alignment isn't about politics or flattery. It's about making sure executives understand your perspective, trust your judgement, and know what you're working on — so that when you need their support, they're already informed.
flowchart TD
BEFORE["🤝 Build Before You Need"] --> REGULAR["📅 Regular Touchpoints\nBrief updates\nNo decisions needed"]
REGULAR --> TRUST["🏆 Trust Built\nExecutives know your work\nand trust your judgement"]
TRUST --> NEED["🎯 When You Need Support\nThey are already informed\nDecisions are faster"]
AFTER["❌ Only Approach When Needed"] --> SURPRISE["😮 Surprise\nExecutives are unprepared\nDecisions are slow"]
SURPRISE --> RESIST["😤 Resistance\n'Don't know enough\nto approve this'"]
The executive alignment playbook:
| Action | Frequency | Purpose |
|---|---|---|
| Brief update | Monthly | 5-minute summary of what architecture is working on |
| Direction check | Quarterly | Validate architecture direction against business strategy |
| 1:1 relationship | Ongoing | Know each other; understand each other's concerns |
| Pre-alignment | Before formal decisions | Share the recommendation before the meeting |
| Post-decision follow-up | After decisions | Report on outcomes — builds credibility for next time |
The alignment calendar: Q1 — direction-setting session. Validate architecture priorities against business strategy. Q2 — progress update. Share results and course-correct if needed. Q3 — investment case presentation. Align on next year's architecture investment. Q4 — year-in-review and forward look. Demonstrate value and set next year's direction.
What executives need from architects: Clarity — one-pagers, not 60-page papers. Confidence — evidence and track record, not just opinions. Conciseness — 5 minutes, not 45 minutes. Connection to business — outcomes and risk, not technology choices. Consistency — regular touchpoints, not ad-hoc requests.
Executive alignment = regular, low-stakes engagement that builds trust — not just approaching when you need approval.
Try it yourself — The alignment check
When was your last engagement with executives?
| Executive | Last contact | Purpose | Next touchpoint |
|---|---|---|---|
If you only approach when you need approval, you're too late.
7. Organisational resistance to architecture — Why it happens and how to address the real cause
Some organisations resist architecture itself — not a specific decision, but the concept of architecture. "We don't need architects." "Architecture slows us down." "We tried that and it didn't work."
Organisational resistance to architecture is almost always a symptom of past failures — architecture that was imposed, that was disconnected from delivery, or that created bureaucracy without value.
flowchart TD
RESIST_ORG["🚧 Organisational Resistance"] --> WHY{"Why does the\norganisation resist?"}
WHY -->|"Imposed"| PAST_1["📜 Was imposed\nTeams had no voice\nResentment built"]
WHY -->|"Disconnected"| PAST_2["🏝️ Was disconnected\nArchitecture didn't\nmatch delivery reality"]
WHY -->|"Bureaucratic"| PAST_3["📋 Was bureaucratic\nCreated overhead\nwithout value"]
WHY -->|"Unclear"| PAST_4["❓ Was unclear\nNobody understood\nwhat architects do"]
PAST_1 --> FIX_1["Fix: Co-create\nInvolve teams in decisions"]
PAST_2 --> FIX_2["Fix: Embed\nArchitects in delivery teams"]
PAST_3 --> FIX_3["Fix: Lighten\nAutomate governance\ndeliver value fast"]
PAST_4 --> FIX_4["Fix: Demonstrate\nShow quick wins\nCommunicate clearly"]
The recovery approach:
| Root cause | Symptom | Recovery |
|---|---|---|
| Was imposed | "Architecture tells us what to do" | Co-create decisions with teams; give them voice |
| Was disconnected | "Architecture doesn't understand delivery" | Embed architects in delivery; be present |
| Was bureaucratic | "Architecture is a bottleneck" | Automate governance; deliver value quickly |
| Was unclear | "What do architects actually do?" | Demonstrate quick wins; communicate role clearly |
The trust-rebuilding ladder: Zero trust ("Architecture is overhead") → Quick wins (solve a real problem for a team) → Present (architects embedded in delivery) → Trusted (teams seek architecture input proactively) → Partner (architecture and delivery collaborate as equals).
The quick win strategy: Unblock a stuck team — architecture helps, not hinders. 1-2 weeks. Simplify a complex integration — architecture reduces complexity. 2-4 weeks. Create a useful template — architecture provides assets. 1 week. Run a useful workshop — architecture facilitates decisions. 1 day. Resolve a technology dispute — architecture provides evidence. 1-2 weeks.
Organisational resistance is almost always a symptom of past failure — fix the root cause, not the symptom.
Try it yourself — The resistance check
Does your organisation resist architecture?
| Symptom | Present? | Root cause | Recovery action |
|---|---|---|---|
If you're treating the symptom instead of the root cause, the resistance will continue.
Putting it all together
Here's the complete picture in one diagram. This is the mental model worth internalising.
flowchart TD
ARCH["🏗️ Architecture Decision"] --> MAP["🗺️ Map Stakeholders\nDecision-makers · Influencers\nAffected · Informed"]
MAP --> UNDERSTAND["🤝 Understand Motives\nWhat do they want?\nWhy are they resisting?"]
UNDERSTAND --> NAVIGATE["🧭 Navigate\nSurface conflicts\nBuild alignment\nUnblock deadlocks"]
NAVIGATE --> EXEC_ALIGN["👔 Executive Alignment\nBuilt before needed\nRegular touchpoints"]
EXEC_ALIGN --> VALUE["✅ Value\nDecisions approved\nConflicts resolved\nTeams aligned"]
The foundation:
The best architecture recommendation fails without stakeholder alignment. Technical correctness is necessary but not sufficient — you need the human system aligned too. Resistance is almost always rational from the resistor's perspective. Before judging, understand their incentives, their history, and their concerns. Find the root cause. Executive alignment must be built before you need it. Regular, low-stakes engagement builds trust. Approaching executives only when you need approval is too late. Map stakeholders, understand motives, build alignment. The human system determines whether the technical system gets built.
Cheat Sheet — All the key terms
| Concept | One-Line Memory | Key Action |
|---|---|---|
| Two systems | Technical and human | Navigate both, not just the technical one |
| Stakeholder mapping | Decision-makers, influencers, affected, informed | Act differently for each category |
| Power/interest grid | High power + high interest = manage closely | Focus energy where it matters most |
| Conflicting priorities | Tensions to be managed, not solved | Surface trade-offs, let decision-makers decide |
| Resistance | Root cause is usually rational | Diagnose before engaging |
| Decision deadlocks | Diagnose the cause before unblocking | Authority, information, conflict, incentive, fear |
| Executive alignment | Build before you need it | Regular touchpoints, pre-alignment |
| Organisational resistance | Symptom of past failure | Fix the root cause with quick wins and co-creation |
How to know if this landed
You'll know this has landed when someone stops treating stakeholder management as optional and starts treating it as core to the architect's role. Has a stakeholder map for each significant architecture decision. Can identify the decision-maker, influencers, and affected parties for any active decision. Conflicting priorities are surfaced and made explicit — not hidden. Decision deadlocks are diagnosed and unblocked within 2 weeks. Executive alignment is maintained through regular touchpoints — not just when approval is needed. Pre-alignment happens before formal meetings — key stakeholders aren't surprised. And organisational resistance is being addressed through quick wins and co-creation.
What changes when the mental model clicks
I've run this session with a large retail organisation where the architecture team was seen as "the ivory tower" — decisions imposed without team input. Engineering teams routed around architecture — building whatever they wanted. Executive sponsor didn't understand what architecture did — no regular engagement. Decision deadlocks were common — 3+ weeks to resolve any cross-team decision. The gap at the start is usually not about understanding politics — it's about not navigating the human system.
What changes after this session:
Teams stop treating stakeholder management as optional and start treating it as core to the architect's role. The stakeholder mapping exercise — "who decides, who influences, who's affected?" — is always the moment things click. People stop treating resistance as irrational and start treating it as a symptom to diagnose. Their results get better. They stop getting surprised by blocked decisions when the real problem was that they hadn't mapped the stakeholders.
The executive alignment exercise tends to immediately change how architects engage with leadership. They start building regular touchpoints. Their approval rates go up. They stop approaching executives only when they need approval when the real problem was that they hadn't built trust beforehand.
Book a Workshop
Ready to navigate organisational dynamics and build stakeholder alignment?
or
1-day workshop includes stakeholder mapping exercise — map the stakeholders for your real architecture decisions, conflict resolution practice — surface and frame real conflicts in your organisation, resistance diagnosis — identify root causes of resistance in your context, deadlock resolution workshop — diagnose and unblock a stalled decision, executive alignment planning — design your touchpoint cadence, trust recovery strategy — plan quick wins for resistant parts of the organisation, and stakeholder map template + conflict resolution framework + executive alignment guide.