In our second AI wave talk, forward deployed engineering sat in the "where it's going" column of one of the slides. A few slides later we were walking through a real project at a national law firm that we'd already run that way. We just didn't have the name for it.
From the ideas backlog to citizen development
This is how it was, and still is in a lot of places. You keep an ideas backlog and chip away at it one or two at a time, as capacity allows. Each idea becomes a project: a spec up front, requirements gathering, a build team, and months from start to live. We have our own four-stage version, Initiate, Implement, Prepare and Operate, and we know it well.
Big law firms added a twist. They'd embed business analysts in a business unit to learn how it worked, and the analysts would bring use cases back to the backlog. Good ideas, written up nicely, waiting their turn.
Then came citizen development, with the people who know the work building it themselves. Even two years ago we were somewhat sceptical, and our own clients have proven us wrong many times since.
Vibe coding, which means describing what you want to an AI tool and refining it through conversation, has made prototypes so quick and cheap that people are building their own agents and small apps, one at a time. IT then helps them productionise and support those in a governed way. Most organisations are still in the backlog and project team world, and that's fine. It depends on how many people you have to put on it.
What forward deployed engineering means
Where it's heading is forward deployed engineering. Instead of embedding an analyst to bring ideas back to a list, you put a highly skilled engineer into the business: someone who can talk business and can talk this kind of technology.
The big difference is how they're measured, which is on outcomes. For a law firm, the target might be to reduce partner admin time, so the engineer works out what to build around the partners to bring it down. Because they're measured on the outcome, they're allowed to build and deploy to production.
What makes that realistic is that the way we build has changed too. With coding agents and skills, the next build is easier than the last. We call it building the machine that builds the machine. That's what lets one engineer inside the business get things live in weeks, with the people who do the work testing it and signing it off.
What it looked like at a national law firm
The project was a contract renewal process at a law firm that handles thousands of contract variation and renewal requests a year. The requests arrive in a shared mailbox and pass through the practice management system (PMS), a title search and the document management system (DMS) before the client gets their documents. By hand, that took over a week.
Before building anything, we asked the business what really mattered to them, and the answers changed the story. The three questions we asked are a piece of their own. Then we worked in four steps:
- We ran a governed proof of concept built on seven technical validations, the things we had to prove across creating the matter, the title search, generating the documents and filing to the DMS. The test was whether, if we could prove those and get the process from seven days down to four or fewer, going ahead would be an easy call. We wanted the answer within three weeks, and if we didn't have it we'd regroup and decide whether to move on.
- We did a scoped build of the supervision app, the agent and the workflows to manage the process.
- We worked as three amigos: a delegate from the client who can make decisions, our product owner (a business analyst), and a developer or solution architect. Every day or every week they run quick demos, answer questions and make the small decisions that would otherwise block things, in place of an all-hands meeting of ten or fifteen people.
- We ran thorough user acceptance testing, then went live with hypercare, meaning close support straight after launch.
Proofs of concept are broken right now. Too many drag on for weeks while someone tries to perfect them. A proof of concept should prove the concept inside a time box and stop. We learnt that at another Microsoft bootcamp in Sydney last year, and it has served us well, and our two-week PoC piece sets out what one should produce.
The build took ten to twelve weeks. It turned out to be a competitive differentiator for the firm, and the firm kept its client.
Looking back, that was forward deployed work. A small team sat next to the person who knows the process, decisions were made on the spot by someone who could make them, and the team built and shipped to production with a week-long process to bring down to days.
Getting IT comfortable first
IT teams are good to work with, every time. This was the third or fourth time we've worked directly with the business on a project like this, and it works much better. The condition is that IT are comfortable first, with the governance we'll follow and the security we need agreed up front. Once they're happy, they let us work forward deployed.
That doesn't mean skipping governance everywhere. A broker portal we built for a bank needed IT right in the middle of it, with high-level governance and a full project. Forward deployed suits something the size of this contract renewal process, worked directly with the people who own it.
What we'd do differently
Some clients want a governed proof of concept first. They want that comfort before committing further, and that's reasonable. We're now pushing to run it as part of the build instead of a separate stage.
The ten to twelve weeks was the build alone. Add two to three weeks of proof of concept and a couple of weeks of decision making, and you're at about seventeen weeks, or four to five months. We think all of it fits in ten to twelve weeks if you fold the proof into the early runs of the build, with an honest agreement to stop if it needs to stop.
Where to start
You don't need to hire a forward deployed engineer to start. Pick one process and one outcome to move, such as lead time, partner admin time or rework, and write it down. Name your three amigos: someone from the business who can make the decisions, someone who can turn that into requirements, and someone who can build. Agree the governance and security with IT up front, so they're comfortable stepping back, and time-box the proof by deciding before you start what has to be true and when you'll stop if it isn't.
The slide put the direction simply: our team next to your process now, and your own engineer next.