On a Thursday morning, a member organisation of Hantam Service Cooperative, a fictional shared-services cooperative in the Northern Cape, saw its cloud storage cost double overnight. The daily anomaly rota caught it within the hour. The second cloud cost analyst, who works Wednesday to Friday, picked it up. But the member's account had been Naledi's until the previous month, and Naledi works Monday to Wednesday.
Without the record, it would have waited until Monday, Naledi's next working day. This time the analyst opened the member's decision record and found the answer in four lines: a fortnight before, Naledi and the member had agreed to move archived backups to a cheaper storage tier, and the migration job had been scheduled for that week. The cost spike was a temporary double-storage period during the move, expected to last three days. The analyst confirmed the job's progress with the platform engineer, wrote a two-line note to the member and closed the alert by noon.
Nothing clever happened. Someone had written down a decision where the next person would look for it. That is most of what makes reduced-time work possible, and it is the subject of this article.
Context is state, and it has to live somewhere
Architects will recognise the problem. A team in which some people are present only on certain days behaves like a distributed system with nodes that are intermittently available. Work in progress is state. If that state lives only in one person's memory, a chat thread or a meeting nobody minuted, it is unavailable whenever that person is.
Full-time teams get away with keeping context in heads because the heads are usually around. Reduced-time teams cannot. The design work in Part 2 reduced the scope of the role. The work here makes sure that what remains can be picked up, checked and continued by someone else on the days the role-holder is not working.
At Hantam the team's week looks like this.
Naledi's regular days are Monday to Wednesday and the second analyst's Wednesday to Friday, and Wednesday is the overlap day used for joint review and handover. In close week each works the first three working days of the month instead, dropping other days, as agreed in writing. The anomaly rota covers every working day. Escalation never defaults to whoever is not working.
Five components
Hantam's arrangement has five parts. None needs special software. All of them need discipline.
1. A single queue of open work. Every open item, whether a member query, an anomaly investigation or a pending recommendation, sits in one shared list with an owner, a status, the next action and the date it is due. Items do not live in personal inboxes. If it is not in the queue, it is not being worked on.
2. A handover note at the end of each working block. Each analyst ends her last working day with a short structured note.
The note has five fields: what changed since the last note, what is in flight and its next action, what is waiting on someone else and since when, what the covering person may decide alone, and what must wait for the owner's return. The fourth and fifth fields matter most. They tell the person covering where their authority ends, which prevents both paralysis and overreach.
3. Decision records for anything that outlasts a week. A commitment purchase, a change to how a member's costs are allocated, an agreement to tolerate a temporary cost: each gets a short record with the context, the decision, the alternatives considered, who decided and when it should be reviewed. This is the same practice that keeps architecture decisions traceable, described in Living architecture documentation, applied to operational choices. It is the record that saved the Thursday morning.
4. An escalation route that does not depend on the absent person. For each type of event, the route names who acts on non-working days and at what threshold. At Hantam, a cost anomaly above an agreed amount goes to the rota, then to the platform lead, then to the finance director. The reduced-time analyst is informed in her next handover, not phoned at home. A small number of genuinely exceptional events can justify an agreed contact on a non-working day; those are listed, and the list is short.
5. Meeting rules that do not exclude. Decisions that affect the analysts' work are not made in meetings they cannot attend. Standing meetings are held on the overlap day or replaced with written updates. Pre-reads go out a working day in advance, and written comments on them count as contributions. A comment on a document is not the same as approval, a distinction explored in Comments are not approval, so decisions that need sign-off say who signs and how.
The Monday test
Hantam tests the arrangement with one question, asked once a quarter as a short drill: could someone pick up any open item on Monday morning from the written record alone, without phoning anyone?
The platform lead picks three open items at random from the queue and tries to continue them using only the queue, the latest handover note and the decision records. Every gap found is a gap in the record, not a failing by the person who was away. In the first drill, two of three items passed. The third failed because a member had agreed a change by phone and nobody had written it down. The rule that followed was simple: any agreement with a member is recorded the same day, by whoever made it.
The drill matters because the architecture degrades quietly. A team under pressure starts making decisions in chat, skipping handover notes on busy days and phoning people who are not working "just this once". By the time anyone notices, the reduced-time role has become a full-time role with less pay.
Where AI helps, and where it must not
AI tools are genuinely useful here, and they are also a new way to lose information.
They help with drafting. At Hantam, the assistant drafts the handover note from the week's queue changes, the analyst's working notes and the member correspondence. It drafts a decision record from a meeting transcript. It summarises a long thread into the three facts the covering analyst needs. That reduces the cost of writing things down, which is the main reason people skip it.
They must not become the record unchecked. A summary that drops a caveat, such as "the member agreed, subject to their board's approval", is worse than no summary, because it looks complete. So the rule is that the author reads and edits every AI-drafted note before it is saved, and the saved note carries her name, not the tool's. The broader principle, that a person relying on AI output must be able to show what they checked, is set out in The human in the loop must show their work.
There is a data question too. Handover notes and decision records about members contain their cost and usage data, and sometimes commercial terms. Which AI service may see that material is a confidentiality decision, made once and written down, as described in Confidentiality before convenience. Hantam's analysts use the cooperative's approved assistant for these drafts and nothing else. This is general information, not legal advice; how member data may be processed is a matter for your privacy and legal advisers.
The second-class participant problem
The quiet risk in any team with mixed working patterns is that reduced-time colleagues become less informed, less consulted and less visible, and then less likely to be promoted. It rarely happens by intent. It happens because decisions drift to whoever is in the room.
The five components are the structural defence. Three habits reinforce them:
- Decisions are announced in writing, in the queue or a decision record, not only in the meeting where they were made.
- Credit is attributed in writing. The monthly report to members names the analyst who did the work, whatever days she works.
- The overlap day is protected. It is not filled with unrelated meetings, because it is the team's main synchronous time.
These are the same disciplines a well-run distributed team uses across time zones. They are rarely applied to colleagues in the same office who simply work different days.
A minimum standard
| Component | Minimum standard | Owner |
|---|---|---|
| Open-work queue | One list, every item with owner, status, next action and due date | Each analyst for her items; team lead checks weekly |
| Handover note | Five fields, written at the end of each working block | The analyst going off shift |
| Decision records | Any decision that outlasts a week, with review date | Whoever made the decision |
| Escalation route | By event type and threshold; absent person is never the default | Team lead |
| Meeting rules | Decisions in writing; standing meetings on the overlap day; pre-reads a day ahead | Meeting owner |
| Monday test | Quarterly drill on three random open items | Platform lead |
Key points
- A team with reduced-time roles behaves like a distributed system: context is state, and it must live where others can read it.
- Five components carry the load: one open-work queue, a structured handover note, decision records, an escalation route that does not depend on the absent person, and inclusive meeting rules.
- The handover note must say what the covering person may decide alone and what must wait.
- Test the arrangement with a regular drill. It degrades quietly under pressure.
- AI lowers the cost of writing things down, but the author checks every AI-drafted record before it becomes the record.
Next: Part 5, The talent pool we designed out of work. All parts are on the series page.
How CloudNala can help
CloudNala helps teams build the working architecture that reduced-time and distributed roles depend on. We set up the open-work queue, handover and decision-record templates, design escalation routes for non-working days, configure AI drafting so that people check what is saved, and run the first Monday-test drill with your team, so that the arrangement holds up under pressure rather than only on good weeks.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Talk to us about AI and work design or write to us at consult@cloudnala.co.za