When Not to Hire Forward Deployed Engineers: The Honest Cases

Accenture is sending about a thousand forward deployed engineers into its Google business, and this week the first cohort got pointed at the federal government.

Larry Dignan reported it at Constellation Research on October 19. Accenture Federal Services and Google Public Sector are rolling out Gemini Launchpads, and the engineers come with it. Accenture Federal is training its first cohort of Google Cloud-skilled FDEs, drawn from the roughly 1,000 in Accenture's Gemini Enterprise Business Group. Ron Ash, who runs Accenture Federal Services, says they'll help "scale value" across government operations. Thomas Kurian's line is that Accenture engineers "work directly inside customer environments."

The next day Milos Mandic published a number at FDE Hub that he says he can't verify, and I believe anyway: around three in four teams calling themselves FDE teams are development shops. He got it from the teams he's talked to and worked alongside. Then he put it next to Gartner's forecast that fewer than one in five FDE engagements will turn customer needs into product, which implies a share a little above 80 percent, and said he wouldn't rely on either as a measurement. An analyst firm and a practitioner, a few points apart.

So the seat is spreading a thousand at a time, and most of the seats being created aren't the seat. That's the week for the part of this series I've been putting off.

This is part 11 of The FDE Transition. Part 10 was the buyer's contract. This one is for the person deciding whether to post the req at all, on either side of the table.

The short version

Don't hire forward deployed engineers unless there's a loop for the work to come back through, and you're willing to pay for it. The seat has one job: absorb what one customer needs, then make the product absorb it, so the next customer needs less of an engineer. If nothing in your company can take the work back, you're hiring custom developers at a premium. Five honest cases where you shouldn't post the req. Your product is opinionated and the work is implementation. Your deals can't carry the seat. Nobody in product will read what comes back. You're the buyer and the scope is already clear. And you're hiring the title because everyone else is, in a market with about 2,000 real ones and demand around four times that. In every case there's a cheaper hire that does the actual job. Name that job and hire for it.

The test comes first

Every part of this series rests on the same mechanism. The loop chapter describes it, part 3 wrote down the packet an FDE owes product, and part 7 put generalization rate on the scorecard. An FDE overfits on purpose for one customer, then someone with authority over the roadmap takes the reusable part and ships it to everyone. Hours per deployment fall. That's the whole business case. Without the second half, you have an engineer building custom software in someone else's building, which is a fine trade, and an old one, with a name and a price already.

Jesse Zhang at Decagon put the harsh version to Tom Dotan at Newcomer in August: embedding software engineers long term just means your software doesn't work. I don't fully agree, because the seat exists to find out what the software needs to do before it can do it. But he's right about the long term. Mandic says it from inside the seat: an FDE who can't leave isn't doing discovery, and a team billing month after month against the same account is a services firm.

So one question before the five cases. Who takes the work back, and what can they take it into? If you can't name the person and the surface, don't post the req.

Case one: the product is opinionated and the work is implementation

First Round Review ran a panel in February on exactly this. Shilpa Balaji ran FDE recruiting at Palantir, and her first question for a founder is "How opinionated are you about what your product should be in the future?" FDEs pay off when the product's shape is still open to discovery. "FDEs are for organic product growth." A SaaS product with a fixed vision and a tight customer profile gets less from the seat, because there's less for the field to find.

Tiffany Siu, First Round's head of talent and a former Palantir recruiter, had the sharper read on the founders who come asking. Most want a software engineer or a post-sales person. If success is measured in deals closed and demos run, "they probably want someone closer to sales, not an FDE."

I'd go further. If the work is onboarding, configuration, and integration against a product that already does what it does, you want implementation engineers, and you should be glad. They're cheaper and there are more of them. The FDE versus sales engineer chapter has the one-question test: does the job start when the contract is signed, or end there? Add a second: when the job's done, did the product change? If no, by design, the seat you're staffing isn't this one.

Case two: the deal can't carry the seat

James Honsa built legal engineering at Ironclad and co-founded Genera. His line on the same panel: "Forward deployed engineering is definitionally an upmarket motion." And the corollary: "You should not be doing this if you believe the end shape of your product is some sort of product-led growth freemium fit."

Frank Bien gave the arithmetic. At Looker, "We needed to be in the neighborhood of $25,000 a year per customer," and "by the time we had 2,000 customers, we could be doing $100 million dollars in ARR." A business shaped like that can't put an engineer in a customer's office for a quarter. So Looker didn't. It ran free trials with pre-sales implementation on the prospect's real data, the cheap cousin of the seat.

Gartner's number is the one to hold next to your contract value. Matt Ashare's report at Channel Dive has the firm estimating that "the bill for FDE consulting fees alone could top $200,000 quarterly" for one use case. The economics chapter ran the margin math. If the deployment can't produce expansion or a reusable product, the engineer is a cost of sale that never comes down, and that's a consultancy's P&L.

Case three: nobody in product will read what comes back

