A forward-deployed engineer is not a contractor with better manners. You are dropped into someone else's business — their data, their customers, their half-true assumptions about how their own operation works — and expected to ship software that survives contact with all of it. The job is only partly writing code. The rest is figuring out what code should exist.
I have done this from both sides. I run a home-services company that takes real bookings from real customers, and I build the software that runs it. So when I embed with a team, I am not learning what an operations problem feels like for the first time. That is the perspective this breakdown comes from.
Here is what actually separates a forward-deployed engineer who lands from one who gets quietly sent home — and, at the end, an honest accounting of which of these anyone can measure.
1. Embed: you learn their business before you touch the schema
The first two weeks decide the engagement. Not because of what you build, but because of what you learn to stop assuming.
Every business has a model of itself that is subtly wrong. The dispatcher says jobs are assigned in the morning; in practice half get reassigned by 10am and nobody logs it. The clinic says every patient has one chart; in practice families share a phone number and the front desk has been merging records by hand for years. If you build against the story instead of the practice, you ship something correct and useless.
The tell for a good FDE is that they ask about exceptions early. Not "what happens when someone books an appointment" but "what happens when someone books, then calls to move it, then doesn't show." The exception path is where the business actually lives.
2. Ship: it runs in production, on their real data
A demo that works on seeded data proves nothing. Real data is where the encoding problems live, where the duplicate records live, where the customer who has been in the system since 2011 with a NULL in a column your code assumes is populated lives.
The gap between "works on my machine" and "runs on their data" is most of the job, and it is where the majority of engineers who are good at interviews turn out to be underpowered. Shipping means it is live, someone who is not you depends on it, and you found out what broke.
3. Judgment: knowing what not to build
The most valuable thing an FDE does is talk a client out of something. The integration that would take six weeks and save four minutes a day. The dashboard nobody will open. The rewrite that is really a symptom of one slow query.
This is uncomfortable because you are usually paid by the hour or the sprint, and the incentive runs the other way. A great FDE has a functioning sense of what a thing is worth against what it costs, and says so out loud, early, in front of the person paying.
4. Transmission: you leave it maintainable by someone who is not you
Forward-deployed work ends. The measure of whether it was any good is what happens six months after you leave.
That means the README explains the why, not just the commands. It means the surprising decision has a comment next to it saying why the obvious approach was wrong. It means the person who inherits it can make a change without ringing you — and if they do ring you, the honest read is that you did not finish.
5. Architecture: complexity that matches the problem
Both directions fail. Under-engineering ships a prototype into production and it falls over the first busy Monday. Over-engineering ships a microservice mesh to a business with four employees and leaves them with something they cannot afford to maintain or replace.
The forward-deployed version of this skill is specifically about their constraints, not your preferences. If the client's team is two people who know PHP, an elegant Rust service is a liability regardless of how good it is.
6. Fundamentals: you can actually debug
When something breaks in production on their infrastructure, on a Friday, with no reproduction, the only thing that helps is being able to reason from symptom to cause. Read the logs. Form a hypothesis. Test the cheapest one first. Not pattern-matching to a similar bug you once saw, but actually narrowing it.
This is the least glamorous item on the list and the one clients remember longest, because they watched you do it while their operation was down.
7. Communication under pressure
You will be wrong in public. The estimate will slip, the migration will surface a data problem nobody knew about, the integration partner's API will turn out to be undocumented fiction.
What separates the good ones is that the client hears it from you first, with a plan attached, before they notice on their own. An FDE who goes quiet when things go badly is worse than no FDE, because the silence buys the problem another week to grow.
8. Sustained cadence
Anyone can sprint for a fortnight. Forward-deployed work is measured in months, often alongside other clients, and the failure mode is not dramatic — it is a project that gets 80% done and then thins out into nothing as attention drifts elsewhere.
Coming back to the same code in month four, and month seven, is a genuine skill. It is also, as it happens, one of the few things on this list that leaves an unfakeable trace.
Which of these can anyone actually measure?
Here is the uncomfortable part, and the reason most developer-ranking systems are worthless.
Four of the eight leave real evidence in a git history. Ship shows up as tests, CI and release tags. Architecture shows up in function length and nesting distributions, and in whether the typing means anything. Judgment shows up in exception handling precision and in how often you return to a file. Transmission shows up in documentation ratio and docstring coverage.
The other four leave nothing. Whether you can map a messy business is not in your AST. Whether you can debug under pressure is a timed exercise, not a property of a repository. Whether people trust your work is a public record, not a local one.
Any tool claiming to score all eight by reading your code is guessing at half of them, and every good engineer spots it immediately.
So measure the half that is measurable
I built Aura Rank because I wanted a legible signal for developers without a logo behind them — people running production systems alone, for real businesses, with nothing on the résumé that recruiters recognise.
It grades a repository out of 100 across the four dimensions above, and it explicitly refuses the other four rather than pretending. It runs entirely offline: your source never leaves the machine, and you can verify that with one grep before you run it, because the scanner imports no HTTP client and opens no socket.
The signal I would pay most attention to is revisit_ratio — the share of files you touched in more than one calendar month. It separates maintained work from dump-and-run. It is invisible to anyone optimising for stars. And it cannot be faked without actually doing the thing. Every vanity metric rewards volume; that one rewards coming back, which is item eight on this list.
Expect a number lower than you want. A typical solo project lands between 15 and 45, and that is not an insult — it is what an untested, actively used codebase honestly looks like. The calibration set tops out with scrapy at 88 and flask at 87, so if you are in the sixties you are keeping company with well-run open source.
Run it on something you have actually built. Sixty seconds, no account, nothing uploaded. Then go and be unmeasurable about the other four.
That is the repository half. The other half of this job is the business around it, and the equivalent check there is the free website check — it measures what a company's customers actually hit rather than what its code looks like. If you are embedding with a business rather than a codebase, the second number is usually the one that turns out to matter.
If you are hiring for this and want to talk about what the work actually looks like from inside a business, or you need someone embedded for a stretch, get in touch. I will be straight about whether the problem you have is one I am the right person for.
