Hybrid work: design an operating model, not an attendance calendar

When a request gets stuck between locations

In this fictional scene set in 2021, a service team divides its week between office and home. A request reaches an on-site manager on Tuesday. The manager talks to two colleagues at a table and changes its priority verbally. On Wednesday, a remote analyst still processes the previous version. Connectivity works, but work does not move reliably. All people, timings, volumes and outcomes in this article are invented teaching examples. They do not describe a CYTIZEN client engagement or an observed client result.

Design hybrid work around the journey from request to decision and from decision to verified execution. The attendance calendar follows that design. Secure remote access is necessary, but it does not define who decides, what must be written or how an urgent request should travel. This retrospective analysis uses official guidance and GitLab's public handbook checked in October 2026. Their current pages are contemporary references, not claimed snapshots of the guidance available in 2021.

Map the handovers

Select a frequent flow, such as a commercial change request, and follow cases from arrival to closure. Observe where someone waits for information, access or approval. Separate working time from waiting time. Identify where the decision actually lives: a ticket, an email, a conversation or a manager's memory. A useful map describes required inputs, expected outputs and responsibility for each handover. An organisation chart alone will not reveal why a request stalls between two otherwise well-equipped teams.

In the example, requests have four states: awaiting qualification, ready for decision, authorised and completed. A broad “in progress” status can hide an unresolved approval. Each state needs an observable definition. A decision-ready request contains the need, impact, options and last useful response date. An authorised request contains a dated decision and its author. A completed request contains evidence of delivery and acceptance by the intended recipient. None of these definitions depends on where an employee sits.

Agree an operating contract for the flow

The contract specifies an entry channel, a triage owner, a response expectation and an escalation rule. Choose timings according to the service. In the fictional team, ordinary requests receive qualification within one working day; genuine emergencies use a direct call followed by a recorded account. People working different hours must understand the case without reconstructing a conversation they missed. Make working hours, leave cover and the difference between acknowledgement and a completed decision explicit.

Asynchronous work succeeds when a message contains enough context for the next action. It becomes expensive when every reply generates another question. A short request form asks what result is needed, what decision is required, which options exist and when a response becomes too late. The author attaches relevant evidence and states a recommendation. The recipient responds in the same case. Avoid distributing one decision across instant messages, personal documents and a meeting that nobody records.

Synchronous discussion still has a purpose: resolving a disputed interpretation, handling an emergency, discussing a sensitive issue or supporting immediate learning. Start with the question to resolve and finish with a written decision. Prepare information beforehand. If an informal office conversation changes a priority, its initiator records the change before asking someone else to execute it. Documentation is part of making the decision effective, rather than an administrative favour to colleagues working remotely.

A completed flow matrix

This fictional example negotiates practical commitments rather than permanent availability. Response times are working times. Start with one flow, observe it and expand to the handovers creating the most waiting or rework.

Add a deputy, a single evidence location and a definition of urgency. Without the last item, requests eventually bypass the normal flow. Review escalations to distinguish missing decisions, unsuitable timings, absent information and excessive workload. Repeated urgency around the same issue often reveals a defect in the operating model. It should not automatically justify keeping everyone connected at all hours or requiring daily attendance regardless of the work involved.

Make performance fair and observable

Measure the flow: time to decision, handovers, rework caused by missing information, unowned requests and escalations. Message counts and online hours reward visible activity rather than useful results. In a fictional sample of twenty requests, nine wait mainly for authorisation. The team does not infer that remote employees are less productive. It tests decision cover and a more complete request form, then compares similar categories. Look at older cases as well as averages so simple requests cannot conceal stalled complex work.

Use performance criteria available equally to remote and on-site colleagues. Managers explain expected outcomes, assess quality and discuss workload constraints. Office conversations cannot become a privileged decision channel others must constantly chase. Promotion and assignment decisions should use documented contributions rather than physical proximity. This requires active management. A presence dashboard cannot replace clear expectations, support or a reasoned discussion about why a particular result could not be delivered.

Onboarding needs its own flow. Specify tools, reference cases, a mentor, early tasks and feedback points. Reading documentation does not teach a new colleague how the team handles ambiguous cases. Add targeted exchanges and annotated examples. In the scenario, a recruit handles one request with a mentor, then a second independently with review. Success means they can use the flow and request help appropriately. Office days can support relationships, equipment-dependent work or difficult workshops when their purpose is clear.

Test before extending the model

Run a bounded trial on a defined flow. Explain the observations, comparable periods and revision conditions. Better average timing may hide difficult cases left behind. More documentation may reduce rework while adding drafting effort, so include that cost and ask whether the information actually enables decisions. Technical security supports the model: protect devices, access and documents according to sensitivity and identified threats. Business decision rights still need their own owners and cover arrangements.

A securely protected case can remain unusable when its owner is absent and nobody has authority to decide. Cover both protection of resources and organisation of work. Competent security specialists adapt technical controls; operational teams define handovers, approvals and closure evidence. Keep these responsibilities connected, with an escalation route when a security restriction prevents the agreed service. The model should offer a lawful, workable path rather than encouraging employees to improvise an unrecorded workaround.

Make sector constraints explicit

Manufacturing needs reliable handovers between physical intervention and remote expertise, including useful readings and on-site confirmation. Financial services must preserve controls and approval responsibilities in documentary flows. Public services need understandable decisions and access for users with differing digital resources. Professional services should specify the review version, questions and arbiter before booking a meeting. These examples prescribe no universal number of office days. They ask what needs proximity, what can move asynchronously and what requires direct discussion.

The practical test is whether a colleague absent from the last conversation can perform the next action correctly. If not, repair the handover. Attendance then follows an agreed operating model, with explicit adjustments for the work and people involved.

Primary references checked in 2026

These references support communication, journey understanding and remote-work security respectively. The scenario and operating rules are original teaching material.

• GitLab Handbook — Communication, current page checked in October 2026, not a claimed 2021 archive.
• GOV.UK Service Manual — Map and understand a user's whole problem.
• NIST SP 800-46 Rev. 2 — Enterprise Telework, Remote Access and BYOD Security, published in 2016.