Career
A 30-day plan to become a forward deployed engineer
Four weeks, week by week: build a real agent, make it survive reality, measure it, and learn to defend it in business language. With concrete checkpoints.
If it had to be one sentence: do the job before you have the title. In thirty days you can have evidence that makes it reasonable to apply for one of these roles.
The schedule below is realistic at a few hours a day. It isn’t a race — if it takes six weeks, fine. The order is what matters.
Week 1 — build an agent that finishes a real task
The goal isn’t a chatbot. The goal is a system that takes a task and completes it — without anyone phrasing the request perfectly.
Pick a real back-office workflow. Don’t invent one: ask someone you know what they do in finance, procurement or HR, and get them to walk you through it step by step. That exercise is itself an FDE skill.
Day by day:
- The agent loop. Plan, act, evaluate, and know when to stop.
- Tool use. Two or three real tools — file reads, HTTP calls, a database query.
- Guardrails. What it may not do. Maximum steps, maximum cost, forbidden operations.
- Context and memory. What goes into the call, what stays out, what has to persist between runs.
- Logging. Every step reviewable: input, decision, justification.
- The whole flow. Wire it together and run it end to end.
- Checkpoint. It works on one task, with tools, guardrails and a log.
Day 5 is the important one, and it’s the one most people skip. If you can’t show what the agent did, nobody will trust it. That’s the difference between a hobby project and a defensible system.
Week 2 — make it survive reality
Your week-one system works on the happy path. Now the rest.
- Structured output. Schema-defined JSON, validated. Don’t parse free text.
- A list of failure modes. Write down how many ways it can break. You’ll find at least twenty if you’re honest.
- Exception handling. For each: retry, alternate path, or route to a human. But never silent swallowing.
- Idempotency. If it runs twice on the same input, it shouldn’t do two things.
- Checkpoint. Throw deliberately bad inputs at it. A corrupt PDF, a missing field, an empty file, the same thing sent twice. None of them should stop it silently.
This is the least impressive week, and it’s what separates a demo from a system. More on it: unhappy paths.
Week 3 — make it measurable and affordable
- A golden dataset. 50–100 cases across every category. Label the correct output. Here’s how.
- A scoring script. One command that runs it all and prints per-category results.
- Failure analysis. Look at what failed, and why. Cluster it.
- A cheaper model on sub-tasks. Measure what you lose. Often nothing.
- Cost and latency per case. A concrete number.
- Checkpoint. You have a number, you know your failure modes, you know what a case costs.
Get this far and you understand your own system better than most AI project teams understand theirs.
Week 4 — learn to defend it
This week is about being able to explain what you built two different ways.
To an engineer. What’s the architecture? Why that way? What was the alternative and why did you reject it? Where’s the bottleneck? What breaks first under ten times the load?
To an executive. What business problem does it solve? How much time does it save, specifically? What’s the risk, and what happens when it’s wrong? What does it cost monthly? Why is it worth it?
The second is harder if you come from engineering — and it’s exactly the part that separates an FDE from a developer.
Then the single most useful step: show it to someone who works in that field. Not for praise. So they can tell you what you got wrong. And they will: “that isn’t how we do it”, “we skip that step”, “that exception is a third of our cases”.
That feedback is worth more than anything else in the month.
What you’ll have at the end
You won’t be an FDE in thirty days. That role takes years to build.
But you’ll have a working system, an eval set, a list of failure modes, and two different talks about the same thing. That’s more than the overwhelming majority of candidates arrive with — and precisely what a company hiring for this role wants to see.
The other side — communication, business understanding, organisational politics — only develops with a real customer. But there’s no reason to sit idle until then.
If you’ve done this and want to talk about it, get in touch — we’re hiring engineers. Worth reading first: what is an FDE.
Questions on this topic
Do I need a software engineering background?
It helps enormously, but not every FDE role requires production code — some are configuration on an existing platform. What every version requires is understanding what the system does, because you'll be the one called when it breaks.
Can you really learn this in 30 days?
Not the role. The entry ticket, yes. The point of the 30 days is to end with a defensible working system and an informed opinion. The rest arrives with your first real customer.
What does this look like at your company?
If this problem sounds familiar, let's start with one process. Tell us which department burns the most manual hours — we'll come back with a concrete proposal.