Forward Deployed Engineering: 6 Skills Big Tech Is Paying For

Most of the client products I've worked on had the same shape. One engineer, or a very small team, sits close to the client, learns how their business runs, builds the thing, ships it to production and stays around long enough to make sure it holds up. For years that was just called client work. This year it got a new name and a lot of money behind it.

Forward deployed engineering has become one of the most talked about roles in AI. This summer AWS announced a billion dollar unit of engineers who embed directly with customers, and Microsoft launched its own version soon after. The reasoning is simple. Plenty of companies have bought AI tools and run pilots, and far fewer have anything working in production. The bottleneck isn't the model. It's the work of fitting AI into real systems, real data and real teams, and that work needs someone in the room.

I don't think the job is new, but I do think it's often misunderstood. People describe it as a developer who can talk to customers, or a solutions architect who writes code. Both descriptions miss what the day actually looks like. These are the six skills that have mattered most in my own client work, roughly in the order I learned them.

1. The first week is spent on their systems, not yours. Every useful thing I've built for a client started with learning what they already had. On a legal billing platform, the value came from pulling activity out of the tools the firm already used every day: their practice management software, their email and their video calls. Nobody wanted a new place to log time. They wanted their existing work to turn into billable entries. On a healthcare product, the first real conversations were about privacy and security requirements, not features. Forward deployed engineers who arrive with a solution and look for a place to install it tend to build things people politely ignore.

2. You're selling while you build, whether you like it or not. Every demo is a sales conversation. Every tradeoff you explain either builds the client's confidence or erodes it. I've had to explain why the enterprise grade services that met every requirement on paper cost many times what the client could spend in a year, and why a cheaper route was the right call for an early product. That conversation had nothing to do with code and everything to do with whether the client trusted the next recommendation. Engineers who see communication as a distraction from the real work struggle in this role, because here the communication is part of the work.

3. Leave behind a system the client's team can run without you. The goal isn't to become indispensable. It's to hand over something that keeps working after you leave. For me that means automated deploys from day one, configuration and secrets stored encrypted rather than in someone's notes, monitoring that tells a person what broke and where, and a codebase that lives in the client's own repositories. AWS describes its new unit the same way: embed, deliver, then hand back a team that can operate on its own. If a client has to call you to restart something, the engagement isn't finished.

4. Own the incident, even when it isn't your code. On a real time multiplayer backend I worked on, the problems that mattered most rarely respected team boundaries. A presence bug might start in a network library, show up as a database issue and get reported as a frontend glitch. The engineers clients remember are the ones who follow a problem across those lines instead of proving it belongs to someone else. My rule is that if a system breaks at three in the morning, I want to know why, and I want to make sure it doesn't happen again. Clients rarely see the architecture. They always see how you handle the outage.

5. Range beats depth, up to a point. This is where I disagree with some of the hiring advice I see. A lot of teams still prefer narrow specialists because they feel safer. For embedded AI work, I'd take the engineer who can move from an interface to a backend service to cloud infrastructure in the same afternoon, because the client's problem doesn't arrive sorted by layer. On most of my projects I've owned the frontend, the APIs, the AI orchestration and the deployment pipeline at once. That said, range without any depth turns into shallow work. The engineers who do well here have one area they know deeply, in my case real time and distributed systems, and enough breadth to never be blocked by the rest.

6. Say no in the client's language. Scope pressure is constant when you sit close to a client, because the distance between an idea and a request is one conversation. Saying no on technical grounds rarely lands. Saying "we can add that, it moves launch by two weeks and adds a new compliance question" usually does. The skill is translating every request into time, cost and risk, then letting the client choose. Done well, it doesn't feel like refusing. It feels like helping them decide.

None of these skills are new, and that's the part I find encouraging. The companies spending billions on forward deployed engineering are paying for something good client engineers have always done: understanding the business first, communicating clearly, shipping to production and leaving things better than they found them.

If you're an engineer thinking about this role, look at your last project and ask which of these six you'd struggle to show evidence for. That's the one to work on next. If you're hiring, put a real client scenario in the interview instead of another algorithm puzzle. Ask the candidate how they'd explain a delay, hand over a system or trace an outage across teams. The answers will tell you more than any coding test.