Building Trust and Communication with Customers

An FDE's code only matters if the customer trusts them enough to adopt it — the relationship is not soft-skills garnish, it's the delivery mechanism.

By Pratik Dhanave · August 11, 2026 · 6 min read

#Forward Deployed Engineer #Communication #Trust #Consulting #Forward Deployed Engineering

You can build exactly the right thing and still fail, if the customer doesn’t trust you, doesn’t feel heard, or feels threatened by what you’re building. Conversely, a modest solution delivered by someone the customer believes in gets adopted, extended, and expanded. For a forward deployed engineer, communication and trust are not adjacent to the technical work — they are the channel through which the technical work reaches reality. This post is about that channel.

Trust is earned in small, fast increments

Customers don’t extend trust because of your résumé; they extend it because you keep doing what you said you’d do, quickly and visibly. The FDE model — show something real every week (post 3) — is itself a trust engine: each small delivered increment is a promise kept. Early wins matter more than their size. Solving one annoying, visible pain point in week one buys you the credibility to tackle the big ambiguous problem in month two.

Do what you said, when you said. Reliability on small commitments compounds into trust on big ones.
Show progress you can see. A working slice beats a status update. Make progress tangible.
Be honest about what’s not working. “This approach isn’t panning out, here’s what I learned and what I’d try next” builds more trust than false confidence — because the customer learns your good news is real.

The gotcha: over-promising to please the customer in the moment is a trust loan you repay with interest at the demo. One missed big promise erodes more trust than ten kept small ones built. Under-promise on timelines you don’t control.

Speak the customer’s language, not yours

The people you serve usually don’t care about your architecture, your model, or your stack — they care about their job, their decision, their deadline. Translating between engineering and their domain is a core FDE skill:

Frame in their outcomes. Not “I built a normalized pipeline with incremental sync,” but “your revenue number is now ready in an hour instead of three days.”
Learn their vocabulary. Every domain — claims, settlements, freight, trials — has its own language. Using it correctly signals respect and comprehension; getting it wrong signals you don’t understand their world.
Tailor to the audience. The executive sponsor wants outcomes, risk, and cost; the daily user wants “does this make my job easier”; their IT/security team wants to know it won’t break or leak. Same project, three messages.

Manage expectations relentlessly

Most FDE relationships sour not from bad work but from mismatched expectations. The customer thought the demo meant “done” (post 3); they assumed the messy-data work was trivial; they expected the timeline you gave for the happy path to hold for the whole thing. Prevent this with constant, explicit calibration: what’s real vs. scaffolding, what’s next, what’s blocked and on whom, and what “done” means (the problem frame from post 2). A short, regular written update — progress, next, risks, asks — is cheap insurance against the “I thought you were further along” conversation.

The gotcha: silence reads as either “everything’s fine” or “they’ve gone dark” — and customers assume the worse one under pressure. Proactive, regular communication (even “no progress this week, blocked on your data access”) beats going quiet and surfacing surprises later.

Navigate the org, not just the project

You’re working inside someone else’s political reality. There’s a champion who wants you to win, and often a skeptic who resents an outsider, fears the work threatens their role, or was overruled when you were brought in.

Invest in your champion. They open doors, get you data access, and defend the work in rooms you’re not in. Make them look good — their success is yours.
Convert or neutralize the skeptic. Understand why they resist. Sometimes involving them, crediting them, or addressing their real fear (job security, control, past burns) turns a blocker into an ally. Sometimes you route around them via the sponsor. Ignoring them is how a technically successful project dies in adoption.
Watch for the threatened. If your tool automates away someone’s manual craft, they may quietly undermine it. Frame the work as making their expertise higher-leverage, not obsolete — and where possible, make them a beneficiary.

Handle conflict and bad news well

Things will go wrong — a missed date, a failed approach, a data problem that blows the estimate. How you deliver bad news defines the relationship. Deliver it early (not at the deadline), factually, with a path forward, and owning your part. “The integration is two weeks behind because the source data needed far more cleaning than the sample showed; here’s the plan to catch up and here’s what I need from your team” preserves trust. Hiding it until it explodes destroys it.

Know when the work is done — and leave well

Part of trust is not overstaying. An FDE who manufactures dependency to stay employed on an account erodes the very trust that made them valuable. The stronger long-game move is a clean handover (post 4): the customer’s team can run it, the champion looks like a hero for bringing you in, and you’ve earned the reference and the expansion. Customers who trust you bring you back and refer you onward — which is worth far more than one prolonged engagement.

An example: turning a skeptic

On the bed-placement project, the charge nurse who does placement today is the skeptic — and it’s rational. An outsider’s tool that “suggests placements” reads as a threat to the judgment she’s honed over fifteen years, and if it’s wrong once it could endanger a patient and embarrass her. Ignoring her guarantees the tool dies in adoption, no matter how good the ranking is.

The move isn’t to overpower her with the sponsor; it’s to understand the fear and address it:

Involve her as the expert. Her exceptions (“never put a post-op patient there”) are the spec — crediting and encoding her knowledge makes the tool hers, not a replacement for her.
Frame it as leverage, not automation. It surfaces options and flags constraints; she decides. It makes her faster, it doesn’t overrule her.
Earn trust on a small, safe slice first. Let it assist on low-risk placements, show it’s reliable, and expand as she gains confidence — trust in small increments.

Convert her and she becomes the champion who defends the tool on the ward; leave her out and she quietly stops using it and tells everyone it’s wrong. Same code, opposite outcomes — decided entirely by the relationship.

The gotcha: the technically-focused FDE sees the skeptic as an obstacle to route around via the executive sponsor. That “wins” the deployment on paper and loses it in practice — the daily user’s quiet non-adoption beats the sponsor’s mandate every time. Convert the skeptic; don’t overrule them.

Key takeaways

Trust is the delivery mechanism for FDE work — the best code fails without it.
Earn it in small, fast, kept promises; early visible wins buy credibility for the hard problems.
Under-promise on what you don’t control; a missed big promise costs more than many kept small ones.
Translate to the customer’s outcomes and vocabulary, and tailor the message to sponsor vs. user vs. IT.
Manage expectations relentlessly with regular written updates; silence breeds the worst assumptions.
Navigate the org — invest in the champion, convert or neutralize the skeptic, reassure the threatened.
Deliver bad news early, factually, with a path forward; leave with a clean handover that makes your champion a hero.