The Rota Is a Design Artefact
On-call · June 22, 2026 · 10 min read
Almost every security team’s rota was produced the same way. Someone opened a spreadsheet, listed the people available, divided the week among them, and adjusted until nobody objected loudly enough to stop it. The requirements were never written down, so the schedule cannot be evaluated against them, and when it fails it fails as a personnel problem rather than a design problem.
A rota is an engineering artefact. It has requirements, constraints, failure modes and a maintenance cost, and it deserves the seriousness given to any other component the organisation depends on continuously.
Write the requirements first
Before any names go into any cells, four things need stating, because they are in tension and the schedule is where the tension gets resolved.
Coverage. Which hours must be attended, and by what capability? “Around the clock” is rarely the real requirement and is expensive to over-specify. The honest version is stratified: certain events need someone awake and looking within minutes at any hour, and everything else can wait until morning. If that distinction is not made explicitly, it gets made implicitly and badly by whoever holds the pager at four in the morning.
Response latency. Not one number but three: acknowledging, beginning work, and having the right people assembled. Acknowledgement can be made fast cheaply. Assembly is slow and expensive, and it is what actually determines how long an incident runs.
Sustainability. How often a person is disturbed outside working hours, how often that disturbance costs them a night’s sleep, and how many consecutive weeks it continues. This is the requirement that never gets written down, and the one that decides whether the rota still exists in a year.
Competence retention. A rota that puts the same two people on everything difficult produces a fast response now and a fragile team later. Deliberately exposing less experienced staff to real events, with support, is a requirement rather than a concession — and it costs response time, so it has to be a stated trade instead of an accident.
The arithmetic nobody does until it is too late
A week contains one hundred and sixty-eight hours. A nominal working week in your jurisdiction contains far fewer. Dividing the first by the second gives a number of people, and that number is where the calculation begins. The real figure has to absorb annual leave, public holidays, sickness, training, notice periods and the ramp time of whoever replaces the person who left. It has to reserve capacity for the work that stops next year’s operational load being worse than this year’s — a team spending all its available hours on the queue guarantees the queue grows. And if the design says nobody works alone, the multiplier applies to every covered hour rather than to the total.
Two consequences follow, both unwelcome. Continuous coverage from a small team is arithmetically impossible without one of three concessions: accept gaps, accept that people work in a way that damages them, or accept that coverage means “someone is contactable” rather than “someone is working”. All three are legitimate choices, and none survives being left unstated, because the organisation will assume the most expensive interpretation while the team delivers the cheapest one.
And the marginal cost of extending coverage is not linear. Business hours to extended hours is an increment. Extended hours to genuinely continuous attendance crosses a threshold where night work, its regulatory constraints and its health consequences all arrive at once, and the team roughly doubles rather than growing by a fraction.
Night work has no good answer, only priced ones
Every arrangement for covering the small hours has a cost. Name which one you are choosing.
Follow the sun removes night work by moving it to somewhere it is daytime. The price is a handover boundary in the middle of every piece of in-flight work, context duplicated in two or three places, and a coordination overhead that is easy to underestimate. It suits transactional work and hurts investigative work.
Fixed night shifts give the rest of the team their sleep and concentrate the harm on a few people. More humane than rotating nights in one respect — the body partially adapts to a stable schedule — and worse in another, because those people are progressively disconnected from the daytime organisation and its decisions.
Rotating nights distribute the load fairly and prevent that adaptation, which is the mechanism by which fatigue accumulates. If this is the choice, the direction and speed of rotation and the recovery periods are the parameters that matter, and they deserve more thought than they usually get.
On-call from home is the cheapest option and the one most often adopted without acknowledging its precondition: it is tenable only if the expected number of night pages is genuinely low. If people are being woken regularly it is not a cheaper form of coverage, it is night work performed by people who are also expected at their desks the next morning — the worst of the four.
That precondition points somewhere important. The page rate is not a fact of nature. It is a design parameter, controlled by what is permitted to page, and it is the single most powerful lever on whether the rota is sustainable.
The pager needs a budget
Give the rota an explicit page budget: the number of out-of-hours interruptions per shift the design can absorb without harm. Then treat exceeding it as a defect in whatever generates pages, rather than a condition to be endured.
That inverts the usual dynamic, in which page volume is incoming weather and the team’s job is to withstand it. Under a budget, a recurring page is a bug with an owner, and the response to a persistent night-time alert becomes changing the condition that produces it, moving it to the morning queue, or accepting that it does not warrant a human — decisions that are obvious in daylight and impossible while holding the pager.
Anything permitted to wake a human should therefore justify it in advance. For each such condition, ask one question: what will the person woken up be able to do at that hour that could not wait? If the honest answer is “make a note of it”, it is not a page.
Handover is an interface, not a courtesy
The most common place for operational state to be destroyed is the boundary between two shifts. The outgoing person knows things that exist nowhere else: a hypothesis half-tested, a supplier who promised to call back, a system deliberately left in an unusual state, an event that looked odd but was not pursued.
Treat the handover as an interface with a defined payload rather than a conversation. Written, so it survives the receiver forgetting it. Structured, so nothing is omitted merely because it did not come to mind. Explicit about what was deliberately not done and why, the class of information most reliably lost. And confirmed complete by the receiving shift, because the outgoing shift is tired and motivated to leave. A handover consisting of “nothing much happened” is a missing record with a friendly tone.
Measure the rota, not just the outcomes
The metrics reported for an operations function describe events. The ones that predict whether the function survives describe the shifts. Watch out-of-hours interruptions per person per rotation, the proportion falling during sleeping hours, the longest run of consecutive on-call weeks anybody is carrying, the rate of short-notice swaps, and how often the schedule changes less than a fortnight before the affected date. That last one is the most neglected: unpredictability is more corrosive than volume, because people arrange their lives around a schedule and one that moves underneath them costs far more goodwill per hour than one that is demanding but fixed.
Then test whether the design is real. Remove any one person from the schedule for a month, without warning, and see whether the rota still satisfies its requirements. If it functions only when everybody is present and well, it is not a design. It is a run of good luck with a spreadsheet attached.