Skip to content
01Understand the role

What does a forward deployed engineer do?

You find the customer’s real problem, build the fix in their environment, and stay until their team can run it.

  1. 01

    Understand the customer

    Watch the real task. The brief usually names a symptom, not the cause.

  2. 02

    Build and adapt

    Ship against their data, systems and release process, where they can see it.

  3. 03

    Help people use it

    Test with the people who will run it. Check weeks later that they still do.

  4. 04

    Carry the learning forward

    When one customer hits a product gap, send the product team an example they can repeat.

repeatsThe stages overlap and repeat. What you learn in one round shapes the next.

Where you work changes the remit

Product companyServices firm
You buildIntegrations and extensions to your employer’s product.Whatever fits: platforms, custom code, existing systems.
You answer forThe customer’s outcome, within product boundaries.An agreed client outcome, scope and budget.
After deliveryRepeated needs go back to product engineering.Agree who maintains it before you leave.
Explore the role in more detail
02Find your starting point

Start from what you already know

Start with the responsibilities you can already demonstrate. Your next step is the gap that limits what you can deliver.

I’m starting in engineering

Build one small app with an API, a database, tests and a deploy, and be able to explain every part. Learn customer work alongside it.

03Build the capabilities

The FDE roadmap

Show each one in a reviewed project first, then on bigger systems and decisions.

01 / 06

Build dependable software

Build software another team can change and operate. Work confidently with unfamiliar code, APIs, databases, tests, and deployment. Use the stack the environment supports.

what good looks like

A reviewed change runs outside your development environment, and you can trace a failure from the request to its cause.

judgment
Choose infrastructure that the team can support. Account for configuration, secrets, and failure handling. Code generated by an AI tool carries the same review and testing responsibility as code you write.
evidence to show
A deployed application, a reviewed change, and a reproduced failure with a tested fix. Show why the fix addresses the cause.

learn CS50 Python, MDN web development, and the PostgreSQL tutorial.

04Show what you can do

Build evidence through work

Build something for one real person. Watch them use it. Change it.

  1. step 01

    Build and explain it

    A working system, its data flow, and a failure you diagnosed.

  2. step 02

    Adapt it with someone

    How a real user’s feedback changed a decision, with evidence.

  3. step 03

    Share responsibility

    Someone else operates and recovers it. Untested assumptions named.

case.mdone per project
problem
What the person needed, in their words.
what I did
Your part, not the team’s.
hard decision
One trade-off, and what you gave up.
evidence
What changed, and how you know.
next time
What you would change. A clear limit beats an unsupported claim.
05Choose your next role

Read the work behind the title

The title tells you little. These six answers tell you the job.

Questions to ask in the interview

  • What would I own in my first engagement?
  • How much work is implementation, discovery, support, or sales support?
  • Who can approve scope, architecture, and production changes?
  • Who helps when a problem exceeds my expertise?
  • Who owns custom code, and what can be reused after the engagement?
  • Who funds and supports the system after launch, and for how long?

expect to

  • Explain your code
  • Debug live
  • Reason through a design
  • Talk a customer through a decision
  • Show what changed because of you

Explore the FDE guides

06Keep growing

Grow beyond your first engagement

More uncertainty, bigger decisions, more teams. Go deep in one area; know enough of the rest to call for help.

01

Technical depth

Diagnose harder failures and make reliability, security, and cost trade-offs explicit.

02

Customer judgment

Narrow a request, challenge a weak assumption, and work through disagreement without taking over another person’s responsibility.

03

Reuse judgment

Recognise repeated needs and turn field learning into product improvements, client capabilities, or delivery patterns with clear ownership.

04

Team impact

Leave decisions understandable, share operating knowledge, and help others deliver without routing everything through you.

Questions people ask

Do I need to be an AI expert first?

No. Build software foundations and learn the AI skills your target role needs. You must be able to evaluate and operate what you use; you need not train models.

Do I need industry experience?

No. Learning the domain is part of the job: ask the basic questions early and watch the work as it is done today. Deep industry experience helps, but it is not required.

Do I need experience in every cloud?

No. Learn one well. Add others when real work needs them.

Can I become an FDE early in my career?

Some teams hire graduates; others want years of production and customer work. Match your evidence to the role, and look for mentoring.

How long will this take?

It depends on where you start and how often you practise on real work. A finished reading list proves nothing.

Your next step

Choose the responsibility to develop next

Choose a capability that limits your work today. Use a project to demonstrate it against the standard above.

Keep learning from the field

FDEOps Field Notes explores decisions behind customer-facing engineering: what to build, what to question, and how to make the result useful.

Read FDEOps Field Notes

Working on an engagement?

FDEOps gives your coding agent a method for each stage and a record of every engagement.

Explore the AI skill pack

A practitioner’s roadmap, not a certification. Reviewed 22 October 2026 by Subash Natarajan.