Who owns the process when nobody is in the same room.

Most processes that worked in one location were never fully designed. A share of the coordination was environmental: someone noticed a colleague was stuck, a question got answered across a desk, a job that had stopped moving was visible because the person responsible was visibly not doing it.

Distribute the same team and the work is unchanged while that mechanism disappears. The process does not break loudly. It develops gaps that nobody can see, and the first evidence is usually a customer asking about something everyone assumed was handled.

This is why remote operations problems are so often misdiagnosed as motivation or communication problems. The underlying issue is that responsibility was implicit, and implicit responsibility requires proximity to work.

The diagnostic question is not "is everyone working?" but "if a task stopped moving today, how long before somebody noticed, and who would it be?"

Ownership gets used loosely, usually to mean the person who does the work. That is insufficient remotely, because the failure mode is not the work going undone by a known person — it is nobody being sure whose turn it was.

A step is owned when all four are true:

• A NAMED ROLE

  Not a team and not a rota that lives in someone's memory. If the answer to who owns this is a department, it is unowned during every hour that nobody picks it up.

• VISIBLE HOLDING

  Other people can see that this person currently holds it, without asking them. Ownership that requires a message to discover is ownership that is discovered late.

• AUTHORITY TO DECIDE

  The owner can settle the ordinary questions the step raises. An owner who must escalate every decision is a queue, not an owner.

• A DEFINED RELEASE

  An agreed moment at which they stop owning it - handed on, completed, or escalated. Without this, items are silently owned by whoever touched them last.

In a distributed team, most handovers are messages. A message is a notification, not a transfer: it tells somebody that something exists without establishing that they have accepted it. The sender believes the work has moved; the receiver has an unread item among many.

That asymmetry is the source of a surprising amount of remote operational failure, and it is not solved by better messaging discipline. It is solved by making acceptance an explicit state that both sides can see.

A process designed for people who share working hours assumes a question can be answered within the task. Spread that team across a meaningful time difference and every implicit question becomes a day of latency.

The productive response is not to force overlap, which usually means somebody working unsociable hours permanently. It is to reduce the number of steps that require a synchronous answer — by making decision rules explicit, by giving the owner authority to settle ordinary questions, and by ensuring a handover carries enough context that the receiver does not have to ask.

Where overlap is genuinely required, it should be named as a requirement of that step rather than expected of everybody all day.

1. 01

   Held and progressing

   Owner

   The current named owner

   Advances when

   Work continues within their hours

2. 02

   Blocked on a question

   Owner

   Still the current owner

   Advances when

   The question is answered, or a stated rule lets them decide

   Ends when

   Sits for a full cycle if neither is available

3. 03

   Handed over, unaccepted

   Owner

   Nobody

   Advances when

   The receiver accepts at the start of their day

   Ends when

   Ages invisibly if the queue has no surface

4. 04

   Escalated

   Owner

   The escalation owner

   Advances when

   Decided and returned with the reason recorded

   Ends when

   Returns to the original queue if the escalation is unowned

This does not require reorganising the team. It requires making a small number of existing moments explicit, starting with the ones where work most often goes quiet.

1. 01

   Find where work goes quiet

   Decides

   At which points do items stop moving without anyone noticing?

   Output

   A short list of real stall points rather than a full process map.

2. 02

   Name a role for each

   Decides

   Who owns this step, by role?

   Output

   Every stall point has a named owner, including the unpopular ones.

3. 03

   Make holding visible

   Decides

   How can anyone see who holds this right now?

   Output

   A shared surface where current ownership is readable without asking.

4. 04

   Turn the worst handover into a transfer

   Decides

   What does acceptance look like, and what happens if it does not come?

   Output

   One handover with an explicit accepted state and a visible unclaimed state.

5. 05

   Write the decision rules the owner may use

   Decides

   Which questions can the owner settle without asking?

   Output

   Fewer steps that require a synchronous answer.

6. 06

   Give ageing a consequence

   Decides

   What happens to an item nobody has claimed?

   Output

   An escalation that triggers on age rather than on somebody remembering.

You cannot assign an owner to a step that has not been described, and you cannot hand over work whose acceptance condition nobody has stated. In practice, ownership and documentation are the same project approached from two directions: documentation makes the steps nameable, and ownership makes them answerable.

That is also why remote operations tend to expose documentation debt quickly. The gaps were always there; proximity was covering them. Distributing the team removes the cover, and the first symptom is a series of questions that turn out to have no agreed answer.

Ownership is easy to declare and hard to verify. A chart with names against steps proves that somebody assigned them, not that the assignment survives contact with a busy week. Because the failure mode is silence, the evidence has to be looked for on purpose.

Four signals are worth watching, and all of them describe the gaps rather than the work. The age of the oldest unclaimed item says whether handovers are being accepted or merely sent. The proportion of items that come back after being handed on says whether the acceptance condition was ever clear. The number of escalated questions that turn out to have no agreed answer says where the decision rules are missing. And the count of items whose owner changed without a recorded release says where ownership is still being inherited by whoever touched the work last.

These belong in the operational category rather than the reporting one: each should prompt an action, and each needs a route to the specific items behind it. A trend line of average handover time will not do the same job, because the average is largely made of the cases that worked.

The purpose of measuring here is not oversight of people. It is that in a distributed operation the gaps are the only part of the process nobody experiences directly — which makes them the only part that has to be made visible deliberately.

Much of this is internal work and should stay that way. A team that can name its stall points, assign roles and agree a few decision rules does not need outside help to do so, and will own the result better for having done it.

The point at which outside ownership becomes worth considering is narrower: when the operation needs someone accountable for running it rather than advising on it, when the stall points keep returning because nobody has the time to hold the system rather than the tasks, or when the process has to keep working across hours nobody internally can cover.

That is a different engagement from process advice, and it is worth being clear about which one is actually needed before buying either.

1. Co-location was performing part of the coordination; distributing a team removes that mechanism without changing the work, so gaps appear where responsibility was implicit.
2. A step is owned only when a named role holds it, the holding is visible without asking, the owner may settle ordinary questions, and there is a defined moment of release.
3. A message is a notification, not a transfer; acceptance has to be an explicit, visible state or handovers age silently in threads.
4. Time-zone distance is a design constraint: reduce the steps that need a synchronous answer rather than forcing permanent overlap.
5. Ownership and documentation are one project from two directions - you cannot own a step nobody has described.
6. Ageing needs a consequence: escalation should trigger on elapsed time rather than on somebody remembering to check.