When you shouldn't use FDE

Here’s something you might not expect from someone at AWS: not every organization should bring in forward deployed engineers.

That’s not a knock on the model. It’s how the model works.

FDE is built for a specific situation: high-stakes, ambiguous problems where the right use cases aren’t known yet, and where speed of iteration matters more than certainty of spec. If you already know exactly what to build and just need hands, traditional delivery will serve you better and cost you less.

From three years of innovation-center engagements, the readiness signals are consistent:

• A business problem your leadership agrees on — not a technology looking for one.
• Capacity to make decisions in days. Embedded teams move at the speed of your slowest approver.
• Security, legal, and ops invited on day one, not discovered in week six.
• Willingness to let the way you work change. The gains live in the workflow redesign, not the tool adoption.

Miss those, and the world’s best engineers will sit in your building waiting for meetings.

The question that predicts success isn’t “should we bring in an FDE team?” It’s “what would we need to change to deserve one?”