Why the best engineer might not be a forward deployed engineer

When companies look for a forward deployed engineer, they usually look for their strongest developer. We think that misses half the picture. AI is opening the role from two directions at once: engineers are moving toward the client, and product people are moving toward the code.

A forward deployed engineer (FDE), sometimes called a forward deployed software engineer, works directly with the client. They find out what the client needs, decide what is worth building, build it and own the outcome. Clients often tell us they don't know exactly what an FDE is, only that they no longer want to pay for a large team of developers. If you want the background first, we covered whether your project needs an FDE a few weeks ago.

This post is about who can grow into the role. It draws on a discussion from AI Engineer, our internal expert session where developers, tech leads and product owners compare how AI is changing their work. Several of them already work as FDEs.

What does a forward deployed engineer do?

For many developers, the FDE profile is arriving without anyone planning it. Marek Tučáni, a tech lead at Erste Digital, sees it in his team. Since AI made coding much faster, the question has become what else a web developer can take on. Some of his developers now help with mobile and backend work, write integration and mock tests, and analyse and prepare their own tasks. Piece by piece, their day starts to look like an FDE's.

Vladimír Hrušovský already works as one. He talks directly with the client on an integration, gathers what they need, proposes a solution and gets it built. Because implementation is fast, he often builds a first version and adjusts it based on feedback instead of debating every detail upfront. That freedom has a limit, though:

"I can't build it just for that one client. The platform serves other clients with similar workflows, so I always have to think about them too."

Speed is only part of the change. The center of the work moved. Writing code used to be the main job, and decisions arrived from someone else. Now the code comes quickly, and most of the day goes to talking with the client and owning the decisions that follow.

Can a product owner become a forward deployed engineer?

The sharpest question of the session came from Diana Krajčíriková, a Product Owner who already works as an FDE on several projects: does an FDE have to be an engineer at all? In her experience, the role absorbs most of what a product owner does today:

"The product owner role almost dissolves into it. The FDE talks to the client, goes through the requirements, plans them and builds them. It's one person who goes through the whole process end to end."

Stanislav Dvorščák, a CTO, reversed the usual direction. Instead of teaching an engineer product skills, why not let a product owner build engineering skills with AI? Maroš Pataky tested it with a thought experiment. Put a strong product owner with a well set up AI workflow next to a skilled coder who struggles with clients. On a typical business application, which product ends up better? His bet: the product owner, with someone technical setting up the AI at the start.

The reasoning holds up. A good PO spends their days understanding the client and knows how to shape a vague wish into something buildable. When the group imagined AI agents talking to clients directly, Diana named the catch:

"And what if the client doesn't even know what they want?"

Someone has to work that out with them, and that is where product people are strongest. They also look past the single request and ask how a change affects the rest of the product and its other users. This kind of FDE starts from knowing what is worth building, and now can build it too.

The engineers added a counterweight. Peter Lastovecký pointed out that someone still has to stand behind what the AI produces. Security and infrastructure costs don't explain themselves, and an agent will happily deploy the most expensive machines because everything technically works. A product person can start without deep technical knowledge, but has to build it over time or work closely with someone who has it.

What skills does a forward deployed engineer need?

When Diana asked who would rather not become an FDE, the answers were candid. The work isn't too hard. It asks for a mix of soft and hard skills that few people have at the start.

On the soft side, you have to be comfortable in front of a client. That means asking good questions, listening and setting expectations when the client disagrees. Marek admitted that many developers chose their path precisely to avoid client communication:

"You have to be a more extroverted type with good soft skills to handle that kind of communication with the outside world. You have to know how to ask and how to listen. Many engineers don't have that naturally."

That is a legitimate preference, and it doesn't make anyone a weaker engineer.

On the hard side, you need enough technical depth to judge what the AI gives you, plus real knowledge of the client's domain. Most people start with one and spend years building the other.

Then there is the load. Developers who already run two or three agents in parallel find the switching tiring, before a single client call is added. And as Marek described, expectations rise fast:

