Forward Deployed Engineer is outsourcing with a better logo

Mykhailo — Fri, 14 Aug 2026 00:26:41 +0000

I spent more than five years in outsourcing companies. That is where I started my career.

The job looked like this: get assigned to a client, learn their infrastructure, fight their legacy systems, sit in calls with people who could not describe what they wanted, ship something that worked, move to the next client. Sometimes I was on their VPN more than my own employer's. Sometimes I knew their systems better than their own staff did.

Now the same job has a new name and a salary that can be twice as high. It is called Forward Deployed Engineer.

Where the name came from

The term belongs to Palantir. The earliest published use I could find is a TechCrunch piece from June 2010 about a funding round, which identifies one of their employees by the title forward deployed engineer.

The name is borrowed from the military, where a forward deployed unit sits in the field instead of at home base. That is the whole idea. Palantir was selling data integration software to intelligence and defense customers who could not describe what they needed, partly because the requirements were classified and partly because nobody had written them down. Shipping the software did not work. So they shipped engineers, cleared and embedded on site, writing production code inside the customer's environment for months at a time.

Internally Palantir called them Deltas, a name they explain in their own post on Dev versus Delta. According to The Pragmatic Engineer, the company had more FDEs than regular software engineers until roughly 2016. That is a striking ratio for a company that sells a product. There is also a day in the life of an FDE from 2022 if you want their version of the job.

So the name is about fifteen years old, and the current wave of AI companies hiring FDEs did not invent anything. They picked up a label that already had a decade of history and a good story attached to it.

The job description is identical

Read what an FDE is supposed to do. Integrate a vendor's product with the client's messy data. Build custom pipelines and workflows on top of it. Sit with non-technical stakeholders and translate business pain into technical requirements. Feed real-world edge cases back to the product team.

Now read what I did in outsourcing. Integrate whatever the client bought with whatever the client already had. Build custom pipelines on top of it. Sit with non-technical stakeholders and translate business pain into technical requirements. File bugs and feature requests upstream when the vendor's product could not do the thing the client paid for.

I cannot find the daily difference. Same messy enterprise APIs. Same undocumented internal system that one person understands and that person is on vacation. Same client stakeholder who changes the requirement after the sprint started. Same travel, same context switching, same burnout curve.

What actually differs

Two business models, one job description.

An outsourcing agency sells hours. The unit of revenue is a person occupying a seat for a month. If a client cuts ten engineers, the agency loses ten engineers of revenue. Every engineer is a line item, and line items get negotiated down. That is why the rate is what it is, and it is why the agency's incentive is to keep bodies billable rather than to make any single engineer irreplaceable.

A product vendor sells licenses. The unit of revenue is an annual contract with a margin an agency will never see. The engineer they send into the client is not the product. The engineer is what makes the contract renew. One person who unblocks a stuck rollout can be the reason a seven-figure renewal happens instead of a churn. That is a very different number to justify a salary against.

If you want the numbers, levels.fyi has them. Palantir's forward deployed software engineer sits around $211K median. An EPAM engineer in the US is $165K. Accenture is closer to $109K. The frontier labs pay far more than any of them, but they pay everyone far more, so that gap is the company and not the title.

The lock-in argument does not hold up

The usual defense is that outsourcing and FDE work create different kinds of dependency. Outsourcing locks the client into people who understand the custom code. FDE work locks the client into the vendor's platform.

Both are lock-in. I have watched both happen. I have written the pipeline that nobody else could maintain, and I have also been the one who inherited someone else's version of it three years later and needed two weeks just to draw the diagram.

The distinction people draw is real but small. It describes who captures the value, not what the engineer does with their day. An engineer wiring a client's legacy database into a vendor's domain model is doing the same work whether the invoice says time and materials or annual license.

What I would actually tell someone trying to make the jump

If you are in outsourcing and you want the FDE title and the FDE compensation, the honest advice is to stop optimizing your engineering and start optimizing three other things.

