One title,
three different jobs

Rungs 1 and 2 are claims about how value is created. This rung is the only one on the ladder that counts something: a census of roughly a thousand job postings, read as data about what employers are actually asking for rather than as commentary on what the role should be.

The central finding is that one title covers several genuinely different jobs. Roughly a third of the postings are pre-sales-shaped — the work is demonstrating, scoping and winning, and success is measured in deals; others are deployment-shaped, where the work is making the thing function inside one customer's systems; and others are GTM or RevOps internal-tools roles, where the work is automating a company's own go-to-market workflows. The compensation structure, the skills rewarded and what "good" looks like differ across all three, and the title does not distinguish them.

Which turns the census into something directly usable, and this is why it earns a place next to two argumentative pieces. If the variants are distinguishable from the posting's own language — whether it talks about quota, pipeline and demos, or about integrations and production support, or about internal workflows and tooling — then you can tell which job you are interviewing for before the interview, and ask the questions that confirm it. The failure this prevents is specific and common: accepting a pre-sales role while expecting to build, which is a mismatch nobody misled you about.

Roughly a third of postings using the title are the pre-sales shape.¹ That is not a criticism — it is a legitimate, well-paid career with its own progression — but it is a different rhythm from delivery work, and accepting one while expecting the other is the most common source of unhappiness in this role.

The technical bar is a strong generalist rather than a specialist; the differentiator is the second column. First Round’s account of hiring for this role puts the engineering bar at staff level, plus a temperament most strong engineers have never been asked to develop.¹¹ If you are technically strong and have never sat in front of an unhappy customer, that gap is what to work on — not your algorithms.

The posting growth is not a fashion cycle, and it is not really about hiring. It is a response to a measurement problem: capability is broadly available, enterprise outcomes are not, and a widely-reported finding put roughly 95% of enterprise AI pilots at no measurable P&L impact.¹⁷ The strategic answer several companies reached simultaneously was to spend margin on deployment depth — a16z’s services-led-growth argument — and the operational expression of that decision is a job posting.⁸

Hence the capital: OpenAI standing up a deployment organisation,⁵ Anthropic and Blackstone launching a $1.5B venture,⁶ Microsoft committing $2.5B to embed engineers with customers.⁷ A thousand postings is what that strategy looks like from the outside.

The census is a blog analysis by Henley Wing Chiu of Bloomberry, published on November 18, 2025 and last updated on January 25, 2026.

1. Source the postings. 1,000 job postings for forward deployed engineers, supplied by Revealera, a job-data provider whose clients are financial firms. The post does not say which job boards were covered, when the postings were collected, or how duplicates were handled.
2. Measure growth by title. Postings titled forward deployed engineer from January to October 2025 are compared with the same months of 2024, giving a 1,165% year-over-year increase; October 2025 was the busiest month the author had recorded.
3. Classify each posting by its work. The author sorts postings into three types from what they describe and attaches typical markers to each, such as coding share, travel and posted pay. The split is the author's judgment, not a field in the data.
4. Count requirements. Skills, responsibilities, experience, team placement and industry are tallied as shares, each over the postings that state that item.
5. Read pay from disclosed ranges. The salary median uses only postings that published a range, and the post treats it as base pay.
6. Add a career-path sample. Separately, 100 LinkedIn profiles of people working as FDEs show where they came from; the author presents it as a sample, not a survey of the field.

The three types, as the census describes them

• Builder FDE (60%). An engineer embedded with customers to build, deploy and maintain production systems, closer to a senior software engineer than to a consultant: 70–90% coding and 30–50% travel.
• Sales Engineer+ (30%). A solutions or sales engineering job under a new title: demos, proofs of concept and product configuration during the sale, with the build handed to implementation teams; 30–40% coding, under 20% travel, and commission on top of base pay.
• Internal Tools Builder (10%). A go-to-market engineering or RevOps role building automation for internal sales, marketing and customer-success teams, which the author argues should not carry the title at all; under 5% travel.

How it relates to the other counts on this page

The 1,206 postings across 669 companies and the $185K median base quoted elsewhere on this page come from an earlier snapshot of a different census, Plank's, which uses a stricter definition of the role (its live page has since been updated). Bloomberry's median is $173,816. The two should not be pooled, because different sources, windows and definitions give different denominators.

FDE, solutions engineer, solutions architect

The census draws its sharpest line between the titles by timing: a solutions engineer's work ends when the customer agrees the product will work, and a forward deployed engineer's work begins there. Its Sales Engineer+ type is the overlap, the work long done under sales or solutions engineer titles. Solutions architects usually design reference architectures and advise across many accounts rather than ship production code inside one. What separates the Builder FDE is its coding share and its ownership of a production deployment at one customer.

