How an engagement starts

An engagement does not start with an architecture diagram. It starts with a person describing what they want to be different, and an engineer asking enough questions to turn that into something a version can be built against.

This article walks through what happens at the start, from the first conversation to the written scope. It is the same for both engagement forms. The difference between forward-deployed and an in-house project shows up later, once the scope exists.

The first conversation is about the outcome

The opening question is always some version of the same thing: what should be true when the work is done. A desk that drafts the response and waits for a person to approve it. A set of the site's documents that anyone on the floor can question. A product that the customer's own customers run, under the customer's name.

The engineer's job in that conversation is to listen for the packet behind the description. What arrives at the desk, and in what form. What a good result looks like, and who decides that. Which step a person still has to take, no matter how good the automation becomes. Which system the result has to land in for the work to count as done.

Customers often arrive with a technology in mind. That is fine, but it is not where the practice starts. A use case is defined by its outcome, and the stack is chosen to serve it.

The posture is taken as given

Early in the start, the practice asks about the posture the site already has. Some sites are air-gapped, with no path out of the building and updates arriving by media. Some are connected, but only to systems the site already secures. Many estates are mixed, with different buildings in different postures.

The practice does not ask the site to change any of this. Air-gapped work is built air-gapped. Connected work uses the systems the customer already secures. A mixed estate stays a mixed estate, and the use case is built to live inside whichever posture the building has.

Knowing the posture at the start matters because it shapes everything after. It decides where the engineers sit, how material reaches the appliance, how a version is published, and how the handoff happens. It is one of the few things that cannot be left vague.

Choosing the form

With the outcome described and the posture known, the next decision is the form. If the work is already well understood and the owner can describe the packet in a sitting, an in-house project can carry it. If the work still lives mostly in the heads of the people doing it, forward-deployed engineers go and learn it on site.

The decision is not permanent. Engagements change form when the work turns out to be different from what was described. But a form has to be chosen at the start, because it decides who is in the room when the first version is built.

Writing the scope

The last step of the start is a scope both sides can point to. It names four things.

The material the use case may read: which documents, which records, which feeds. The calls it may make: which on-premise systems it reaches through declared routes, and for what. The role that approves: the named role whose approval a version waits for before an action lands. The systems of record: where the result goes so the work counts as done.

For a forward-deployed engagement, the scope describes the desk and the outcome, and leaves room for what the engineers learn on site. For a project, the scope is the contract: the version that comes back is built to it and nothing else.

Either way, the scope is written before anything is built. It is the first artifact the customer holds, and it is the thing the handoff is measured against.

When intake opens

Intake on the site is not yet open. When it is, the engagements page at /engagements is where the start will be described. In the meantime, naming what done means covers the first conversation in more depth, and two ways an engagement can run covers the choice of form.