Building with the people who will run it

There is a kind of consulting engagement where engineers disappear for a stretch, return with something that works, and hand it over with a training session. It can produce good software. It rarely produces a team that owns it.

Forward-deployed work at E31 Consulting is built the other way around. The operators who will run the use case are part of building it, and the engineers' job is as much to put decisions in the operators' hands as to make the version work.

Who is in the room

Three roles from the site need to be inside the build.

The operators at the desk. They know what arrives and what a good result looks like. When a bound is set in Agency Studio, one of them confirms it is the right rule. When the version drafts a response, one of them says whether they would have sent it.

The approving role. Somewhere in the use case a person has to act before an action lands. That person, or someone in that role, should see the approval step as it is built, so that when the version waits for them in production it is waiting the way they expected.

The person who will own publishing. After the engineers leave, someone on the site team publishes the next version. They should be watching, and then doing, each publish during the engagement.

None of these people need to be engineers. They need to know the work, which they already do.

How the keyboard moves

Early in the engagement, the engineers do the hands-on work. They compose the first agents, index the first corpus, declare the first routes, and publish the first version. The operators watch, answer questions, and confirm decisions.

As the engagement goes on, the keyboard moves. An operator adds the next set of material to the corpus. The approving role adjusts the bound that was too tight. The publisher sends a version through approval and publishes it with an engineer watching.

By the last stretch, the engineers are answering questions and keeping their hands off. The site team is making the changes. This is not a ceremony at the end; it is a gradient that runs the length of the engagement.

Why this is the method and not a courtesy

Building together is what makes the end of a forward-deployed engagement testable. The test is whether the site team can publish the next version alone. A team that has made every decision inside the version, with an engineer beside them, can. A team that received a finished version and a document usually cannot, not because the document is bad but because they were never inside the decisions.

It also produces a better version. Every bound carries an operator's rule. Every exception the version stops on is one an operator explained. The version is the desk's own knowledge, made explicit and published, which is why the desk recognizes it as theirs.

The operating picture is built, not written

The operating picture is who may publish, which model the version uses, where a person has to approve, and which systems it may call. In a version built with the operators, each of those was decided by someone on the site team, inside Agency Studio, on the appliance.

That is why the picture survives the engineers leaving. It was never the engineers' picture. It is a set of properties of the version that the people who set them can read and change.

What this asks of the site

Building together asks for the operators' time, in short stretches timed to the work. It asks for the approving role to be reachable. It asks for someone to own publishing before the engagement ends, not after.

In return, the site gets a team that can change what was built, which is the only outcome the practice counts as finished. Finished when your people can publish alone describes the test at the end, and methods that survive the engineers leaving describes the working habits that make it hold. The practice page at /practice covers how certified engineers are trained to work this way.