FDE · Stakeholders

Deployments Die on Org Charts.

Almost nobody loses a deployment to an architecture problem. They lose it to a data owner who never says no but never grants access, a manager whose team the system automates, a sponsor who changes jobs in month five, and a set of users who quietly kept the spreadsheet. This lab gives you six real-shaped people at one customer. First read the room — classify each one from what they say, not their title. Then handle the three situations that actually end projects, while a coalition meter tracks who is still with you.

classify 6 stakeholders · gatekeeper · threatened manager · champion resigns
economic buyer

Controls the budget. Can approve alone. Often absent from every meeting you are invited to.

champion

Spends their own credibility on you internally. Not the same as someone who likes the demo.

blocker

Can stop it without owning it. Security, legal, procurement, or a manager with quiet influence.

data gatekeeper

Controls the access you need. The most underestimated person in the building, every time.

meridian-logistics — deployment stakeholder map
Act 1 · Read the room
Meridian Logistics has bought a shipment-exception triage system. Six people were in the kickoff. Each said one sentence that tells you what they actually are. Classify them — titles will mislead you at least twice.
1/4
act
0
score
coalition

The five roles, and why titles lie

One person can hold two roles. A senior title can hold none. What identifies someone is not where they sit on the chart but what they are accountable for and what they stand to lose.

RoleHow to recognise themWhat they need from you
Economic buyerTalks in outcomes and money, not features. Often has not been in a working session since kickoff.A number, twice a quarter, in their language. Never a demo.
ChampionDefends the project when you are not in the room. Their reputation is now attached to it.Ammunition — evidence they can forward, and no surprises. Protect them publicly.
End userAsks specific questions about their actual Tuesday. Sceptical in a detailed way.To be consulted before the design is fixed, and to not look stupid in front of colleagues.
BlockerRaises process objections. Rarely says no outright; says “that will need to go through…”To be engaged early, on their terms, in writing. Late engagement is what makes them adversarial.
Data gatekeeperOwns the system you need. Cautious, specific, and has been burned before.A narrow written request and evidence you will not misuse what they give you.
most underestimated
gatekeeper
most fragile
single champion
quietly decides
the users
costs most
late escalation

Why Palantir handed forward-deployed staff a book on improv

The often-repeated detail is that Palantir gave new forward-deployed hires Keith Johnstone’s Impro — a book about theatre, status and accepting offers. It reads as a joke until you have sat in a customer meeting where the real subject was who would be seen to have been right.

01

Status is being negotiated constantly

Who defers to whom, who interrupts, who gets to reframe the problem. In a customer’s room you have no formal status at all — only the status you are granted — and a great deal of what happens next depends on reading that accurately in the first ten minutes.

02

“Yes, and” beats “no, but”

Blocking someone’s idea in front of their colleagues costs you more than the idea was worth. Accept the offer, then extend it: “yes — and if we do that, we will need X, so the trade is Y.” Same information, no bruise.

03

Make your partner look good

The improv principle and the deployment principle are identical. Your champion presenting your results as their win is the best possible outcome, not a slight. People fight to keep projects that make them look effective.

04

Read what is actually happening in the room

The objection stated is often not the objection held. “I am concerned about data quality” can mean exactly that, or it can mean “my team produces that data and you are about to audit it in public”. Responding to the wrong one loses you the person.

The three situations, and the honest answers

# 1. the gatekeeper who never says no instinct escalate to the sponsor result access in ~3 weeks, an enemy for ~18 months, and every future request routed through the slowest legitimate path better ask what their process is · put a NARROW request in writing (tables, columns, read-only, retention) · offer masked or synthetic data while approval runs · give them a way to say yes # 2. the manager whose team you are automating instinct reassure — "nobody's job is going away" result you cannot promise that, it breaks, and you lose the room better treat the resistance as information · find the version that is good for them (exceptions not volume · capacity for work they never got to · their team OWNS the system) · give them a win # 3. the champion resigns in month five instinct carry on and hope the successor inherits the enthusiasm result a new manager reviewing commitments they did not make better while they are still there: get value-to-date IN WRITING in front of the economic buyer · ask them who else cares · then build the second champion you should have had by month four

Notice the shape all three share: the instinct is to treat the person as an obstacle, and the better move is to treat them as someone with a rational position you have not yet understood.

Common questions

Who are the key stakeholders in an enterprise deployment?

Five roles, and one person can hold more than one. The economic buyer controls budget and can say yes alone. The champion spends their own credibility internally. The end users decide whether it is used. The blocker can stop it without owning it — usually security, legal or procurement. The data gatekeeper controls access to the systems you need, and is the most consistently underestimated.

How do you handle a data gatekeeper who will not grant access?

Escalating is the instinct and it is usually wrong: it makes an enemy of someone you need for the rest of the engagement, and they can comply slowly and legitimately for months. Ask what their approval process actually is, send a narrow written request naming exact tables, columns and read-only scope, and offer to work with masked or synthetic data while approval proceeds.

What do you do when your champion leaves?

Move while they are still employed: get a written summary of value delivered in front of the economic buyer, and ask the champion directly who else in the organisation cares about this outcome. Their successor inherits a commitment they did not make, so the project needs a second relationship in a different reporting line — ideally built in month four rather than in the week they resign.

How do you work with a manager whose team you are automating?

Their resistance is rational; treat it as information. Do not promise that nobody’s job changes — you do not control that, and the promise destroys your credibility when it breaks. Find the version of the outcome that is good for them: their team handling exceptions rather than routine volume, taking on work they never had capacity for, or owning the system themselves.

Why do deployments fail politically rather than technically?

Because the technical problem is usually solvable and the organisational one often goes unaddressed. A system nobody adopted, an access request that took five months, a sponsor who moved teams, or a manager quietly encouraging their staff to keep using the old process will each end a deployment regardless of how well the software works.

Keep going

Finished this one? 0 / 58 Labs done

Explore the topic

See this alongside everything else on the same subject — handbooks, system designs, challenges and tools, in one place.

More Labs