How to build a forward deployed engineering team

This is the founder's playbook: what to confirm before hiring, who to hire first, where to deploy them, and the two structural decisions that matter more than the hires.

Step zero: confirm the prerequisites

First Round Review's February 2026 guidance names three conditions for the model to fit, and they function as a gate.

You are selling to enterprises. The deployment cost has to be carried by the contract. First Round reports Looker validating $25,000 or more in annual contract value before committing to the model, alongside a trajectory toward 2,000 customers and $100 million in recurring revenue. Do your own arithmetic rather than adopting that figure, and write the floor down.

Your product is still flexible. First Round is direct: if you hold strong opinions about product direction and do not want them moved, embedded engineers are a bad fit. The value of the model is what the engineers learn, and learning you will not act on is expensive.

Your customers' use cases differ. If every implementation is the same shape, you have a documentation problem rather than a deployment problem, and templates will serve you better.

Missing one of three is manageable with eyes open. Missing two means the model will cost you margin without returning a mechanism. When forward deployed engineering is the wrong answer is the fuller version.

Step one: hire two or three, not a department

Start small enough that the first engagements are visible to you personally.

The reason is that the first two or three engagements are where you learn what your own version of this model is: what generalises, how long production actually takes at your kind of customer, and what your engineers need that they do not have. That learning does not survive delegation to a team of fifteen.

Deploy them on your highest-value accounts only. First Round's guidance is to reserve embedded engineers for the highest contract values and the customers with complex, non-standardised needs, typically organizations of 1,000 employees or more, and to serve smaller accounts with repeatable implementations.

Step two: hire the right profile

First Round's five qualities, which are more specific than most role descriptions:

An independent thinker without preconceived frameworks. Early-career engineers often do well here, and ten or more years at a large tech company can be a red flag, because the role needs somebody who operates without institutional scaffolding.

Grit. First Round's phrase is a willingness to eat pain, and the practical version is somebody who keeps going at a problem that looks unsolvable for a fortnight.

A real engineering foundation. Do not lower the coding bar. The role writes production code, and First Round is explicit that candidates should clear a rigorous engineering interview.

A compulsive builder. Somebody who ships across many contexts rather than optimising one.

Business curiosity. Genuine interest in how an organization operates, because the job is finding which problem matters.

Shilpa Balaji's summary bar, quoted in the same piece, is the one to keep: would you want to be in the trenches with this person.

The hiring data is consistent with this profile being mid-level. Across 1,000 postings, 60 percent targeted three to five years of experience, and 45 percent of routes in came from software engineering. How to hire covers sourcing and signals.

Step three: pick the reporting line, deliberately

This is the decision most companies get wrong, and it is nearly free to get right at the start.

Report the function into product or engineering. Marty Cagan's warning is that if embedded engineers sit in a separate professional services unit, you lose the feedback loop and drift toward a pure services business.

The hiring data suggests over half of the market has already made the wrong choice: only 45 percent of the 1,000 postings analysed sat on a dedicated forward deployed team rather than reporting into sales.

Where the function should report covers the argument and the exceptions.

Step four: assign the productization job in month one

Not later, when there is something to generalise. Now, when there is one engagement, because the habit is what you are installing rather than the output.

Somebody owns asking, on a fixed cadence, what of everything built this period generalises. Somebody decides what gets promoted into the platform. And somebody applies the stop rule: expand scope when the work creates reusable value, stop when the next iteration will only ever serve one customer.

Without this, you get what a16z's Marc Andrusko describes as bespoke deployments that cannot be maintained or upgraded, with revenue growing and nothing compounding. The productization loop is the mechanism in detail.

Step five: build the shared layer early

The custom work should sit on reusable primitives from the beginning, even when there is one customer.

The AWS partner programme names the modern version of that layer: reusable delivery harnesses including domain ontologies, evaluation frameworks and capability registries. With one customer that sounds like overhead. With four it is the difference between a platform and four forks.

The cheapest version at the start: keep a clear boundary between shared and custom code, and track the ratio per account. If the custom share grows with each new account rather than shrinking, the model is not working.

What to measure from the start

Do not measure utilisation. It rewards the endless engagement.

Measure time from contract signature to production, the share of engagements that reach production, revenue per embedded engineer over time, and what came back into the product. Measuring the function and revenue per engineer cover both sides.

If you would rather not build it

Building this function takes a hiring cycle, two or three engagements of learning, and a structural decision most companies get wrong. Staffing engineers through a partner or engaging a firm that already works this way are the alternatives, with different costs and different risk. Three routes to the capability compares them, and our own service is one of them.