Are You Still a Real Engineer as a Forward Deployed Engineer

It is the quiet fear behind almost every conversation about this role. You take a forward deployed engineering job, the pay is excellent and the work sounds exciting, and then a voice at the back of your head asks whether you are still a real engineer or whether you have quietly become a well-paid consultant with a technical vocabulary. The fear is common enough to appear in nearly every honest discussion of the role, and almost no career article addresses it directly. This one does.

The short answer is that it depends entirely on which version of the role you are in, and that the fear is pointing at something real rather than imaginary. The dilution of the title means both jobs exist under the same name, and telling them apart is the whole game. If you want the version that keeps you genuinely technical, you have to build genuinely technical skills, which is what the Forward Deployed Engineering Program is designed to do.

Key Highlights

• The worry about not being a real engineer is legitimate, because the title now covers both deeply technical build roles and relabelled support jobs, and the two lead to very different places.
• Palantir's own commercial leader has said the label has been diluted to mean almost anyone customer-facing and slightly technical, which is why the fear is grounded rather than paranoid.
• The genuine version of the role is arguably more technically demanding than a standard product job, because you build against unfamiliar systems and hard constraints without the usual scaffolding.
• Whether you stay a real engineer is determined less by the title and more by how you spend your weeks and whether you keep building deliberately.
• You can protect your technical identity with specific habits, and the choice of employer and engagement matters more than the choice of title.

Where the fear comes from, and why it is fair

The anxiety is not manufactured. Ted Mabrey, who leads commercial at Palantir, the company that popularised the role, has been candid that most attempts to copy the forward deployed model were half measures, and that the title has been stretched to cover almost anyone who is customer-facing and a little technical. When the originator of the role says the label has been diluted, the person worrying about that dilution is not being neurotic. They are paying attention.

What this means practically is that two very different jobs now share one name, and the gap between them is one of the strongest arguments to weigh before committing. In one, you spend your weeks writing and deploying real software against genuine technical constraints. In the other, you spend them in meetings, demos, and configuration, with the actual engineering happening somewhere else. Both are called forward deployed engineer. The fear of not being a real engineer is really the fear of ending up in the second job while believing you took the first, and that is a rational thing to be careful about rather than a confidence problem to talk yourself out of.

The genuine version is more technical, not less

Here is the part the anxious framing misses. The real version of this role is often harder than a conventional engineering job, not softer. When you build inside a customer's environment, you do it without the scaffolding a product team takes for granted. The documentation is thin or wrong. The systems are unfamiliar. The data is messy and half-accessible. The constraints are real and often strange. You cannot lean on the internal tooling and tribal knowledge that make a product role smoother.

Doing solid engineering under those conditions demands more range, not less. You have to understand systems you did not build, integrate with tools you have never seen, and make sound technical judgements fast and in public. The modern version also sits squarely on the frontier of applied AI: retrieval systems, intelligent agents that act inside the customer's tools, evaluation, and production hardening. That is not a step down from engineering. For many people it is the most technically stretching work they have ever done, precisely because the safety nets are gone.

The distinction that actually decides it

If the title does not tell you which job you are in, what does? The answer is how you spend your time, measured honestly over a typical month. A real engineering role has you writing code, designing systems, debugging, and deploying for a substantial majority of your weeks. A diluted one has you doing those things occasionally, around a core of demos, status meetings, and configuration that someone else could do. This ratio is also what separates the role from a conventional software engineering track, where the building is assumed rather than something you have to actively protect.

This is worth measuring rather than sensing, because the drift is gradual and easy to miss. An engineer who starts in a genuine build role can slide, engagement by engagement, into a coordination role without ever deciding to, simply by saying yes to the customer-facing work and letting the building quietly migrate elsewhere. The way to stay a real engineer is to watch the ratio deliberately and protect it. If you notice the building shrinking and the talking growing, that is the signal to act, whether by renegotiating your scope or by changing engagements, long before the ratio settles somewhere you did not choose.

Why the comparison to a solutions architect misleads people

Part of the real-engineer anxiety comes from mentally filing the forward deployed role next to roles that are genuinely less technical, and then assuming the label transfers. The most common of these is the solutions architect, a role that in many companies is primarily about design, diagrams, and advising rather than building. If you assume forward deployment is just a solutions architect who travels, the fear that you will stop coding follows naturally.

But the comparison misleads, because the defining feature of the genuine forward deployed role is that you build what you design, inside the customer's constraints, rather than handing a design to someone else to implement. That build responsibility is exactly what keeps it an engineering role. A solutions architect can succeed without writing production code for months. A genuine forward deployed engineer cannot, because the deliverable is working software running in the customer's environment, not a recommendation about how it might be built. This distinction is easy to miss from the outside, which is why so many people import the wrong expectations, and it is worth understanding the adjacent roles clearly enough to see where the forward deployed role genuinely differs from them rather than assuming it inherits their limitations.

Consultant, engineer, or both, and why the framing is a trap

Part of what makes this fear sticky is a false binary. People imagine a clean line with real engineer on one side and mere consultant on the other, and they panic about which side they are on. The better forward deployed engineers reject the binary. The role at its best is genuinely both: deeply technical and deeply customer-facing, and the combination is the point rather than a compromise.

Consider what the strongest practitioners actually do. They sit with a customer, understand a problem no specification captured, and then build the solution themselves against the customer's real constraints. That requires consulting skills and engineering skills in the same person at the same time. Alex Singla of McKinsey has described wanting exactly this rare combination, people with the propensity to be both a strong consultant and a strong technologist, then grooming them for both. The fear of not being a real engineer often rests on the assumption that adding customer skills subtracts technical ones. It does not. It adds a second axis of capability that most engineers never develop, and that scarcity is a large part of why the role pays what it does.

