Stakeholder Negotiation Planner

Stakeholder Negotiation Planner

When to Use

You need to prepare a strategy for an architecture negotiation — a conversation where the architect must persuade, push back, or reach consensus with someone who disagrees. Typical triggers:

This skill prepares the negotiation strategy. The human executes the actual conversation.

Before starting, verify:

Context

Required Context (must have before proceeding)

Observable Context (gather from environment)

Default Assumptions

Sufficiency Threshold

SUFFICIENT when ALL of these are true:
The counterpart type is known (business, architect, developer)
The specific disagreement is understood
The user's desired outcome is clear or can be inferred
PROCEED WITH DEFAULTS when:
Counterpart and disagreement are known
Power dynamics and history can be assumed
MUST ASK when:
The counterpart type is completely unclear
The disagreement itself is ambiguous

Process

Step 1: Classify the Negotiation Type

ACTION: Determine which of the three negotiation audience types this falls into, as each requires different techniques.

WHY: Negotiating with a business stakeholder who doesn't understand technology requires completely different techniques than negotiating with a senior developer who understands the technology deeply. Business stakeholders respond to cost and time framing. Developers respond to technical demonstrations. Other architects respond to evidence-based trade-off analysis. Using the wrong approach wastes credibility.

| Audience | Core Technique | Key Lever | |----------|---------------|-----------| | Business stakeholders | Leverage their grammar — translate to cost, time, and risk | They care about business outcomes, not technical elegance | | Other architects | Divide and conquer — find areas of agreement, isolate disagreements | They understand trade-offs; focus on evidence and alternatives | | Developers | Demonstration defeats discussion — show, don't tell | They trust working code and concrete examples over authority or argument |

Step 2: Prepare Audience-Specific Strategy

ACTION: Based on the audience type, prepare the negotiation strategy using the appropriate techniques. For detailed technique breakdowns, see references/negotiation-techniques.md.

WHY: Each technique targets a specific cognitive bias or communication barrier. Leverage grammar works because stakeholders literally don't hear technical arguments — they filter for business impact. Demonstration defeats discussion because developers have seen too many "it should work in theory" arguments fail in practice. Divide and conquer works on architects because it prevents ego-driven all-or-nothing positions.

For Business Stakeholders: 1. Leverage their grammar — Use business terms (cost, time-to-market, risk, competitive advantage) not technical terms. If the CTO says "we need 99.999% availability," don't argue about infrastructure complexity. Instead say: "99.999% means 5 minutes downtime per year and costs $200K in infrastructure. 99.9% means 8.7 hours per year and costs $40K. Given this is an internal tool used by 50 people, which investment matches the business value?" 2. State impacts in cost and time — Every technical recommendation must translate to dollars and calendar time. "We should refactor the data layer" is invisible to a business stakeholder. "Refactoring the data layer now costs 3 weeks but saves 2 weeks per feature for the next 12 features" is a clear business case. 3. Provide justification, not dictation — Never say "because I'm the architect." Explain the WHY. Architects who dictate without justification create the Ivory Tower anti-pattern — disconnected, distrusted, eventually ignored.

For Other Architects: 1. Divide and conquer — Before debating the disagreement, establish everything you agree on. "We agree the system needs to be distributed. We agree REST is the right protocol for these 4 services. The only disagreement is whether services A and B should communicate via REST or events." This prevents the conversation from becoming a referendum on either architect's overall competence. 2. Present trade-off analysis — Bring a structured comparison of both approaches across multiple dimensions. Let the evidence drive the conclusion rather than either person's preference. 3. Acknowledge when they're right — If the other architect has a valid point, say so explicitly. Credibility comes from intellectual honesty, not from winning every point.

For Developers: 1. Demonstration defeats discussion — If a developer insists REST is better than event-driven, don't argue. Build a small proof-of-concept showing the specific problem (latency under load, coupling during deployments) that event-driven solves. Working code settles technical arguments faster than any slide deck. 2. Avoid ivory tower behavior — Stay connected to the codebase. Architects who don't code lose credibility with developers. You can't demand event-driven architecture if you've never implemented an event consumer. 3. Explain the WHY behind constraints — Developers comply reluctantly with rules they don't understand. When they understand WHY a constraint exists, they enforce it themselves.

Step 3: Apply the 4 C's Framework

ACTION: Evaluate and strengthen the negotiation strategy against the 4 C's of Architecture.

