A forward deployed engineer is dropped into your domain. A forward developed one is built out of it. This is the final part of a series1 on the forward deployed engineer. Part 1 followed the money into the role and asked who owns the intelligence that compounds. Part 2 traced the pattern from Frederick Winslow Taylor and the soldiering it produced through Meta this spring. I then observed that in Toyota the capability to improve the work has been built into the people doing it; this final part is about doing that on purpose.
Not forward deployed. Forward developed. An engineer built out of a domain expert rather than dropped into a domain.
The difference shows up in staffing. The deployed path writes a job description, sources candidates from software, hires against a scarce and expensive profile, and hopes domain knowledge accrues over the engagement. The developed path starts at the other end. Name a workflow problem, build the project team out of the people who run that work, and give them the tools, the time, and a support structure. The AI capability accrues as a byproduct of solving a problem they already cared about, and it stays where it accrued.
Someone will object that this only works for incremental change, and that what AI brings is not incremental. Lean has a word for the other kind. Kaikaku is radical change, the deliberate redesign of a process rather than the patient improvement of it, and it has always been done differently than kaizen: you hand the challenge to a cross-functional team assembled for it, and it still beats outsourcing the redesign to someone who arrives, runs stakeholder interviews, and hands back a new way for your people to work. Be honest with the team about what happens at the end of it. In the face of radical change, there are no easy answers, only more and less honorable ones.
There is a condition on all of it, and it is the one the soldiering arithmetic already exposed. People surface their methods when disclosure stops being used against them. That is a management commitment with content: improvement costs nobody their employment, the person who finds 20 minutes in a four-hour task shares in the gain, and teaching the better method is paid work rather than a tax on competence. Toyota’s version was employment security tied to improvement. The Training Within Industry (TWI) version was building the programs into how the place was managed, which is why it survived there and evaporated everywhere else. Withhold the commitment and the forward developed engineer is a new name for someone you have asked to volunteer for their own redesign. They will do the math. They always have.
People surface their methods when disclosure stops being used against them.
The vendors have conceded the premise: Varick’s CEO and the technology leader with the unfillable requisitions, both from Part 1 of this series, reached the same conclusion from opposite sides of the table, which is that the person does not exist in sufficient numbers.
From there, two directions can be taken. Scramble for the scarce outsiders and the tooling to multiply them. Or build proficiency on the inside, where the context the deployed engineer is burning out trying to extract already lives. Most organizations will need some of both.
The hard part is not the strategy. It is that the people best equipped to redesign the work are usually your strongest performers, and a manager asked to release somebody for an improvement project will part with almost anyone else first. That is not obstruction. It is the same arithmetic that keeps improvement work from happening in ordinary times. You need a mix regardless: somebody who knows the work cold, somebody patient enough to sit with the tool until it breaks, somebody with enough standing to get a decision made, and behind them a manager who still owns the balance of demand and pace because that is where the improvement gets cashed. Naming that requirement before you ask is what gets you the person you need rather than the person who happened to be free.
With the forward developed engineer approach you will need to run more than one experiment. A single careful pilot tells you what happened once, in one process, with one team. Several at once, in different domains, will show you where your data actually lives, what your documentation was hiding, and which people move toward this work when nobody is making them. That last one is the real output, and those people are usually not who the org chart would nominate.
A hackathon on a real problem works, with two rules that matter more than the agenda. Be as lazy as possible: keep handing work back to the tool until it breaks, because the break is the information. And start as early as possible: bring the tool into the thinking and the framing of the problem, not just the finishing of the deliverable. Most people reach for it too late, when the hard decisions have already been made without it.
In a Claude Code hackathon Anthropic ran this past February, 500 selected participants got one week to build. Four of the five winners were not professional developers: a personal injury lawyer, a cardiologist, a roads and infrastructure specialist, and an electronic musician. First place went to the lawyer, who built a tool for California’s permitting bottleneck without writing the code himself.2
We have been watching the same thing at closer range. Andy Buczewski, Director of Operations at Viwinco, and Chinua Akaosa, Distribution and Warehouse Manager at O.C. Tanner, both came to this from the domain rather than from technology, and both now build things their technology organizations did not expect them to be able to build. The reaction from those leaders is consistent: surprise at the speed, then a reclassification. The domain expert stops being a stakeholder and becomes a resource. Art Smalley is currently running weekly practice sessions with homework for a purchasing group, working up a ladder of capability while they solve a live problem inside their own function, so that when the end-to-end redesign eventually comes, they arrive as participants rather than as interview subjects.
Then watch who catches the bug. In any group of 30, three or four will stay in it past the point where the exercise ended. Those are your candidates, and the intervention is small: real tool access, a workflow to own, protected time. But surfacing them is only one of the exercise’s jobs. It tells everyone else that the work is changing, and making time for the team to engage in both structured and unstructured ways signals your organization’s commitment to developing people, not just machines.
What we take from this is not that such people are rare. It is that most organizations have several, and that forces are at work to keep them hidden. Nothing in the structure selects for them, and the incentives make developing them expensive for the very people with the sway to do it. That is the constraint, and it is a management problem rather than a talent problem. Then move on what worked, into real process redesign rather than another pilot, because pilots that stay pilots produce learning that never compounds. TWI succeeded nearly everywhere it ran. It compounded only at Toyota, where it was built into how the place was managed instead of run as a program.
And a last word on whether this capability can simply be bought. It can. What cannot be bought is an end to the buying. The tuning does not hold still. The models change every few weeks, so what fit the work last quarter needs refitting this one, and the fitting is the part that requires knowing the work. Nobody is going to reprocure a vendor engagement every time the ground moves, and the vendors know it, which is why the new offers look less like projects than residencies. Rent the refitting and you carry a standing cost that grows with the pace of the technology, and every refit runs your process knowledge through the vendor’s loop one more time. Develop it and the same volatility works for you: each model release is practice for people who already know the work. The faster the technology improves, the wider that difference gets.
In the absence of the highly specialized person you cannot find, you have good leadership and well-run experiments. That is a less impressive line item than a forward deployed engineer. It is also the only thing on the list you already own.
The tools are new. The choice is not.
Organizations that can will buy the deployed version, because it has a title, a number, and a vendor, and because it can be defended in the room before the quarter closes. Some will insource it and rebuild the planning department behind their own perimeter. A few will do the harder thing.
You are going to have forward engineers. The technology is not optional, and the mandate is already written. The only question left is the preposition: whether they are deployed into your organization or developed out of it.
Judgment and accountability stay human. The question is whose.
Lean AI Basics gives your practitioners a repeatable framework for putting AI to work in lean, taught live by Art Smalley. Two sessions, online. See dates and register.