"As soon as they give you AI, they expect miracles overnight. Everything got easier, so why aren't you more productive? And they pile on more responsibilities."

Peter named what may be the most underrated FDE skill: knowing how much you can realistically deliver, and managing expectations instead of absorbing them.

The FDE path suits some people, not all. Many prefer a clearly defined role, and good teams still need them. Those who become FDEs usually grow into it gradually, rather than being told one morning that their job is now three jobs.

How FDEs manage the workload with AI agents

People already working this way agree on one point: a bigger role calls for different habits, not longer hours. Stanislav put it this way:

"If you try to keep up with every agent yourself, it doesn't scale. If you have your own orchestrator that you keep improving, it does."

The habits we see working in our teams:

1. Delegate, don't babysit. Work through one main agent that splits tasks and hands them to smaller agents. Only questions that truly need a person reach you. One colleague keeps a set of context files for her orchestrator, so it answers most of the workers' questions without her.
2. Manage project knowledge on purpose. Built-in AI memory sometimes picks up the wrong lessons and carries them into the next task. Several of us now keep project knowledge in written, versioned files and give each agent only what it needs. Slavomír Seman calls project knowledge the third pillar, next to tools and orchestration.
3. Make time for the domain. Stanislav blocks a fixed hour for learning the client's field and lets AI scan relevant sources daily and summarize what matters. Product people already have a head start here.
4. Set boundaries. An always-on agent can easily become an always-on job. Maroš is firm about it: nobody should get a notification at ten in the evening because an agent wants approval.

None of this is a finished playbook. Two people can use the same setup in very different ways, and what works on one project may not work on the next.

Why an FDE shouldn't work alone

The FDE is often pictured as a lone operator, and that worries clients as much as it worried us. What happens when that one person gets sick, goes on parental leave or leaves? And who do they talk a decision through with?

Maroš and a colleague showed one answer. They work toward a shared goal, each with their own agents, coordinated by one main agent that holds the plan. Their agents even pass messages to each other through Git. The technology turned out to be the easy part. Human decisions were the bottleneck: when a choice needs the other person and that person is offline, work waits. Maroš still wouldn't go back to working solo:

"Alone it would probably be faster, but worse."

This is also where engineers and product people complement each other. One person notices code quality or a security gap, another sees what the client will really do with the feature. Stanislav suggests that each person keeps their own AI review style, so those views show up side by side instead of being averaged away. The final decision still comes from a conversation between people.

What this means if you're looking for a forward deployed engineer

The first instinct is to look for the strongest engineer you can find. Our experience suggests a wider search.

The right person might be an engineer who enjoys sitting with clients. It might just as well be a product owner or PM who already understands your business better than anyone and can now build working software with AI. What matters is someone who understands the client and can judge the technical side well enough to own the result.

Be realistic about timing too. People grow into this role; you can't switch it on overnight. It needs room to build new habits and a team around the person, so nothing depends on a single individual.

At Hotovo, engineers and product owners already work this way, close to clients and building with AI every day. Every project teaches us something new about what makes the role work.

Curious how it could look on your project? Let's talk. We'll share what we've seen and listen to what you're facing.

FAQ

What is a forward deployed engineer? A forward deployed engineer (FDE) works directly with a client, works out what they need, builds the solution and owns the outcome. With AI speeding up implementation, most of the role now sits in client conversations and decisions.

Does a forward deployed engineer have to be a software engineer? Not necessarily. A product owner or PM with strong client skills can grow into the role using AI, as long as they build technical judgment over time or work closely with someone who has it.

How do you become a forward deployed engineer? Most people grow into it from one side. Engineers build client skills; product owners build technical judgment with AI, ideally with an engineer's support at the start.

What skills does an FDE need? Client skills on one side; on the other, enough technical depth to judge AI output and real knowledge of the client's domain. Few people start with all of it, so most grow into the role.

Is one FDE enough for a project? It can run with one FDE, but it shouldn't depend on one. Pairing FDEs, or backing one with a team, protects the project when someone is away and gives decisions a second view.