How to build a forward deployed engineering team

This is the founder's step-by-step plan: 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 you should check all three before you start.

You are selling to enterprises. The deployment cost has to be paid for 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 calculation rather than adopting that figure, and write the minimum down.

Your product is still flexible. First Round is direct: if you hold strong opinions about product direction and do not want them changed, 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, you have a documentation problem rather than a deployment problem, and templates will serve you better.

Missing one of three is manageable if you know the risk. Missing two means the model will cost you margin without giving you anything back. When forward deployed engineering is the wrong answer is the fuller version.

A quick way to check yourself honestly on the third prerequisite: pull up your last five signed contracts and list, in one sentence each, what was actually different about the deployment. If four of the five sentences say roughly the same thing with different customer names, your use cases do not differ enough to justify the model, whatever the sales narrative said during the deal. If all five sentences describe genuinely different integration points, data shapes, or approval processes, the prerequisite holds and the model has something real to do.

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 is lost when it is delegated 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.

Resist the pressure to spread the first two or three engineers across more accounts than that, even when several customers are asking for the same attention. A founder who splits a small team across six accounts to keep everyone happy learns six shallow lessons instead of two or three deep ones, and shallow lessons about what generalises are worse than no lessons at all, because they get written into the platform with false confidence.

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 warning sign, because the role needs somebody who operates without the support structure of a large company.

Grit. First Round describes it as a willingness to accept hard, unpleasant work, 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 standard. The role writes production code, and First Round is explicit that candidates should pass a rigorous engineering interview.

A compulsive builder. Somebody who releases working software in many different settings 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 test, quoted in the same piece, is the one to keep: would you want to work through a hard, stressful project 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 career paths into the role started in 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, what they learn stops reaching the product and the company moves 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 building rather than the output.

Somebody owns asking, on a fixed schedule, what of everything built this period generalises. Somebody decides what gets moved 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 no reusable work building up. The productization loop is the mechanism in detail.

Do this even if it feels premature with a single customer. The habit of asking what generalises is easy to build when the answer is obvious and hard to build later, once three separate codebases already exist and asking the question means admitting that a year of work needs restructuring. A founder who assigns this job in month one is paying a small, visible cost now to avoid a large, invisible one later. That trade is the entire argument of this page, so treat it as more than a formality.

Step five: build the shared layer early

The custom work should sit on reusable components 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.

Utilisation looks like the obvious metric to a founder used to running a services business, because it answers the question of whether engineers are busy. The trouble is that a busy engineer inside an endless engagement scores perfectly on utilisation while producing exactly the outcome the model is supposed to avoid. Time to production and revenue per engineer both ask a harder, better question: whether the engagement is moving toward an end and whether the function is getting more efficient as it learns. Track those from the first engagement, not once there is enough data to make a chart, because the habit of measuring the right thing is as important as the numbers themselves in the early months.

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. None of the three routes removes the underlying work of confirming the prerequisites and choosing a reporting line: a partner or a vendor executes the plan, but the plan still has to be yours. Three routes to the capability compares them, and our own service is one of them.