What does a Forward Deployed Engineer actually do?

People keep asking me what a forward deployed engineer actually does. The title is suddenly everywhere and the “roadmaps” online do not really tell the truth.

The tweets and roadmaps come in two shapes. One sells the role like a consultant for hire: an engineer billed by the hour, just seated closer to the customer. The other sells a roadmap to the title: learn this, build that, apply. Look at who wrote the roadmap, and it is usually someone who has never done the job.

Both are easy to sell. Hours are easy to price, and roadmaps are easy to follow. But both skip the one question the whole job hangs on: what does the customer actually pay you for?

The consultant is closer

Of the two, the consultant picture is closer to the truth. A lot of my week does look like consulting: I work with the client, learn their business, ask questions, and help them shape their own problem clearly, tied to an outcome that needs to move. There is far more to this job than code, and the consultant picture at least gets that much right.

But a consultant usually sells hours and advice. What the client does with the advice is the client’s problem. My job, though, does not end there. I work with the client the way I would work with my own team. I stay for the build, and I stay after it, because their outcome is mine too. The closest honest description I have found for being an FDE is engineering and customer success living in one person. And that combination changes what the customer is really paying for.

What you’re paid for

So what does the customer pay for? Not code. They could hire engineers for that. And not advice either; advice is cheaper than we are. They pay for a number to move. For example: support tickets closed faster on average, with much less human intervention. And that number is not handed to me on day one. Part of the job is figuring out which metric actually matters, setting a baseline for it, and then iterating until it moves consistently.

That changes how you carry your own work. A feature shipped is not the finish line, because nobody is paying for features. Outcomes are what matter, not your output. If the number does not move, the work did not happen, no matter how clean the code was. And every two weeks, someone on the client side looks at what they paid us and what moved, and decides whether we make sense.

I think about metrics more than I think about code. It is one of the differences from every engineering job I had before: I used to be responsible for whether the thing works. Now I am also responsible for whether it is worth it. And honestly, that is the fun part for me.

Questions before code

Finding that metric is also where an engagement really begins. A client brings us in for, say, three months, and the natural assumption is three months of building. But the first two to three weeks have no code in them at all. They are all discovery. I work with the client, understand their business constraints, and keep asking questions until the real problem has a clear shape: root cause, not symptoms.

The questions change with the client, though. For a fintech client, I would have to learn how shares get settled and what a stock registry is before I could ask anything useful. For a client digitizing their operations, the questions would be about workflows: where their records live, who touches them, and how to bring it all to one place. Same process, completely different homework.

Only after we align with the client on a constraint and how we will solve it does the familiar part start. Build, QA, staging, UAT, production. This is the part every engineer already knows. It is also the shortest stretch of the whole journey.

Also, I do not think one should hold all of that in their head; if you do, you become the bottleneck. So part of my job is also building the flow that holds it for me and the team: calls and notes get captured and digested on their own, and anything repeatable gets automated. If preparing a document takes me more than six hours, the bottleneck is me. The thinking should be the slow part, never the paperwork.

There is more to the job than this. I build a harness, a system of work that lets me move fast without losing quality. I work async with clients in other timezones. And what I learn on one project goes into our platform, so the next project starts further ahead.

If you still want the title

If you are chasing an FDE title, notice what the roadmaps will not tell you. The skills that carried me these six months are not on any of them. Asking questions until a vague complaint becomes a problem worth solving. Getting fluent in a business that is not yours, quickly. Owning a number you do not fully control, and iterating until it moves. Building the flow that keeps a dozen threads from drowning you. Every one of these can be practiced in your current job, in some shape.

There are other skills you will only pick up on the job. My mentor put it in one line: “Whatever you do, have fun. Everything else is a by-product. Do not chase titles.”