One day, hands-on
Be worth more than your output
You'll learn to decide what gets built, not just how to build it. One messy business problem, carried all the way to something you could put in front of real users.
Why this exists
Something shifted in the last couple of years, and most teams haven't caught up with it yet. Product managers are shipping working prototypes. Designers are writing specs that used to take an engineer a week. Anyone with a clear description can generate a few thousand lines of plausible code before lunch — and plausible is the word that should worry you, because plausible is not the same as correct.
The lines that used to separate these roles have started to blur, and that leaves an uncomfortable question behind: if implementation isn't the scarce thing any more, what exactly is an engineer for?
I don't think the answer is typing faster. Enough product sense to know which problem is worth solving at all. Enough design sense to see the thing from the person actually using it. And enough business sense to say out loud how this particular piece of work turns into revenue, or retention, or cost that stops being spent. That isn't a soft skill sitting politely next to the engineering. It's the engineering now — and it's the part no agent is going to hand you.
This workshop is where you practise it.
Why this role, now
The job market moved before the job titles did
The title is new. The work is not.
Forward Deployed Engineer is what happens when a company realises the hard part of shipping AI is not the model — it is everything between the model and a customer who has a real problem, a real deadline and a real opinion about what "working" means.
It sits where three things meet: the AI system, the design of the solution, and actually delivering it to someone. Discover, build, deploy, transfer, communicate. Most engineers have done every one of those steps at some point. Very few have been asked to own all five at once, which is exactly what makes the role scarce.
The scarce part moved
When anyone can generate plausible code, the bottleneck stops being implementation and becomes deciding what to implement, and proving it works for the person paying.
It is the part agents do not do
An agent will build what you decided. It will not sit with a customer, hear what they actually meant, and change the plan.
It is hiring under many names
Forward deployed engineer, solutions engineer, applied AI engineer, delivery lead. Different titles, the same job: carry a real problem to something real.
What you leave with
Things you can use on Monday
A way to turn “we need a dashboard” into something you can actually build
You'll take a request that sounds simple, work backwards to the behaviour someone genuinely wants changed, and come out the other side with explicit decisions, a model of the domain, and a first slice you could hand to anyone.
The handful of questions that change what gets built
There are always forty questions you could ask. Usually only four of them would alter the answer. You'll get better at finding those four quickly, and at letting the rest go.
Context an agent can't misread
Coding agents are excellent at doing what you decided and terrible at deciding it for you. You'll learn what to write down first — the decisions, the rules that must never break, the scope of this one change — so you can delegate the work without quietly delegating the judgment.
A way to tell a demo from a product
By the end you'll have a review you can run on any feature, covering the unglamorous things that decide whether it survives contact with real users: who's allowed to do what, what happens when a request arrives twice, what breaks when the schema changes underneath it.
How the day runs
One problem, carried the whole way through
- 09:30We start with a bad briefA real business problem, deliberately under-specified — the kind you'd normally receive on a Monday. We work backwards from the feature request to what somebody actually wants to be different.
- 11:00We cut it down and model itThe smallest version worth shipping, then the concepts underneath it: what things are called, how they relate, and which rules the system must never let you break.
- 13:30We build it with agentsWe choose an architecture because something is pushing on it, not because it's fashionable. Then we implement it in thin slices, working from the decisions we made rather than around them.
- 15:30We make it production-gradeWe go back through what we built the way an experienced engineer would, and find the things that would have broken later. This is usually the part people say they'll remember.
Who this is for
Be honest with yourself about this bit
A good fit
- Engineers who want to deliver more than tickets
- Anyone who'd rather be in the room when the decision gets made
- Anyone whose output went up this year while they're quietly unsure their impact did
Not a fit
- Anyone looking for prompt tips
- Anyone wanting a tutorial on one particular agent
- Watchers — you'll be the one building
Run by
Vijay Rangan
Twelve years building and scaling systems at ThoughtWorks, Postman, Gojek and Nubank, across payments, identity, developer tooling and large-scale backend architecture.
Dates
Upcoming dates
Nothing scheduled at the moment. Leave your details and I'll tell you when the next one is.
Questions