What a forward deployed engineer actually does

A forward deployed engineer makes software work inside one customer's reality, then proves that it did. The reality includes their data, their systems, their politics and their deadlines. The title sounds military and the job descriptions sound like a list of everything. The core of the job is simpler than either.

The job in one sentence#

Software engineers make a system correct. Solutions engineers show a buyer that a product could fit. Consultants recommend what a client should do. An FDE does a bit of all three, but owns something none of them own: whether this customer actually gets the result, measured in their terms, and whether they would buy again.

That last column is what makes the role hard. "Done" is not a merge, a signature or a slide. It is a customer saying that the work changed something they care about. Everything else in this handbook is a way of getting to that sentence sooner and more often.

Two kinds of FDE#

The title covers two quite different jobs, and it pays to know which one you are applying for.

A product FDE works for a company with a platform and deploys it to customer after customer. Palantir made this model famous, and AI labs and many AI start-ups now run it. You become an expert in one platform and learn which ways of deploying it tend to work. Part of your value is what you report back: the product improves because you watched it struggle at real customers.

A services FDE works for a firm that builds whatever the client needs, with whatever tools fit. Each engagement is a new problem, often in a stack you haven't used before, so learning fast matters more than knowing any one product deeply.

Most of the work overlaps: discovery, scoping, building, proving value and landing the change. Preparation differs at the edges. For product roles, learn the company's platform and read everything it publishes about deployments. For services roles, practise ramping up fast on tools you have never seen, and get comfortable pricing your own work.

Who is around you#

You are rarely alone. On your side there is usually someone who owns the commercial relationship, a few engineers who build alongside you, and a platform or operations person who gets things into production. On the customer's side the cast is bigger and less organised.

• The sponsor holds the budget and the deadline, and has already told someone senior that this will work.
• The champion lives with the problem every day and wants it fixed more than anyone. They are your best source of facts.
• Gatekeepers in security, legal or IT can stop the project. They are often not invited to the first meeting, which is exactly why you must find them early.
• End users know the exceptions that nobody wrote down. If the tool adds steps to their day, they will route around it.

Your job is to turn many voices into one plan, and to make sure each of them hears the part of the plan that matters to them. Chapter 3 covers how to find these people and what to ask each of them.

Why the role exists now#

The FDE model is decades old, but AI products made it common, for a structural reason. A model is general. Its value to one company depends on that company's data, workflows, permissions and appetite for risk. None of that ships in the box. Someone has to wire the general capability into the particular business, and then show that the result is worth paying for.

Investors have described this as trading some gross margin for a moat. The engineering hours spent at each customer are expensive, but they produce deployments that are hard to rip out and product knowledge competitors do not have. That is why the role shows up at labs, at AI start-ups and inside large service firms at the same time.

The gap between a convincing demo and a system people rely on is where FDEs live.

What good looks like#

Good FDEs are recognisable less by their technical range than by a handful of habits that compound.

• They write things down fast. Notes from every customer conversation go out within a day, ending with decisions and owners.
• They show work on the customer's own data early. A rough result on real inputs beats a polished demo on sample files.
• They put a number on value. Hours saved, cost per case or error rate, measured against what the customer does today.
• They say what they will not build. A clear "not in this phase" protects the deadline more than overtime does.
• They argue for the customer inside their own company, and for their company's constraints inside the customer. Both sides should trust them.