What FDE Actually Looks Like

The demo goes well. It usually does.

You show the product running on your own cloud. Clean logs, quick responses, a nice dashboard. The customer nods along, asks good questions, and says the sentence you are hoping for: "Okay, let's get this running in our environment." Everyone feels good.

Then you get access to their environment, and you realize their world looks nothing like yours.

Maybe their servers cannot reach the internet. Not slow internet. No internet. Maybe the cluster only pulls images from an internal registry, sitting behind a proxy that swaps out every certificate. Maybe the Kubernetes version is years old and nobody is going to upgrade it for you. The thing that worked perfectly in the demo does not start at all. Not a subtle bug. It just does not come up.

That gap, between the demo and the environment, is the whole job. If you want to understand what a forward deployed engineer actually does all day, that gap is the answer. Everything else is detail.

So what is a forward deployed engineer

The short version: a forward deployed engineer, or FDE, is an engineer who goes and makes the product actually work inside the customer's world, using the customer's constraints, next to the customer's people.

That sounds simple. It is not the same job as building the product, and it is not sales, though it sits between both. A product engineer owns the code. A sales engineer owns the pitch and the proof of concept. The FDE owns the part where a real customer, with real rules and real infrastructure, needs the thing to run and keep running. You are the person who has to make the promise come true.

A lot of this work right now is AI systems. The promise sounds like "your teams will have agents doing real work by next month." Getting from that sentence to agents that actually do the work, inside a company that will not let its data leave the building, is the part that takes real effort.

The sentence that gets people in trouble

"It works on my infrastructure."

I have said it. You have probably said it too. It is the honest truth in the moment, and it is almost useless.

It works on your infrastructure because your infrastructure was built by people who wanted your software to work. Latest versions. Open network. A GPU when you need one. Deploy whenever you like. The whole thing was set up, on purpose, to remove friction. Of course it works.

The customer's infrastructure was built by people who wanted something else entirely. They wanted to pass an audit. They wanted to survive a breach. They wanted one team to not be able to break another team's systems. Your software is a guest in a house that was designed around rules you were not in the room for. None of those rules are wrong. They are just not yours.

The wall

It helps to picture a wall. On one side is your cloud, where you control everything. On the other side is the customer environment, where you control almost nothing. The demo lives on the left. The job lives on the right.

Everything that made the demo easy is on the left, and none of it crosses to the right. The FDE works on the right, with what is actually there.

It is easy to treat the right side as the left side with a few annoyances. It is not. It is a different place with a different set of rules. Once you start treating it that way, the surprises mostly stop, and that is half the battle.

Turn the constraints on yourself

Here is a simple way to see it. Start from a build that works perfectly in your own cloud. Then turn on the things a real customer environment actually has, one at a time, and watch how much of your happy path is left standing.

Go ahead and click through them. Each one is a normal thing to run into.

The environment gap

Start from a build that works perfectly in your own cloud. Now turn on the things a real customer environment actually has, one at a time, and watch how much of the happy path is left.

Happy path that survives100%

This is the demo. Everything works because nothing is in the way yet.

The point is not that any single constraint is hard. Most of them are not. The point is that they stack. One or two, and you are fine. Turn on four or five, which is a completely normal enterprise, and you are no longer shipping the product you demoed. You are shipping a cousin of it that you are partly designing on the spot. The code was never the hard part. The environment was.

Where the time actually goes

It is easy to picture this role as writing clever code at a customer site. The reality is that writing the feature is the smallest slice of the week, by a lot.

A rough week as an FDEshare of the week

Not a real timesheet, but close to how these weeks tend to look. The dark bar is the part most people think the job is. Everything else is the job.

None of this is a complaint. But if you come into the role expecting to code all day and instead you get a two-week wait for a firewall rule and a daily call with a nervous security team, it is easy to feel let down for the wrong reasons. It helps to know that going in.

The waiting deserves its own mention. A lot of FDE time is not active work. It is blocked work. You need a port opened, or a service account, or someone to approve a change, and the person who can do it has forty other things and a process that takes two weeks. You end up keeping three things in flight at once, because at any moment two of them are stuck.

