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 compounds or just costs.

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 bought 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 feed on what they learn at the front lines. If they sit in a separate professional services unit, you lose the feedback loop and drift 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 closing 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 drifts 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.

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 nothing compounding.

What good looks like under product or engineering

Engineers are allocated by learning value and contract value together, not by deal proximity.

Findings have a standing route to the roadmap, with a cadence 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 field work.

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 carrying the number 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 hold it.

How to tell your reporting line is wrong

Four tells, 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 promoted 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.

The exception worth naming

At a company with fewer than about twenty people, this is moot. The founders are in every conversation and the loop is a hallway.

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.