The Handoff Check

The decision it forces

Somewhere in your organization, work passes from one specialist to the next. A draft goes to a designer, a report goes to a reviewer, a case file goes from intake to someone who knows the law. Each pass has a queue, a sign-off, a calendar, and a reason it was set up that way.

Most of those reasons were good ones. Some of them were only good because the work used to be impossible for one person. That's the question this page asks, one handoff at a time: which is which, and what are you about to lose if you collapse the chain.

To run it, copy the prompt below into any model you already use.

The argument

Sam opened Episode 14 with it:

What processes in your organization only exist because the actual work used to be impossible? Not the hard stuff, the impossible stuff. somebody once needed a team or a budget or six different specialists to do it. So a process grew up around that, or some sort of queue or sign-off or handoff.

He closed it with the exercise this page turns into rows: pick one handoff, a place where work passes from one specialist to the next, write down what it protects, then ask whether the person with one capable model could do the whole chain, and if they could, where that would live and who would check it.

The order matters. What it protects comes before whether one person could do it. A handoff is two things at once: a transfer of work, and very often a second pair of eyes nobody ever wrote down as the point. Collapse the transfer and the second look goes with it, unless someone decides on purpose where it now lives.

The fields

One row per handoff. The left half is what a machine can map from a process document, a ticket history or an org chart. The right half is what it can't.

The verdict rule

A row with one_person: yes and an empty who_checks is the finding, not an incomplete row.

That's a handoff someone could collapse tomorrow, and if they did, the second look it carried would disappear without anyone deciding it should. Don't fill who_checks with "the team", a job title or "the model". Leave it empty, because the empty box is the true answer.

An empty protects is a finding too, of a different kind. If nobody can say what a handoff protects, either it protects nothing and is only there because the work used to need two people, or it protects something nobody has written down. Both are worth knowing before the chain changes.

Expect a first pass to come back with more empty boxes than filled ones on the right. That's what this looks like when it's working.

Run it with any model

This interviews and maps. It may never decide what a handoff protects, whether it can go, or who checks.

Help me run a Handoff Check: one row per handoff in a process I own, where work
passes from one specialist to the next, so I can see what each one protects
before anyone collapses the chain.

WHAT YOU DO
Help me list the handoffs and describe them. If I give you a process document, a
ticket history, a workflow export or an org chart, read it and draft the from,
to and what_passes columns from what is actually in it, showing me where each
one came from. Use roles, not people's names, in from and to.

WHAT YOU NEVER DO
1. Never fill protects, one_person, where_it_would_live, who_checks or
   still_worth_protecting. Not from a document, not from an inference, not from
   a plausible guess. Those columns are the point of the check, and an answer
   you supply is worse than a blank, because a blank is honest.
2. Never put a team, a function, a job title, a tool or a model in who_checks.
   If I answer with one, tell me that is a blank and ask me once for a person's
   name. If I do not have one, record null.
3. Never tell me a handoff should be removed, kept or automated, and never
   estimate the time or money a change would save. This check records what each
   handoff protects and who would look afterwards, not whether the change is a
   good idea.
4. Do not ask for credentials, customer data or the contents of any system.
   Roles, descriptions of the work and the names I choose to give are enough.

INTERVIEW ME, one handoff at a time, three questions at a time at most.

For each row ask from, to and what_passes. Then ask protects as "if this handoff
disappeared tomorrow and nothing replaced it, what would go wrong?" before
asking anything about collapsing it. Then one_person: yes, no or not_yet. If
yes, ask where_it_would_live, then ask who_checks as "whose name is on the
second look?", then still_worth_protecting. If no or not_yet, record the rest as
null and move on.

OUTPUT
Valid JSON matching the schema handoff-check/v0.1 as published at
https://sigsub.show/takeaways/handoff-check/, then the check as a table with
empty cells visibly empty rather than filled with dashes or placeholders, then
four counts: rows in total, rows where protects is unknown, rows marked
one_person yes, and rows marked yes with no named checker. End with one plain
sentence giving that last count, and nothing after it.

What to check in the answer

It can read a process document, map who passes what to whom, find the handoffs nobody listed, and count the rows. That's tedious, and better done by something that doesn't get bored.

It may never say what a handoff protects, whether it can go, or who checks once it's gone. A model asked for those will produce a confident, plausible answer, usually "quality" and "the team", and both turn a real gap into a filled cell nobody has to answer for. The second look a handoff carried is exactly the thing that disappears quietly. A machine that fills the box has made it disappear on paper too.

The other route

Jonathan, the guest on Episode 14, collapses chains for a living, and he's clear about where it stops working. Running one person across many parallel sessions, he said, is worthless for one little task; it only pays when there's a real idea to manage. And on the kind of AI that collapses a chain by regenerating everything at once:

if you're doing client work, they want you to change little tiny things. And if you used AI to generate that video, you're totally screwed.

His point is that the one-person route only holds when the output stays editable and the work is big enough to be worth managing. A row marked one_person: yes should survive both of his tests. He didn't speak to the handoff exercise itself on air, and nothing here puts him on the side of it.

The part that's not optional

Run it before the chain changes, not after. Once one person is already doing the whole thing, the protects column gets filled in from memory by the people who no longer do the work, and memory is kind to its own decisions.

Then take every row marked yes with an empty who_checks to whoever owns the process, and ask them one question: whose name goes on the second look? If nobody answers, the handoff stays until someone does.

There's no worked example on this page. A filled check names real people and real reporting lines inside one organization, and it belongs to them.

{
  "schema": "handoff-check/v0.1",
  "process_scope": "",
  "handoffs": [
    {
      "from": "",
      "to": "",
      "what_passes": "",
      "protects": null,
      "one_person": null,
      "where_it_would_live": null,
      "who_checks": null,
      "still_worth_protecting": null
    }
  ],
  "totals": {
    "rows": 0,
    "protects_unknown": 0,
    "collapsible": 0,
    "collapsible_unchecked": 0
  }
}