WHY: The 4 C's are a meta-framework for all architect communication, not just negotiation. Failing at any one of them undermines the negotiation regardless of how good the technical argument is.

1. Communication — Is the message clear to THIS audience? Technical language for business stakeholders = communication failure. Business jargon for developers = condescension. 2. Collaboration — Is this framed as a joint problem-solving exercise or a win-lose argument? Negotiations framed as "let's figure this out together" succeed more than "I'm right, here's why." 3. Clarity — Is the recommendation unambiguous? Vague recommendations ("we should probably consider something more scalable") invite reinterpretation. Clear recommendations ("we should replace the single database with two domain-partitioned databases, one for user profiles and one for transactions") leave no room for misunderstanding. 4. Conciseness — Is the argument as short as it can be while remaining complete? Executives check out after 3 minutes. Developers check out when they sense padding. Architects check out when arguments become circular.

Step 4: Identify BATNA and Compromise Positions

ACTION: Define the Best Alternative to a Negotiated Agreement (BATNA) and identify possible compromise positions.

WHY: Entering a negotiation without knowing your walk-away point and your compromise zone is negotiating blind. The architect should know: "If I can't get event-driven architecture, I can accept REST with a message queue for the high-throughput services as a compromise. My BATNA is documenting the risk and revisiting in 6 months when the performance problems materialize."

Include: 1. Ideal outcome — what you want if the negotiation goes perfectly 2. Acceptable compromise — what you can live with that still addresses the core concern 3. BATNA — what you do if the negotiation fails entirely 4. Red lines — what you cannot accept under any circumstances, with justification for each

Step 5: Generate the Negotiation Brief

ACTION: Compile the complete negotiation strategy into a concise brief the user can reference before and during the conversation.

Inputs

Outputs

Negotiation Strategy Brief

