The L2 network engineer is down with a fever. The client's core switch throws an alert at 6.40 a.m. The NOC lead has two L1 analysts, a ticket queue with an SLA clock running and no one who has ever logged into that firewall. The short answer to "how do we cover absence" is: by deciding months earlier who can do what, who is on the shadow roster and what a stand-in is allowed to touch.
First, separate absence you can see from absence you cannot
- Planned leave: known weeks ahead, so cover is a roster problem.
- Sick leave at short notice: a stand-in problem, solved by the shadow roster.
- On-call fatigue: the person is present but not fit to take a night page, a rest problem.
- Resident engineer on a client site: a client-facing problem, because the site cannot be left bare.
Each needs a different answer. Mixing them is why most firms keep guessing.
Build a skill grid before you build a roster
List every client, every technology and every engineer. Mark who is trained, who is shadowing and who has never touched it. The grid usually shows that one engineer holds the only cloud-access credentials for a tenant, and another is the only one who understands a legacy router at a bank branch. That is your absence risk, laid out on a page.
- 1
Rows: engineers, columns: client stacks
Use a spreadsheet. Mark each cell as lead, backup or none.
- 2
Rule of two
Every client stack needs at least two named people able to act on a P1 ticket without calling the lead.
- 3
Spot the single points
Highlight cells where only one person is marked. Those are training targets for the next quarter.
- 4
Link it to credentials
Check that the backup has the access in their own account and that a password vault entry names them, not a shared login.
The shadow roster
A shadow roster names one backup for each primary on-call slot. The backup is not on duty. They are simply the next person called if the primary fails to acknowledge within a stated time. Give them an allowance when they are called, not for being named, otherwise the list becomes a favour and breaks down. See our note on uneven on-call duty for the fairness side.
Handover notes and runbooks make the stand-in useful
A stand-in without a runbook is a spectator. Keep a living page per client: contact list, escalation matrix, change windows, backup schedule, the exact ticket categories, known quirks. At every shift change, the outgoing engineer writes five lines: open tickets, pending changes, client moods, what to avoid, what is next. The incoming engineer reads and replies with a tick.
What a stand-in may and may not touch
Cover fails when nobody states the limits. Write a short access card for each client: which consoles a bench engineer may open, which changes need CAB approval, which need the L3 on a call. Keep VPN tokens, SSH keys and jump-host logins in a vault with named entries, so a stand-in gets their own login and the audit trail stays clean. Never hand a sick colleague's password to a replacement.
Hardware sites bring a second layer. A data-centre rack with a failing PDU or a branch UPS needs someone with remote hands and a spare from the depot. Keep a spare-parts register with RMA status, bin location and the engineer who last signed it out. An absent field engineer should not mean a client waits for a replacement fan tray.
Triage rules for a thin shift
When two people are out, the helpdesk and the pager still ring. Agree triage rules in advance. Router and firewall alerts for hospital, bank or plant clients go first. Printer, mailbox and password tickets wait. Say who may postpone a quarter-end report, who may refuse a go-live and who tells the account lead. A runbook line such as "if the tenant login fails, call the L3 before resetting" saves a bad hour. Post the triage card beside the NOC console and revisit it after each thin shift.
Use a bench, but be honest about its cost
A small bench of trained generalists can fill gaps, but it is paid for whether or not anyone is absent. Keep it lean and rotate bench duty so the same person does not become the permanent fixer. When the bench is used often, that is a sign of understaffing, not resilience. Review bench use each quarter with the workforce planning service as a guide.
A morning checklist for the lead on a thin day
- Read the overnight NOC log and the pager history before the stand-up.
- Check the runbook link for every client with an absent owner.
- Confirm VPN token validity for the stand-in, and test the jump-host login before 9 a.m.
- Look at the change calendar: defer any firewall, router or tenant migration that needs the absent person.
- Message the client service manager with names, hours and the freeze list.
Cross-training that sticks
- Pair an L1 with an L2 on one ticket type each fortnight.
- Rotate the NOC console seat so no one owns the same dashboard for years.
- Hold a quarterly failover drill where the backup handles a mock P1 under the primary's watch.
- Keep short screen recordings of tricky fixes beside each runbook page.
Planned leave and the change calendar
Put leave and change windows on one calendar. Do not approve three leaves in the week of a data-centre migration. Ask for leave requests early for periods when a client has a quarter-end freeze or a go-live. The leave and shift process page sets the rules, and the IT support firms page and the networking companies page show the shape for two types of firm.
For the wider set of patterns in this sector, return to the IT infrastructure and managed services hub.
