Training the site team to change it

The engagement is not finished when the use case works. It is finished when the people who own it can publish the next version without an engineer in the building. That standard shapes how E31 Consulting trains a site team: not a course at the end, but a transfer of the work itself while the work is being done.

Who gets trained

The site team is whoever will touch the use case after the handoff. On a desk that drafts and waits, that is the people who read the drafts and the person who approves them. On a corpus people can question, it is whoever curates the documents and whoever answers when a result looks wrong. On a product that ships under the customer's name, it is the team that owns releases.

It usually also includes someone from IT who owns the segment the appliance sits in, and the role that holds the right to publish. The training is not for everyone; it is for the named roles that appear in the version.

What they learn to do

The training is organised around changes, because changes are what the team will actually make. The engineers pick the changes this site is most likely to need and walk the team through each one on the real appliance, against the real version.

Publishing. An operator takes a small change from draft to published under their own role, and sees it appear in the version history with their name on it.

Changing the corpus. The team adds a document set, watches retrieval pick it up, and removes it again. They learn what the agent can see and how to prove it.

Moving an approval. A bound is moved from one role to another and the team confirms, by running a case, that the new role is the one that now waits.

Adding a route. A new declared route to an on-premise system is added, and the team sees that until it was declared the agent could not reach that system at all.

Reading the run record. The team opens the record for a run that went the way they expected and one that did not, and learns to tell from the record alone what the agent read, what it called, and who approved.

Republishing an earlier version. The team publishes the previous version again and confirms that the picture, the routes, and the approvals revert with it.

How it is taught

Forward-deployed engineers teach by sitting beside the person who will do the task and letting them do it. The first time, the engineer talks through it. The second time, the operator does it and the engineer watches. After that, the operator does it alone and the engineer is somewhere else in the building. The notes described in the published version and the notes to change it are written from these sessions, in the operator's words.

In an in-house project the training happens at handoff, on the customer's appliance, with the delivered version. The format is the same, compressed: each change in scope is performed by a member of the site team before the handoff is signed off.

How the practice knows it worked

There is one test. A member of the site team publishes a version, by themselves, that changes something real. If they can, the engagement can end. If they cannot, the training is not done, and no amount of documentation substitutes for it.

Certification is not part of the handoff. The site team does not become E31-certified by being trained; certification is for the engineers, and it is described in what a certified engineer is. What the site team gets is narrower and more useful: the ability to change the use case they own.

After the engineers leave

The team keeps the version history, the notes, and the record. They keep the habit of trying a change on a new version rather than editing the running one. When a change is bigger than the notes cover, that is the moment to scope a new project, as described in after the engagement: support and the next version. The ordinary changes stay with the site, which is where the practice meant them to be.