Score yourself on the 8 skills of the AI era's most valuable engineer, then fix the first gap.
By the end of this you'll have done three things: scored yourself 1 to 5 on the 8 capabilities that make up a Forward Deployed Engineer, named your single biggest gap, and walked out with a 90-day plan to close it. No theory you can't act on the same afternoon.
I run delivery for a unit of 100+ engineers, and I keep a small AI lab on the side to test what's coming before it hits corporate scale. From both seats I've watched the same thing happen this year: the job that pays and matters most stopped being "the person who can build it." Let me show you what replaced it, and how close you already are.
An FDE is the person who can sit with a customer at 9am, understand the business problem well enough to argue about it, and have a working AI solution running a few days later. Something the customer can open and click.
The title comes out of companies like Palantir and now the AI labs, where engineers get sent straight into the customer's world instead of waiting behind a product manager. The shape of the role is older than the title though. It's an engineer who also carries the questions a consultant, a product manager, and a founder would ask.
One person carrying six sets of questions at once. That overlap is the whole job, and it's why the role is rare.
Here's the part that matters for your career. Each of those circles used to be a separate hire. The reason one person can hold them now is that AI ate most of the manual cost inside each one. So the value moved to the seam between them, and the seam is where few people are trained.
For 20 years the hard, expensive, slow part of software was building it. Whole careers were organized around that bottleneck: specialists who could write the code, architects who could make it hold together, managers who could keep 30 of them moving.
AI moved the bottleneck. Writing a first version of almost anything is now cheap and fast. When building gets cheap, the expensive question becomes the one that stayed manual: are you building the right thing for this specific customer, and will they actually use it?
When the cost of building collapses, the constraint jumps to problem selection and adoption. That's the new scarce skill.
So the FDE is valuable for a plain reason. The role lives exactly on top of the new bottleneck. It owns the choosing and the adopting, on top of the building. In Vietnam I see very few people training for this on purpose, which is most of the opportunity.
Capabilities are the visible layer. Under them sits an operating system, the defaults you reach for without thinking. You can be a strong engineer and still run the old defaults, and the old defaults are what hold most people back. Here are the 7 shifts that separate an FDE from a very good developer.
Read these as defaults, not slogans. The question is which side you reach for under pressure.
The old reflex is to open the editor. The FDE reflex is to ask what breaks for the customer today and what it costs them per week. If you can't put a number on the pain, you're about to build something the customer never asked for. Failure mode to watch: starting to code because the problem feels obvious. It rarely is.
A feature is something you shipped. An outcome is something that changed for the customer: hours saved, a cost cut, a deal closed faster. You can ship 10 features and move nothing. Tie your work to a number the customer already cares about, and check it after you ship.
You don't have to become an accountant to build for accountants, but you do have to understand how they make and lose money. The best questions in a customer meeting are about their workflow, not your stack. Spend the first hour learning their job and the architecture mostly designs itself.
Customers ask for what they can imagine, which is usually a faster version of what they already do. Your job is to show them the option they couldn't picture. That takes the nerve to say "I think there's a better way" in the room, and the evidence to back it.
Speed here is how you learn. A rough thing in front of a customer on day 3 teaches you more than a polished thing in month 3. AI-assisted building is what makes this realistic now, so the constraint is no longer your typing speed, it's how fast you can see the problem clearly.
Meet the customer Monday, put something they can click in front of them by Thursday. The loop is the product.
This is the hardest one because it's three habits in one body. The engineer ships. The consultant reads the room and the business. The product thinker decides what's worth building at all. Most people are strong in one and quietly avoid the other two.
The task ends when the code merges. The outcome ends when the customer is getting value in production and would be upset if you took it away. Those are months apart, and the gap is where adoption lives or dies. Owning that gap is the founder habit, and it's the one clients remember.
Now the visible layer. These 8 pillars are what you can actually build and measure. Score yourself 1 to 5 on each, where 1 is beginner, 3 is competent, and 5 is expert. Be honest, the whole exercise is worthless if you round up.
Eight pillars. Four are usually a senior engineer's strength, four are usually the gap. The split is the interesting part.
| Pillar | Competent (3) | Expert (5) |
|---|---|---|
| Elite software engineering | Ships production code that holds up | Designs systems others build on, full stack, alone if needed |
| AI engineering | Builds with LLMs, RAG, and agents from tutorials | Ships reliable AI features and knows their failure modes cold |
| Product thinking | Can spot a weak feature idea | Finds the right problem before anyone asks for it |
| Customer obsession | Listens well in meetings | Understands the customer's business better than they expect |
| Rapid prototyping | Builds a demo in a week | Working prototype in days, used to learn, not to impress |
| Data engineering | Moves and cleans data when needed | Builds reliable pipelines and real-time systems by default |
| Business acumen | Understands cost and revenue at a high level | Reasons about ROI and risk like the person paying the bill |
| Founder mindset | Takes ownership of their tasks | Owns the problem, solution, and adoption to the end |
Put your 8 numbers on a radar. The shape tells you more than the total. A balanced octagon at 3s means you're a solid generalist who needs depth somewhere. A spiky shape means you have a real strength and a real hole, which is honestly easier to fix.
Plot yourself honestly. The dent in the shape is your next quarter's work, not a verdict on you.
If you're a senior engineer out of an enterprise or outsourcing background, I can usually guess your radar before you draw it. Strong on the left, thin on the right.
Here's the pattern I see in almost every strong enterprise engineer in Vietnam. The advantages are real and hard to teach: deep systems thinking, architecture under pressure, the ability to talk to a business stakeholder without flinching, and years of knowing how large organizations actually work.
Your advantage column took years to build. The gap column can move in one quarter if you point at it on purpose.
The gaps cluster around the same 4 things: shipping AI products fast, building with the customer in the loop instead of behind a spec, owning the full stack alone, and the specific craft of AI application engineering. None of those need 10 years. They need deliberate reps on real problems, which most enterprise work never gives you.
So your biggest gap is usually the lowest score among those 4, not the lowest score overall. A 2 in data engineering matters less than a 2 in rapid prototyping if your goal is to become an FDE, because prototyping is on the critical path of the role and pure data work often isn't.
One gap, one quarter. Spreading attention across all 8 is how people make no progress and feel busy doing it. Pick the lowest of your 4 likely gaps and aim everything at it.
Thirty days to get unembarrassing, thirty to get useful, thirty to ship something a real user touches.
The shape that works, using rapid prototyping plus AI engineering as the example since that's the common gap:
Days 1 to 30, get unembarrassing. Build 3 throwaway prototypes end to end with AI assistance. Pick real, small problems from your own work, the messier the better. The goal is to kill the fear of the blank repo and learn where AI helps and where it lies to you.
Days 31 to 60, get useful. Take one of the three to a real person, ideally an internal team with an actual pain. Watch them use it. Rebuild based on what you saw, not what they said. This is where the customer-obsession and outcome muscles grow.
Days 61 to 90, ship something owned. Get one thing into real use and stay on it past launch. Track one number it was supposed to move. Owning it past the demo is the founder rep, and it's the hardest to fake on a CV.
You don't become an FDE by reading about it. You become one by running this loop on a real problem, in public, three times.
Vietnam doesn't have many people building this profile on purpose yet. The senior engineers here are strong. The gap is in where they point that strength. If you score yourself honestly today and aim one quarter at one weakness, you're closer to the front of this than almost anyone around you.
Draw your radar. Find the dent. Start the 90 days.
1 to 2 emails a month. Easy to unsubscribe.
1 to 2 emails a month. Easy to unsubscribe.
Comments