Where forward deployed engineering should report

This is one structural decision, it is nearly free to make correctly at the start, and it decides whether the function builds lasting value or only costs money.

The answer

Product or engineering. Not sales. Not a standalone professional services organization.

Why the reporting line decides the outcome

The economic case for embedding engineers is that they learn things nobody could learn from outside, and that those learnings improve the product for every future customer. The margin you spend is paid back by the product getting better.

That only happens if there is a route from the engineer's discovery to the roadmap. A reporting line is that route. Without one, the learning stays in one engagement and the margin is just gone.

Marty Cagan puts it plainly: forward deployed engineers are deeply involved in product discovery, and strong product teams use what engineers learn at customer sites. If they sit in a separate professional services unit, what they learn stops reaching the product and the company moves toward a pure services business.

What goes wrong under sales

Sales leadership is measured on bookings and retention. Those are legitimate goals and they produce predictable behaviour when embedded engineers report into them.

Engineers get allocated to whichever deal is closest to being signed rather than to the deployment where the learning is most valuable.

Custom commitments get made to win contracts, because the person who will build it reports to the person who needs the signature.

Nothing generalises, because generalising is invisible to a bookings number and takes engineers away from accounts.

The role turns into presales. This is measurable in the market: the analysis of 1,000 postings found 30 percent of roles carrying the forward deployed title were really sales engineering with implementation duties, and only 45 percent sat on a dedicated forward deployed team rather than under sales.

None of that requires anyone to behave badly. It is what the incentive produces.

Consider the ordinary version of how this plays out. A sales director has a deal at high probability, closing this quarter, and the customer wants a proof of concept built before signature. The engineer working the healthiest deployment, the one where the loop is running and the learning is compounding, gets pulled to build the proof of concept, because that deal has a number attached and a date attached and the healthy deployment does not. The healthy deployment slips. Nobody decided that the healthy deployment mattered less. The org chart decided it, before anyone in the room had an opinion.

This is also why the mistake is hard to see from inside a sales-led structure. Every individual reallocation looks reasonable in isolation. The deal is closer to signing. The proof of concept does need building. It is only in aggregate, over quarters, that the pattern becomes visible: the function never generalises anything, because it is never allowed to stop moving.

What goes wrong in a standalone services unit

This is the more sophisticated mistake, and it looks like good organizational design.

A professional services group has its own leader, its own margin target, and its own delivery methodology. It gets efficient at delivering. And the moment it has a margin target, generalising work becomes a cost to it, because a capability moved into the platform is revenue the services unit no longer bills.

The structure now has an incentive against the mechanism that justified it. a16z's Marc Andrusko describes the end state as bespoke deployments that cannot be maintained or upgraded, with revenue growing and no reusable work building up.

The services unit also tends to hire for a different skill than the one this role needs. First Round Review's guidance is to look for grit and business curiosity beyond ordinary engineering skill, because the job is discovering what a customer actually needs before building it. A standalone services organization, staffed and measured like every other services organization, drifts toward hiring for delivery efficiency instead, which is a different person doing a different job under the same title.

There is a second cost to the services structure that shows up later and is harder to reverse: once a services unit has its own profit-and-loss statement, closing it becomes a headcount and revenue decision rather than an org-chart change. Executives who would happily move a reporting line on a whiteboard resist dismantling a unit with its own budget, its own leadership team, and a stated revenue number attached to its existence. The two-year delay mentioned at the end of this page usually is not two years of nobody noticing the problem. It is two years of somebody knowing and finding the fix too disruptive to make.

What good looks like under product or engineering

Engineers are allocated by learning value and contract value together, not by how close a deal is to being signed.

Findings have a permanent route to the roadmap, with a schedule and an owner. The productization loop is that mechanism.

Generalising is part of the job, not overhead, because the same organization owns the platform and the work at customer sites.

Saying no is possible. An engineer who reports to engineering can decline a customer request that only serves one account. An engineer who reports to the person with the sales target cannot, realistically.

Anthropic's own posting for the role names identifying repeatable deployment patterns and sharing them with product and engineering as a responsibility. That duty only makes sense if the reporting line supports it.

The pairing that works

Reporting to product or engineering does not mean sales is uninvolved.

The arrangement that works in practice: the engineer reports into product or engineering, and an account owner in sales or customer success owns the commercial relationship. The engineer builds; somebody else owns the renewal conversation and the escalation.

That split also protects the time allocation. First Round Review puts the healthy split at roughly 20 percent customer-facing and 80 percent building, and an engineer who also owns the relationship will not keep to it.

How to tell your reporting line is wrong

Four warning signs, in order of how early they appear.

Nothing has changed the roadmap in two quarters. The clearest signal. If a function whose purpose is learning has produced no product change in six months, the route does not exist.

Engineers are being moved between accounts mid-deployment to support deals.

Nobody can say who decides what gets moved into the platform. If the answer is a committee or nobody, it is nobody.

Custom commitments appear in contracts that engineering did not see. The clearest sign the line runs through sales in practice, whatever the org chart says.

A fifth sign worth watching, less dramatic than the other four but just as reliable: the same question gets answered differently by different engineers because there is no registry and no owner tracking what already exists. That is not strictly a reporting-line problem on its own, but a reporting line into product or engineering is what makes a registry someone's job rather than nobody's job. When the answer to "have we built this before" depends on which engineer you happen to ask, the organization has already lost the thing embedding engineers was supposed to buy it.

How this differs from the ratio and pricing questions

This page answers a structural question: who does the function answer to. It does not answer how many embedded engineers you need relative to product engineers, which has no defensible published benchmark and has to be calculated from your own accounts and deployment history; see the ratio question. It also does not answer how the work gets priced, which is a separate decision covered in how to price forward deployed engineering. All three interact, but getting the reporting line right first is what makes the other two decisions answerable with real data instead of guesswork, because a function that reports through sales never accumulates the deployment history the ratio calculation needs.

The exception worth naming

At a company with fewer than about twenty people, this does not matter. The founders are in every conversation and the feedback happens in hallway conversations.

The decision matters from the point where the person doing the embedding and the person deciding the roadmap are no longer in the same meetings by default. That is earlier than most companies expect, and the cost of setting it up correctly then is close to zero. Reorganising a services unit two years later is not.

Next: the ratio question, or the productization loop for the mechanism this reporting line exists to enable.