Every website has chores that nobody enjoys: applying updates, checking backups, clearing spam, reviewing broken links, proofreading pages before they go live. In most small organisations those chores settle on one person, usually the one who built the site or the one who once said “I can look at it.” This comparison sets two models side by side, a fixed website maintainer and a website maintenance rotation, and weighs them on workload, quality, knowledge and risk. The conclusion favours rotation, with conditions, and the conditions matter as much as the verdict.
The two models defined
Model A: the fixed maintainer. One named person owns all maintenance duties. They know the system intimately, answer every question and receive every late-night notification.
Model B: the rotating stewardship. A small pool of people takes turns holding the maintenance duties for a set period, perhaps a week or a month. The steward on duty handles updates, content checks and urgent fixes, then hands over in writing to the next.
Comparison one: workload and fatigue
Under Model A, the load is predictable in volume and unfair in distribution. The maintainer absorbs the dull weeks and the crisis weeks alike. Over time the work expands into evenings and weekends, because the site never sleeps and no one else can respond. Under Model B, the unpleasant weeks are shared, and so are the quiet ones. Nobody carries a full year of urgency, and everyone sees what the work costs.
Verdict: rotation wins, provided the pool is large enough that nobody is on duty too often. A pool of two is merely a fixed maintainer with a stand-in.
Comparison two: quality of the site itself
A fixed maintainer builds good habits and develops a consistent eye. That is a genuine advantage. However, a single pair of eyes also stops seeing problems that have become familiar. Pages that nobody questions go stale. Consider the typical advice about what makes a service page persuade a first-time visitor or about the role an About Us page plays in earning trust. Both depend on fresh, honest copy. A rotation brings a new reader to those pages regularly, and fresh readers spot the outdated claim, the vague heading and the dead link.
Verdict: a narrow win for rotation on review quality, and a narrow win for the fixed model on consistency. A shared checklist closes most of the gap.
Comparison three: knowledge and resilience
This is where the models diverge most. Under Model A the logins, the plugin quirks and the awkward fixes live in one head. Everyone is content until that person is ill, on leave, or leaves the organisation. Recovery then requires reconstructing years of undocumented decisions. Under Model B, the handover note is mandatory, so documentation accumulates as a by-product of the schedule. Each steward leaves notes because the next steward needs them.
Verdict: decisive win for rotation. The fixed model stores knowledge in a person; the rotating model stores it in notes and in several people at once.
Comparison four: speed and accountability
The fixed maintainer is quick, since there is no question about who acts. The rotation can feel slower at the start, with the questions of whom to call and who decides. Clear steward-of-the-week labelling answers this. An internal page listing the current steward, the next steward and the escalation route removes the ambiguity.
Verdict: fixed model wins at the start; the gap closes after a few cycles.
A summary table in words
- Workload fairness: rotation is clearly better.
- Review quality: slightly better with rotation, assuming a shared checklist.
- Continuity of knowledge: rotation is much better.
- Speed of response: the fixed model is quicker initially.
- Training value: rotation, since every steward learns the system.
- Cost in meetings and coordination: the fixed model is lighter.
A short scenario to ground the comparison
Take a small consultancy with a five-person team and a website that carries a services section, a blog and a contact form. Under the fixed model, the office manager looks after everything. When the contact form silently stops delivering messages during a busy fortnight, nobody else knows where to look, and the office manager is on holiday. Under the rotating model, the steward for that week runs a form test as part of the checklist and catches the fault on day one. Talent was not what separated the two outcomes; a routine that put a different pair of eyes on the same chore every week made the difference.
What a good handover note contains
Good handover notes are brief. A useful one answers five questions: what was changed this cycle, what broke and how it was fixed, what is waiting for a decision, what looks suspicious, and which task the next steward should do first. Keep it in a shared document that the whole pool can read, and date every entry. Over a few months that document becomes the most accurate manual the site has ever had.
Conditions that make rotation work
- A pool of at least a few people. Too few and the rotation is a fiction.
- A short written checklist. Updates, backup confirmation, form tests, link check, content review. Keep it to one page.
- A handover note every cycle. What changed, what failed, what to watch.
- A buddy for first-time stewards. The previous steward remains reachable for the first days.
- Protected time. A steward needs space in their calendar, or the duty becomes another burden on top of a full week.
- A named escalation route. For serious faults, everybody knows whom to call, and that person is not necessarily on duty.
When the fixed model is still the right call
For a tiny team of two or three people, or a site that changes only a few times a year, a formal rotation may be heavier than the problem. In that case, keep one maintainer but add a deputy, a written checklist and an annual swap. You capture most of the resilience without the overhead.
The wider parallel in technology operations
The comparison above has a close relative in the world of cloud and platform operations, where the pager is the chore nobody wants. Organisations in that field have long argued for on-call rotation rather than a permanent hero, because the same two people answering every alert will tire and the know-how will stay with them. DevOpsSupport, a consulting and support company working across DevOps and cloud operations, is one example of a provider that helps teams make such arrangements fair and well documented. The principle carries straight over to website care: share the hard duty, and write down what you learn.
Risks of rotation, stated plainly
A rotation has costs. Responsibility can blur, so a fault falls between two stewards. Standards can drift if each steward interprets the checklist differently. People can resent being asked to do technical chores outside their usual role. Each of these is manageable through a clear escalation route, a checklist written in specific terms, and training that is offered rather than assumed. Naming the risks up front makes the trial more honest and the eventual decision more defensible.
A practical way to decide
Score your own situation honestly. Ask who would cope if your current maintainer disappeared tomorrow. Ask how many evenings that person lost last quarter. Ask when anyone other than them last logged in. If the answers are uncomfortable, trial a rotation for a quarter, with the checklist and handover above. At the end, compare the experience against the fixed model on the same four measures: fairness, quality, resilience and speed.
Most teams find the trial reveals hidden work they did not know existed, hidden skills they did not know they had, and a maintainer who is quietly relieved. That, rather than any theory, is the best evidence for choosing the rotating model.
