Client Psychology for Forward Deployed Engineers

Most AI projects don't die because the model was wrong. They die because someone in the room never wanted them to live — and nobody noticed in time. As a forward deployed engineer, the hardest part of the job isn't the retrieval pipeline or the agent graph; it's reading the people who will decide whether your system ever reaches production. That skill has a name: client psychology. It means knowing the human before you know the problem.

This is the part of the role that doesn't show up in a job description. You can ship a technically flawless system and still watch it get blocked in week three by a stakeholder you never spoke to. The deployments that survive are the ones where you mapped the room first — who has power, who feels threatened, and what each person is actually afraid of. Forward deployed engineering is a role Palantir originated, and for the wider picture of what it involves I wrote a separate piece on what separates a developer from a forward deployed engineer; this post is about the human layer underneath it.

#Know the human before you know the problem

A typical engagement starts with a clean-sounding brief. A CEO sees a 34% spike in support tickets and wants an AI chatbot live in six weeks. The instinct of most engineers is to start scoping the chatbot. The instinct of a forward deployed engineer is to walk into the room and ask a quieter question first: who is actually here, and who isn't?

"Client" is rarely one person. It's a set of people with different incentives, different fears, and very different amounts of power over your project. Treating them as a single voice — usually the loudest, most enthusiastic one — is how good systems get built for the wrong reality. Before you write a line of the spec, you need to know the human terrain. Scoping comes next; I cover that in how to scope an AI agent before you build it.

#The four stakeholders in every AI deployment

Across AI deployments, the room tends to hold four roles. Sometimes one person plays two; often the most important one isn't physically present. Learn to name them:

• The Champion — the person who brought you in and believes in the project. They're your ally, and also your most dangerous source of requirements, because they're describing a workflow they don't personally perform.
• The Sponsor — they hold the budget. They care about outcomes and cost, not implementation. Lose them and the project loses oxygen.
• The Blocker — often the most dangerous person in the deployment, and frequently not in the room. Security, compliance, risk, a skeptical operations lead. They can't greenlight your project, but they can absolutely kill it.
• The End-User — the person whose day actually changes if the system works. They know the edge cases nobody documented. If they quietly resist, your adoption numbers die even after a "successful" launch.

Here's the rule I'd tattoo on every new FDE: you cannot contract with someone who is out of the room. The single biggest mistake in this job is taking requirements from the Champion about what the End-User does. The Champion gives you the tidy, official version of the workflow. The End-User lives in the messy real one. If you haven't sat with all four — Champion, Sponsor, Blocker, and End-User — your agent is dead on arrival.

Picture a common pattern in bank and NBFC rollouts: an AI deployment gets enthusiastic sign-off from the CTO, the budget is approved, the build goes well — and then the operations VP blocks it in week three, because the system changed a process her team is accountable for and nobody had mapped her as a blocker. One honest conversation in week one would have restructured the entire design. The technology was never the problem. The org chart was.

I've felt the other half of this gap from the engineering side. Building document-extraction systems, I've watched a requirement that reads cleanly — "analyze the financial statement" — hide a detail no spec mentions: when a statement runs long enough that you have to split it to fit a model's context window, a single transaction can land across the seam and quietly vanish from the analysis. Nobody writes that down. It lives in the head of the person who works with those statements every day. The official requirements doc — the PRD or BRD — is the Champion's map of the workflow; the missing edge case is the End-User's territory. That's the concrete reason "just take the requirements and build it" produces systems that pass review and fail in production.

#The two fears that quietly kill your project

When a stakeholder resists, they almost never tell you the real reason. People's emotions are data points — and resistance is usually one of two fears wearing a more professional-sounding costume.

#Fear of control — the Blocker's fear

AI is probabilistic. Blockers — risk, compliance, security — are paid to prevent unpredictable outcomes, and your AI is, by definition, unpredictable. So they reach for the language of process:

"Security won't allow this." • "You'll need SOC 2 compliance first."

What they actually mean is: I can't explain to an auditor why an AI made this decision. That's not an objection you beat with a better model — it's one you answer with explainability, audit logs, human-in-the-loop checkpoints, and a clear story for how any single decision gets traced. Hear the fear under the words and you can design for it. Argue with the words and you lose.

#Fear of vulnerability — the End-User's fear

The End-User has spent years mastering a workflow. Your AI threatens to compress that hard-won expertise into a replicable algorithm. So they say:

"You don't understand our edge cases." • "The data isn't clean enough."

What they actually mean is: if this works, what happens to me? Sometimes the edge cases are real and important — you should mine them hungrily. But the emotional engine underneath is job security. You address it by positioning the system as something that removes the drudgery and elevates their judgment, not as their replacement — and by making them a visible co-author of the tool rather than its casualty.

Notice that the same sentence — "the data isn't clean enough" — can be a genuine technical constraint or a fear in disguise. Telling the two apart, in real time, in a live conversation, is the craft. It's also why I think hard about when an LLM is even the right tool before reaching for one.

#How to map the room in week one

Client psychology isn't a soft afterthought you get to once the system works. It's week-one work, and it's concrete:

1. List all four roles by name. Literally write down who is the Champion, Sponsor, Blocker, and End-User. If any box is empty, you have a blind spot, not an absence.
2. Find the blocker before they find you. Ask the Champion, "who could stop this?" — then go talk to that person early, while you can still change the design.
3. Sit with the actual End-User. Watch them do the real workflow, not the documented one. The gap between the official process and the lived one is where your project succeeds or fails.
4. Translate every objection into the fear underneath it. When you hear "compliance won't allow it" or "our data's too messy," ask what outcome the person is protecting, and design for that outcome.

This is the part of forward deployed engineering that earns you a seat in the room. The technical skill gets you into the building; reading the humans is what lets you ship inside it. You're not just translating a business problem into a system — you're holding the business problem, the technical constraint, and the politics of four different people in your head at once, and making good tradeoff calls live. That isn't a soft skill bolted onto the engineering. For a forward deployed engineer, it is the engineering.