Building for a place you do not control

Once you have done a couple of these, you start writing software a little differently. Not because the old way was bad, but because it assumed a world the customer does not live in. A few habits start to make sense.

You make everything configurable, and you assume every default is wrong. Endpoints, timeouts, model names, batch sizes, the certificate path, whether telemetry is even allowed to leave. If it might be different at a customer, and it usually is, it goes in config. Hardcoding a URL feels fine right up until you are reading it out of a stack trace on a late call.

You write logs for a stranger, because the stranger is you. When something breaks inside a customer environment, you often cannot attach a debugger, cannot reproduce it at home, and cannot see their screen. The logs are all you get. So they have to say what the code was trying to do, not just that it failed. A log that says "connection refused" is useless. A log that says "could not reach the model endpoint at this address, using the proxy from this setting, after this many seconds" tells you exactly which wall you just hit.

You make the software degrade instead of die. No GPU? Fall back to a smaller model and say so clearly. Cannot reach a service? Retry, then run in a reduced mode, then tell someone. The worst outcome is not a feature being slow. The worst outcome is the whole thing falling over and the customer quietly deciding your product is fragile. You rarely get a second first impression inside a big company.

You also stop trusting "it should be fine." It is worth checking every assumption against their actual setup, on their actual versions, before promising a date. The demo cluster proves the code runs. It proves nothing about their cluster.

The part nobody warns you about

One thing that catches people off guard is that the hardest parts of the job are usually not technical.

You are in the customer's Slack now. You are in their time zone, or awake for it. You are in their meetings, including the ones about budgets and politics that have nothing to do with you, except that they decide whether your project lives. When something breaks, you are the face of your whole company to a room full of people who are stressed and want it fixed now. You cannot hide behind a ticket queue. It is just you.

That means a lot of the work is trust, and trust is slow. It is tempting to want to prove you are smart. What the customer actually wants is to believe you will not disappear, that you will tell them the truth when something is broken, and that you understand their constraints are real and not just you being blocked. Saying "you are right, that is a real problem, and here is what I am going to do about it" tends to go further than any clever fix.

You also learn to translate. The customer's security team is not being difficult for fun. They have been burned before, probably badly. When they say no to outbound internet, they are protecting themselves from a real thing that happened to someone like them. If you argue with the rule, you lose. If you understand why the rule exists and design around it, you win, and you often win a friend on their side who then helps you get everything else done.

What makes someone good at this

From what I can tell, the people who do this well are not usually the strongest coders in the room. They tend to share a few habits.

They stay calm when things break, and things break a lot. A calm engineer in a crisis is worth more than a brilliant one who panics. They are honest about what they do not know, which builds trust faster than pretending. They chase down the one person who can open the port instead of waiting to be handed it. And they care about the thing surviving after they leave. The person who writes the boring runbook is the one the customer remembers a year later, when it is still running.

If there is one trait that matters most, it is being comfortable with not being in control. If you need a clean environment, full access, and the freedom to do things your way, this role will wear you down. If you can walk into a messy place with half the doors locked and calmly find a way through, you will do well, and you will probably enjoy it.

If you are thinking about this kind of role

Go for it, but go in with your eyes open.

You will not code as much as you think. You will spend real time waiting, explaining, and negotiating. You will hit problems that have nothing to do with your software and everything to do with the place it has to run. You may sometimes be the only person from your company that a large, important customer really talks to, and that is a lot of trust to hold.

But you will also see your work actually land. Not in a demo, not in a staging environment that nobody uses, but inside a real company where people depend on it. There is a specific kind of satisfaction in watching a thing you fought to deploy quietly do its job in a place that fought you the whole way. It is harder than the version of engineering most people picture at first. It is also, on the good days, a lot more real.

"It works on my infrastructure" is where the easy part ends. Everything worth talking about happens after that sentence.

And all of that is before the thing you are deploying is an agentic system that does not give the same answer twice. Same wall, same locked doors, except now the software itself will not sit still. That is a whole other kind of hard, and it is what I want to write about next.

What FDE Actually Looks Like.