So, I’m a Forward-Deployed Engineer

So it comes to this: after decades of working all over the field, from warehouses and factories to executive teams and boardrooms, while sneaking code in along the way, I’ve finally found out what I am.

Apparently, I’m a forward-deployed engineer. And I’ve been one for a while.

I like this title because it explains a combination of things that has always been annoyingly hard to put on a résumé. I can go into a messy operation, talk to the people actually doing the work, figure out what the real problem is, build something technical to fix it, measure whether it worked, and then explain the whole thing to senior management without making everyone sit through a 100-page deck.

These days, almost anyone can build software. Give someone Replit, Claude, ChatGPT, or whatever comes next and, with enough patience or stubborn persistence, they can produce an app. That’s great. But engineering is still something different.

An engineer has to think architecturally: define the problem by talking to the people facing it, understand their individual and organisational constraints, simplify the &%$* out of it, design a system, test it, and work out whether the thing actually solved anything. Unusually, I even have the credentials to back up the noun. I graduated from Monash with a Bachelor of Engineering with first-class honours.

But the vast majority of engineers would never be “forward deployed”. A smaller group are comfortable talking to customers and executives, so they become technical leads, solutions engineers, product managers, or engineering managers. A much smaller group can walk onto a factory floor, repair depot, warehouse, airport, customer-service centre, or rental lot and be taken seriously there too.

That’s the part I’ve been doing for years.

What is a forward-deployed engineer?

The shortest definition I can come up with is: a consultant who can code, or an engineer who can consult.

The role combines two skill sets that companies usually hire separately. Consulting teaches you to structure ugly, ambiguous problems and strip away unnecessary complexity. Engineering gives you the ability to build the solution instead of finishing with a recommendation and handing it to someone else.

Palantir, which pioneered the title, describes forward-deployed engineering as a commitment to the outcome. Its engineers embed with customers, learn the problem in context, and build past the normal boundaries of the product when that’s what the problem needs.

OpenAI describes its FDE team in similar terms: engineers own discovery, technical scoping, system design, building, and rollout, then feed what they learn back into the product and model roadmaps.

That’s a much better description of the work I’ve always liked than “operations”, “consulting”, “special projects”, or even “engineering” on its own.

Building software isn’t the same as solving the problem

It’s tempting to say that anyone can now be a full-stack engineer. You can pay a few dollars for an AI coding tool, type what you want, and eventually get a working application.

But engineering starts one step earlier: what should you build?

A classic example is the dashboard. Any half-decent tool can turn a database into charts. But what metric are you trying to move? Why does that metric matter? What behaviour changes it? Who can act on it? Half the time, you don’t need a dashboard at all. You need one number, a target, and a process for moving it.

Figuring that out usually requires being there. You watch the operation. You ask why someone is doing something. You notice the spreadsheet under the keyboard, the paper checklist taped to a wall, the unofficial WhatsApp group, the queue nobody measures, or the workaround everyone has accepted as normal.

An engineer sitting at headquarters can solve hard technical problems. Field problems are hard in another way: the requirements are incomplete, contradictory, political, human, and frequently not written down at all.

You also have to be credible with the people doing the work. You can’t be some person with a laptop interviewing them from the corner. Sometimes you need to process the queue, repair the scooter, move the cars, pack the boxes, take the customer complaint, or stand around long enough to see why the “official process” isn’t what happens.

The consulting part: brutal simplification

I started my career at Accenture and then Bain. I have plenty of complaints about management consulting, but one thing the big firms teach very well is how to reduce a complicated problem until there’s something you can actually act on.

That’s still embedded in how I work. What’s the question? What evidence would change the decision? What’s the smallest thing we can build or test? What result tells us whether to keep going?

I’m also sick of giant slide decks. If a project even needs a deck — and I try hard to avoid one — I usually want it under seven pages. A working system, a before-and-after metric, and a short explanation beat a hundred pages of recommendations.

This is partly why the FDE model is appearing everywhere in AI. AI makes building faster, so the bottleneck moves toward understanding the business problem, integrating messy systems, earning trust, and deciding what should happen in production. KPMG’s Justin Johnsen recently described the same shift: AI has moved more of his work from writing code toward gathering context, integrating systems, and working directly with clients.

“Forward-Deployed Engineers” in the wild

I went looking for current job ads because I wanted to see whether companies were using the title the way I was. They are. These were live or recently indexed on 22 September 2026.

