What an FDE Is Not (A Rant in Six Parts)

I've been called a lot of things on client sites. Most of them were polite. A few were accurate. But none of them were quite right, because the role of a Forward Deployed Engineer sits in a weird blind spot in the organizational chart. You're not staff. You're not a vendor. You're not a consultant, exactly. You're something else — and that ambiguity makes you a target for misunderstanding.

Here are the six most common forward deployed engineer misconceptions I've encountered. If you're considering hiring an FDE, read this before you write the job description. If you're an FDE, print it and tape it to the break room fridge.

Not IT Support

The first week at a new client, someone will ask you to fix the printer. It happens every time. You wear a lanyard, you sit in the open office, and you look like you know how computers work. To a non-technical person, that makes you IT.

Here's the boundary: FDEs build software that solves business problems. They don't reset passwords. They don't debug the Wi-Fi. They don't figure out why Karen's Outlook calendar won't sync. Every hour spent on IT support is an hour stolen from the engagement's actual goal. More importantly, it erodes the FDE's standing. Once you're the printer guy, you're the printer guy forever. Nobody takes technical advice from the person who unjammed the copier.

The fix is simple and hard: say no politely, consistently, and early. The FDE's contract should explicitly exclude general IT support. The client sponsor should communicate this to the team before the FDE arrives. And the FDE should redirect requests with a standard line: I don't have admin rights on your systems, but I can build you a tool that reduces the tickets you file with IT. That reframes the value. It also happens to be true.

Not a Sales Engineer

Demos are fine. Building a working prototype that proves a concept is exactly what FDEs do best. But there's a bright line between demonstrating capability and carrying a quota. If your FDE has a sales target, they're not an FDE. They're a sales engineer with a better title.

The distinction matters because incentives diverge. A sales engineer's goal is to close the deal. An FDE's goal is to ship working software that survives the first month of real use. Those are not the same thing. The sales engineer can hand-wave the hard parts. The FDE has to live with them.

I've seen companies try to blur this line. They embed an engineer at a prospect's site, call it a pilot, and measure success by contract signature. That's not forward deployment; that's a long sales cycle with code. It wastes the engineer's time, sets false expectations with the client, and produces software that's optimized for the demo, not the operation.

Building credibility and closing deals are related, but they are not the same job. Keep them separate.

Not a Project Manager

Gantt charts are not the FDE's native language. Stakeholder update emails are overhead, not output. The FDE's job is to ship, not to coordinate. Yet embedded engineers get conscripted into coordination theater all the time.

It usually starts innocently. The client doesn't have a PM on the engagement, so someone asks the FDE to run the weekly standup. Then they're asked to update the project tracker. Then they're asked to schedule the review meeting. Six weeks in, the FDE is spending half their time on logistics and half their time coding at midnight. Nobody's happy.

FDEs can self-manage. They should know what they're building, why it matters, and when it's due. But they should not be the project's central nervous system. If the engagement needs a PM, hire one. If it doesn't, let the FDE work directly with users and skip the ritual.

Great FDE engagements have a single client sponsor who clears blockers and a single engineer who builds. That's it. Anything else is bureaucracy wearing a collaboration costume.

Not a Full-Time Employee

The engagement model is temporary, outcome-focused, and deliberately external. That's not a limitation. It's the whole point.

When an FDE becomes a full-time employee, the magic dies quickly. They learn the politics. They start attending the all-hands. They develop opinions about the break room coffee. And suddenly, they're not an outsider with fresh eyes. They're just another engineer with a desk and a 401k.

The external perspective is what makes FDEs valuable. They see the workflow gaps that insiders have normalized. They ask why do you do it this way without the social cost of being the new guy who doesn't get it. They can push back on bad ideas because their job isn't at stake.

Permanent embedding also blurs accountability. An employee can kick a problem down the road indefinitely. An FDE has a contract end date. That deadline creates urgency and forces prioritization. The best FDE engagements are explicitly temporary — three months, six months, one specific outcome. Then they end. If the client wants more, they re-engage. That's not instability; it's clarity.

Not a Cheap Developer

The day rate makes founders blink. A typical independent FDE runs between one-fifty and three-fifty per hour. A Palantir-level FDE costs more. If your primary goal is to minimize hourly cost, the FDE model is the wrong choice.

But cost and value are different currencies. An FDE ships in days what a traditional team ships in weeks because they're co-located with users, free from internal process, and focused on a single outcome. Say you need a workflow tool that saves twelve hours a week. An offshore team might quote twenty thousand dollars and deliver in three months. An FDE might quote thirty thousand and deliver in three weeks. The FDE costs more per hour but less per result — and the result arrives two and a half months sooner.

The math only works when speed and context are valued. If your organization measures success by headcount efficiency, FDEs look expensive. If you measure by time-to-value, they look like a bargain. The misunderstanding isn't about the rate; it's about the metric.

Not a Magic Wand

Some problems need policy, not code. Some orgs need a restructure, not a dashboard. Some processes need to die, not be automated. A good FDE knows the difference — and says so.

Perhaps the most dangerous forward deployed engineer misconceptions is that an embedded engineer can fix anything. They can't. If your sales team is underperforming because the compensation plan is misaligned, no CRM customization will help. If your warehouse is inefficient because the floor layout was designed by someone who never visited a warehouse, no scheduling algorithm will fix it. If two departments won't share data because of a political turf war, no API integration will bridge the gap.

Saying no to things that shouldn't be built is part of the FDE's job. That's harder than it sounds. Clients want solutions. Sponsors want progress. Users want their lives to be easier. Telling them that their problem is organizational, not technical, feels like admitting defeat. It's not. It's the most valuable thing an FDE can do.

Great FDEs are builders first. But they're also honest enough to stop building when the tool won't solve the real problem. That honesty is rare. It's also why clients keep rehiring the good ones.

If you want the full myth-busting treatment, read common FDE myths debunked. And if you're still figuring out what the role actually is, start with what is a forward deployed engineer.