FDE vs Solutions
Engineer & Architect

Everything else — travel, demos, customer meetings, technical depth — is shared. All three are customer-facing. All three do demos. All three need to explain a system to a sceptical stranger. Sorting them by “how technical” is the classic mistake, because a senior solutions architect at a cloud provider can be extremely technical and still never own production.

An analysis of a thousand FDE postings found the title splits about 60% builder, 30% pre-sales-shaped, 10% internal.¹ The relabelling is rational: “forward deployed engineer” attracts engineers in a way “sales engineer” no longer does. So screen the text, not the title.

Two consequences of this timeline are worth internalising if you are choosing between the roles. First, the SE’s work is judged in weeks and the FDE’s in quarters — different feedback cadences suit different temperaments. Second, the FDE inherits every promise made earlier in the timeline. The demo that skipped the hard integration, the SOW clause that says “95% accuracy” with no definition of accuracy — those become your problem. Good FDEs get involved before the ink dries.

The page warns about a SOW that says “95% accuracy” with no definition of accuracy. Here is what an FDE does with one. Say the deployment routes incoming invoices to the right approval queue. The golden set and the scores are illustrative; the arithmetic was computed.

Steps 4 and 6 are the trap. Version 1 passes the contract and still fails the customer, because the overall number hides the slice that matters. Nobody in the sale did anything wrong by sales standards: “95% accuracy” is a fine thing to promise in a demo. It only becomes a problem when nobody defines it before signature. Step 8 is why you size the high-value slice up front. With 40 cases, a single error is worth 2.5 points, so the result jumps around with every run. A larger high-value set gives the gate steadier readings. This is the concrete version of “good FDEs get involved before the ink dries”: draft steps 1, 2 and 7 for the SOW, and the go-live conversation becomes a measurement instead of an argument.

Here Case is the role or the move, Time is when your work is judged, Space is what you still hold after signature, and Why is the pay shape and its catch.

What variable pay does to a year: on-target earnings (OTE) is base plus variable at 100% of quota. Take an illustrative $200K OTE at a 70/30 split: $140K base and $60K variable. Paid linearly, with no accelerators or caps, 50% attainment pays $170K and 150% pays $230K. Real plans add accelerators, caps and clawbacks, so read the plan document itself. A builder FDE’s base does not move with bookings. Their variance sits in the equity instead. So the SE’s pay is uncertain year to year but readable on the plan document. The FDE’s is steady in cash and uncertain in the part you cannot read off any document. Which kind of uncertainty you can live with is a fair way to choose between the two.

• Reading the title, not the comp line

  About 30% of FDE-titled jobs are pre-sales-shaped. “Quota”, “OTE” or “bookings” in the posting settles it faster than anything else in the ad. That is not a verdict on the job, only on which job it is. Pre-sales can be a strong career; the mistake is taking it while expecting to build.

• Sorting the roles by how technical they are

  A senior architect can out-design most engineers and never own production. Ask who is accountable after signature instead. Depth is shared across all three roles. Ownership is not.

• Shipping demo-grade code as production

  Demo code and production code part ways at idempotency, retries, verification and reconciliation. A demo that runs once on sample data has tested none of them. Coming from pre-sales, these four are the reps to do first: each is a challenge on this site with hidden tests.

• An FDE who never reads the SOW

  The acceptance criteria live there. An undefined “95% accuracy” becomes your problem at go-live, as the worked example shows. Ask to review the criteria before signature. If you arrive after it, propose the definition in week one, in writing, and get the customer to agree to the golden set before you build against it.

• Demoing past the hard integration

  A bake-off built on sample data can skip the system the customer actually runs. If it did, say so in the handoff, so the deployment plan starts from the real integration, not the demo.