Who You Actually Serve: Stakeholders and Expectations
Overview
Section titled “Overview”You have a definition, a way to judge decisions, and a set of tools. All of it is useless if the people who have to agree don’t.
This topic closes Section 1 by answering the second half of the module’s question — what am I actually responsible for here? — and gives you the document that makes the answer stick.
Finding the real stakeholders
Section titled “Finding the real stakeholders”A stakeholder is anyone who can affect the initiative or is affected by it. That’s broader than the invite list to the kickoff meeting.
The org chart gets you the obvious ones. It misses three archetypes that matter more:
- The person everyone checks with informally. Long tenure, deep knowledge of the system nobody else fully understands, no title granting a veto — and a veto anyway.
- The person who gets the work. Whoever’s team will use the thing daily, and who typically has not been asked.
- The person who can say no for reasons outside your domain. Compliance, legal, security. They can block regardless of how good the architecture is.
A useful habit in your first weeks: ask each person who else should I talk to? Names that recur and aren’t on the org chart are your informal power map.
Interests versus positions
Section titled “Interests versus positions”The most useful distinction in this topic.
A position is what someone asks for. An interest is what they actually need. They’re often different, and the gap is where your leverage is.
| Role | Position (what they say) | Interest (what they need) |
|---|---|---|
| Product lead | “Ship it this quarter” | Not to miss a commitment made externally |
| Engineering lead | “We don’t have capacity” | Not to have existing work slip because of yours |
| Principal engineer | Technical objections to the design | Not to repeat a failure they lived through |
| Sponsor | “We need this faster” | Relief for a team they’ve watched struggle |
Positions collide; interests often don’t. An engineering lead’s position blocks you. Their interest — protecting work already in flight — is something you can design around, and an architecture that visibly protects it turns them from obstacle into ally.
If you negotiate positions, someone loses. If you find the interest underneath, there’s often a design that serves both.
The cost: finding interests takes individual conversations, and people don’t volunteer them in groups. Nobody says “I’m afraid of repeating the last failure” in a planning meeting.
Formal authority and informal power
Section titled “Formal authority and informal power”Two different things, and confusing them is how initiatives die quietly.
Formal authority is visible and therefore manageable. Someone who can block on compliance has stated criteria; you can find them out and design to them. You will know where you stand.
Informal power is invisible. It doesn’t arrive as “no”. It arrives as sustained technical scepticism, slow reviews, and a team that quietly deprioritises your work. You often discover it only when something fails to move.
You can’t out-authority either, because you have none. What you have is the ability to address the interest underneath — the stated criteria, the remembered failure — before it hardens into a position.
Conflicting expectations are normal
Section titled “Conflicting expectations are normal”Stakeholders want incompatible things. One wants speed, another caution, another a capped cost, another their existing work left alone.
This is not a problem to be solved before the real work begins. It is the real work. An initiative where everyone agrees is either trivial or has stakeholders who haven’t thought about it yet.
The failure is not conflict. It’s unnamed conflict — everyone proceeding on incompatible assumptions until the collision happens at the worst moment.
Managing expectations deliberately
Section titled “Managing expectations deliberately”Here’s the mechanism that decides how your first year goes:
If you don’t define the role, it gets defined by accumulation.
Whoever asks you for something first sets the precedent. Review every pull request in week two and that’s your job now. Say nothing about vendor selection and you either own all of it or none of it — discovered at the worst possible moment.
The counter is to state your remit early, in writing, before the accumulation starts.
The architecture charter
Section titled “The architecture charter”One page. The most useful document you’ll write this month, and the least likely to be asked for.
A workable charter covers:
- Accountable for — that the initiative meets its business drivers, satisfies compliance, and doesn’t damage work already in flight
- I decide — cross-team structure, technology constraints, where data may live, the escalation model between automation and human
- I don’t decide — implementation choices inside those constraints, staffing, product scope and priority, the release date
- I advise on — sequencing, buy-vs-build, risk
- How I work — decisions written down with reasoning; anyone may challenge a decision by challenging the reasoning
The section people skip carries the weight: what you will not decide.
Writing “I don’t choose which vector store the team uses; I set the constraints it must satisfy” does two things at once. It tells the team they retain real ownership — which buys goodwill from exactly the people watching for the opposite. And it draws a line you can point at when someone later tries to make an implementation choice your fault.
That last bullet is doing quiet work too. It invites disagreement in a specific, productive form — far better than disagreement surfacing as passive resistance six weeks later.
The cost of a charter: it makes your limits explicit, and some people read explicit limits as unhelpfulness. Worth it. Vague availability is how architects end up accountable for everything and empowered for nothing.
Getting it endorsed
Section titled “Getting it endorsed”A charter you wrote and filed changes nothing. It works when someone with authority has read it and not objected.
That means your sponsor, and whoever owns the engineers you’ll need. You don’t need a signature. You need to have said it out loud to both, and to be able to say “as we discussed” later.
Expect the conversation to be short and slightly awkward. Still cheaper than discovering in month four that one of them assumed you’d be reviewing their teams’ designs and you assumed you wouldn’t.
Feeds the workbook
Section titled “Feeds the workbook”This topic feeds the stakeholder map and the architecture charter. Write the charter last — it’s easier once the other artifacts have shown you what the job involves.
→ That closes Section 1. You can now answer the module’s question in writing. Next, what has changed recently — and it’s about half the module. — Code as Liability