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.

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.

And he closed it with the exercise this page turns into rows:

pick one handoff in your organization, a place where work passes from one specialist to the next. And write down what that handoff protects.

Could do the whole chain. And if they could, where that would live? Like who would check that? How can you think about that? What is actually worth protecting now?

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 check

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 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.

The schema

{
  "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
  }
}

The human fields are null rather than empty strings when nobody can fill them, so a count of nulls is a real number. one_person is one of yes, no or not_yet. collapsible counts the rows reading yes, and collapsible_unchecked counts those with who_checks still null.

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.

The other route

Jonathan, the guest on Episode 14, collapses chains for a living, and he's clear about where it stops working. On running one person across many parallel sessions:

granted, you can't just do this if you don't have a good idea If you're just trying to do one little task, it's kind of worthless.

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.

What a machine may never do

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 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.