An FDE job description should let a candidate answer four questions before applying: What customer or user problem will I own? What will I build or operate? What decisions belong to me? What are the working conditions? The title alone cannot answer those questions. “Forward deployed engineer” is used for production engineering, data integration, technical consulting, and several combinations of those jobs.
Use the description to name the work your company needs now. Start with the outcome, then describe the technical work and the people the engineer will work with. State what the role owns from discovery through launch, and where another team remains accountable.
Start with the real assignment
Write one paragraph that names the product, customer, and first problem. Replace broad language such as “drive innovation” with a concrete assignment:
You will work with [customer type] to move [product or capability] from [listed state] to [production outcome]. You will own [discovery, build, deployment, or operations] and work with [teams].
Then list three to six outcomes for the first [time period]. Good outcomes describe work that can be observed. Examples include a production integration, a validated workflow, a deployment runbook, or a reusable component. “Be a trusted partner” can describe how someone works, but it is not an outcome by itself.
Recent postings show why this detail matters. OpenAI describes FDEs owning discovery, technical scoping, system design, build, and production rollout, with success measured through production adoption and workflow impact. Notion’s FDE postings separate customer discovery, solution architecture, and stakeholder communication from hands-on migration execution in some teams. A smaller company may combine all of those responsibilities. The job description should say which model applies here.
Separate required and preferred experience
Required qualifications should describe evidence a person needs to do the stated work. Keep the list short. For a production AI role, that may include shipping production software, designing a service or workflow, and working directly with technical customer stakeholders. For a data and integration role, it may include APIs, SQL, data modeling, authentication, testing, and production rollout.
Preferred qualifications are useful only when they change the work someone can take on. Put domain knowledge, a specific cloud, or experience with a particular model framework there when a capable engineer could learn it after joining. Do not use “preferred” to hide a requirement the first project truly depends on.
Describe equivalent paths when they are real. Notion lists backend, data, integration, implementation, consulting, and solutions engineering backgrounds for one migration role. That is clearer than requiring a previous FDE title. State the level of ownership and the evidence you need, rather than filtering by a title.
Explain the customer-facing part
Say who the engineer meets and what those conversations accomplish. Examples include mapping a customer’s workflow, agreeing on data access, explaining trade-offs, running acceptance testing, or handing over an operating system. If a manager owns the relationship and the FDE owns implementation, say so. If the FDE owns both, say so.
Avoid calling a role “customer-facing” without describing the contact. A candidate needs to know whether the work is discovery, demos, implementation, incident response, training, or a mix. They also need to know whether the customer is an end user, a technical team, or an internal business group.
Name the engineering work
Use the technologies that the first projects require, but connect each one to a task. “Python for services and data transformations” is more useful than a list of ten tools. Explain whether the engineer will write production code, prototypes, configuration, integration scripts, or all four.
Notion describes APIs, data pipelines, migrations, custom agents, permissions, and governance. Firecrawl describes TypeScript or Node.js integrations, third-party APIs, authentication, debugging, and reusable playbooks. These examples show the level of specificity candidates need. They do not establish a universal FDE stack.
State conditions before asking for interest
Include the employing entity, employment type, work location, office expectation, travel expectation, work authorization policy, compensation range, equity or bonus approach, and application contact. State the known conditions and explain what remains undecided.
Give a salary range for the stated location and explain what varies by location or level. If equity, bonus, commission, or benefits are part of the offer, say what is known and link to the benefits page.
Remove common ambiguity
Before publishing, check each phrase below against the actual assignment:
| Vague phrase | Replace it with |
|---|---|
| “Own end to end” | The stages and decisions the role owns |
| “Work cross-functionally” | The teams, meetings, and handoffs involved |
| “Move fast in ambiguity” | An example of an unclear input and the decision expected |
| “Customer obsessed” | The customer activity and outcome to deliver |
| “Full-stack” | The layers the engineer will change in the first project |
| “High impact” | The user, workflow, reliability, or adoption result |
Do not promise autonomy, rapid promotion, or a particular career path unless the company can support that promise. Do not require ten years of experience for a first FDE hire because the role is undefined. Define the first responsibility clearly and hire for the evidence needed to do it.
A final publishing check
Ask a hiring manager who did not write the draft to point to the first project, required decisions, customer contact, and working conditions. Ask an engineer outside the team to identify the evidence each requirement is testing. If either reader has to infer the answer, revise the description.
Use one of the editable templates below as a starting point: