How to think & work
like an FDE?
A workshop on the Forward Deployed Engineer mindset - what it is, how FDEs think, how they communicate, and how you can adopt the mindset yourself.
Two parts. First we learn, then you play.
Part 1 · The FDE mindset
What a Forward Deployed Engineer actually is, where the role comes from, the mentality behind it, and the thinking and communication patterns that make FDEs effective.
Part 2 · You are the FDE
Three real-world scenarios, four questions each. One of you answers, we reveal together - confetti if you nailed it, and a clear "how to handle it" play either way.
💡 Goal: by the end, every Avanai engineer in this room should be able to walk into a client site and operate like an FDE from day one.
What is an FDE?
The role, its origin, and why it's different from everything you've done before.
An engineer deployed forward - into the client's world.
A Forward Deployed Engineer works embedded with the customer, owns a business outcome rather than a backlog ticket, and ships working software where the problem lives. The role was pioneered at Palantir, and today it powers how companies like Anthropic and OpenAI deploy AI into enterprises - and how Avanai delivers automation to clients.
Forward
You sit with the client - physically or virtually. You see their tools, their data, their politics, their pain. Not a spec handed over a wall.
Deployed
You ship to production, in their environment, under their constraints. A demo on your laptop counts for nothing until it runs in their world.
Engineer
You still build. But the code is a means to an outcome - you measure success in hours saved and processes transformed, not features merged.
One person, three hats.
The FDE is the intersection of three roles that are usually separate people. That's what makes the role demanding - and what makes it valuable.
Engineer
Builds the solution hands-on: n8n workflows, agents, integrations, infrastructure. Quality and security are non-negotiable even at speed.
Consultant
Reads the organization: who decides, who blocks, who adopts. Translates between business language and technical reality - in both directions.
Product manager
Owns the "what" and "why": finds the highest-value problem, slices the scope, sequences the wins, and says no to the rest - constructively.
🎯 The shift: a software engineer asks "what should I build?" - an FDE asks "what outcome does this client need, and what's the fastest safe path to it?"
Same skills. Completely different posture.
The FDE Mentality
How FDEs think, how they communicate, and how you can rewire yourself into the mindset.
Four beliefs that change everything.
1 · Own the outcome, not the task
"I built what was asked" is not success. If the workflow ships but nobody uses it, you failed. The outcome is yours end-to-end: discovery, build, adoption, value.
2 · Trust is the currency
Every interaction either deposits or withdraws trust. Deliver small promises relentlessly - on-time demos, honest status, fast responses - and the big asks become possible.
3 · Speed is a feature
A working slice this week beats a complete solution next quarter. Momentum convinces organizations in a way no slide deck ever will. Ship, show, iterate.
4 · Embed, don't visit
You're not a vendor who attends meetings - you're a teammate who happens to come from Avanai. Eat lunch with the users. Learn their acronyms. Their problem is your problem.
Business problem first. Thin slices. The demo is the spec.
Start from the pain
Never start from the technology. Find where the client bleeds time or money, quantify it, and work backwards. "Cool" is not a requirement - "saves 6 hours per week per analyst" is.
Slice thin, ship fast
Cut every problem into the smallest slice that delivers real value on its own. 80% of the value usually lives in 20% of the scope - find that 20% and ship it in days, not months.
The demo is the spec
When requirements are fuzzy, don't write more documents - build a rough prototype and put it in front of people. Reactions to a working thing converge faster than comments on a page.
🧪 Validate before you scale
Prove the riskiest assumption with the cheapest possible experiment. Then invest.
🛡 Pragmatic, never sloppy
Move fast on scope, never on security, credentials, or client data. Those are the lines you don't cross.
🔁 Build → measure → learn
Every delivery is an experiment. Instrument it, watch real usage, and let the data pick the next move.
Translate. Own. Never surprise.
FDE communication has one job: keep trust growing while reality unfolds. That means speaking the listener's language, owning bad news early, and making sure nobody is ever surprised in a meeting.
✗ How engineers often talk
- "The webhook auth broke because the OAuth token rotation conflicted with the proxy."
- Status updates only when asked - and only when there's good news.
- "That's not possible." (conversation over)
- Promises made in the hallway, forgotten by Friday.
- Jargon as a shield when things go wrong.
✓ How FDEs talk
- "Logins to the tool failed for 2 hours. It's fixed, here's what we changed so it can't recur."
- Proactive updates on a rhythm: what shipped, what's next, what's blocked.
- "Here's what we can do by Friday, and what the full version needs."
- Every promise written down, tracked, and closed loudly.
- Bad news delivered early, in person, with a plan attached.
Communication you can run on autopilot.
📅 The weekly heartbeat (to stakeholders)
🗣 In every conversation
The mindset is a habit loop, not a personality type.
Nobody is born an FDE. You install the mindset by practicing small behaviors until they become reflexes.
🔄 Ask "so what?" three times
For every task: so what does this give the client? So what does that change? So what is it worth? If you can't answer, you're building the wrong thing.
📆 Demo every week, no exceptions
A standing weekly demo forces thin slices, honest progress, and constant client contact. The calendar invite does the discipline for you.
👂 Shadow before you build
Before automating any process, watch a real person do it once, end to end. You will always find something the requirements missed.
📣 Practice saying the hard thing early
"We're behind", "that approach won't work", "this will cost more" - said early, these build trust. Said late, they destroy it.
🧰 Default to showing, not telling
Replace your next status paragraph with a 2-minute screen recording or a live click-through. Watch how differently the room reacts.
🪞 Run your own postmortems
After every milestone: what did the client feel, not just what did you ship? Blameless, written, shared. That's how the loop closes.
Part 2 · You are the FDE
Three scenarios. Twelve situations. Your call.
How the game works.
1 · One of you answers
I show a scenario question with four options. I pick one participant - you commit to an answer out loud. No lifelines.
2 · We reveal together
I click your chosen option. Confetti if you nailed it 🎉 - a small rain of sadness if you didn't 😢. It's all in good fun.
3 · We learn the play
Right or wrong, the slide then shows how an FDE handles that situation - that's the part to remember.
🎲 Three scenarios, four questions each: A · Client Communication · B · Discovery & Scoping · C · Incidents & Pushback
Client Communication
You're embedded at a large enterprise client. People talk to you all day - every answer shapes their trust in Avanai.
A senior stakeholder catches you in the hallway: "We saw the AI agent demos - can your platform automate our entire compliance reporting by next month?"
What do you say?
How an FDE handles it
Stakeholder excitement is an asset - never kill it, but never bluff capability either. Channel the hype into something concrete and testable.
- Pull the conversation from the solution ("AI agents") back to the problem (what hurts in compliance reporting today, and what it costs).
- Commit to a thin slice with a date: "give me your most painful report and two hours with the person who builds it - I'll show you a prototype next week."
- An honest small promise kept beats a big promise broken. The hallway answer becomes your reputation.
In the monthly steering meeting, a non-technical executive asks: "Why is the milestone two weeks late?" (Partly, the client's own data team delivered an export late.)
How do you answer?
How an FDE handles it
Executives don't need internals - they need impact and a plan. And blame, even when factually justified, always reads as weakness in a steering meeting.
- Structure: "We're two weeks behind. Impact: X. Here's the recovery plan, and here's the new date I'm committing to."
- Handle the dependency privately and structurally: agree on data-delivery SLAs with the data team, and surface dependencies as risks in advance - not as excuses afterwards.
- Bring the new date before anyone asks for it. Owning bad news with a plan is a trust deposit, not a withdrawal.
An angry email lands: "Your workflow is BROKEN. Half the team is blocked!" You check - the workflow is fine. They uploaded a file format it was never designed to accept.
What's your move?
How an FDE handles it
To the user, their experience is the truth. "Works as designed" might be technically right and is still a failure - the design let them get blocked.
- Speed of response matters more than the fix itself: a one-hour "I'm on it, here's a workaround" changes the whole temperature of the thread.
- Treat "user error" as a design signal: validate inputs, fail with guidance ("this looks like X - the workflow needs Y, here's how"), and make the docs findable from the failure.
- Never argue with the frustration. Fix the experience first; the explanation can come after they're unblocked.
The client's architect insists on an approach you're convinced is wrong - it will work, but it'll be slow to build and painful to maintain.
What do you do?
How an FDE handles it
Silent compliance and shadow rebellion both fail. The FDE play is: disagree with evidence, then commit without resentment.
- Replace opinion-vs-opinion with data: a one-day spike comparing both approaches settles in hours what meetings argue about for weeks.
- Frame the concern around their interests: maintenance cost, time to value, operational risk - not "my way is better".
- Once decided, commit fully and never relitigate. "Disagree and commit" preserves both your integrity and the relationship - and if you're proven right later, the spike is on record.
Discovery & Scoping
You've just been deployed to a new client. Nothing is built yet - what you do in the first weeks decides the project.
It's your first week embedded at the client. You have a signed statement of work, a requirements document, and a lot of goodwill.
What do you do first?
How an FDE handles it
The requirements document describes the process as someone imagines it. Shadowing shows you the process as it is - they're never the same.
- Sit next to real users for a day. The spreadsheet-on-the-side, the workaround, the "oh, we never use that field" - that's where the real automation value hides.
- Quantify the pain as you observe it: minutes per task, tasks per week, error rates. That becomes your value baseline later.
- The relationships you build while shadowing are the same people who will adopt - or quietly reject - what you build.
After discovery, the client hands you a wishlist of 30 automation ideas and asks: "When can we have all of this?"
What's the FDE move?
How an FDE handles it
A shipped 20% beats a planned 100%. The list is not a contract - it's a snapshot of today's imagination, and it will change the moment something real ships.
- Score the list quickly with the client on two axes: business value and effort. Pick the high-value, low-effort winner and commit to a date measured in days.
- The first delivered win buys you the trust (and the data) to tackle the big, hairy items later.
- Keep the full list visible and revisit it after every delivery - re-prioritizing together is itself a trust-building ritual.
A key requirement is ambiguous - the operations team and the finance team interpret it in two contradictory ways, and both are sure they're right.
How do you resolve it?
How an FDE handles it
The demo is the spec. People struggle to react to paragraphs but react instantly and precisely to a working thing in front of them.
- Time-box a rough prototype - hours, not days. Make it obviously disposable so nobody mistakes it for the product.
- Show it to both teams in the same room. "That's wrong" pointed at a screen is fast, concrete, and ego-free in a way document comments never are.
- Capture the resolved interpretation in writing the same day - the prototype resolves the debate, the written decision prevents its return.
While building the agreed workflow, you stumble on a different process that looks like it could deliver 5x the value of what you were asked to build.
What do you do?
How an FDE handles it
Spotting unrequested value is exactly what FDEs are deployed for - but reliability on current commitments is the license that lets you propose more.
- Never pivot unilaterally: the current scope is a promise, and promises kept are your currency.
- Package the discovery like a product: the problem, the rough ROI, the thin slice that would prove it, the effort estimate. One page, business language.
- Route it through the sponsor - they get to be the hero who found extra value, and you get the mandate. This is how engagements grow.
Incidents & Pushback
Things break and people resist. This is where FDEs are made - or unmade.
One hour before the client presents your automation to their board, the production workflow starts failing.
What's the first move?
How an FDE handles it
Bad news ages terribly. The client finding out from you at T-60 minutes is a problem; finding out on stage in front of their board is a catastrophe.
- Order of operations under fire: communicate → stabilize (rollback, last good version, feature-flag off) → root-cause. Understanding comes after the bleeding stops.
- Always have a demo fallback ready: a recording, a sandbox copy, yesterday's data. FDEs assume demos break and prepare accordingly.
- Afterwards, follow up unprompted with what happened and what now prevents it - that note is what the client remembers.
The incident can be patched with a quick workaround in 30 minutes. The proper fix - restructuring part of the workflow - takes two days.
Which path do you take?
How an FDE handles it
Speed with transparency. Users are blocked now - but a silent hack quietly becomes permanent architecture.
- Mitigate first: a safe workaround that unblocks users in 30 minutes is almost always right - if it's genuinely safe (no data risk, no security risk).
- Make the debt visible: tell the client what the workaround doesn't cover, create the follow-up ticket in their tracker, and put a date on it.
- Don't outsource the judgment call (option D) for routine trade-offs - owning decisions like this is what they're paying an FDE for. Inform, don't escalate everything.
A member of the client team - someone whose daily tasks you're automating - says to you over coffee: "You're here to automate us out of our jobs, aren't you?"
How do you respond?
How an FDE handles it
Resistance is information, not an obstacle. End users decide adoption - the same person can become your saboteur or your champion, and this conversation is where it's decided.
- Don't dismiss the fear (A) or dodge it (C) - both confirm it. Hear it out fully before responding; the concern is legitimate.
- Get concrete: show which steps disappear (the copy-paste, the chasing, the re-keying) and what stays human. Vague reassurance soothes nobody; specifics do.
- Make them an owner: their name on the workflow, their feedback in the next iteration, them demoing it to their team. Co-designers don't sabotage what they built.
The incident is resolved. In the review meeting, the client sponsor asks bluntly: "So - whose fault was this?" (Technically, a schema change by their data team triggered it.)
What's your answer?
How an FDE handles it
Blame kills information flow - on both sides. Systems fail; people operate within systems. The postmortem is your chance to turn an incident into a trust deposit.
- Reframe the question: "The more useful question is what let one schema change take production down - here's the timeline and the three gaps it exposed."
- Show the guardrails, not the guilty: schema-change notifications, validation on inputs, alerts before users notice. Every gap gets an owner and a date.
- Sharing an honest postmortem - including Avanai's own gaps - signals confidence. Clients trust partners who can examine their own failures in the open.
Think in outcomes.
Ship in days. Earn trust daily.
That's the whole job. Everything else is detail.