# Negotiation Brief: {Topic}
Situation
Counterpart: {who, role, relationship}
Disagreement: {what's contested}
Stakes: {what's at risk if unresolved}
Audience Classification: {Business / Architect / Developer}
Strategy
Key Techniques
1. {primary technique with specific application}
2. {secondary technique}
3. {fallback technique}
Opening Frame
{How to open the conversation — specific language to use}
Key Arguments (in order of deployment)
1. {strongest argument, in counterpart's language}
2. {supporting argument}
3. {evidence/demonstration if available}
Anticipated Objections and Responses
| They might say... | Respond with... |
|-------------------|-----------------|
| {objection 1} | {response using appropriate technique} |
| {objection 2} | {response} |
Positions
| Position | Description |
|----------|-------------|
| Ideal outcome | {best case} |
| Acceptable compromise | {what you can live with} |
| BATNA | {what you do if negotiation fails} |
| Red lines | {what you cannot accept, with WHY} |
4 C's Check
Communication: {language adapted for audience? Y/N}
Collaboration: {framed as joint problem-solving? Y/N}
Clarity: {recommendation unambiguous? Y/N}
Conciseness: {argument as short as possible? Y/N}

Key Principles

Examples

Scenario: Pushing back on unrealistic availability requirements Trigger: "My CTO wants 99.999% availability for our internal tool used by 50 employees. That would cost $200K in infrastructure." Process: Classified as business stakeholder negotiation. Primary technique: leverage their grammar by translating availability percentages to cost and downtime impact. Prepared comparison table: 99.9% = 8.7 hours downtime/year at $40K vs 99.999% = 5 minutes downtime/year at $200K. Framed as "what's the cost of each hour of downtime for 50 internal users?" to let the math make the argument. BATNA: implement 99.9% with monitoring, propose revisiting if actual downtime impacts exceed the cost differential. 4 C's check: using cost language (Communication), framing as "let's find the right investment" (Collaboration), specific numbers not vague "it's expensive" (Clarity), two-slide comparison not a 30-page report (Conciseness). Output: Negotiation brief with cost comparison table, opening frame, anticipated objections (e.g., "but what about that outage last year?"), and compromise position at 99.95%.

Scenario: Disagreement with senior developer on architecture pattern Trigger: "The senior developer insists REST is better for everything. He has 15 years of experience." Process: Classified as developer negotiation. Primary technique: demonstration defeats discussion. Prepared a plan for a small proof-of-concept showing the specific scenario where event-driven outperforms REST (e.g., order processing where downstream services don't need synchronous response). Also identified the Frozen Caveman pattern — the senior developer may be defaulting to REST because of a bad experience with messaging years ago. Strategy: acknowledge their REST expertise explicitly, agree REST is appropriate for most of the services (divide and conquer), but propose a POC for the 2 services where async communication has clear benefits. BATNA: implement REST everywhere with the understanding that the 2 high-throughput services may need refactoring later, and document this prediction in an ADR. Output: Negotiation brief with POC proposal, specific service pair for demonstration, acknowledgment language, and ADR template for documenting the decision.

Scenario: Negotiating tech debt vs features with product leadership Trigger: "The product team wants 5 new features. I think we need to address tech debt first." Process: Classified as business stakeholder negotiation (VP of Product). Primary technique: state impacts in cost and time. Translated tech debt to business language: "Each feature currently takes 3 weeks because of the data layer complexity. After a 4-week refactor, each feature would take 1 week. Five features at 3 weeks = 15 weeks. Four-week refactor + five features at 1 week = 9 weeks. The refactor saves 6 weeks and every future feature is faster." Compromise position: do the refactor in parallel with 2 of the 5 features, deferring 3 features by 2 weeks. BATNA: proceed with all 5 features, document the increasing delivery time trend, and revisit when feature delivery time exceeds stakeholder patience. Output: Negotiation brief with ROI calculation, delivery timeline comparison chart, compromise proposal, and risk documentation plan.

References

License

This skill is licensed under CC-BY-SA-4.0. Source: BookForge — Fundamentals of Software Architecture by Mark Richards, Neal Ford.

Related BookForge Skills

This skill is standalone. Browse more BookForge skills: bookforge-skills

Scenario: Pushing back on unrealistic availability requirements Trigger: "My CTO wants 99.999% availability for our internal tool used by 50 employees. That would cost $200K in infrastructure." Process: Classified as business stakeholder negotiation. Primary technique: leverage their grammar by translating availability percentages to cost and downtime impact. Prepared comparison table: 99.9% = 8.7 hours downtime/year at $40K vs 99.999% = 5 minutes downtime/year at $200K. Framed as "what's the cost of each hour of downtime for 50 internal users?" to let the math make the argument. BATNA: implement 99.9% with monitoring, propose revisiting if actual downtime impacts exceed the cost differential. 4 C's check: using cost language (Communication), framing as "let's find the right investment" (Collaboration), specific numbers not vague "it's expensive" (Clarity), two-slide comparison not a 30-page report (Conciseness). Output: Negotiation brief with cost comparison table, opening frame, anticipated objections (e.g., "but what about that outage last year?"), and compromise position at 99.95%.

Scenario: Disagreement with senior developer on architecture pattern Trigger: "The senior developer insists REST is better for everything. He has 15 years of experience." Process: Classified as developer negotiation. Primary technique: demonstration defeats discussion. Prepared a plan for a small proof-of-concept showing the specific scenario where event-driven outperforms REST (e.g., order processing where downstream services don't need synchronous response). Also identified the Frozen Caveman pattern — the senior developer may be defaulting to REST because of a bad experience with messaging years ago. Strategy: acknowledge their REST expertise explicitly, agree REST is appropriate for most of the services (divide and conquer), but propose a POC for the 2 services where async communication has clear benefits. BATNA: implement REST everywhere with the understanding that the 2 high-throughput services may need refactoring later, and document this prediction in an ADR. Output: Negotiation brief with POC proposal, specific service pair for demonstration, acknowledgment language, and ADR template for documenting the decision.

Scenario: Negotiating tech debt vs features with product leadership Trigger: "The product team wants 5 new features. I think we need to address tech debt first." Process: Classified as business stakeholder negotiation (VP of Product). Primary technique: state impacts in cost and time. Translated tech debt to business language: "Each feature currently takes 3 weeks because of the data layer complexity. After a 4-week refactor, each feature would take 1 week. Five features at 3 weeks = 15 weeks. Four-week refactor + five features at 1 week = 9 weeks. The refactor saves 6 weeks and every future feature is faster." Compromise position: do the refactor in parallel with 2 of the 5 features, deferring 3 features by 2 weeks. BATNA: proceed with all 5 features, document the increasing delivery time trend, and revisit when feature delivery time exceeds stakeholder patience. Output: Negotiation brief with ROI calculation, delivery timeline comparison chart, compromise proposal, and risk documentation plan.