Interest in forward-deployed engineers, or FDEs, has surged in recent months as companies try to get real value from AI. The term may be a buzzword for a service that consulting firms and technology providers have offered for years: embedding engineers at a a client's company, inside its systems and data, to build software alongside the people who will use it.
As the AI era gets underway, companies are finding that off-the-shelf AI tools often don’t fit their specific needs. Getting real value from them means adapting tools to a specific business problem and helping teams change how they work. An FDE does both, which is why this form of collaboration seems particularly well suited for business today.
In this video Explainer, McKinsey’s Holger Hürtgen, Martin Harrysson, and Nick Robson set out what an FDE does and how AI has changed the job. The three agree that FDEs can help companies derive value from AI by tailoring it to a company’s specific problems; their views on the separation between an FDE and a traditional consultant suggest the role is still evolving.
These interviews have been edited for length and clarity.
What is a forward-deployed engineer?
Holger Hürtgen: First and foremost, it’s an engineer, so you basically do data science, data engineering, software engineering. You work with data, you work with technology. The forward-deployed part is the interesting part to me personally, meaning you work directly on client systems. You don’t work in a lab. You work with the real problem.
Martin Harrysson: It’s someone at a company whose main task is to make the technology work, solve a problem, and reach the outcome we’re trying to achieve. So, as opposed to a standard engineer who might be working on a product and to make the technology work, a forward-deployed engineer is not primarily about making the solution just run; it’s about reaching the right people to do the job, and in a different way, to reach some kind of outcome. I think the forward-deployed part probably comes from its military meaning. But it’s more that they’re embedded in the company.
Nick Robson: To me, a forward-deployed engineer is someone who is able to not just apply software fit to a business problem or fit into a company’s current business process. Rather, it’s someone who can work hand in hand with clients to figure out how to change their business process, along with software, technology, and tools, to create a whole new way of working. It’s a unique skill set that requires a ton of creativity and a pretty generalist tool kit.
How is an FDE different from a consultant?
Martin Harrysson: The traditional meaning of a consultant was probably more incentivized around a recommendation, say, or coming up with a plan for action. For instance, here’s a recommendation; this is the direction we’re going to go. Whereas a forward-deployed engineer is much more about implementing some technology that changes how you do work and has a more direct impact on a particular workflow.
Holger Hürtgen: A difference between a forward-deployed engineer and a consultant is that as an engineer, you have to work in the system of a client and develop a product, so you leave behind the product. A difference between an FDE and a software developer is that a developer has predefined the product they will build. A forward-deployed engineer, like a consultant, needs to understand the problem and discuss with clients what the solution should look like.
Nick Robson: The roles are merging a lot more nowadays, with the forward-deployed engineer and consultant roles kind of becoming one. You can’t just go in, deliver insights, and walk away. You have to work with clients, dissect a business problem, figure out who the right people are to work with, drive the technology, and rewire processes. I don’t think about it as two roles. I think a really good consultant makes a really good forward-deployed engineer.
Why are we hearing more about FDEs right now?
Holger Hürtgen: I’ve been doing this job for 20 years, and I would admit that the FDE terminology itself is maybe a bit of a buzzword. The concept, however, is more relevant than ever because the new LLMs [large language models] themselves are not sufficient. It’s about tailoring them to the problem at hand and making sure you get the business impact out of it. Otherwise, you’re just implementing AI for the sake of AI. You will see token spend going up, but you won’t see any bottom-line impact. This is why FDEs really solving the problem is so important.
Nick Robson: I think people are talking about it more than ever, and the demand for [McKinsey’s AI arm] QuantumBlack is higher than ever. It is the longest wait list I’ve ever seen for that kind of talent, and part of it is because clients are really seeing its value. We’re able to truly meet clients where they are. And the benefits of adoption and the client experience are astronomical. Three years ago, everybody was just installing enterprise-wide AI platforms. But they then realized they weren’t getting value from them, and people weren’t using them. So today, my clients realize that if we can rewire an entire domain end to end and fully reimagine a business process, that will drive adoption.
Looking for direct answers to other complex questions?
Martin Harrysson: The core problem of trying to get technology to do something useful, productive, and good for a company or for one of our clients is not new. What is new is that AI has amplified a lot of these problems. We have more technology tools to solve more problems, but they don’t come ready and packaged. Clients will roll out a new AI tool and hope that the impact will just happen, and that’s just not the case. This is where the leap from individual impact to team impact to organization-wide impact is not automatically happening because you need to collaborate. Just because I can do one part of the problem faster doesn’t mean we have figured out how to run meetings more effectively or how to communicate faster.
How has AI changed the job of an FDE?
Holger Hürtgen: AI is changing the job on two fronts. One is the way you develop software, by using agentic AI and agentic engineering to code. It’s less coding than I did 20 years ago; AI does it for you. You need to think more about the specifications, or what you want AI to do. The other part is that the end product itself is becoming AI. So you are building agentic AI systems and not just machine learning systems like we did a couple of years ago.
Nick Robson: Before, we would staff a team of many computer engineers or data scientists, but with the technology we have today, with AI, analytics, and software engineering, that’s all really becoming democratized. Today, the business analysts at QuantumBlack are acting almost like managers for AI. The manager that we had two years ago is now acting like a director and working across a team of people running their own teams.
Martin Harrysson: AI has changed what deploying technology looks like, to some extent. Previously, it was about deploying more prepackaged software at a client and maybe customizing it a little bit, or configuring it in certain ways. AI is a little different because, in some ways, it is a general-purpose tool. But you have to put a few things together. You usually need a model, but you also need a data layer and some understanding of the organization. You need to build in a harness to make sure it behaves in the way you expect. And you usually need to change the workflows and have people do something different to get the full value out of it.
What does an FDE do in the first few weeks of a job?
Martin Harrysson: A typical first week or initial phase of a forward-deployed engineer’s work usually involves sitting next to people performing a task. Say we have a team working on supply chain planning. They get a bunch of data, already have a system in place, and are making decisions about whether to reroute ships or trucks to make sure the right things show up in their warehouse. What a forward-deployed engineer does is insert themselves in that team, try to understand who makes decisions, what makes a difference, and what data matters. Just really immerse themselves in understanding how this works, because a lot of those things may not always be documented very well.
Holger Hürtgen: It’s difficult to describe a typical FDE job, because it really depends on the type of project. What’s always the same is that it starts with defining a problem—what do we want to solve—and finding the data. This means identifying the core systems in client environments where data sits and then determining how to take it out of those systems and put it into, for example, cloud infrastructure. That’s more the data engineering part. At some point, you then also add software engineering components or front-end engineering components, because you eventually want to build a real tool. Then there are iterations, because you continuously have to demo what you build to the client, get feedback, and possibly start over from scratch.
Nick Robson: The job is more focused on the business problem. How do we scope this? How do we know what will drive business impact? FDEs spend much of their early work time scoping problems, dissecting the actual business itself, spending time with folks, figuring out where the value is, et cetera.
What problems do FDEs solve?
Nick Robson: One of my clients is an industrials player that makes complex products with a specialized supply chain. Due to geopolitical circumstances, they are experiencing a demand ramp-up for their products that is many times what they’ve delivered before. They needed something made exactly for their supply chains that could drive visibility into whether they have the right parts at the right time, provide the sequence in which to action things, drive accountability, and perform complex analytics. We were challenged on Tuesday to create this capability, and we got it working on Thursday. This tool that we built in basically a day and a half is something that in the past has taken hundreds of people many years to build.
Holger Hürtgen: FDEs have to be able to make judgment calls. Consultants may identify a problem and define what the best solution should look like. But as an FDE, you should decide what the best methodology is. What’s fit for purpose? Is gen AI the best tool? Is agentic AI? Or is it machine learning? Or is it a very simple regression? It doesn’t matter how advanced the tool is if it has an impact.
The focus now is on agentic AI systems. For instance, we all know how annoying it can be to interact with a call center. We basically “agentified” the call center of a utility, and it was quite interesting solving that problem to make sure that the agents would always have the proper answer, that they wouldn't hallucinate, and that customers would really like it. It was a real call center that you could call, and agents would support your journey through that call center.
Why is changing how people work so difficult?
Martin Harrysson: Often, ironically, one can say that the more difficult part is the human aspect of it. People are not always open to change or to new things. This is sometimes even trickier than getting the actual technology to work.
I think an interesting example of this came from a client recently, as we’re transforming how they develop software and use more agents. One of the most experienced software developers at this client went through agentic training and then went back to his job. He started using agents, but they didn’t work. Because he was a really experienced and qualified engineer, he put the agentic part aside. He fired up the IDE [integrated development environment] and fixed the code. But the agentic part of it went sideways. The next time, he might not even try to do the work using AI and agents. Sometimes, if you have people who are really good at what they do, it almost becomes harder to make that change.
Holger Hürtgen: You have to solve the problem with real data in real systems and make sure people who are supposed to use it like the solution and do use it. This is the only way to get the business impact.
Nick Robson: We had a client who was against agentic engineering or agentic coding. He explicitly told us, “I don’t really trust this stuff. I don’t like AI.” We spent an hour and a half teaching him some of the fundamentals of AI and how to apply it to a specific problem that he needed to solve in the next 24 hours. The next week, he came in and said, “I’ve used all my tokens.” He asked us to teach his entire team how to use AI and become their own forward-deployed engineers.
What kind of person is good at this job?
Holger Hürtgen: If you are, like me, an extrovert nerd, if you like teaching people, if you like not only the machine room but also talking to human beings, I think that’s the perfect profile for an FDE. It’s the perfect combination of coding in the machine room, explaining to people what you did, collecting feedback, and doing it again. That’s the beauty of the job.
Martin Harrysson: You need to be something of a multisport athlete or someone who is bilingual or trilingual. What I mean is, it’s not necessarily about multiple languages; you just need to be technical enough. You need to be an engineer, to some extent, in the sense that you understand how a technical system works. But if you’re only technical and you can’t extract how decisions are being made, and all the informal connections that are happening, to solve a problem for a client, you won’t be very good at solving the problem. That requires a lot more interpersonal experience: being able to communicate well, ask the right questions, and empathize.
Nick Robson: I think it’s a combination of a few different things. One is actual content knowledge and content expertise. The second is good people skills. Delivering business impact, consulting—it’s all a people sport. The last is being good with technology, yes, but the more important skill is the ability to learn quickly. I think the best FDEs are the ones who can be super creative or think outside the box for something that has never been created before. And a big part of the job is inspiring clients.
