Forward Deployed Engineer
For engineers who want to be worth more than their output. You'll learn to decide what gets built, not just how to build it.
We take one messy business problem and carry it all the way to something you could put in front of real users. You do the building. I sit beside you while you do.
12+ years building and scaling systems at ThoughtWorks, Postman, Gojek and Nubank — payments, identity, developer tooling, large-scale backend architecture.
The role this workshop trains for is already being hired
This is not simply a new job title. It is a response to a deeper shift in enterprise engineering.
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 — and it is now scarce in public, in job postings you can go and read.
1,000%+
Growth in forward deployed engineer job postings, January to August 2026, against the same months in 2025
Fortune, on Lightcast data2,100+
Global Capability Centres now running in India, employing around 2.3 million people
Economic TimesAbsorb the ambiguity
Take a customer problem as it actually arrives — half-formed, contested, still being argued about — and work directly with the people who have it until there is something worth building.
Decide, then execute
Make the product and technical calls, integrate with enterprise systems nobody designed for you, and use AI to move at the speed those decisions now allow.
Own the outcome
Carry the work past the demo into production, and stay accountable for whether anything actually changed once real users arrived.
The same profile is being hired under other names, much of it close to home.
- Emids plans 1,000 forward-deployed context engineers in India over a year Times of India
- MathCo has announced 2,000 specialised AI roles, forward deployed engineers among them Express Computer
- Accenture is advertising the role in Bengaluru, from roughly three years of experience upward Accenture careers
The title may still change. The skill profile underneath it is not going to: enterprises are paying for engineers who can operate close to the problem, bridge the business and the technology, and carry work from ambiguity into production. That profile is what this day builds.
Why I run this
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. I think engineers have to expand their skill set as well. 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.
PROVE: my five step framework for making sure you're building the right thing
Every engagement starts with somebody handing you a solution. A thing they saw at a conference, a date already promised to a board. Your instinct is to work out how to build it. That instinct is now the expensive one.
So we prove the brief first.
- PPayoff
What number moves, and what is it worth?
If this column is empty: You are building on somebody's enthusiasm. You will ship the RIGHT solution to the WRONG problem.
- RReality
Walk me through what actually happens today.
If this column is empty: You are designing against the org chart, not the work. Every estimate is fiction.
- OOwnership
Who signs off that it is right, and who is worse off if it works?
If this column is empty: You get blocked in week six by someone you never met, or blindside someone who did not deserve it.
- VVerification
How would we know we were wrong?
If this column is empty: You have no definition of done. "It works" means whatever the last demo did.
- EEdges
What would stop us that is not code?
If this column is empty: Licences, contracts, data rules and notice periods arrive as surprises at the worst moment.
What you leave with
Turning a half-explained problem into a plan you can defend
You'll start with a request that doesn't say enough, and work backwards to what someone actually wants to be different. By the end you'll have named the parts, made the calls out loud, written down what must never break, and cut a first piece small enough to build. Vague work can't be checked. This kind can.
The handful of questions that change what gets built
There are always forty questions you could ask. Usually only a handful of them would alter the answer. You'll leave with PROVE — five columns, five questions — for finding those quickly, and for 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.
And these, to keep
The PROVE worksheet
The five columns as a page you fill in, one per brief. You'll run it on somebody else's problem during the day, then on your own for the rest of the year.
An agent skills pack
Skills that put PROVE inside the coding agent you already use, and hold it to code a colleague can still maintain — decades of software engineering practice, written down where an agent will actually read it.
A production-readiness review
The checklist from the last block of the day. Who's allowed to do what, what happens when a request arrives twice, what breaks when the schema moves underneath you. It runs on any feature, not only the one we built.
The ADR Pack
A template for writing a decision down so it survives the people who made it, and three worked examples of decisions that were worth the argument.
Cheap Code, Scarce Judgment
The book the day is built on, as PDF and EPUB. You don't have to wait for the workshop to get this one — it's further down this page.
A numbered certificate
Issued after you successfully complete the workshop.
Agenda
One problem, through the day. You won't watch me build.
- 01
We start with a brief
A real business problem, deliberately under-specified — the kind you'd normally receive on a Monday. Somebody has already decided what they want built. Nobody has said why.
- 02
We PROVE it
What number moves, what actually happens today, who signs it off and who is worse off, how we would know we were wrong, and what could stop us that isn't code. This is usually where the brief you were handed stops being the problem you have.
- 03
We cut it down and model it
The 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.
- 04
We build it with agents
We 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.
- 05
We make it production-grade
We 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
Every engineer, honestly — and I mean that as a claim, not a marketing line.
What's changed isn't the job description of a staff engineer. It's the definition of software engineering. If writing the code is no longer the scarce part, then everyone doing this job is being asked for something they weren't necessarily trained for, whether they're two years in or twenty. Judgment used to be the thing you grew into slowly, somewhere around your second or third serious outage. Now it's what the work expects from you up front — and I don't think it has ever mattered more than it does right now.
So come if you want to deliver more than tickets. Come if you'd rather be in the room when the decision gets made than hear about it afterwards. Come if your output went up this year and you're quietly unsure your impact did.
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
Prompt tips and a tour of one particular agent make a useful afternoon. This just isn't that one.
Vijay Rangan
12+ years building software at ThoughtWorks, Postman, Gojek and Nubank — payments, identity, developer tooling, and backends that had to stay up for tens of millions of people. Teams of ten, and teams of a few thousand.
These days I work as an embedded engineering partner to startups: inside the codebase, in the standups, accountable for what happens after a decision rather than only for making it. That's where this day comes from. The problems we work through are ones I either got wrong myself or watched go wrong from close enough to remember.
I also wrote Cheap Code, Scarce Judgment, which is the thinking model the workshop is built on — and which you can have for free, further down this page.
Connect on LinkedInWhat usually stops people
A whole day is a lot to give up
It is. The bet is that the day pays for itself in the work you're already doing, because the expensive mistakes in that work aren't typing mistakes — they're deciding to build the wrong thing carefully. One day is also the whole commitment. There is no six-week cohort waiting behind it.
Couldn't I pick this up from a blog post?
Some of it, yes, and you should. But reading about judgment and being made to exercise it are different activities. You'll spend the day making calls out loud, on a problem you didn't choose, with someone sitting next to you who will ask why. That part doesn't come out of a video.
Will my company pay for it?
Often, yes — ask before you pay yourself. Register and reply to your confirmation, and I'll send an invoice with whatever your finance team needs. There's a paragraph below you can forward to whoever signs it off.
How do I know it's any good before I pay?
Read the book first. It's free, it's a couple of hours at most, and it's the thinking model the entire day is built on. If it doesn't convince you, don't come.
A one-day workshop on taking an ambiguous business problem to production: scoping, domain modelling, architecture decisions, and delegating implementation to coding agents without delegating the judgment. It is hands-on — the attendee builds, working a real under-specified brief end to end — and PROVE, the discovery framework they leave with, applies to every brief the team picks up afterwards.
Cheap Code,
Scarce Judgment
The Engineer’s Guide to Building Products with AI.
- Seven chapters, 96 pages
- PDF and EPUB, both attached
- Free — it is the workshop’s thinking model
“Plausible software is not necessarily correct software.”
Where should I send it?
Tell me a little about where you are and I’ll send the book straight away.