Stakeholders, communication, and influence

The two-thirds of the job

Module 2 described the EA role as roughly one-third analysis and two-thirds communication and influence. This module is about that two-thirds. It’s where engineering managers have a head start, and also where the habits that served you as a manager may need adjusting.

Stakeholder mapping, properly

Module 6 introduced TOGAF’s power/interest grid. It’s a good start but too coarse to plan with. For each key stakeholder, capture:

Field	Question
Goals	What are they measured on? What does success look like for them this year?
Concerns	What worries them about this initiative? (cost, timeline, losing control, risk, their team’s workload)
Current position	Supporter, neutral, skeptic, or opponent?
Influence	Formal (budget, decision rights) and informal (who listens to them?)
Preferred format	Numbers, narrative, diagrams, a walk-through, or a one-pager?
What you need from them	A decision, resources, public support, or just not blocking?

Find the informal influencers

Org charts show formal power. Real influence often sits elsewhere: the long-tenured principal engineer everyone checks with, the finance business partner who shapes the CFO’s view, the founder who left the executive team but still has the CEO’s ear. Ask, “Who would you talk to before deciding this?”

Writing for decisions

Most EA output should help someone make a decision. The single most useful format is the one-page options paper.

Structure

1. Decision needed: one sentence. “We need to decide how to handle customer identity for EU launch by 30 April.”
2. Recommendation: one or two sentences, with the main reason.
3. Context: just enough for the decision. Three to five bullets.
4. Options: usually three, including “do nothing” or “minimal”. For each: what it is, cost, risk, time, and what it enables or rules out.
5. Trade-offs: what you give up with the recommendation, stated honestly.
6. Next steps: what happens if they agree.

Principles

• Bottom line up front. Executives might read only the first two lines. Make them count.
• Always show the trade-offs. A recommendation without downsides reads as advocacy, not advice, and loses trust.
• Quantify where you can, even roughly. “About two team-quarters” is far better than “significant effort.”
• One page. Put detail in an appendix for those who want it.

One story, three audiences

The same architecture decision needs different framing for different audiences:

Audience	They care about	Lead with	Avoid
Executives	Outcomes, risk, money, timeline	What it enables for the business; cost and risk of each option	Technology names; diagrams with more than eight boxes
Product leaders	Customer experience, time to market, roadmap impact	What customers get, and when; what it unblocks or delays	Infrastructure detail
Engineers	Constraints, trade-offs, the “why”, what changes for them	The problem, the options considered, and the reasoning	Hand-waving; vague mandates without rationale

A useful habit: before any important conversation, write down the one sentence you want them to remember.

Building credibility

Influence without authority rests on credibility. Credibility is built through:

• Being useful early. Solve problems people already have before asking anything of them. At first, the most valuable thing you can offer is context: connecting people working on related problems who don’t know about each other.
• Being right, and honest when you’re wrong. Track your recommendations. Owning a bad call publicly builds more trust than it costs.
• Showing your reasoning. ADRs and options papers make your thinking inspectable. People trust what they can check.
• Following through. Do what you said you’d do, especially the small things.
• Staying technically credible. Keep enough hands-on depth that engineers respect your judgment. Read code, review designs, try new tools.
• Giving credit away. When an initiative succeeds, the teams that delivered it get the credit. Your reward is being invited to the next one.

Disagreement and escalation

You’ll disagree with powerful people regularly. Some patterns that work:

1. Separate the concern from the position. “I don’t want PayNest absorbed into the core platform” is a position. The concern behind it might be “I’ll lose my team’s speed and autonomy.” Concerns can often be addressed; positions can only be won or lost.
2. Take it offline. Public standoffs make people defend positions. Have a one-to-one to understand the concern properly.
3. Look for options that address both sets of concerns. There often is one.
4. Escalate cleanly, if you must. Agree with the other person what the disagreement is, write it up jointly, and take it to the decision-maker together. Never escalate around someone.
5. Disagree and commit. Once a decision is made, support it fully, even if you argued against it. Record your concerns in the ADR if they matter, then move on.

At Quillfeather

The PayNest conversation

The Head of Payments, PayNest’s former founder, opposed your SEPA recommendation in a leadership meeting, saying, “This is the first step to absorbing PayNest.”

You didn’t argue in the room. The next day, in a one-to-one, you asked what they were worried about. Their concern turned out to be less about technology and more about autonomy: PayNest’s team ships weekly, while the core platform’s release process is slower.

Your revised options paper made that concern explicit and recommended:

• SEPA built in PayNest, by PayNest’s team, keeping its own release cadence
• PayNest adopts the central identity provider and notification platform (enterprise ADRs), but keeps its own payments domain model
• A fitness function to stop other teams calling PayNest’s database directly, which protected PayNest’s autonomy as much as it protected the architecture

The Head of Payments co-presented the final recommendation to the CTO. It was approved in one meeting.

The board update

For the board’s technology plan, your one-pager opened with:

To launch in the Netherlands and Germany within 18 months, we need to make four platform changes in the next three quarters: EU data residency, local payment methods, single sign-on, and GDPR-grade consent management. Together they cost roughly four team-years; without them, we can’t legally or commercially operate in the EU.

The rest was the capability-based roadmap from module 9, simplified to one slide, and a risk table. There was no architecture diagram.

Reflection

• Pick your most important stakeholder for a current initiative. Fill in the six-field map above. What surprised you?
• Rewrite the opening of a recent proposal or email you sent as a “bottom line up front” sentence.
• When did you last escalate a disagreement? Would the “escalate cleanly” pattern have changed the outcome?