The requirements problem

Every major AI lab now hires forward deployed engineers. Most of them are optimizing for implementation speed when the actual bottleneck is upstream.

Leszek Bartkowski spent nearly a decade as a Palantir Technologies FDE. He knows what the job actually was, and why the new wave is missing the point.

The misconception: FDEs deploy software

The name says "deployment". That implies there's ready-to-deploy software and someone to install it.

Clients called Palantir because nothing else had worked. They couldn't articulate what the problem was – only that something was broken. The FDE's job started before a single line of code: figure out what's actually wrong.

Leszek flew to Trinidad to work with an oil company.

“They hoped for  dashboards and pipelines to uncover wisdoms lurking somewhere in data lakes, (hoping) that just need better data integration”.

On the ground, Leszek's team discovered the client needed modern causemap tooling for root cause analysis – a way to trace why something broke, not a dashboard confirming that it was broken.

That's the role. Not writing code. In Leszek’s own words:

“Ultimate goal was to discover what client business actually needs, not what it asks for. Very often those were completely different things.”

What were seeing

The diagnostic skill is the scarce one. AI has absorbed the implementation grunt work – the SQL pipelines, data wrangling, client-specific integrations that used to eat FDE hours. As Leszek puts it:

"AI absorbs the tedious parts of the FDE role and leaves the valuable ones intact."

What's left is the original value: knowing when the problem the client thinks they have isn't the problem they actually have. That's judgment, not engineering.

Client readiness determines everything. Leszek saw three types of engagements. Some clients had sharp engineers who understood their data and were excited to collaborate – those worked. Others had back-office teams running on institutional exhaustion. As he describes it:

"They didn't make much effort. When something broke, the reflex wasn't to fix it, but rather to find someone else to handle it."

No amount of engineering overcomes a client with no stake in the outcome.

Then there were the clients who were never buying. One government ran free Palantir pilots, learned what it could, and walked away to implement it themselves. They wanted a proof of concept to copy, not a product to pay for.

The lesson Palantir learned the hard way: not every engagement deserves to be saved. At one point, working with a major Swiss institution, the team negotiated an exit – handed over what worked and parted ways.

The new FDE wave is repeating old mistakes. AI labs are staffing FDEs to help enterprises integrate their APIs – the same pattern as cloud providers staffing "Customer Engineers" a decade ago, with the same failure mode. Most are hiring for technical implementation – the part AI itself can now handle. They're under-indexing on the hard part: diagnosing ambiguous problems, qualifying whether a client is ready, and knowing when to walk away.

What to do instead

Redesign the FDE role around diagnosis, not implementation. If AI handles the SQL and pipeline work, the FDE's value is entirely upstream: scoping the real problem, translating vague requirements into buildable specs, and distinguishing between clients who need your product and clients who need to fix something else first. Hire for that. Interview for pattern recognition and client judgment, not technical depth.

Clarify client qualifications. Palantir learned that some engagements are unwinnable. Before deploying an FDE: Does the client have internal ownership of the outcome? Can they articulate what success looks like, even roughly? Is there a decision-maker with authority and urgency? If the answers are no, your FDE will burn months diagnosing organizational dysfunction, not a technical problem. That work is closer to Partner responsibilities at the Big Four than engineering at a tech company.

As Leszek said himself:

“Project success often hinged on identifying a single empowered stakeholder with both the authority and the motivation. Without that person, the initiative typically unraveled.”

Separate the diagnostic from the build. The old FDE model bundled both because one person was all you had on-site. AI allows for a separation. The diagnostic phase – understanding what's broken and what to build – should be a distinct, time-boxed engagement. The implementation phase can now be heavily automated. Conflating them wastes your scarcest resource (judgment) on your cheapest task (code).

The diagnostic for leaders. Before staffing your next FDE: are you hiring someone to implement, or someone to figure out what to implement?