How should software development companies plan cover for absence so work does not stop?

The only developer who understands the invoicing module's batch job is on a flight to a cousin's wedding. At four in the afternoon the client reports that month-end statements have not generated. The tech lead opens the repository, finds a cron entry with no comments and a script that calls three internal services. The standup note says 'Anil knows'. Anil is above the Arabian Sea with his phone off.

Short answer: attach cover to the system rather than the person, and record it before anyone applies for leave. What follows covers the method, then the follow-on questions.

List the parts of your work that can stop: each client account, each service in production, the release pipeline, the staging environment, the support queue, the billing job. Beside each, write a primary owner and a second owner. The second must be able to open the repository, read the logs and run the deploy or the fix. A name on a spreadsheet is not cover. Cover is a person who has done it once with the primary watching.

Outages rarely come from the big architecture. They come from items held in one head or one laptop. Walk the estate and ask who holds each.

• The SSL certificate renewal and the DNS panel login.
• The nightly backup job and the restore drill nobody has run.
• The Android keystore, the Play Console account and the iOS push-notification certificate.
• The payment gateway webhook secret and the sandbox keys.
• The cron entry that generates month-end statements, with no comment above it.
• The SMTP relay credentials and the bounce mailbox.
• The Docker registry, the CI runner and the staging database seed script.

Put each item in a shared vault, with two people able to open it. Add a calendar reminder for every expiry date, owned by a named pair. A lapsed certificate on a Saturday has ended more weekends than any sickness.

• A fortnight's planned leave: handover note, tickets reassigned on the board, a chat status naming the second owner.
• Sudden sickness for a day or three: the second owner takes the sprint card, the lead moves a lower-priority ticket to the next sprint, nobody phones the patient for a status.
• On-call and release week: a fixed rota, with swaps entered in the rota sheet and not bargained across the desks.
• Notice period: the knowledge-transfer plan starts on the day of resignation, with sessions recorded and a shadow reviewer assigned.
• Long absence such as maternity, medical or study leave: a planned project, with a back-fill, a reduced-scope client communication and a return plan.

A runbook is a short page for one system: what it does, where it runs, how to restart it, which logs to read, who to ring at the client, and what a normal and a broken state look like. Keep it in the same repository as the code. Review it each time the system changes. Test it quarterly: ask the second owner to run a deploy or a restore from the page alone, with the primary sitting quietly nearby.

Put releases, UAT windows, audit demos and client reviews on the same calendar as leave. Adopt a cap of one absentee per squad in a release week, and bar planned leave for any sole owner in the run-up to a go-live. Announce both in January so weddings and pilgrimages get planned around them. Writing such rules in plain words is the job of a good leave and shift process.

Developers waiting for allocation can cover absences, but only if they know the codebase. Rotate bench staff through shadowing slots on live accounts, so a floater is not a stranger. Do not park the same person on every emergency, or he starts to look for a way out.

• Modules with only one named owner.
• Runbooks tested in the last quarter.
• Weeks in the year when two or more people from one squad are away.
• Hours of cover work done outside normal time, by person.

The last measure matters. If cover work piles up on the same people, you have moved the problem, not solved it. Second owners are best taught from day one, as the joining routine for bespoke software shops shows. The software development hub places all this in its group. For a cover plan drafted around your squads, write to us via the requirements wizard.