The FDE mindset
Skills get you into the role; mindset determines whether customers trust you with their hardest problems. The best forward deployed engineers share a handful of habits that look small on paper and compound over every engagement.
Outcomes over output
Your customer did not buy software; they bought a change in how their business performs. Before you write code, be able to finish this sentence: "This is successful when ___ moves from ___ to ___." If you can't, you are not ready to build.
Output-thinking asks, "Is the feature done?" Outcome-thinking asks, "Is anyone using it, and did the number move?" The second question is uncomfortable, because the honest answer is often "not yet" — and that is exactly why it is valuable.
Own the problem end to end
FDEs don't get to say "that's the customer's IT team's job." If the project is blocked on a firewall rule, a missing data extract or an unanswered security questionnaire, it is your problem until it is solved. You may not do the work yourself, but you make sure it happens: you find the owner, write the request so it is easy to approve, and follow up.
Ownership means the customer never has to wonder who is driving. If something is stuck, you are the person who knows why and what happens next.
Bias to the smallest thing that proves value
Large engagements fail slowly. Prefer the smallest deliverable that proves value with real data and real users — a working slice beats a perfect plan. A thin end-to-end path (data in → model or logic → result in front of a user) teaches you more in a week than a month of architecture diagrams.
Comfort with ambiguity
You will rarely get a clean spec. Requirements change after the first demo, data turns out to be different from the documentation, and stakeholders disagree. Treat ambiguity as information:
- Write down your assumptions explicitly and get them confirmed.
- Turn open questions into small experiments.
- Decide reversible things quickly; slow down only on irreversible ones (data deletion, security posture, contractual commitments).
Be two people at once
To the customer, you are their engineer — on their side, honest about limitations, protective of their time. To your own company, you are the customer's advocate — bringing back the unvarnished truth about what works and what doesn't. Holding both loyalties at once is the job.
Write everything down
Customers rotate people, executives forget, and memories of agreements drift. Short written artefacts — a discovery summary, a scope note, a weekly status, a decision log — are the cheapest insurance you will ever buy. They also become your portfolio.
Anti-patterns to avoid
| Anti-pattern | What it looks like | Better habit |
|---|---|---|
| Hero mode | Quietly working nights to hit a date nobody agreed to | Surface the trade-off early and renegotiate |
| Gold-plating | Building a general framework for a one-off need | Solve it concretely; generalise on the second request |
| Demo-driven development | Optimising for the wow moment, not for production | Design every demo on a path to production |
| Vendor-speak | Defending your product when it doesn't fit | Say what doesn't work and propose a workaround |
| Silent blockers | Waiting days for access without escalating | Escalate on day two, with a clear ask |
Behavioural questions for FDE roles probe these habits directly: "Tell me about a time a customer changed requirements late," or "Tell me about a time you were blocked by another team." Prepare stories that show ownership and calm, structured handling of ambiguity.
Senior Full-Stack Engineer · AI & AWS. I turn ambiguous customer problems into production systems — cloud, data and AI.