The Thing Only One Person Can Do
Every shift has capabilities held by exactly one rostered person. They are countable, the count is small, and the failure is entirely predictable.
Capabilities on one early shift
Needed on shift
7
Rostered
7
Actually present
3
Seven capabilities are needed and three of them are held by a single person each. Headcount is full. Three of the seven requirements are one phone call from failing, and the rota shows nothing.
An absence hurts in proportion to how replaceable the missing capability is, not to how many people were on shift. One of eight is trivial if the eight are interchangeable and total if the one held something nobody else holds.
The practical issue in “The Thing Only One Person Can Do” is easier to manage when operational time records can be checked without treating activity as intent. For teams exploring time tracking with screenshots, a practical route to time tracking with screenshots can add time and project context, provided collection is proportionate, employees can review inaccuracies and consequential decisions receive human review.
Those single-holder capabilities exist in every operation, they are a short and specific list, and almost nobody has written it down. The result is that the organisation discovers them one at a time, each time at six forty, each time as a surprise.
For an independent benchmark relevant to “The Thing Only One Person Can Do”, consult the WHO mental-health-at-work resources. Use it to test scheduling, working-time limits, attendance records, employee rights and exception handling against the real operation rather than treating a software report as self-explanatory evidence.
Finding them
For one shift pattern, list what has to be done. Against each, list which rostered people can do it. The ones with a single name are your list.
Half an hour per shift pattern. The output is usually between five and fifteen items per operation and it is immediately recognisable to anyone who works there — these are the things people already say out loud, in the form of "if she's off we're stuck".
What they usually turn out to be
A licence or certification: the forklift, the vehicle class, the controlled-drugs authorisation, the first-aider, the fire marshal, the competent person for a particular task.
A system permission: the only person who can authorise a payment, release an order, override a lock, or approve a change. These are the most common and the easiest to fix, because the fix is an administrative grant rather than training.
A key, a code, or a physical access right.
Local knowledge: the one person who knows the client, the route, the old machine, the resident who will not accept anybody else. This is the hardest to duplicate and the most often dismissed as not a real dependency, which it is.
A language, which in some operations is a hard requirement and in the data is invisible.
Fixing them, cheaply
Most of the list resolves for very little. Train a second person. Grant the permission to one more. Cut a second key. Document the local knowledge so somebody else can pick it up badly rather than not at all.
Do the system permissions first: they cost nothing, they take an afternoon, and they are usually the largest group. The reason there is only one person with the authorisation is almost never a decision — it is that nobody asked for a second.
Training takes longer and should be prioritised by how often the capability is needed, not by how senior it sounds. A capability required every shift with one holder is a weekly risk. One required monthly with one holder can wait.
The two-deep rule
The target worth adopting is that nothing required on a shift is held by fewer than two rostered people, and anything critical by three.
It is a target rather than a rule, because some capabilities genuinely cannot be duplicated quickly. Stating it as a target gives the gaps a status: a capability at one is a known, accepted, listed exposure rather than an invisible one, and when it fails nobody has to pretend to be surprised.
Keeping the list alive
It goes out of date the moment somebody leaves, changes role, or lets a certification lapse. Expiry dates are the common failure — a first-aid certificate that ran out in March means the organisation has believed it had cover for six months.
Tie the review to two triggers: any leaver, and any certification expiry. Both are already tracked somewhere, and joining them to the capability list is a smaller piece of work than it sounds.
What it does for the morning
The person on the phone can answer the only question that matters — can this shift run — instead of finding out at nine that it could not. And when the answer is no, they know immediately that the call-out list has to reach somebody specific rather than anybody at all, which changes who gets rung and in what order.
Who holds the register
The capability register tends to live in three incompatible places: a training spreadsheet, a certificate folder, and the scheduler's memory. None of them is consulted at six forty.
One owner, one list, and a column for the expiry date. The owner does not have to be senior; they have to be the person who finds out when somebody is trained, qualified, authorised or leaves. In most operations that is the scheduler or the administrator rather than the manager, and naming them is what stops the register ageing quietly for two years.