Forward Deployed Engineers — fewer middlemen, faster turnaround, same team

1. The cost of translation

A warehouse supervisor at one of our customers describes a workflow her team needs in plain operational language. She explains it the way she explains it to her own deputies — with the right concrete examples, in the right order, at the right level of detail for someone who lives in that operation.

That description doesn't travel intact. It gets summarised by a customer success manager into something shorter for the implementation consultant, who re-summarises it into something else for the engineer who will write the code. By the time the spec hits the engineer, the warehouse supervisor would no longer recognise her own problem in it.

The engineer ships what the spec says. The spec is wrong in ways the engineer cannot diagnose because the engineer never saw the original problem. The customer pushes back. We rework. The next change request inherits the same lossy chain.

Multiply that across hundreds of customers and the aggregate cost of translation becomes a line item large enough to be worth designing around. The most expensive thing in enterprise software isn't building the wrong feature. It's building the right feature against the wrong problem statement.

2. Why HR makes this worse, not better

In most enterprise software domains the end user is one kind of person. In HR, it's every kind of person. The same HRMS serves a finance manager booking annual leave from a laptop, a warehouse supervisor approving attendance from a phone in a noisy shop floor, and a delivery rider clocking in from a vehicle between drops. Their friction points share almost nothing.

A customer success manager fielding feedback from all three flattens it. The synthesis sounds reasonable on a call recording — “we need better mobile ergonomics”— and useless in the code. Mobile ergonomics for a delivery rider clocking in at 5am is a different design problem from mobile ergonomics for a warehouse supervisor approving twelve regularisations at noon, which is a different design problem again from a finance manager who only ever opens the mobile app to approve someone else's leave on weekends.

An engineer who has seen each context first-hand — literally seen the warehouse floor, sat in the delivery rider's vehicle, watched the finance manager hesitate — builds something different from an engineer reading a synthesised spec.

3. Two terms, one move

The role we're building has a name that already exists. Palantir popularised Forward Deployed Engineerover a decade ago. OpenAI has been hiring under the same title for the last two years. Several tier-one companies are running variants of the same idea in 2026. The term is recognised, searchable, and culturally established — which is precisely why we're using it.

We are not copying Palantir's implementation. Palantir's FDEs work on bespoke government and defence problems where each customer has fundamentally unique requirements. HR SaaS isn't that. Customers' problems overlap heavily; the patterns across them are the real product. What we're adopting is the principle — put the engineer in the room where the problem lives — not the operating model.

The article that explains the principle does the rest of the work. We don't have to justify the role category from first principles; the category exists. We have to make the HR-specific adaptation legible.

4. The eight we picked, and the domains

Eight engineers out of a 40+ engineering organisation — roughly 20% — have moved into the program. We chose eight, not four and not sixteen, for a specific reason. Four would have left gaps in domain coverage; sixteen would have stretched the mentorship bandwidth past breaking. Eight is the size where every HR functional area has a directly-named owner who can carry that domain end-to-end into a customer conversation.

The domain split:

• UI / UX. Owns the conversational and screen-level surfaces; bridges the Zero UI execution layer to whatever interface a given customer's users actually use.
• Security · end-to-end. Tenant isolation, role-based authorisation, audit surface, encryption at rest and in flight. The single accountable engineer when a customer's CISO asks a hard question.
• Infrastructure · end-to-end. Multi-region deployment, capacity, performance, observability. The engineer who can answer why was the system slow yesterday afternoon without escalating.
• Payroll · end-to-end. The continuous-state Zero Touch Payroll engine, the Intelligent Payslip layer, statutory configuration across 25 countries. The most domain-loaded slot on the team.
• Talent management. Performance, learning, succession, recruitment pipelines. The engineer who understands the HR-strategy side of the product, not just the workflow side.
• Leave & time management. Attendance, leave, shift rosters, overtime, compensatory off. The domain where blue-collar workflows live or die.
• Integrations & connectors. The MCP server topology, the NiFi-based ingestion plane, the connector library, the GraphQL operations catalogue. The engineer customers reach for when HONO has to talk to a payroll provider, a biometric device, or a Workday tenant.
• AI-native & automations. The agentic AI patterns — the seven-stage pipeline pattern shipping across three domains, dual-model routing, classifier stacking, prompt and tool-use architecture. This FDE is the one who deploys the agentic pattern into a new customer domain when one is needed.

Each engineer owns their domain across every customer engagement they touch. A customer's payroll question goes to the payroll FDE regardless of which country, which industry, which size — because the payroll FDE is the one who built the engine and has seen it land at every other customer.

