What Separates The Best FDE Teams From The Rest?

Elton Chan is the Co-Founder of Second Talent, a solution that connects global tech leaders with AI-native engineering talent across Asia.

gettyI read a lot of job specs. We staff engineering teams across 10 Asian markets, so role descriptions land on my desk months before anyone writes an article about what they mean, and forward-deployed engineering is the one description I can’t stop noticing.

There’s a recent report that counted 5,426 FDE and FDE-adjacent roles across 1,311 employers. Only 923 carried the FDE title. So five out of six are hiring solutions engineers, implementation engineers, deployment engineers or just senior engineers with a customer-facing line buried in the fourth bullet.

My read is that the practice has gotten well ahead of the vocabulary. More companies are putting engineers close to customers, but they’re not all getting the same thing out of it.

That’s what I’ve become interested in. What separates the teams that get better with every deployment from the teams that simply get better at doing more deployments?

I liked the original argument for FDEs. Enterprise AI falls apart at the last mile, so you send engineers past the last mile. Cut the handoffs between sales, solutions and support. Get something usable into the customer’s hands in weeks rather than quarters.

That still works—that is, as far as it goes. But research covering 1,500 FDEs found the median one spends around 47% of their time working directly with customers, and I’d assume your competitor has people doing roughly the same—possibly under a different job title, with an identical calendar.

So when I hear “our engineers sit with your team” now, I don’t hear a reason to choose someone. I hear the price of entry. It gets you into the room, and I’m not sure it does much for you once you’re standing there.

Where I think the advantage has gone is downstream—into what a company does with everything those engineers pick up.

That makes the question less about what an FDE does in the room and more about what the company does with what it learns there.

In one, the deployment closes, there’s a handover and the engineer moves to the next account. The team gets better at delivery, but the learning largely stays with the people doing the work. When they leave, much of that learning leaves with them.

In the other, recurring customer problems make their way back into the product. Something built for one customer becomes a product capability. Over time, the product absorbs more of what the FDE team learns, so each subsequent deployment needs less custom engineering.

I can’t see anyone’s margin from where I sit. What I see is the hiring.

The first kind keeps coming back for roughly the same number of engineers for every new customer. The second asks for a lot of engineers early on, then comes back needing fewer. The hires get more senior, too. The work has moved from building things for customers to working out what should become part of the product.

I noticed that pattern before I understood it. It took me a while to realize I was watching two different bets on what the FDE team is for.

Nobody defaults to delivery because they haven’t thought about productizing the work.

Custom work is revenue you’ve already booked. Productizing it writes that revenue down in exchange for margin you might see a year out. Your delivery lead has a utilization number to hit. Your FDEs get promoted for shipping into named accounts, not for removing the reason to ship. And your customer, who is paying, wants their thing built now, not a generalized version of their thing built for somebody else later.

Nothing in that arrangement rewards the engineer who says we shouldn’t build this a fourth time. So they don’t say it. The pattern goes unrecorded, and the company keeps paying for the same discovery over and over.

Fix the comp plan and the calendar, and the behavior follows. That’s a cheaper fix than most strategy problems.

Log the problem, not the deliverable. After each deployment, write one sentence describing what the customer couldn’t do before you arrived. Keep it separate from the technical scope. Scopes almost never look alike across accounts. The problems underneath repeat constantly, and you’ll only notice the repetition if they’re written in language you can compare.

Use a rule of three. If you identify the same underlying problem in three deployments, it should go on the product road map—automatically. No business case, no escalation and no waiting for a VP to connect the dots: Make it mechanical so raising it doesn’t cost anyone political capital.

Put someone in charge of reducing billable work. If nobody owns the question of what should stop being custom, it lands fifth on everyone’s list and stays there. Judge that person on implementation days per deployment, trending down—not on utilization.

We take work we should have generalized. It happens a few times a year, usually because the account is strategic, the timing is bad or the quarter needs to land a certain way. I don’t expect that to stop entirely.

The direction is clear enough to plan around, though. Once every AI company can put a capable engineer in front of a customer, closeness to the problem can stop being the thing that separates you. What will be left is whether the next customer still has the problem.

Your FDE team is a delivery function or a research function. Most companies never actually pick between the two, then wonder why year three looks like year one with more headcount.​​​

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?