Learn one product deeply instead of ten stacks shallowly. Outsourcing rewards breadth. You get thrown at whatever the next contract needs, and after five years you have touched a dozen stacks and mastered none of them. Product companies hire for the opposite. They want someone who knows their platform's data model well enough to argue with the core team about it. Pick a platform, go deep, get certified if the vendor offers it, build something real on it in public.

Get comfortable being wrong in front of executives. In outsourcing my escalation path was almost always internal. There was an account manager and a delivery lead between me and anyone who owned a budget. FDE work removes those layers. You are in the room where the customer decides whether to keep paying, and you have to say "that integration will take three weeks and here is why" to someone who wanted to hear one week.

Go find out what they are actually hiring for. Change your LinkedIn title to Forward Deployed Engineer and start reading the job posts. Scrape them if you want, there is nothing hidden here. A few dozen descriptions will tell you what the requirements really are, and once you line them up against your own CV the gaps are obvious. Then build a plan to close them.

What you will notice is that almost every one of these roles is at a product company. So you need a product mindset. Not just "solve the client's problem", but understand why the company put you at this particular client, what that account means to them, and what happens if it goes badly.

None of this is about writing better code. If you are already the person the client asks for by name, you have the engineering part.

The part I am not sure about

I do not know how durable the FDE label is. Roles that exist to make a specific product land tend to get squeezed when the product gets easier to deploy, or when the vendor decides the work belongs to a partner network. That is more or less what happened to a lot of specialist consulting niches over the last decade.

I also do not know whether the pay gap survives the title becoming common. Right now it is scarce enough that the compensation reflects the revenue it protects. In five years there may be a lot of people with FDE on their profile, and the salary may look a lot more like a senior engineer's, and the same people who chased the title will be looking for the next one.

I did this job for five years before it had the good name. Nobody called it strategic then, and I still cannot tell whether they were wrong about the work or just early on the pricing.

Originally published on yetmike.com.

Podman Lost to Docker. I Stopped Fighting It.

Mykhailo — Mon, 27 Apr 2026 20:18:32 +0000

Most "Podman vs Docker" articles treat it as a technical comparison. It isn't. It's a migration cost problem.

The technical case for Podman is real: rootless by default (not opt-in like Docker's 20.10 mode), no dockerd running as root, no $9–15/user/month for Docker Desktop, and Quadlet (5.0, 2025) for native systemd integration. These are genuine architectural wins.

But Stack Overflow's 2025 survey shows Docker at 71.1% adoption — the largest single-year jump of any technology. Podman at 11.1%. Docker Hub: 318 billion pulls. Podman Desktop: 3 million total downloads since launch.

That's not a competitor. That's a niche.

The question that actually matters

Not "which is better?" but "what context are you in?"

Starting fresh — use Podman if it fits. On RHEL, it's the obvious choice: Red Hat ships it by default, Quadlet integrates directly with systemd, rootless-by-default matters when someone audits your runtime. The CNCF accepted it into sandbox in January 2025. Greenfield project, no legacy tooling — go for it.

Migrating an existing Docker setup — think twice. This is where the calculation breaks down. The spreadsheet shows Docker Desktop at $9–15/user/month. It doesn't show:

Migration day
Debugging socket path differences (Podman uses a different socket location than Docker)
Updating CI pipelines built around Docker socket compatibility
Fixing Dev Containers when VS Code stops finding the right runtime
The 30-minute Podman explanation for every new hire who's never heard of it

These are real hours from real people. None of them ship anything a user will ever see.

Why Docker won anyway

Not on merit. On surface area.

GitHub Actions assumes Docker. Rancher Desktop defaults to Docker. MCP server configs reference Docker. Every Stack Overflow answer assumes Docker. Every internal platform template your company has written assumes Docker.

When you switch, you're not just swapping a binary. You're swimming against the accumulated inertia of every tool your team uses daily. Podman's remaining real advantages — daemonless architecture, rootless-by-default, Quadlet — are genuinely better. They're also genuinely invisible to 90% of the people making the decision.

I wrote about the full trade-off breakdown, including where each argument actually landed and what Docker did and didn't fix, in the original post on yetmike.com.

The short version: run the numbers with migration costs included. Then decide.

Originally published on yetmike.com

DEV Community: Mykhailo