Skip to content
ELEMENT 31

Glossary: forward-deployed

Forward-deployed is the engagement form in which certified engineers join the team that owns the outcome, on site and inside the customer's segment, and finish when that team can publish alone.

· 2 min read

IN SHORT

Forward-deployed is one of the two forms an E31 Consulting engagement can take. Certified engineers join the team that owns the outcome, on site and inside the customer's network segment, learn the real packet by sitting with the desk, and build the use case on the customer's Czar with the people who will run it. The engagement ends when those people can publish the next version themselves.

Forward-deployed is one of the two forms an E31 Consulting engagement can take: certified engineers join the team that owns the outcome, on site, inside the customer's network segment, and build the use case with the people who will run it. The engagement is finished when those people can publish the next version themselves.

Why it matters

Most of what makes a use case work is not in any document. It is in what actually arrives at the desk, what a good result looks like to the person who handles it, which step a person still has to take, and which system the result has to land in. An engineer who is not in the building has to guess at those things. An engineer sitting with the desk does not.

Forward-deployed also changes who the work belongs to. Because it is built with the operators rather than for them, the operators know it from the inside by the time it is published. There is no transfer at the end because the transfer happened throughout.

How it works here

The engineers work inside the segment the customer's IT provides, on the customer's Czar, in the posture the customer has chosen. On an air-gapped site that means air-gapped work, with no path out. On a connected site it means using the systems the customer already secures and nothing more.

They learn the packet by sitting with the desk. They build the agent or workflow on Substrate and Agency, publishing versions as they go so the desk can try each one. They write the notes in the desk's own vocabulary while the questions are fresh. They train the site team by letting them make each change with their own hands.

The engagement ends when a member of the site team publishes a version alone. Engineer access ends with it. What the site holds is described in what the customer keeps.

The alternative form, where the customer describes the result and the engineers build it as a scoped project, is the in-house project. Choosing between them depends on whether the work can be described from outside the room.

Questions this raises

Is forward-deployed the same as staff augmentation?
No. The engineers are not added to the customer's headcount to do general work. They build one named use case to a stated definition of done, train the site team to change it, and leave when the team can publish without them.
Can forward-deployed work happen on an air-gapped site?
Yes. Air-gapped work is built air-gapped, on the air-gapped side of the site, with no path out. Certification includes being assessed on working inside sovereign sites, so the engineers arrive expecting it.
When is a project a better fit than forward-deployed?
When the customer can describe what should be true when the work is done from outside the room, name the materials, approvals, and systems in scope, and does not need engineers at the desk to learn the packet.

KEEP READING

Related.