Two findings change how the rest of this page reads. Most postings are builder roles, not sales ones. And on pay the census contradicts itself: it describes the Sales Engineer+ type as earning commission and carrying a quota, yet counts only 8% of all postings mentioning on-target earnings and 0% mentioning a quota. Even if every OTE mention were a sales-shaped posting, at most about a quarter of them could carry one, so the type must have been recognized mostly from the work described, not from pay terms.

The other limits are partly the author's own. The 60/30/10 split is a classification, not a measurement. Pay covers only postings with a published range and only base salary; experience and industry shares cover only postings that state them, and 79% name no industry at all. The growth figure is by title, so renamed solutions-engineering jobs count as new demand, and one year's count cannot tell a hiring cycle from lasting change. And a posting is what an employer advertises, not a filled role.

This is arithmetic on the census's reported figures, with the 1,000 postings as the base wherever a share covers all of them.

The counts make the census's inconsistency concrete. Even if all 80 postings that mention on-target earnings were Sales Engineer+ roles, they would cover 80 of 300, about 27 percent, of a type the census describes as paid on commission, and not one posting mentions a quota. So the type must have been assigned mostly from the work described, not from pay terms.

The growth multiple needs the same care. A 1,165 percent rise is a ratio of title counts, so a team that renamed ten solutions-engineering postings in 2025 adds ten to the numerator while the 2024 count never saw them: renaming and new demand look identical. And the $11,184 gap between the two medians is not a pay trend or a premium for either definition of the role; the two censuses use different sources, windows and definitions, so the difference mixes all three and should not be read as anything until they are put on one denominator.

The census is most useful as a way to read one posting well. Most misuses come from applying its aggregates to a single job, or its labels to a different question.

• Using pay terms to spot the sales-shaped role

  Only 8% of postings mention on-target earnings and none mentions a quota, yet 30% were classed as sales-shaped. So a posting with no commission language can still be a sales job. Read the work described instead: demos and proofs of concept against owning a production deployment, the coding share, and whether the team sits in sales.

• Preparing for the wrong seniority

  First Round's account of hiring describes a staff-level engineering bar, while 60% of census postings that state experience ask for three to five years. The two sources describe different slices of the market; prepare for the bar the specific posting and its interview loop set, not for either average.

• Treating the skill tally as a syllabus

  A tally counts the words employers write, which favours named tools: Python at 66%, AWS at 32%. Practices such as evaluation or careful integration are usually written as prose, so a low or missing count says little about how much the interview will probe them.

• Comparing an offer with the median

  The $173,816 median is base pay, from postings that published a range, while 70% of postings mention equity and sales-shaped roles add commission. Compare base with base and the full package with the full package, within the same role type.

• Hiring under one title for three jobs

  For employers the census is a warning: a posting called forward deployed engineer will draw candidates expecting any of three different jobs. State the type, the coding share, the travel and where the team reports, or expect offers declined and early departures from people who wanted a different one.

Job postings measure what organisations say they want, which is related to the work but not identical to it. A posting is written to attract candidates and frequently to satisfy an internal process; the requirement list is often aspirational, the seniority label is often negotiable, and the actual day-to-day is set by the team's current pressures rather than by the text. So this is a census of demand as advertised.

It is also a snapshot. A count taken at one moment in a fast-moving market cannot separate durable structure from a hiring cycle, and the growth figures that make the market look dramatic are precisely the ones most sensitive to the window chosen. Postings also over-represent organisations with formal hiring processes, and under-represent the small teams where this kind of work is often most concentrated.

What survives all of that is the taxonomy, and it is the durable contribution. That one title spans a sales-shaped job, a deployment job and a product job is a structural observation, not a statistic — it does not depend on the exact proportions and it explains most of the confusion in how the role is discussed. Read alongside rung 2, the two fit together: a company trading margin for moat needs all three of those variants, values them differently, and has an incentive to describe them with one word.

Work each one out before you open it — a number, a prediction or a reason, not a definition. Producing the answer is what makes it stick. Your progress is kept on this device.

Not research papers: a consultancy census, a VC essay and a job-posting analysis. Included because their figures get quoted as if they were, and read here for their method.

1. 1The 95% Number, Examined2026
2. 2Trading Margin for Moat2026
3. 31,000 FDE Jobs, Analysed2026

All 110 papers, in 19 ladders →