The quiet one, and I think the most common.

The company posts for FDEs. The engineers are good. They land deployments. And every packet they send back goes into a folder nobody owns, because product was never told it had a new input. The product changes chapter lists what has to exist before the first FDE lands: a configuration boundary, a sandbox, an eval harness the customer's cases can join, an observation record, and a feedback path with an owner. Most companies hiring the title this year have none of the five. They have a roadmap and a release train, and the engineer's deployment is a ticket in it.

Honsa saw it from the inside. He described work at Ironclad where "there was no clear path toward a software upside," and the panel's answer was managers who handle the scope creep. I'd put it earlier than the manager. If no PM is named as the reader of the handback, and no quarter has shipped a product change that started in a customer's building, the loop isn't slow. It doesn't exist. Hiring more engineers into the front of a loop with no back is how you get Mandic's three in four.

Case four: you're the buyer and the scope is already clear

Part 10 argued the buyer should contract for the loop, not just the exit. This is the step before: whether to buy the seat at all.

Gartner's advice to buyers, in the same Channel Dive piece, is more conservative than vendors would like. Customers who don't build their own engineering skills may pay "premium rates for work that, once the scope is clear," a traditional services or partner model "could potentially deliver more cost-effectively." Read the condition. Once the scope is clear. An FDE earns the premium on the problem you can't yet write down. After that, you're paying discovery prices for delivery.

So buy the seat for the workflow nobody can specify, with the month-two condition attached: a named person on your side who can change the customer layer when the engineer leaves. For the workflow you can specify, hire a partner or your own engineer and skip the premium. Praveen Jonnala's "backward-deployed domain experts" from part 10 is this case from the CIO's chair.

Case five: you're hiring the title because everyone else is

Here's the arithmetic the hiring plans leave out. Mukul Saha at Gartner counts about 2,000 active FDEs. "Demand is probably quadruple that, so there aren't enough engineering resources available." Against that: Microsoft's 6,000 engineers headed into the field, AWS's $1 billion unit, Accenture's thousand, and this week's federal cohort. DXC committed to training tens of thousands of Claude-certified FDEs and, per Raul Fernandez on the July earnings call, "had 86 on the books and was operating in 57 customer environments."

Nothing wrong with 86. It's an honest number. But if you're hiring 500 into the title this year, the question is who the other 414 are, and in most plans the answer is consultants with a new line on their profile. Saha's warning to product vendors is the one I'd pin above the headcount request: don't build "a large team of consultants sitting on the bench bleeding money." His advice is to train partners instead. Mine is narrower. Size the FDE team to the loop that can absorb its output. The org design chapter said plan to shrink. A team you can't shrink was never an FDE team.

The Accenture federal cohort may be fine, by the way. Dignan's report describes outcome-based agents built on Gemini and integrated into agency systems. That's deployment work, and deployment work is real. I'd only ask that it's priced and measured as deployment. The premium is for the loop.

What this means in the seat, and at the top

If you're the FDE: before you take the seat, ask who reads the handback and what shipped last quarter because of the field. A blank answer is a consultant's job at a consultant's retention.

If you run product: the FDE req on your desk is a claim that your product can absorb what the field finds. If the five changes don't exist, say so before the hire, not after the first packet lands.

If you run the company: the title is cheap and the seat is not. Name the job you actually have open. Implementation, sales engineering, your own AI engineer, or the loop. Then hire for that one.

One thing to try this week: before posting the FDE req, write three lines next to it. The PM who reads the handback. The last product change that started in a customer's building, with a date. The deal size the seat has to pay back. Any blank, post the other req. You'll save the premium, and you'll have told yourself which business you're in.

Sources: Larry Dignan, "Accenture Federal Services, Google Public Sector roll out Gemini Launchpads," Constellation Research (October 19, 2026), with Ron Ash and Thomas Kurian quoted · Milos Mandic, "The Move-Out Clause," FDE Hub (October 20, 2026) · First Round Staff, "So You Want to Hire a Forward Deployed Engineer: How to Know If You Need One and How to Get the Role Right," First Round Review (February 24, 2026), with Shilpa Balaji, Tiffany Siu, James Honsa, and Frank Bien quoted · Matt Ashare, "Are forward deployed engineers flirting with failure?", Channel Dive (September 30, 2026), with Mukul Saha and Raul Fernandez quoted · Mukul Saha, "Gartner Predicts 70% of Enterprises Will Abandon Agentic AI Built by Vendor Forward-Deployed Engineering by 2028," Gartner (September 29, 2026) · Tom Dotan, "Decagon Hit $100 Million Betting Against Forward Deployed Engineers," Newcomer (August 11, 2026), with Jesse Zhang quoted

Part of the running argument on AI Product Management: once building is cheap, the scarce work is deciding what gets built for everyone, and a forward deployed engineer with no one to decide that is a custom developer with a better title.

Related answer: When should a company not hire forward deployed engineers?