The reality of being a forward deployed engineer (FDE)

Estimated reading time: 9 minutes

Key takeaways:

• Understanding the client’s business makes the technology easier to implement.
• Effective forward deployed engineers (FDEs) know who to ask when a problem falls outside their own expertise.
• The role is moving from AI demos toward reliable production systems.

---

What skills does someone need to be successful as a forward deployed engineer (FDE)?

On the technical side, the role requires Python, structured query language (SQL), REST application programming interfaces (APIs), Docker, and agent frameworks such as LangGraph and n8n. At first glance, that makes it easy to think the role is primarily about having a broad technical skill set and being able to build whatever the customer needs.

However, there are other elements of the role that matter just as much: business communication, relationship building, requirements gathering, and understanding the industry you work in.

I know this because, until earlier this year, I was not an FDE.

Your existing skills may matter more than you think

I was a software development engineer in test (SDET) focused on data quality engineering. My title changed, but my core skills didn’t. What changed was the context in which I had to apply them.

I already knew how to scale processes through automation, understand the extract, transform, load (ETL) lifecycle, and break complex things down for non-technical people. Those skills became useful during the last customer onboarding for an automated process I had built.

A colleague was facing friction with change management, while the project timeline was tightening. Instead of trying to solve the problem entirely from the technical side, I asked a senior leader to join a client meeting so I could explain what we were asking the customer to do.

That was my first real client interaction.

At the time, I didn’t realize how much that experience would resemble the work I would eventually be doing as an FDE.

As customer demand for AI demos grew, my company formed an FDE team to understand customer requirements and build solutions for their use cases.

I wanted to build that skill set, so I started learning voice agents and frameworks such as LangGraph, n8n, and CrewAI. I participated in a hackathon at the Pittsburgh Tech Council, where I prototyped a way to give food trucks visibility without paying for placement on Google Maps. I later taught around 30 people at a Steel City AI workshop how to build a travel itinerary tool.

That was the technical side, but the role quickly taught me that becoming an FDE meant learning how to work through uncertainty, communicate with customers, and understand the business problem behind the technology.

You don’t need to know everything

When I first moved into the role, I thought I needed to know more before I could be useful.

Impostor syndrome was real. I had to unlearn the idea that not knowing something was something to feel guilty about. I also had to stop pretending I knew everything and become comfortable asking for help.

One of the clearest tests of that came during a migration when I was mapping the most complex section of the platform.

The client wanted to understand how it worked and asked for a product specialist to demo alongside me. During the conversation, the client asked how a specific feature would work for their use case. I didn’t know.

So I told them I didn’t know yet. I also explained that I was new to this, but I would find out and show them exactly how it would work. They were fine with that answer.

I spent the weekend watching product videos and getting context from the technical team. As I understood the business context, I could relate it back to the technology. During the demo, I broke everything down simply, answered follow-up questions, and learned more about the client’s business with minimal friction.

Understanding the business can matter more than knowing the technology

That experience changed how I thought about the skills required for the role.

The technology matters, but knowing the business matters more than I initially expected. Understanding the business makes it easier to implement the technology and enable the client because you can understand why something matters instead of simply understanding how it works.

I also had to unlearn my assumption that moving fast was the only way forward. I believed I shouldn’t make mistakes and that vulnerability was a bad thing.

Mistakes used to freak me out because I was afraid of being judged for them, but the people around me were supportive.

The hardest stretch came when we were trying to load a large volume of data into the client’s staging environment. It kept hitting resource limits, so I dug through logs and queues to understand why. 

Another time, I made a mistake in a test environment that needed another team’s help to recover. In both cases, we owned it and fixed it together.

The reality is that being an FDE doesn’t mean you stop making mistakes. It means you become responsible for finding them, communicating them, and working with the right people to fix them.

You don’t just build what the customer asks for

Before becoming an FDE, I automated things based on requirements someone else had interpreted from the client.

If those requirements were right, great. If they were wrong, there was no way for me to know.

As an FDE, I work across data ingestion, data validation, and reporting. One of the most interesting projects has been migrating a client’s data from a legacy system onto our platform when the source had no data dictionary.

I led the creation of a partial data dictionary mapping the client’s legacy system to ours. That meant profiling their legacy data and working out how the tables connect. A lot of it doesn’t connect.

