Forward deployed engineer: why knowing how to code is no longer enough

The most valuable engineer is no longer the one who writes the most code, but the one who knows what not to build.

LAURA SORIA
HR Manager Orbitant

AI has made writing code cheap, but what remains expensive —and scarce— is knowing what to build, for whom, and why. Out of that scarcity, a new profile has emerged, one the industry has started to call the forward deployed engineer: someone who doesn’t sit around waiting for a well-defined ticket, but instead gets inside the customer’s problem, understands the business almost as well as their own code, and makes decisions with that context in hand. This isn’t a marketing label; it’s a real redefinition of what makes an engineer valuable once generating code is no longer the bottleneck.

That definition can’t stay theoretical, and that’s why, as HR Manager at Orbitant, my job is to turn it into something you can assess in an interview, write into a job posting, and sustain through someone’s first months on the team — not leave it as a nice line for a LinkedIn post about company culture.

Where the forward deployed engineer concept comes from and why we adopted it

We didn’t invent the term: as The Pragmatic Engineer documents, it comes from how certain AI companies place their engineers directly inside the customer’s operations —companies like Stripe, Databricks, and Palantir have had dedicated teams doing this for years— rather than keeping them behind a backlog and a product manager.

In Spain, according to Manfred, the concept has started to appear strongly over the past year, and it’s a profile we’ve been talking about across various team conversations for a while, because it connects very naturally with something that’s already part of our DNA as a company: the idea that, in a market where writing code costs less and less, the engineer who adds value isn’t the one who executes a ticket best, but the one who understands why that ticket exists in the first place.

Out of those conversations, four traits that define the profile have gradually taken shape:

• Real business knowledge.
• Autonomy to make decisions without escalating every detail.
• Genuine AI capabilities: not just using it to move faster, but knowing when to trust it and when not to.
• Solid engineering foundations and well-established best practices.

No single trait replaces the other three: an engineer with lots of business context but no technical foundations can make the right calls and then build them badly, while one with solid foundations but no business context can build something well that shouldn’t have been built at all.

Turning these four traits into an operational criterion, and not just an intention, is what I explain below, connecting them to Orbitant’s three pillars.

The three pillars we turn into hiring criteria

Engineering, innovation, and business understanding are the three pillars Orbitant is built on, and when we design a role or prepare a technical interview, those are the terms in which we connect each of the traits above:

• Engineering: we look for and reinforce a solid technical knowledge base and well-established best practices, which high-performance engineering teams depend on, and which make it possible to work with legacy code without losing quality, even under pressure; without this base, AI doesn’t compensate — it amplifies every shortcut you were already taking before you had an agent writing code.
• Innovation: we value real, day-to-day use of AI over interview talk, because having Claude licenses doesn’t make a team AI-first; that’s why we ask about specific tools, about decisions that were made using AI and what was learned from them, and about measurable results in real projects.
• Business understanding: we look for the ability to ask why before how, since it’s not enough to execute well what the customer asks for — you have to understand whether it’s really what they need, even when that means questioning the assignment itself.

The fourth trait —empowerment— isn’t a separate pillar, but the consequence of holding the other three at the same time: granting autonomy without solid foundations is a risk for the project, while demanding foundations without granting autonomy is wasting talent that ends up looking for it somewhere else. That’s why we don’t assess the three pillars in isolation, but whether they coexist in the same person at the same time.

This changes the questions we ask in an interview. Instead of asking which technologies someone knows, we ask why they decided not to use AI for a specific task at a given moment, or why they defended a technical decision to the customer when it didn’t serve the business outcome. The answers to those kinds of questions say far more about a person’s judgment than any list of technologies on a résumé.

How this translates into a real job description

At Orbitant, “forward deployed engineer” isn’t a job title, but the way of working we look for in any technical role today, and the most concrete example of how this translates is the description we wrote for an AI Engineer role, where we don’t ask for “experience with AI” in the generic sense — instead we ask, among other things, that the person be able to:

1. Take a project from pilot to production: define which evaluations matter, instrument traceability, observability (and good practices in general), and make sure what gets deployed meets the agreed business outcome, not that “the demo works” on a shared screen.
2. Design multi-step agent architectures with state management, harness usage, and error recovery, rather than chaining together loose prompts and hoping they hold up.
3. Build offline and online evaluations with real metrics and datasets, measured against business outcomes and not against the subjective feeling that “it works fine”.
4. Question the why before the how: collaborate with business profiles to define the expected outcome before touching the architecture, not after.

These points aren’t just about asking for seniority in the traditional sense: they describe a different profile, someone comfortable moving between a business conversation and an architecture decision in the same afternoon, who understands that the trade-off between cost, latency, and model capability is a product decision as much as a technical one, and who can defend it in front of the customer without needing sign-off from someone more senior.

That’s why, in the initial screening, we don’t prioritize whoever has used the most trendy tools, but whoever can explain why they chose one agent architecture over another in a specific project, or why they decided not to use fine-tuning when it seemed like the obvious option: that kind of answer can’t be memorized the night before.

What changes in how we assess and support this profile

Adopting this criterion in hiring doesn’t count for much if it doesn’t also change what happens after the contract is signed: we follow a 30-60-90 day onboarding plan, with training and small first tasks in the first month, autonomy and a first project of their own between days 30 and 60, and defined responsibilities and KPIs, with a formal review, between days 60 and 90.

The difference from a traditional onboarding is in the support. From day one, each person is assigned a buddy —not their manager or a technical mentor— for their first 90 days, with daily contact in the first week and weekly check-ins after that; their role is to convey Orbitant’s culture and business context before the tools arrive, not the other way around.

This also affects how we evaluate performance further down the line, where we don’t measure delivery speed alone, but whether the person is still asking business questions six months after they’ve already understood the project’s architecture, or whether they’ve stopped asking because they now “know how this works”; the second signal is the one that worries us, and the first is the one we aim to reinforce in every performance review. But this support solves the adaptation of one person, not that of the whole team, and that’s a separate question.

Why we train the whole team to think in business terms

A team’s agility doesn’t depend only on its processes, but on how close each person is to the business: the less a technical decision depends on escalating it to someone in product, the faster the whole team moves, and that closeness doesn’t happen on its own — it has to be trained.

That’s why we’ve spent twelve weeks running an internal product training program with hands-on exercises in every session, not just theory: the discovery part, for example, is worked through with the double diamond framework, first exploring the customer’s real problem before converging on a solution — exactly the sequence we ask a forward deployed engineer to follow day to day.

Each person, in addition, assesses their own level of product manager and tech lead competencies on a platform dedicated to it. It’s not a one-off course or generic content: it’s the path by which someone who came in knowing how to defend an architecture ends up also defending why one feature is worth building before another.

That same logic of constant learning repeats outside the product program through Knowledge Sharing and Asteroids: sessions and short pills, five to fifteen minutes long, that anyone on the team can propose and deliver on any topic —from agent architecture to customer negotiation— because sharing what you learn is a team objective, not an activity that depends on there being spare time.

It’s this combination —judgment in hiring, real support, and continuous business training— that makes it possible for someone inside Orbitant to think and act like a forward deployed engineer, and not settle for a nice definition on paper.