Failure Modes and the Honest Case Against

The org-level trap that turns FDE teams into consulting shops, the misappropriation problem the role has on LinkedIn, and the personal-burnout dimension we deliberately won't fake.

The services-shop trap

The most credible org-level failure mode for FDE-heavy teams is what Peraspera Strategy calls the 'services shop' problem. Direct quote from their analysis: 'Bespoke solutions are artisanally built and rebuilt at multiple sites... Implementation backlog dwarfs platform backlog... you may be running a services shop.' Translated: when the FDE org grows faster than the platform org, and when patterns surfaced by FDEs aren't being absorbed back into the product, the company has quietly become a consulting business with a software veneer. The economics are different. Services scale linearly with people; products scale super-linearly. The early Palantir narrative was haunted by exactly this critique (see the recurring 'Palantir is consulting in a trench coat' refrain on Hacker News through the 2010s). Palantir's eventual answer was Foundry: a productized platform that absorbed the lessons of a decade of Delta engagements. Companies that don't have that loop, or that have it but don't enforce it, eventually face the question: are we a product company or a consulting company that ships code?

Why this matters to you, the engineer

If you join an FDE org that is silently becoming a services shop, three things happen. First, the work calcifies; you're rebuilding similar bespoke stacks for new customers rather than working on increasingly leveraged platform abstractions. Second, your comp ceiling is lower than it would be in the equivalent platform role at the same company, because services revenue compresses margins. Third, your career narrative gets harder to defend; 'I shipped one customer's bespoke implementation' has a different shape from 'I shipped a platform feature 500 customers use.' The mitigation is to ask, at interview time and during ramp, what the Dev/Delta ratio is and whether there's an explicit mechanism for FDE-surfaced patterns to become product. If the company can't answer either question, you're looking at a services-shop risk, regardless of how senior the leadership talks about 'platform.'

The misappropriation problem

A useful piece of context from Francisco Ferreira's widely-shared LinkedIn post ('I cringe every time I see forward deployed engineer'): much of what gets labeled 'FDE' in 2025-2026 hiring is not FDE work at all. Ferreira's framing, quoted directly: 'An FDE understands that mowing the grass is only the method, not the mission... If the instructions are wrong, a consultant follows them anyway. An FDE fixes them and brings back the learnings into your core product.' The 'cringe' in his post is at companies relabeling sales engineers, customer success engineers, or contract implementation work as 'FDE' because the title is trendy. This matters for two reasons. First, it dilutes the role; titles that mean everything mean nothing. Second, it traps individuals: someone who joins a 'forward deployed engineer' role that is actually a customer-success role does not develop FDE-shaped skills, but their resume now reads as if they did. Read job specs carefully. If the spec doesn't list customer-environment artifacts (MCP servers, sub-agents, agent skills, deployed services in the customer's infra) and doesn't reference patterns being absorbed back into a product, you may be looking at a relabeled role.

Personal burnout: a deliberately empty section

We deliberately won't write a long paragraph about FDE travel burnout, IC depth atrophy, or customer dependency, because our research could not find verified first-person accounts that survived adversarial review. The Peraspera framing of 'high attrition driven by burnout' was specifically refuted; the popular characterization of FDE work as 'physically and operationally grueling' was refuted as overstated. This doesn't mean the burnout is fictional; it means the public record is thin enough that we won't make confident claims. What we can say generally: any customer-facing role that requires multi-day onsite presence (which OpenAI's engagement model does) carries travel load; any role where you are the customer's primary technical contact creates dependency that constrains your ability to leave cleanly; any role that prioritizes breadth over depth means you accumulate context, not codebase mastery, which can feel different from traditional SWE growth. Whether any of these tips into 'burnout' for you depends on your tolerance. If someone hands you a confident burnout statistic about FDEs, ask where it's sourced; we tried, and it isn't.

Who should not become an FDE

The honest counter-recommendation is not 'don't take an FDE role,' it's 'don't take an FDE role if you want certain things.' If you want long, deep ownership of a single codebase over years, FDE is the wrong shape; the Dev side of the same org is closer. If you want a predictable weekly schedule that doesn't involve travel or live customer pressure, the role's onsite cadence is a recurring tax you'll resent. If you want unambiguous credit for your technical contributions to a product, FDE work often produces customer-specific artifacts that don't propagate back as visible features. If you want comp parity with platform engineers at the same level, that may or may not be true depending on the company and your ability to negotiate, and the public data isn't strong enough to predict. None of these are deal-breakers for everyone. They are the things people who should not take the role are sometimes only discovering after they've taken it.

Key takeaways

•Services-shop trap (verified, Peraspera): the most credible org-level failure mode. FDE teams that out-grow the platform org silently become consulting businesses.
•Ask interviewers about the Dev/Delta ratio and the explicit mechanism for FDE-surfaced patterns becoming product. No good answer = services-shop risk.
•Misappropriation problem (Ferreira): much of what's labeled 'FDE' in 2025-2026 isn't FDE work. Read specs for customer-environment artifacts and product-feedback loops.
•Personal burnout dimension is deliberately under-described here. The public record was too thin for confident claims; we won't fake it.
•Counter-recommendation: don't take the role if you want deep single-codebase ownership, predictable weekly schedules, unambiguous product credit, or pre-decided comp parity with platform engineers.

Exercise

Take the job spec for an FDE role you're considering. Check three things. (1) Does it list customer-environment artifacts (MCP servers, sub-agents, deployed services in customer infra) as deliverables? (2) Does it reference how patterns surface from engagements into the product backlog? (3) Does it ask about technical depth in the production stack, or only about communication/customer skills? A spec that fails all three is probably a relabeled role; a spec that passes all three is closer to the real thing.

Self-check

1.What's the services-shop trap, and what two interview questions test for it?
2.Quote Ferreira's distinction between an FDE and a consultant. Why does the 'mowing the grass' metaphor matter?
3.Why does this lesson deliberately not cite a burnout statistic for the FDE role?
4.Name three traits or wants that would make someone a bad fit for the role despite being a strong engineer.

Sources