5. What an FDE actually does

The engagement model isn't a Slack handoff. It isn't a once-a-quarter customer visit. It's operational.

• On-site visits when the work calls for it. Walking the warehouse floor. Sitting next to the payroll clerk during a run. Watching the actual interaction the product is supposed to support.
• Daily or alternate-day callswith the customer during active builds. Not a status update — a working session with the person who'll use what's being built.
• Weekly reviewswith the customer's decision-makers. Demos against the original problem statement, not against the spec.
• Monthly state-of-things discussionson the broader trajectory — what the FDE is seeing about the customer's evolving needs, what HONO is shipping that the customer should pull in, where the friction is.

The transformation isn't developer → consultant. It's developer → a hybrid role that holds engineering depth, functional consulting instinct, and customer-success ownership in the same person.The engineer doesn't stop being an engineer. They stop being only an engineer.

6. The three-month formation arc

The program is bounded as a three-month transformation, not an open-ended title change.

• Month 1 — Foundation.Understand the landscape. Build the core. Onboard the engineer onto the FDE way of working: customer-facing communication, scope framing, decision documentation. Deep dive into the assigned domain's architecture, tools, and history. Shadow live customer interactions without yet owning them.
• Month 2 — Immersion.Apply the skills. Handle real customer cases under direct supervision. Engage directly. Design and implement solutions in the customer's own context. Collaborate, iterate, improve — the operating rhythm of the role lived end-to-end for the first time.
• Month 3 — Impact. Own outcomes. Lead end-to-end engagements without supervision. Drive customer success on a measurable feature or workstream. Mentor the next cohort. Be the trusted expert on the ground.

Three months is intentionally tight. It's long enough to transform an engineer's instincts. It is short enough that the program can be evaluated, iterated, and either scaled or rolled back without the organisation having committed to a model it can't back out of.

7. The training already underway

This isn't a written document with a launch date. It started two weeks ago, and I'm running it myself.

Five live classes so far, each one to two hours, each tied to whatever the engineer in front of me was working on that day. Alternate-day calls between me and the cohort — not status updates, working conversations about the customer scenario, the technical decision, or the framing problem in front of us. Nothing is being delivered top-down. We're thinking through real engineering decisions together, reframed for an engineer who has to think like an FDE.

The bandwidth cost is real. Five classes plus alternate-day calls is a meaningful slice of my time. I'm spending it deliberately. The program is small enough that direct involvement is feasible, and the early shape of how this works deserves my attention now in a way the steady state won't later.

8. Using the AI tools to measure who's evolving

The most unusual piece of the program is how I measure whether each engineer is actually changing — and I suspect other engineering leaders will steal this once they hear it.

Every engineer in the cohort already uses AI coding tools daily. Claude. Cursor. The internal copilots we've built around our own platform. Those tools watch every prompt, every clarifying question, every back-and-forth on a design decision. They have the kind of long-form view of how an engineer actually thinks at the keyboard that no human reviewer ever gets.

So I ask them. Every few weeks I prompt the model each engineer is working with and ask it directly — how has this engineer's thinking changed over the last month? Are they asking more about the customer's context before they ask about the code? Are they framing scope in product terms or in implementation terms? Are they catching their own assumptions earlier in a conversation? Are they shipping less and thinking more, or shipping more and thinking more?

The model is a useful witness. It has the long memory of every interaction. It has none of the social filters a human reviewer applies. The output is patchy and directional, not definitive — but it surfaces signals that a quarterly review would miss entirely. An engineer who is starting to ask better questions of the model is an engineer who is starting to ask better questions full stop.

It also turns the AI tool from a productivity multiplier into a coaching surface. That's a different kind of value, and I think more engineering leaders will start using it this way as the models build longer memory of the people who work with them.

9. The economic thesis — scaling clients without scaling the team

The strategic reason for the program is one sentence: we should not need to scale the team linearly with the customer base.

In a traditional enterprise-software delivery model, every new customer adds load to customer success, implementation consulting, support, and engineering. Some of that load is genuinely new work. A lot of it is translation overhead — the same customer's feedback getting routed through the same chain for the same kind of fix, at a cost that scales with the number of customers.

An FDE absorbs both ends of the chain into one person. The same engineer who saw the problem ships the fix. The same engineer who shipped the fix knows what to generalise back into the platform so the next customer doesn't need the same fix at all. Marginal cost per customer drops. Marginal value per engineer rises.

