TL;DR: The dividing line between the three roles is what each is allowed to build. Solutions engineers build demos and architectures to win the deal. Implementation engineers configure and integrate the product as it exists. Forward deployed engineers write custom code that doesn't exist yet, for one customer, and feed it back to the product. Titles are unreliable (FDE postings grew 800%+ in 2025, much of it relabeling), so use the output test, not the job title.

Three titles, one customer-facing technical surface, and endless confusion, for candidates deciding which job to take, for leaders deciding which role to hire, and for customers trying to figure out who does what. The confusion got worse when forward deployed engineer became the hottest title in software and companies started relabeling adjacent roles into it. This guide draws the boundaries by output, the only signal that survives title inflation.

The three roles by output

Solutions engineer (SE)

When: pre-sale. Output: demos, proofs of concept, technical answers to security and architecture questions, the solution design that wins the deal. Success metric: revenue influenced, deals won. Reports to: sales or presales. The SE's builds are disposable by design: a POC exists to prove a point, not to run in production.

Implementation engineer (IE)

When: post-sale, through go-live. Output: the product configured, integrated, and live in the customer's environment: API wiring, data migration, SSO, environment setup. Success metric: time to go-live, activation, customer reaching first value. Reports to: services, CS, or a delivery org. The IE works within the product's existing surface, and their skill is making that surface fit a messy real environment, repeatedly, across many accounts.

Forward deployed engineer (FDE)

When: post-sale (often pre-sale too), embedded for months. Output: custom code that didn't exist before, built for this customer because the product's surface isn't enough, with the builds feeding the core roadmap. Success metric: customer outcome plus product learnings. Reports to: engineering or a dedicated FDE org. From our nine practitioner interviews, the day splits roughly in half: with the customer understanding the problem, and building the solution. The FDE also owns scoping, deciding what to build, which our research found is the skill that washes people out.

The output test

Ignore the title on the req and ask three questions:

  • Does the work end at signature? Yes: SE. No: keep going.
  • Is the job configuring what exists, or building what doesn't? Configuring: IE. Building: keep going.
  • Do the custom builds feed the product roadmap? Yes: real FDE. No: it's services work, whatever the title says.

We've seen the mismatch in our own research CRM: a person doing textbook FDE work titled "Implementation lead," and a titled FDE doing classic delivery management. With postings up 800% in nine months, assume relabeling until the output test says otherwise. Hiring managers can find the full JD and screening playbook in the manager's guide to hiring FDEs.

Adjacent roles, quickly

  • Solutions architect: designs the technical solution in a business context, usually senior, usually spanning pre- and post-sale. The data-platform services lead we interviewed was pushing her FDEs to grow into exactly this, and expected to lose a third of them to the jump.
  • Implementation manager: owns the project and the relationship through go-live; coordinates rather than builds. Often the IE's non-coding counterpart.
  • Professional services consultant: billable delivery work, scoped by SOW, measured on utilization. The role FDE gets confused with most, and the one it's most often a relabel of.

What all three share: the context problem

Whichever role you hire or hold, the same tax applies: parallel accounts, truth scattered across calls, Slack, email, and the CRM, and hours spent reconstructing what was promised before any real work starts. FDEs in our interviews put meeting prep at up to three hours per customer conversation. That's the problem a project brain solves: sourced, evidence-linked account state maintained automatically, so the SE's discovery history, the IE's configuration decisions, and the FDE's scope conversations live in one place across the handoffs between them. That's what Tandem builds, and why FDEs specifically feel it hardest. If you run any flavor of these teams, start with Tandem for FDE teams or see it on your own accounts.

Custom code is also the line that decides when a request is discovery and when it is creep. Scope creep vs discovery applies the output test to scope.

FAQs

Is a forward deployed engineer the same as a solutions engineer?

No. The SE's job is winning the deal with demos and architecture; it largely ends at signature. The FDE's job starts around signature and centers on building custom, production-bound code inside the customer's environment for months.

Is FDE just a fancy title for implementation engineer?

Sometimes, and that's the inflation problem. The real boundary: IEs configure and integrate the existing product; FDEs build what doesn't exist yet, with a feedback loop to the roadmap. If the job description is configuration with an FDE title, it's an IE role.

Which role should a growing AI company hire first?

Map it to where deals die. Losing on technical credibility pre-sale: SE. Winning deals that stall before go-live: IE. Product needs per-customer extension to land at all (common for AI products in messy enterprise environments): FDE.

Which pays more?

Generally FDE > SE > IE at comparable seniority, with FDE comp pulled up by the AI-lab market and by demand growth. Verify against the output test: a relabeled services role pays like services.

Can one person do all three?

At an early-stage company, one person often does, and it works until volume forces specialization. The first role to split out is usually IE (repeatable work), then SE (deal volume), leaving the FDE profile for the accounts that need custom builds.

Key terms

  • Solutions engineer: Pre-sale technical role; wins deals with demos, POCs, and architecture.
  • Implementation engineer: Post-sale technical role; configures and integrates the existing product to go-live.
  • Forward deployed engineer: Embedded engineer building custom solutions for one customer, half discovery, half building, feeding the roadmap.
  • Output test: Classifying a role by what it produces (deals, go-lives, custom code) instead of its title.
  • Title inflation: Relabeling services and implementation roles as FDE to ride the market.
  • Feedback loop: Custom builds informing the core product roadmap, the signature of a real FDE function.