How you actually lose your technical edge

To protect something you have to know how it is lost, and the loss here is rarely dramatic. Nobody takes your keyboard away. Instead, the erosion is quiet. You take on more accounts, so there is less time to build. You become the person who understands the customer, so you get pulled into every conversation. The demos multiply because you are good at them. Each individual shift is reasonable, and the sum is an engineer who has not written meaningful code in months and has started to feel it.

The compounding is the danger. A quarter of mostly-talking does no harm. Two years of it quietly narrows your capability to one vendor's configuration surface and erodes the market value that made you attractive in the first place, even as your title grows more impressive. This is why the engineers who stay sharp treat their technical practice as something to defend actively rather than assume. They keep building on real problems, they stay current with theagentic AI stackrather than letting it pass them by, and they refuse to let the customer-facing motion crowd the engineering out entirely.

The erosion is particularly easy to miss because the field itself keeps moving. Even an engineer who was genuinely current two years ago can fall behind without doing anything wrong, simply because the tools, the frameworks, and the accepted way of building have all advanced while they were busy on customer sites. Staying a real engineer therefore requires running to stand still, keeping pace with how the discipline is evolving, including the shift fromprompting toward the broader engineering practices that now define serious AI work. The engineers who treat learning as a finished task rather than a continuous one are the ones most surprised, and most exposed, when they finally test their value on the open market.

The habits that keep you a real engineer

Protecting your technical identity in this role is a matter of deliberate practice rather than luck. The engineers who manage it tend to share a few habits. They keep a hands-on project, inside work or outside it, that forces them to write real code regularly, so the muscle never fully rests. They stay current with the tools the field is moving to, treating learning as continuous rather than reactive.

They also choose engagements with an eye on the technical content, not just the customer or the compensation, because the surest way to stay technical is to keep taking technical work. And they invest in structured skill-building so their capability grows rather than merely holds, whether through the Agentic AI Foundation training, hands-on engineering with Claude, or material aimed at software developers moving deeper into AI. None of these is exotic. The point is that staying a real engineer is an active choice repeated over time, not a status the title confers on you and then guarantees.

What the strongest forward deployed engineers actually build

It helps to make the technical work concrete, because the fear of not being a real engineer tends to fade the moment you look at what the genuine role involves day to day. A strong forward deployed engineer working on an AI deployment is not clicking through configuration screens. They are designing retrieval systems that have to work over a customer's messy, half-documented data. They are building agents that take real actions inside the customer's tools, with all the error handling and guardrails that implies. They are wiring up evaluation so the system's behaviour can be measured rather than hoped at, and hardening the whole thing for production inside an environment they do not fully control.

That is a demanding technical portfolio by any standard. It draws on the same foundations as any serious AI engineering role, the difference being that you apply them against a live customer problem rather than an internal roadmap. If anything, the customer constraints make the engineering harder, because you cannot simply change the environment to suit your solution. Seeing the work at this level of detail is the fastest cure for the real-engineer anxiety, and it is why building genuine capability through something like the Forward Deployed Engineering Program settles the question in practice: once you can do this work, whether it counts as real engineering stops being a worry and becomes obvious.

Choosing the version of the role you want

Since both jobs share a name, the decisive move happens before you accept an offer. Screen the role hard for its technical content. Ask what you will build in the first ninety days and whether you will be writing and deploying code or configuring someone else's system. Ask how the team splits its time between building and customer coordination. Ask who owns production after go-live, because the answer reveals whether you will be doing real engineering or handing it off.

A genuine role answers these questions concretely and confidently, in terms of real systems and real ownership. A diluted one answers vaguely, in the language of enablement and stakeholder management. Neither is dishonest, but they are different jobs, and the interview is where you find out which one you are being offered. Doing this screening well requires knowing what good technical answers sound like, which is another reason that building real capability first, rather than chasing the title, is what protects you. You cannot screen for engineering depth you do not yourself possess.

Why the fear persists even in good roles

Here is something worth naming for the engineer who is in a genuine build role and still feels the anxiety. The fear does not always come from the work being insufficiently technical. Sometimes it comes from the visibility of the customer-facing part. When you spend a chunk of your week in front of a client, that part of the job is loud. It is what people see, what gets talked about, and what your own memory reaches for at the end of the day. The engineering, done quietly at a keyboard, is less visible even when it is the larger and harder share of the work.

This creates a distortion where you undercount your own technical contribution simply because it is the invisible part. Engineers in genuinely technical forward deployed roles sometimes talk themselves into feeling like consultants purely because the consulting-shaped moments are more memorable, not because they dominate the actual work. The corrective is to measure rather than feel. Keep an honest log of where your hours go for a month. Most people in real roles are surprised by how much of it was building, and the surprise tells them the fear was tracking visibility rather than substance. If the log genuinely shows the building shrinking, that is real information worth acting on. If it shows the opposite, you can let the anxiety go, because it was measuring the wrong thing.

The bottom line

The worry about whether you are still a real engineer as a forward deployed engineer is legitimate, because the diluted title now covers both deeply technical build roles and relabelled coordination jobs. The originator of the role has said as much. But the genuine version is if anything more technically demanding than a standard product job, because you build against unfamiliar systems and hard constraints without the usual scaffolding, and increasingly on the frontier of applied AI.

Whether you stay a real engineer is decided by how you spend your weeks and whether you keep building deliberately, not by the word on your business card. Screen hard for technical content before you accept, protect the ratio of building to talking once you are in, and treat your technical practice as something to defend actively. Building real capability through the Forward Deployed Engineering Program is both how you earn the genuine version of the role and how you make sure it never quietly turns into the other one.