The Forward Deployed Engineer, Chapter 13: When FDE Goes Wrong — Failure Modes and Lessons

This is Part 13 of a series walking through my book The Forward Deployed Engineer. In the previous chapter, we surveyed the new wave. This one closes Part IV with the inverse view — the six failure modes that kill FDE functions before they scale.

The two preceding chapters surveyed functions that, broadly, succeeded. Most don’t. Failure modes cluster, not because every function fails the same way, but because the role’s structural pressures — customer-facing, technically senior, politically exposed, economically ambiguous — produce a small number of recognizable break patterns. I’ve catalogued six. Each one is named in the book, each one has a remedy, and each one has an early-warning signal that, in my experience, founders consistently dismiss until it’s too late.

The most common is the consulting trap. The function starts shipping faster than the platform team can absorb the learnings, customer engagements pay well, and slowly the gravity of high-margin customer-specific work pulls the function out of orbit. Without anyone making an explicit decision, the function has drifted into being a high-end consulting business that happens to use software. The trap is gradual; the signal is unmistakable, if anyone is looking: a platform repo whose customer-specific code is growing faster than its general code. The intervention is unromantic. Enforce platform commits with the same seriousness as you enforce ship dates. Reject deployments whose patterns don’t graduate. Promote engineers whose work generalizes.

A close cousin is the snowflake-per-customer trap. Every customer gets a custom deployment, nothing generalizes, the platform team falls behind, and the unit economics quietly invert. The trap is harder to see from inside because each individual deployment feels well-built and the customers are usually happy. By the time the math becomes visible, the function is too entangled with its customer base to extract itself without breakage. The remedy is the same as for the consulting trap, applied earlier and more ruthlessly: every deployment has to leave a paveable pattern behind, or the deployment didn’t actually graduate.

Hero Engineers, Demo Debt, Sponsor Collapse, and Burnout

Two patterns common to early-stage functions deserve their own paragraph. The hero engineer is the indispensable individual who carries the function on personal heroics and undocumented practices. Founders love hero engineers because they ship; they only realize what the hero pattern cost them when the hero resigns. The fix is to refuse the pattern: pair every customer with two engineers, write down everything, and treat any single-FDE customer as an active risk to manage. The demo-debt spiral is the second early-stage pattern, in which the function ships demos that the production system can’t back up. Every subsequent engagement starts with a debt of expectations the platform can’t pay, and the team spends more energy reconciling demos than shipping the next deployment.

Two patterns affect mature functions in different ways. The sponsor collapse happens when the executive who bought the deployment leaves, gets reorganized, or loses political authority. The deployment, however technically successful, loses its champion. The chapter walks the soft-stack moves that limit the damage — cultivating two sponsors from the start, building bottom-up usage that survives the top-down change — and the realistic limits of what an FDE can do when their counterpart inside the customer organization disappears. The hardest version of this failure is when the new leader arrives with their own preferred vendor, and the chapter is honest about the fact that some of those engagements simply end.

The most damaging failure mode I’ve seen, and the one founders are slowest to recognize, is the burnout death spiral. High-stakes work, no off-ramp, no rotation discipline, no career ladder, and the most senior engineers leaving first. The cycle is recognizable and the four moves that break it are well-known — deliberate rotation, enforced downtime, peer support structures, and a real career ladder — but founders consistently underinvest in all four because they don’t see the cost until the senior IC departures start. By then the cycle is already three quarters old. The chapter closes on the cross-pattern early warning signs — rising customer-specific code, falling time-to-deploy for new customers, rising senior attrition, a thinning sponsor pipeline — that together signal something is wrong even when none of them alone is decisive. Tomorrow: where the function actually belongs, with the full operational detail.