In a product company
Make your employer’s product work in the customer’s environment. Build integrations and extensions within agreed product boundaries.
Bring recurring needs back to product engineering. Recognise when the product does not fit.
A practical roadmap
Become an FDE
Build the engineering depth and customer judgment the job requires. Find your starting point and choose what to learn next.
Free to use. No installation required.
01Understand the role
What does a forward deployed engineer do?
A forward deployed engineer works with customers to define a problem, build a solution, and help their team use and operate it.
The work combines engineering and customer judgment: observe a task, debug an integration, compare options, and test whether the change helps.
FDE roles span AI, data platforms, applications, and infrastructure. Check each job’s responsibilities: what you build, which decisions you own, and who supports it.
- 01
Understand the customer
- 02
Build and adapt
- 03
Help people use it
- 04
Carry the learning forward
These activities overlap and repeat.
Where you work changes the remit
In a services or consulting firm
Deliver an agreed client outcome using suitable platforms, custom code, and existing systems.
Work within the agreed scope and budget. Establish who maintains the solution after delivery.
These models overlap. In both, you build with the customer and share responsibility with their business and technical teams.
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
Begin with programming, APIs, databases, testing, and deployment. Build a small application you can explain and maintain. Learn the customer-facing work alongside it, with guidance on your first projects.
I already build software or AI systems
Check the technical capabilities, then focus on customer work and operation. Add AI evaluation if your target role involves models. Your next gap may be scoping, economics, adoption, or an unfamiliar environment.
I work with customers
Bring your discovery and communication experience. Check your hands-on ability to implement, debug, test, and operate what you recommend. Start with the technical capabilities you cannot yet show.
I already work as an FDE
Use the roadmap to find a weakness that repeats across engagements. Then strengthen scope and architecture judgment, cross-team decisions, and the ability to help others deliver without relying on you for every answer.
03Build the capabilities
The FDE roadmap
Engineering depth supports the role. Progress means taking responsibility for harder decisions across the customer’s work, systems, and operation.
Use these six capabilities to assess your next step. Early in your career, demonstrate them in a bounded project with review. With experience, apply them across less familiar systems and more consequential decisions.
The capabilities you build as an FDE
01Build dependable softwareBuild, debug, test, and deploy02Connect systems and dataIntegrate without losing meaning or control03Understand customer workRecommend a useful, justified change04Choose and evaluate AIDemonstrate where AI helps and where it fails05Help a team run itSupport use, correction, and recovery06Make field learning reusableMake learning useful beyond one engagement
The capabilities develop together; the engagement determines which needs attention.
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 and evidence
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: A deployed application, a reviewed change, and a reproduced failure with a tested fix. Show why the fix addresses the cause.
Foundations: CS50 Python, MDN web development, and the PostgreSQL tutorial. Use these where your engineering foundation needs work.
Connect systems and data
Connect systems without losing the meaning, freshness, or access restrictions of their data. Establish which source owns each record and how changes reach downstream users.
What good looks like
Retries, stale records, and unavailable dependencies produce explicit outcomes without duplicate writes or unauthorised access.
Judgment and evidence
Judgment: A timeout does not prove a write failed. Define how retries avoid duplicates, how conflicting records are reconciled, and what happens when data is missing. Respect upstream API limits and supported interfaces.
Evidence: A data-flow diagram and tests covering duplicate events, denied access, schema changes, and interrupted writes. Identify any recovery that still requires a person.
References: HTTP, Stripe’s error-handling guide, and OWASP authorization guidance.
Understand customer work
Turn a customer request into an agreed outcome and a delivery decision. Establish the baseline, constraints, alternatives, and who can authorise the work.
What good looks like
The customer can explain the proposed change, its expected value, what it excludes, and the decision they need to make.
Judgment and evidence
Judgment: Separate time spent working from time spent waiting. Include integration, review, and maintenance in the business case. Saved hours create capacity; cash savings require a separate explanation. A scope change needs an owner’s agreement on cost and displaced work.
Evidence: A concise recommendation with observed facts, labelled estimates, alternatives, scope, and a decision owner. Record disagreements that could change the build.
Reference: GOV.UK contextual research guidance covers observing work and checking your interpretation.
Choose and evaluate AI
Choose where AI earns its place in the workflow. Work with model APIs, context and retrieval, structured outputs, and tool use as the task requires. Define what the system may do and how its output will be checked.
What good looks like
You can defend the design against a simpler alternative using representative results, failure cases, latency, and total operating cost.
Judgment and evidence
Judgment: Evaluate the whole task, including human review. Test missing information, outdated sources, and consequential errors separately from average performance. Enforce permissions outside the model and treat retrieved instructions as untrusted input.
Evidence: A representative evaluation set, results by failure type, cost including retries and review, and explicit limits on deployment. Label synthetic cases and distinguish local tests from customer outcomes.
References: Building effective agents and Demystifying evals for AI agents.
Help a team run it
Make the system usable and recoverable under an agreed support model. Establish rollout conditions, monitoring, rollback, and who owns incidents, rules, and source data.
What good looks like
The operating team can handle a common failure and escalate an unfamiliar one without relying on your private knowledge.
Judgment and evidence
Judgment: A technically healthy service can still create extra work. Track review, rework, and adoption alongside reliability. Keep human approval where it is needed, with a named role and clear authority. Agree how long support lasts.
Evidence: A controlled release plan, actionable alerts, and a recovery exercise completed by the operating team. Capture the gaps the exercise exposes before expanding the rollout.
Reference: OpenTelemetry’s observability primer explains the signals used to investigate running systems.
Make field learning reusable
Decide what should stay local and what others can reuse: a product change, client-owned capability, connector, or delivery method.
What good looks like
Another team can adopt the useful part with clear ownership, supported boundaries, and permission to use it.
Judgment and evidence
Judgment: One customer’s need does not establish demand for a platform. Look for repeated requirements and stable behaviour before generalising. Agree maintenance with the product, client, or delivery team; check rights before sharing code or data.
Evidence: A proposal or reusable component that states who needs it next, what remains customer-specific, and who will maintain it. Keeping a change local is a valid decision.
04Show what you can do
Build evidence through work
A useful case shows what changed because of your work. A practice project can demonstrate engineering ability; claims about customer value require customer evidence.
Build and explain it
Show a working system, its data flow, and a failure you diagnosed. Explain the trade-offs behind the design.
Adapt it with someone
Show how user feedback changed a decision and what evidence supports the result.
Share responsibility
Help another person operate and recover it. Be clear about which production assumptions remain untested.
Keep a short account: the problem, your contribution, the alternatives, one difficult decision, the evidence, and what you would improve. Share only material you have permission to disclose. A clear limitation is more useful than an unsupported success claim.
05Choose your next role
Read the work behind the title
Compare roles you would actually consider. Look for what you will build, how you will work with customers, who supports production, and what the role expects on day one. Check travel, location, and on-call responsibilities directly with the employer.
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?
Prepare to explain code, debug a problem, reason through a design, and discuss a decision with a customer. Use your project evidence to show what changed because of your work. Interview formats and experience requirements vary; prepare against the actual role.
Explore the FDE guides
Go deeper into the part of the role you want to understand next.
What an FDE does
Understand the responsibilities and how the role varies between companies.
FDE capabilities
Assess the engineering, customer and communication capabilities behind the role.
Moving into the role
Choose a target role, assess your existing evidence and plan a career transition.
Interview preparation
Prepare for coding, design, and customer-facing discussions.
Writing your resume
Present your contribution, decisions, and results clearly.
Finding FDE roles
Understand job descriptions and choose opportunities that fit.
06Keep growing
Grow beyond your first engagement
As you gain experience, take on work with more uncertainty, more consequential decisions, or more teams involved. Keep a technical area where you can go deep. Learn enough about adjacent areas to recognise a problem and bring in the right help.
Technical depth
Diagnose harder failures and make reliability, security, and cost trade-offs explicit.
Customer judgment
Narrow a request, challenge a weak assumption, and work through disagreement without taking over another person’s responsibility.
Reuse judgment
Recognise repeated needs and turn field learning into product improvements, client capabilities, or delivery patterns with clear ownership.
Team impact
Leave decisions understandable, share operating knowledge, and help others deliver without routing everything through you.
Repeated difficulties across engagements identify where to deepen your skill. Review the decisions behind them with someone who has handled that responsibility.
Questions people ask
Do I need to be an AI expert first?
No. Build the software foundations and learn the AI skills your target role needs. You should be able to evaluate and operate the systems you use, even if you do not train models yourself.
Do I need experience in every cloud?
No. Learn one environment well, then compare alternatives when the work calls for it. Build breadth through real needs rather than collecting platforms.
Can I become an FDE early in my career?
Some employers hire graduates; others seek substantial production and customer-facing experience. Match your evidence to the role and look for appropriate support and mentorship.
How long will this take?
That depends on your starting point and opportunities to practise. Use the capability descriptions to identify gaps. Completing a reading list alone does not demonstrate the work.
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 NotesWorking on an engagement?
FDEOps gives your coding agent reusable instructions for customer-facing engineering tasks. Use a task independently, or keep an ongoing engagement's confirmed context in a local record with the fde coordinator. The skill pack supports your work; it does not replace the capabilities in this roadmap.
Explore the AI skill packThis roadmap is an editorial recommendation, not a certification, employer-endorsed curriculum, or guarantee of hiring readiness. Reviewed 16 September 2026 by Subash Natarajan.