The thesis isn't that 8 FDEs replace 8 customer success managers and 8 implementation consultants. It's that the FDE program lets the existing team — the 40+ engineering organisation, the customer success team, the implementation team — deliver to a materially larger client base than the same headcount could otherwise serve. Same team, more customers, sharper product. The unit economics of HR SaaS look different from this angle.

10. The early evidence

The case for the program isn't hypothetical. The pattern was visible before we named it.

• At one of India's largest metals and mining conglomerates,payroll change requests over the last cycle landed with direct developer involvement. The turnaround was visibly faster than comparable changes in the prior chain-of-translation model, and the customer's payroll lead was willing to say so out loud.
• At a large Indian diversified conglomerate spanning FMCG and hospitality,a set of in-product customisations that would normally have cycled through requirements, approval, and rework reached production in the shape the client actually wanted — because the engineer who built them sat with the client's functional team while building them.
• At an India-based facilities management services group,a payroll tollgate feature with a long history of clarification rounds shipped quickly and correctly after the developer engaged the client's payroll team directly. The feature matched what the client had been trying to articulate, not what the intermediate document had recorded.

The common thread across all three: the client ended the engagement proud of what was delivered. That second feeling — the customer's pride in the product — is the leading indicator that the model is working. Word of mouth between procurement peers is the most efficient marketing channel in enterprise software, and it follows from a customer who is proud of what they bought, not just satisfied.

11. What could break this — the honest list

The program is not without obvious failure modes. None of these are reasons not to ship it. All of them are reasons to ship it with eyes open.

• Engineer exhaustion in early months.The role is cognitively and emotionally heavier than steady-state engineering. Customer-facing work, technical work, and ownership work compound. We expect the first quarter to feel hard and the second to feel natural. If it doesn't feel natural by month six we'll have learned something we need to act on.
• Friction with Customer Success and Implementation Consultants. Genuine and expected. The honest answer is that the program is not designed to displace these teams; it is designed to demonstrate a delivery model whose results those teams can adopt into their own work. The point isn't to replace the customer success manager. The point is to show what becomes possible when the engineer is in the room — and to let the rest of the organisation evolve toward that shape on its own terms.
• Custom forks that don't generalise.The risk that an FDE solves one customer's problem in a way that becomes a maintenance liability rather than a platform improvement. The discipline we're building into the role is that every customer solution gets a deliberate generalisation pass — what was learned, what should land back in the platform, what is local to this customer and why.
• The 20% off platform work tradeoff.Eight engineers doing FDE work is eight engineers not doing core platform work. The bet is that the platform learning that flows back from FDE engagements is worth more than the same engineers' output as platform-only contributors would have been. The tradeoff is real and we are tracking it.

I'm also unusually cautious about introducing organisational change that the rest of the company hasn't had a chance to adopt at its own pace. My intent isn't to disrupt the engineering organisation with this. My intent is to demonstrate a shape of work that the broader organisation can choose to lean into. I'll know we've got it right when the customer success and implementation teams describe what they're doing in the same shape — without me having told them to.

12. What this means for the engineer

The career path inside an enterprise-software engineering team usually goes: junior → senior → staff → principal → director. Each rung adds scope; each rung also adds distance from the customer. The most senior engineer in a traditional org is, by structural design, the one furthest from the person using the software.

FDE is a different rung on a different ladder. It adds scope without adding distance. The engineer keeps writing code. The engineer also owns the customer relationship that the code serves. The work is harder. The leverage is higher. The visibility is direct.

We're building it as a path engineers should want to walk into, not one they get assigned to. The eight in the first cohort were chosen because the potential was visible, but every one of them also opted in. The second cohort is going to face the same selection bar and the same opt-in moment. Conscripted FDEs would burn out faster and serve customers worse.

13. The honest open question

Whether the model scales beyond eight.

The reason the program works at eight is that the bond between each FDE and the customers they serve is close, durable, and personal. I know each FDE's week. Each FDE knows each customer's context. The feedback loop from customer to platform is short because there are few hops on the path.

Sixteen might still work. Forty might not. Past some number, the FDEs themselves need a layer of leadership between them and me, and the bond stretches. Palantir solved this by accepting a high attrition rate and a strong cultural filter at hire. OpenAI is solving it differently. I may have to solve it differently again — possibly by accepting that the FDE program is deliberately small, and that the rest of the organisation evolves toward FDE-shaped working without everyone carrying the title.

The intentional smallness might be the feature, not the bug. A small, high-leverage program that the rest of the organisation learns from could matter more in the long run than a large program where the leverage gets diluted at the edges.

We will find out. The next six months are the test.