That means the job isn’t simply taking a requirement and turning it into code. A major part of the work is understanding how the client expects data to show up on the platform compared with the reality of their own data.

The job is translating between the customer’s needs and the system

Requirements gathering has become a major part of my work. I help translate what the client wants, validate it with them, gather feedback, and determine whether a request is viable today or whether it requires a different approach.

Broadly, the role is about establishing trust and then finding a way to solve the use case, even when the solution is a big lift.

For example, one client wanted visibility into an area that wasn’t part of our standard offering. Instead of simply saying that we couldn’t do it, we found a way to give them what they needed. That is different from how I originally thought about engineering work.

The goal isn’t always to build the exact thing someone asks for. Sometimes the job is figuring out what they actually need and finding the best way to get there with the system you have.

You won’t just work with engineers

Before this role, I mostly worked with data engineering and customer success, with almost no customer contact. Now the scope is massive.

Each product suite has owners and subject matter experts, and I’m expected to know across all of them. I’ve learned that being effective doesn’t mean knowing everything. A lot of the job is knowing who to go to.

• When I need help with a complex demo, I work with the product specialist.
• When I’m mapping tables without a data dictionary, I work with a product subject matter expert.
• When something breaks in a test environment, I work with infrastructure and database reliability.

Some of those subject matter experts are in other time zones, so getting the right people together takes work. Sometimes that means late nights for everyone involved.

On the client side, I’m working with stakeholders, data owners, and business leaders. Internally, I’m working with engineers, account teams, and project managers.

You become the connective tissue

The role sits between a lot of different groups. You need enough technical knowledge to understand the system, enough business knowledge to understand the customer, and enough relationship-building ability to get the right people involved when something falls outside your own expertise.

The more I work in the role, the more I realize that being the person who knows exactly who to ask can be just as valuable as being the person who knows the answer.

The future of the role isn’t building AI agents

When I first started thinking about the FDE role, it was easy to associate it with building AI agents, demos, and new AI-powered workflows. However, my current migration doesn’t involve building agents at all.

The role is moving toward reliable production systems

Once the underlying data layer is solidified, then AI agents can reduce the operational burden. That is why I think the role is moving from demos toward reliable production systems, with more deterministic outcomes and less ambiguity.

That requires a deeper understanding of how systems interact, including the edge cases and the ability to move quickly when something breaks.

Our proofs of concept used a small sample to show how the platform displayed the data. That helps lock the requirements, but the scripting was built from a sample, and a sample can’t tell you whether something works for every record.

The customer validates their full dataset against the approved sample. The data is messy. Many free-text fields have been filled out over years in whatever way worked at the time.

We can cover as many cases as possible, but when new data comes through, we have to re-ingest it, push it to the platform, and see whether it displays as intended.

Then we validate it again.

The game is context

The other major change I’ve noticed is how much AI tools can help with context.

I’ve sat through dozens of hours of meetings, and tracking everything discussed over that amount of time is difficult. A field source might have been discussed weeks earlier, leaving me searching through handwritten notes.

I started using our company’s approved AI assistant to check my meeting notes for whether we had already covered something. We had.

Our internal knowledge base helps the same way: I can check whether a problem has already been solved before asking a colleague, which makes my questions better. But context cuts both ways.

When the AI assistant helped map tables without a data dictionary, it invented column names that didn’t exist. A product subject matter expert validated the mapping, and I added what I could infer from the data.

Another time, the AI assistant missed which columns a table needed and why. If I hadn’t reviewed the output, it would have broken something downstream. So I review everything AI writes and I keep giving it context about what I’m doing and why.

What I think an FDE actually needs to do

The biggest lesson for me is that being an FDE isn’t just about becoming a better engineer. It’s about becoming better at working across technology, people, business context, and ambiguity.

If you’re trying to become an FDE, pick a problem. Talk to the people who face it and understand their day-to-day workflow. Create a fix that doesn’t add another thing to their workflow. Break requirements into simple steps. Find gaps and edge cases customers may not see, and surface them early.

Most importantly, fit the technology to the problem, not the other way around.

Get articles like this in your inbox

Choose your LeadDev newsletters to subscribe to.