• Forward Deployed Engineer III, Google Cloud, Applied AI — Google, Los Angeles. Google is hiring FDEs in Applied AI to work directly with customers on production AI systems. The LA role is based at its Playa Vista campus. Posted base salary: US$174,000–252,000.
• AI Forward Deployed Engineer — Regal, New York. Regal builds AI agents for enterprise customer interactions. Its FDE role sits with customers and engineering rather than as a conventional sales-engineering job. Posted base salary: US$135,000–180,000.
• Forward Deployed Software Engineer — Palantir, London. Palantir is the company most associated with the title. Its description says FDEs embed directly with customers and tackle their most important problems. Quote: “Forward Deployed Engineering is a radical commitment to the outcome.” Salary: not disclosed in the UK posting.
• Forward Deployed Engineer — OpenAI, London. OpenAI says FDEs own deployments from discovery through production and work alongside customer engineering and domain teams. Quote: “lead complex end-to-end deployments of frontier models in production”. Salary: not disclosed in the UK posting.
• Forward Deployed Engineer — Meticulous, London. Meticulous builds AI-era software testing systems and wants engineers who work directly with advanced customer teams. Posted base salary: £150,000–300,000, about US$201,000–401,000 at September 2026 exchange rates.
• Forward Deployed Engineer — Nash, Sydney or Melbourne. Nash builds AI-driven delivery infrastructure used by large retailers. Its description is almost comically close to what I mean: “hands-on engineering at the edge — not pre-sales, not implementation.” A current third-party listing gives an indicative range of US$90,000–140,000 for the Australian role.
• Forward Deployed Engineer — OpenAI, Sydney. The Sydney role owns technical delivery from prototypes to stable production, embeds with customers, and feeds field lessons back to product and research. Salary: not disclosed in the Australian posting.

The wording changes, but the pattern is extremely consistent: work beside the customer, understand an ambiguous problem, build the system, deploy it, measure whether anyone actually uses it, and carry the field feedback back into the product.

Examples of my work that suddenly make more sense

The “Dana Server” at Lyft

Back when I was a “Special Operations” manager at Lyft, my brief was basically to do whatever needed doing. One of my favourite problems was figuring out how to understand tens of thousands of in-person customer interactions across Lyft’s 200-plus physical sites.

The sites weren’t part of conventional customer service yet, and my team had no dedicated engineering resources other than yours truly. So I built an API gateway that processed transaction data from our queue-management system and stored it for analysis. It gave us a way to see what people were coming in for, how sites were performing, and where the operational problems were.

Years after I left, I heard that the “Dana Server” was still hanging around as one of those legacy systems engineers had to understand and integrate. It annoyed a lot of people off with how core it was and yet that it was built outside the core. I’m oddly proud of that. The glamorous definition of legacy software is: software that worked long enough to become somebody else’s problem.

DIY trading and prediction-market models

Like many people trying to work out how AI changes investing, I’ve built trading models for US equities and prediction markets. I particularly like doing this through MCP tools, so I can design and test models directly through Claude or ChatGPT, backtest them, and deploy the ones worth testing further to a production server.

The results were mixed, which is exactly why testing exists. I did end up with some longer-term theses around AI infrastructure that I still use in my own investing. I also built PaperTiger to make simulated prediction-market trading easier.

Backtesting AI security systems

I recently did consulting work for Calvis, an AI-driven physical-security company. They had a very AI-era problem: the team kept improving the prompts used by core services, but changing a production prompt raised an obvious question — what would this new version have done on all the shifts we’ve already seen?

I helped build a backtesting system that could take historical production data and run it through alternative prompt versions. Instead of changing the live system and hoping for the best, the team could ask, “What would have happened if the prompt had looked like this?” and compare the result before deployment.

DiscoHQ: running a business through AI

For years I’ve run my publishing business on an AI and MCP backbone. I have a cloud server connected to publishing systems and business data, and I manage a large part of the operation through ChatGPT: research, planning, content updates, media handling, scheduling, and execution.

I wrote a longer idiot’s guide to running a business with AI if you want the architecture rather than the career-label navel-gazing.

So, apparently this is my job

For most of my career, I struggled to give a clean answer to “what do you do?” Operations sounded too managerial. Consultant sounded like slides. Engineer sounded too far removed from the field. Product sounded too neat. Founder just means I have a bunch of my own problems I’m working on.

Forward-deployed engineer is the first title I’ve found that captures the whole loop: go to where the problem is, understand it, build something, put it into production, measure what changed, and explain the result to whoever needs to make the next decision.

It also describes where I think technical work is going. AI makes code cheaper and faster. That increases the value of knowing what to build, earning enough trust to deploy it in the real world, and being able to tell whether it worked.

So after years of being the operations person who coded, the consultant who built things, and the engineer who kept wandering onto factory floors, I’m happy to finally have a title for it.

If you want the more conventional version of my background, my résumé is here. You can also read why I went all in on AI, and my older thoughts about AI removing “middleware” jobs. Apparently I’ve been circling this idea for a while.