the cause behind the roles · endgame engineering

The new roles are bottlenecks with job titles.

When AI commoditizes the labor, a job title stops naming the labor and starts naming the boundary it dissolves. Every hot role that’s crystallized in the last few years maps to a specific cell of the bottleneck taxonomy — and where a cell is expensive and durable but still unnamed, the taxonomy predicts the role before the market does.

By · V-Squared AI

See the mapping The diagnostic: the Taxonomy ↗
Emerging roles mapped onto the bottleneck taxonomy grid, showing coverage gradient F1 Don't understand F2 Can't work with F3 Can't align G1 Technologists G2 C-level G3 Business units G4 Customers G5 Marketplace FDE PM frontier high coverage (FDE) one seam (PM / translator) — — the G2 executive cells: priced, but no clean title yet

These roles aren’t emerging because the technical work got harder. They’re emerging because AI collapsed the cost of the technical work — and when the doing gets cheap, the scarce value moves to the boundary-crossing.

Every one of these titles is the market pricing a specific bottleneck cell. The technical skill is table stakes; the bottleneck it removes is the job. That’s a testable claim, and it runs both directions. It explains the roles that have already crystallized — every one maps to a hot, persistent cell — and it predicts where the next ones appear: wherever a bottleneck cell is both expensive and durable, a role will form to remove it.

When AI commoditizes the labor, a job title stops naming the labor and starts naming the boundary it dissolves.
role → cell

Every hot title maps to a cell.

Notation is (Group, Failure): who the model is about, and how it fails. G1 technologists · G2 C-level · G3 business units · G4 customers.

◆

Forward Deployed Engineer

The cleanest example — it removes the customer–technologist bottleneck at all three failure levels at once. The FDE embeds inside the customer’s organization, and the first thing they build isn’t code; it’s a customer-specific ontology, grounding the system in the customer’s own nouns and verbs. That’s the modeling cell. Because they’re embedded rather than handing a spec over a wall, the model never gets stuck — translation removed by presence. Because they ship and stay accountable for production code, the build aligns to the model. Then they route what they learn back to the platform: MAIT’s Improve→Transform loop wearing a job title. The tell that this is bottleneck-removal and not engineering: OpenAI created the role to fix a specific gap — customers stuck bridging trial to production — and the honest analysis says the models aren’t the problem, the deployment is.

Prices: (G4,F1) + (G4,F2) + (G4/G1,F3)

 bottleneck-removal role
◆

The builder & the AI Product Manager

Marc Andreessen’s “builder” merges product manager, designer, and engineer into one person — and the reason given is explicitly the elimination of the communication bottleneck between those three functions. That’s a pure translation play inside the product org. The AI Product Manager is described in the same language: a “translator” coordinating engineers, designers, and legal, sitting on the seam between what the model can do and what actually ships.

Prices: (G1,F2) + (G4,F2)

 bottleneck-removal role
◆

The Analytics Translator

McKinsey’s analytics translator bridges data science and the business. Practitioners are candid that it’s a skill set rather than a job title — which is exactly what you’d predict for a role that is nothing but bottleneck-removal with no technical deliverable of its own. It exists to move a model across the line to the group that owns the decision.

Prices: (G1,F2) + (G3,F2)

 bottleneck-removal role
◆

Design Engineers & Product Engineers

The builder’s narrower cousins. They remove the design-to-engineering translation tax — the friction where an intent understood by one function fails to survive the handoff to the next. A single, expensive seam, closed.

Prices: (G1,F2) internal seam

 bottleneck-removal role
◆

Solutions & Deployment Engineers

The FDE’s lighter-weight relatives — customer-embedded, but a step down in coverage precisely because they don’t own production code. They clear the customer translation cell but leave customer alignment partly open. That gap is the point: the gradient of coverage is itself a taxonomy prediction.

Prices: (G4,F2) · (G4,F3) partly open

 bottleneck-removal role
the coverage gradient

The more cells a role closes, the more it’s worth — and the harder it is to hire.

That gradient is itself a prediction of the taxonomy. Coverage isn’t a résumé line; it’s the number of gates a role opens between capability and outcome.

wide coverage → scarce

The Forward Deployed Engineer spans a whole block — model, translate, and align the customer, plus the technology alignment behind it. That’s why its compensation runs where it does.

a single seam → common

The AI PM, the analytics translator, and the design engineer each sit on one translation seam. Valuable, learnable, and more plentiful — one gate, not a block.

partial coverage → the tell

The solutions engineer clears customer translation but leaves customer alignment open, because they don’t own production code. The open cell is exactly where the value leaks.

The frontier: the roles the taxonomy says are coming

The executive cells — how a specific executive decides, and getting the model across the line to them — are the obvious next frontier. The “AI translator to the C-suite” doesn’t have a clean title yet, but the taxonomy says it’s coming, because the cell is both expensive and durable. When a bottleneck is priced but unnamed, a role is forming to remove it.

the general case

The market is reinventing the capability set, one job posting at a time.

Each Valley role special-cases the same map. The outcomes engineer is the general case — and its six capabilities are how you build the removal skills for whichever cell you target.

See the six capabilities Diagnose the bottleneck ↗