Sitting with the desk
The real packet is not in the process document. It is in how the desk actually works. Forward-deployed engineers learn it by sitting there, watching, and asking about the exceptions.
· 4 min read
IN SHORT
Forward-deployed engineers sit with the desk because the real packet, what arrives, what a good result looks like, which step a person still takes, and where it lands, is rarely written down accurately. Watching the desk work and asking about exceptions produces a scope that matches reality and a first version the operators recognize as their own work.
Every desk has a process document, and every process document is wrong in ways that matter. Not because anyone lied. Because the document describes the desk as it was designed, and the desk has been running for years since then.
Forward-deployed engineers sit with the desk because the real packet is only visible there. This article describes what they are looking for and what they do with it.
What the engineer watches for
Four things, in roughly this order.
What arrives. The process document says a request comes in through a form. The desk shows that the form is used for half the requests and the rest arrive by message, by phone call, or by someone walking up. The engineer wants to see every channel that actually carries work, because the use case has to read from them.
What a good result looks like. The document says the desk produces a response. The desk shows that a good response has a particular shape: certain fields always filled, a certain tone, a certain thing it never says, a certain check done before it goes out. These are the bounds the first version will carry.
Which step a person still has to take. There is almost always one. A judgment call, a signature, a physical action, a relationship that should not be automated. The engineer wants to find it precisely, because that is where the version will draft and wait, and the role that performs it is the approving role.
Which system it has to land in. The document names one. The desk often reveals that the result goes into one system to count as done and into another for the people downstream to actually use. Both are systems of record, and both need declared routes.
The exceptions are the job
The main path of a desk is usually easy to describe and often not where the value is. The exceptions are where an experienced operator earns their place: the request that does not fit the categories, the record that contradicts itself, the customer who needs a different kind of answer.
Exceptions are learned one at a time. The engineer notices the operator do something different and asks why. The answer is sometimes a rule nobody wrote down and sometimes a judgment the operator cannot fully articulate. Either way, it goes into the picture of the packet.
A version that handles the main path and stops cleanly on every exception is a good first version. A version that tries to handle exceptions it never saw is a bad one. Sitting with the desk is how the engineer learns the difference.
From the desk to the scope
What the engineer learns becomes the scope. The channels that carry work become the material the use case may read. The systems the result lands in become the calls it may make through declared routes. The step that stays human becomes the approving role. The shape of a good result becomes the bounds.
In a forward-deployed engagement, the scope written at the start leaves room for this. It names the desk and the outcome and expects the detail to come from the desk. By the time the first version is composed in Agency Studio, the scope reflects the desk as it is, not as the document said.
From the desk to the first version
The first version is built within reach of the desk. The engineer composes it on the appliance, with the operators able to look at it. When a bound is set, the operator who knows the rule confirms it. When the version drafts something, the operator who would have written it says whether it is right.
This is where sitting with the desk turns into building with the people who will run it. The two are not phases. The sitting continues while the building happens, because every version raises a question only the desk can answer.
What the operators get from it
Operators are sometimes wary of an engineer watching their work. What usually changes their view is the first exception the version handles the way they would have, because they explained it. The version becomes theirs, built from their knowledge, carrying their rules.
That ownership is the point. A desk that drafts and waits is only done when the people at the desk recognize it as their own work and can change it. The practice page at /practice describes how certified engineers approach this, and naming what done means covers the statement the desk's packet feeds into.
Questions this raises
- How long does an engineer sit with the desk before building?
- Long enough to see the main path and a representative set of exceptions, which varies by desk. The practice does not fix a duration. Building usually starts while the sitting continues, because the first version raises questions that only the desk can answer.
- Does sitting with the desk disrupt the operators?
- It adds questions to their day, which the practice tries to keep short and timed to the work. Operators usually find it worthwhile because the questions are about their own exceptions, and the answers shape a version that handles them.
- What if the desk's work is confidential?
- The engineer is inside the segment under the site's own access rules, and sees only what the scope and the site's roles allow. The material stays on the appliance. Nothing the engineer learns leaves the building in any form.
KEEP READING