The fastest-growing job in tech is mostly conversation

There is a job in tech growing faster than almost anything else right now, and the odd thing about it is what it asks people to do.

Postings for forward-deployed engineers rose more than 1,000% between January and August of this year compared with the same stretch last year, and more than 4,600% against 2023, according to Lightcast data reported by Fortune. The broader tech job market grew 13% over the same period.

The pay reflects the scarcity.

At some AI labs, individual forward-deployed postings run several times that.

What the job actually is

The model came from Palantir, which spent years taking strong engineers out of headquarters and placing them inside customer organisations — defence departments, manufacturers, national governments — to build things in the room with the people who would use them.

For a long time that looked like one company's idiosyncrasy. It now looks like the shape of an industry. Microsoft, Google, Meta, OpenAI, Anthropic and Nvidia are all hiring for versions of it, and the pattern has spread beyond engineering into product and architecture roles.

The reason is mundane. Companies have access to extremely capable models and cannot get them working inside their own businesses. The blockers are proprietary data, legacy systems, and workflows nobody has written down. None of that is solvable from a distance, because most of it is not documented anywhere — it lives in the heads of people who have been doing the job for eleven years.

So somebody has to go and ask them.

The part of the job description people skim

Read an actual forward-deployed listing and the day it describes is split down the middle.

One half is what you would expect: architecture, data at scale, building the thing. The other half is discussing the design with the customer's engineers, sitting with non-technical operators to work out what they actually do all day, presenting to executives, and setting direction while the requirements are still a fog.

Palantir's own framing is that the responsibilities resemble a startup CTO's. That is a flattering comparison and also a warning, because startup CTOs spend a great deal of their time talking to people who do not share their vocabulary.

Industry people describing what separates strong candidates land in the same place repeatedly. The technical fundamentals are table stakes. The differentiator is whether you can walk into an ambiguous situation, work out how a process really operates, and communicate with technical and non-technical stakeholders well enough to build something that produces a measurable result.

Why engineers are structurally unprepared

This is not a story about engineers being bad at talking. It is a story about what the last fifteen years optimised for.

Engineering careers have been steadily rebuilt around asynchronous written communication. Design docs. Pull request comments. Slack threads. RFCs. All of it valuable, all of it deliberate, and all of it practice at a different skill from sitting across a table from a sceptical logistics director who has forty minutes.

Remote work accelerated it.

Then there is the ladder itself. Promotion criteria at most companies measure scope, technical judgment, and influence — and influence, in practice, usually means influence over other engineers, in writing. Almost nobody is assessed on whether they can explain a tradeoff to a customer's CFO without losing them in the second sentence.

None of this was a mistake. It does mean the industry spent a decade producing close to the wrong preparation for the job it now wants to hire for.

What actually helps

The advice that circulates is to work on your soft skills, which is not advice. Concretely, this job seems to reward four specific things.

Explaining your work to someone outside it. Not simplifying — translating. The test is whether a smart person with no context can follow you and then ask a good question.

Asking rather than telling. Most of the job is uncovering a workflow nobody has documented, which is closer to the discovery calls salespeople run than to a design review. Engineers are generally much better at telling.

Handling interruption. Executives interrupt. They ask about slide nine while you are on slide three. Holding your thread through that is a skill, and rehearsing a talk end to end does not build it.

Saying "I don't know" well. In front of a customer the honest version buys credibility and the evasive version spends it. Most people get this wrong under pressure, because the instinct is to fill the gap.

Where to get the practice

That is the awkward part. The obvious answer is to learn on customers, which works and is expensive for everyone involved, including the customer.

The less obvious answer is that all four are rehearsable, and the real barrier is finding someone willing to be the difficult person on the other side of the table.

Vera is a phone call for that. You say who it should be — a sceptical operations director, an executive who interrupts, a customer engineer who thinks your design is wrong — and it holds the role while you practise. Uncomfortable in the way the real thing is, with nothing at stake.

If this is where your career is heading, the specific things worth running a few times are explaining a technical decision without a diagram, asking questions instead of pitching, and being interrupted mid-explanation by someone senior.

The technical half of this job you already know how to study for. The half that pays the premium is the other one.