Jeff Christian has been placing executives for decades and said in July he had never seen enterprises hire in the middle of summer. His firm, Christian & Timbers, had just put numbers on the forward deployed engineer market for TechCrunch: about 17,000 FDEs in the US, roughly 2,000 of them able to deliver measurable ROI, demand projected up 2,100% by year end, and the share of companies planning to hire FDEs up from 5 to 10 percent in January to 70 percent by the second quarter. Large consulting firms were increasing their FDE needs tenfold. Enterprises were standing up internal teams of 20 to 100.
Everyone read that as a talent story. Two thousand people, everyone wants them, pay goes up, the end.
I read it as a product story. Because 15,000 engineers did not get worse at their jobs this year. The job changed underneath them, and the product most of them are deploying was never built for the job they are now being asked to do.
This is part 2 of The FDE Transition. Part 1 is the thesis: the FDE is the Product Builder arriving from the services side. This part is about the shortage everyone is talking about, and why the fix is not in recruiting.
The short version
Two jobs are hiding under one title. Chris Taylor, who runs Ode with Anthropic, drew the line in the same TechCrunch piece: many FDEs can help you roll Claude Code out to your workforce, very few can build your flagship AI product feature. The first job is deployment and most of the 17,000 can do it. The second is product, and it needs four things the engineer does not carry in: a harness they can change on site without a redeploy, an eval the customer's cases can join, a handback path with a product owner on the other end, and a sales motion that sells scope instead of magic. Give a competent engineer those four and they deliver ROI. Take them away from one of the 2,000 and you get forks and a resignation. The shortage is real. Its cause is the operating model around the seat, and that is a product leader's problem to fix, not a recruiter's.
Two jobs, one title
Read Taylor's line again, because it is the most useful sentence anyone has said about this role all year.
Rolling out Claude Code to a workforce is real work. It is integration, enablement, permissions, and patience. It is also bounded: the product exists, the FDE makes it land. I would put most of the 17,000 in this bucket and I would not call any of them a disappointment.
Building the flagship AI feature for a customer is a different job. Nobody knows what the feature is yet. The FDE has to find the workflow nobody documented, decide what correct means for this customer, get the model to do it, prove that it did, and then hand the whole thing back to a company that has to decide whether it becomes the product. That is not deployment. That is the Product Builder job with a visitor badge, and the 2,000 are the people who figured out how to do it inside products that mostly fight them.
The mistake the market is making is hiring for the second job and equipping for the first.
What the 15,000 are missing, and it is not skill
I have run product orgs on the receiving end of deployment feedback, and the pattern is consistent enough that I will state it as a rule. An FDE's effectiveness is mostly a property of the product, not of the person.
Four things decide it.
A harness the FDE can change on site. If the behavior of the product lives in code, every customer-specific fix is a pull request, a review, a release train, and a wait. The FDE learns to work around the product instead of through it, which is how you end up with a bespoke fork per customer and a company that is secretly a consultancy. If behavior lives in editable context, prompts, rules, and evals, the fix ships the afternoon it is found. What has to change in the product before FDEs can work walks through this in detail, and none of it is exotic. It is the same harness argument the whole industry has been circling since Salesforce named it.
An eval the customer's cases can join. Without one, the FDE is doing error analysis by hand at the customer's desk and calling it done when the customer stops complaining. With one, the customer's ugly cases become rows, the fix is a score that moved, and the next FDE at the next customer inherits the work. The eval is the spec applies to deployed work more than anywhere else, because the deployed work is where the real inputs are.
A handback path. This is the one product leaders skip, and it is the one that makes the difference between an FDE org that compounds and one that just bills. Somebody on the product side has to own the question "what did we learn at this customer that generalizes?" and have the authority to put it on the roadmap. Without that person, every FDE insight dies in a Slack channel. The deployment-to-product loop is how the work becomes roadmap, and it needs a name on the product side, not a process.
A sales motion that sells scope. If what was promised in the room was "it does everything," the FDE walks into a customer who is already disappointed and spends the first month resetting expectations instead of shipping. FDE versus sales engineer covers the boundary. The short form: sales owns the promise, the FDE owns the outcome, and the two have to be written down before the contract is signed or the FDE will be paying for the gap in nights and weekends.
Give a solid mid-market engineer those four things and they deliver ROI. Take one of them away from one of the 2,000 and you get a fork, a burned-out engineer, and eventually a resignation letter addressed to a frontier lab, where at least the comp covers the friction.
What this means if you are building the team
If you are standing up 20 to 100 FDEs, you are about to enter a bidding war for the 2,000 against Anthropic and OpenAI, whose comp for the role tops out around a million dollars at staff level. You will lose most of those bids and you should not want to win them, because a great FDE inside a product with no harness is an expensive way to produce forks.
The alternative is to make the 15,000 effective. Fund the harness and the eval before the headcount. Put a product owner on the handback path and give them roadmap authority, not a suggestion box. Rewrite what sales is allowed to promise, in writing, with the FDE lead's signature on it. Then hire for judgment and customer accountability, which are trainable in people who have shipped anything real, rather than for a resume line that says Palantir. Building the FDE team has the reporting line, the bar, and the pairing model.
Do that and your team of forty ordinary engineers outperforms a competitor's team of eight stars. The stars are scarce. The operating model is not.
What this means if you are in the seat
Your effectiveness is mostly not about you, and you should interview employers on that basis. Three questions, asked plainly: how does a prompt change reach a customer's production, and how long does it take? Is there an eval I can add the customer's cases to? Who on the product team owns what I learn, and what happened to the last three things an FDE brought back?
Good answers mean you will become one of the 2,000 there, because the product will let you. Vague answers mean you will spend the year writing forks and reading about the FDE shortage on LinkedIn while being one of its causes.
Where this series goes from here
Two parts a week, each written against that week's findings, because this role is being defined in public right now and a series written in advance would be wrong by October.
Next: the handback. What an FDE hands to product, when, and in what form, and what product owes back. After that, the codebase contract with engineering, who owns the promise with sales, month two with customer success, the FDE scorecard, the career path out of the seat, comp and the equity problem, buying from an FDE company, and the case for not hiring FDEs at all. The full sequence and reading order live on the series page, and every part links to the rest.
One thing to try this week: ask your last three FDE hires how many days it takes to get a prompt change into a customer's production. If the answer is not "today," you are not short on FDEs. You are short on the product that lets them work.
Sources: Rebecca Bellan, "Forward-deployed engineers are the AI industry's latest talent obsession," TechCrunch (July 30, 2026), reporting the Christian & Timbers study with Jeff Christian and Chris Taylor quoted · Oluwadamilola Oshungboye, "Why OpenAI and Anthropic are hiring forward deployed engineer teams," The New Stack (May 28, 2026) · Perspective AI, 2026 Forward Deployed Engineering Compensation Report (May 21, 2026)
Part of the running argument on AI Product Management: the role that owns the outcome is the role that needs the product built for it.
Related answer: Why is there a shortage of forward deployed engineers?
Frequently asked
What did the Christian & Timbers FDE study find?+
Per TechCrunch's July 30, 2026 report by Rebecca Bellan, the executive search firm found roughly 17,000 forward deployed engineers in the US market, of whom about 2,000 can deliver measurable ROI. It projected demand rising 2,100% by year end, said the share of companies planning FDE hires went from 5 to 10 percent at the start of the year to 70 percent by the second quarter, and described large consulting firms increasing their FDE headcount needs tenfold, with internal teams of 20 to 100 being built. Founder Jeff Christian said enterprises were hiring in the middle of summer at a speed he had never seen.
Why call the FDE shortage a product problem rather than a talent problem?+
Because the 15,000 who are not in the elite group are mostly not failing at deployment. They are being asked to build flagship product features inside products that cannot absorb on-site changes. Chris Taylor of Ode with Anthropic drew the line: many FDEs can roll Claude Code out to a workforce, few can build the flagship feature. The second job needs a harness the FDE can change without a redeploy, an eval the customer's cases can join, a handback path into product, and a sales motion that sells scope. Those are product decisions, and they decide whether a competent engineer delivers ROI or burns out.
What are the four things a product has to give an FDE?+
A harness where behavior lives in editable context, prompts, and rules rather than in code, so a fix ships the day it is found. An eval set that accepts the customer's real cases, so done means the score moved. A handback path with a product owner who decides what generalizes from a deployment into the roadmap. And a sales team that sells a bounded scope, so the FDE arrives to a customer whose expectations match the product. The handbook chapter on product changes for FDEs covers each in depth.
What does this mean for a leader building an FDE team of 20 to 100?+
Hiring the 2,000 is a bidding war you will mostly lose to frontier labs. The alternative is to make the 15,000 effective by changing the product they deploy: fund the harness and the eval before the headcount, put a product owner on the handback path, and rewrite what sales is allowed to promise. Then hire for judgment and customer accountability, which is trainable, rather than for a resume that says Palantir.
What does it mean for someone in the FDE seat?+
Your effectiveness is mostly a property of the product, not of you, and you should evaluate employers on that basis. Ask in the interview how a prompt change reaches a customer's production, whether there is an eval you can add cases to, and who on the product team owns what you learn. An employer with good answers is where a competent FDE becomes one of the 2,000. One without them will have you writing forks.
What is The FDE Transition series?+
A twice-weekly series on falkster.com for forward deployed engineers and the leaders building around them. Part 1 is the thesis that the FDE is the Product Builder arriving from services. The parts that follow cover the operating model: the handback to product, the codebase contract with engineering, who owns the promise with sales, month two with customer success, metrics, career, comp, and when not to hire FDEs at all. Each part is written against that week's findings, and every part links to the rest.
Comments (0)
Sign in with LinkedIn to leave a comment.
Sign in with LinkedIn