Draw the org chart of a mid-size company and hold it against the work that needs doing now. Operations holds the workflow knowledge: the exceptions, the Tuesday walk, the customer who must never be auto-emailed. Engineering holds the system-building skill: the ability to make software true in production. Between the two groups, on paper, runs a dotted line labeled collaboration.
The work that needs doing now lives on that dotted line. Every AI deployment, every automation, every process change that involves software is a joint production of the two knowledges, and the org chart contains no role that holds both. The forward deployed engineer, whatever the hiring hype says, is best understood as the market's answer to that vacancy: a person rented to sit exactly where the hole is.
This framing does something the talent-scarcity framing cannot. It turns the FDE boom from a hiring question into an org-design question, and org-design questions have different answers than hiring questions.
The hole, precisely
The gap is not a skills shortage. It is a structural separation of two knowledges that must combine to produce any deployed system.
Operations people cannot build, and are not supposed to: their value is the accumulated, undocumented model of how the company actually runs, which is precisely the knowledge documentation never captures. Engineers can build, and are not embedded: they receive the operation as requirements, which is to say as a lossy compression of the real thing. The compression step is where deployed projects die, because the requirements describe the designed company while the build has to survive the operating one.
An FDE closes the gap by holding both knowledges at once, sitting inside the operation while building into it. That is the whole trick, and it is a real one. But notice what the trick accomplishes structurally: it does not fill the hole in the org chart. It spans it, temporarily, with a rented person. The hole remains. Whether that matters is the strategic decision most companies are making by accident.
Rent the bridge or grow the pier
The market offers the rental at scale in 2026, with vendor FDE teams, deployment partners, and agency models, and for a first deployment the rental is usually right. The domain is new, the failure modes are unknown, and paying people who have already made the mistakes elsewhere is cheaper than making them yourself.
The rental has a term hidden in its structure, though, and the term is comprehension export. The vendor FDE who walks your operation and ships your system leaves with the most valuable artifact the engagement produced: an accurate model of how your company works, joined to the ability to build against it. Judgment Does Not Transfer names the mechanism from the system side: exported systems carry the assumptions of the ground that grew them. Here it runs in reverse, and worse: the ground's comprehension exports cleanly, but it exports to the vendor, where it becomes the vendor's pattern library, priced into the next customer's proposal.
So the rental's expiry date is the second engagement. A company deploying once can rent. A company whose strategy involves repeated deployments, automations, and AI work, which is now most companies, is running a permanent bridge rental, and permanent rentals have a property worth stating plainly: the asset being rented appreciates, the rent follows, and the tenant's alternative shrinks each year, because in-house capability that is never grown never compounds.
The alternative is growing the pier: internal people who sit on the dotted line, FDE-shaped, whose comprehension stays. Not replacing the vendor, partnering with it deliberately. The strongest pattern from practice is pairing: every vendor FDE engagement includes named internal counterparts whose job includes absorbing the walk-through, the design decisions, and the judgment calls, with the pairing written into the statement of work as a deliverable. The vendor's margin-for-moat math still runs, on their side. But on your side, each engagement deposits people, and people are the only inventory of judgment a company holds. Human Judgment Is the Scarce Layer makes the general case; the org-design version is narrower: judgment retained is org structure, not headcount.
The honest skeptic's question
The skeptic's version of the FDE story, circulating this year, asks whether the role is just consulting with a better title. The question deserves a straight answer rather than a defense, because it is half right.
What is consulting: the embedding, the scoping, the custom build, the hourly economics, the vendor-side conversion of engagement into reusable assets. What is not: the production-grade engineering under real constraints, and the specific pairing of the two knowledges on the dotted line, which classic consulting deliberately avoided by keeping strategy and implementation apart. The FDE is what consulting would be if it shipped systems and stayed for the consequences.
But the skeptic's question, asked from the buyer's side, is the useful one, because its answer is the whole strategy of this piece: if the role is consulting with a better title, then renting it forever carries consulting's classic failure, dependence dressed as partnership. The title matters less than the terms. The same embedded engineer, under terms that extract the map, deposit the inventory, and grow internal counterparts, is a capability investment. Under terms that don't, it is a very good consultant.
The org-chart test decides. After three engagements, does the dotted line have anyone standing on it who works for you? If yes, the hole is closing. If no, the hole has been professionalized, and you are its subscriber.
What this is not
Not an argument that every company needs internal FDEs on day one. First deployments should rent. The failure is not the rental; it is the never-growing pier, the five-year strategy of borrowing the same bridge and calling the rent a partnership.
Not an argument against vendors, who in this model are honest counterparties playing their own correct game. The complaint department for margin-for-moat is empty. The buyer's job is to run its own version of the same math, and Every Deployment Should Leave Product Behind is that ledger.
And not a claim that the hole is unusual. Most industrial-era org charts have it; software merely made it expensive, and AI made it urgent. The companies being praised for FDE-style agility are, mostly, companies that noticed the dotted line before the market started renting them a bridge across it.
Take-home
- Find the dotted line in your org chart, the place where workflow knowledge and build skill are supposed to collaborate. Whoever is standing on it, and whose payroll they are on, is your AI strategy in one fact.
- If you are renting the bridge, write the pier into the terms: named internal counterparts on every vendor engagement, with absorption as a deliverable, not a hope.
- Ask the three-engagement question honestly: is anyone who works for you now fluent in both knowledges? If not, the engagement budget is training everyone except your company.
Related reading:
- Judgment Does Not Transfer
- Human Judgment Is the Scarce Layer
- Every Deployment Should Leave Product Behind
- The Deployment Teaches the Company What It Is
- Small Teams, Real Owners, Fast Executives
- The Forward Deployed Engineer: Mastering AI Deployment in the Real World
If your org chart has a hole where the deployments keep happening, renting better engineers will span it forever without closing it. If you want help designing the pier before the next engagement rents the bridge again, book a discovery call.
FAQ
Why does the FDE role exist?
Because org charts separate two knowledges that deployed systems require together: workflow knowledge lives in operations, undocumented and load-bearing, while system-building skill lives in engineering. The requirements handoff between them is a lossy compression of the real operation. The FDE sits on that dotted line, holding both knowledges at once, which is a rented bridge rather than a filled hole.
When should a company rent vendor FDEs versus build internal capability?
Rent for the first deployment or two: the domain is new, failure modes are unknown, and experienced outsiders are cheaper than your own mistakes. Grow internal capability once deployments become repeated strategy, because rental comprehension exports to the vendor with each engagement, and a permanent rental means the asset you need appreciates on someone else's balance sheet.
How do you grow internal FDE capability while using vendors?
Pair deliberately. Write named internal counterparts into every vendor engagement, with absorbing the walk-through, the design decisions, and the judgment calls as an explicit deliverable. The vendor still runs its own economics, but each engagement deposits people, and people are the only inventory of judgment a company holds.
Is the FDE just consulting with a better title?
Half right. The embedding, scoping, and vendor-side economics are consulting. The production engineering under real constraints, and the pairing of workflow and build knowledge in one head, are not, and classic consulting kept those apart deliberately. From the buyer's side the title matters less than the terms: with extraction and pairing clauses, the role is a capability investment. Without them, it is a very good consultant.