The Procedure Nobody Rehearsed: A Drift Check for Small UK Tech Teams

There is a particular kind of confidence that comes from a document called New Starter Setup v3. It sits in the shared drive, neatly formatted, with numbered steps and a few screenshots. Everyone knows it exists. Nobody has followed it from beginning to end since the person who wrote it left.

That is not a scandal. It is normal. Software changes, people change, and the notes that were accurate in February can be politely wrong by November. The problem is not that documentation drifts. The problem is that teams only discover the drift when someone is under pressure: a new starter on their first morning, an auditor asking how access is granted, or a supplier change that means someone else now needs to understand your setup.

A drift check is a small rehearsal. Not a documentation rewrite. Not a policy project with a steering group and a RAG status. Just a short, repeatable test of the procedures your team actually relies on, run against the live system, with a named owner for whatever needs fixing.

Pick five procedures, not fifty

The fastest way to kill this idea is to announce a full documentation review. That is how you end up with a spreadsheet containing 87 documents, 12 of which are marked "in progress" and none of which have been opened.

Start with five. Choose the procedures that would cause the most friction if they failed this week:

• How a new starter gets their first-day access.
• How someone leaves and their accounts are closed.
• How a backup restore is requested and approved.
• How a supplier invoice or renewal gets signed off.
• How an admin password or API key is rotated.

Your five will be different. The point is to choose procedures with real consequences, not the ones that are easiest to test. A runbook for booking the meeting room is not the priority.

Test the procedure, not the document

This is the important shift. Do not sit around reading the runbook and commenting on its tone. Open the live system and try to follow it.

If the guide says "ask the workspace admin to approve the request", find out who the workspace admin actually is today. If it says "check the box marked Sync with Finance", log in and see whether that box still exists. If step four says a notification goes to it@, send a test and see where it lands.

You are looking for the exact point where the document and the system stop agreeing. That point is the drift. Write it down plainly: "Step 3 refers to the Permissions tab. The tab is now called Access Controls. The rest of the step still works." That is more useful than a general note saying the document needs updating.

Keep the evidence small and specific

A drift check is not an audit, but it produces the kind of evidence an audit likes: a dated record of what was tested, what was found, and who owns the fix.

A simple table is enough. Five columns:

1. Procedure name.
2. Date tested.
3. Tester.
4. What broke or differed.
5. Owner and fix date.

Keep it in the same place as your other operational records. If someone asks in six months how joiners get access, you can show them the procedure and the last time it was rehearsed. That is stronger than a folder of documents with no evidence they have been opened since 2023.

This also helps at handover. When a team lead moves on, the next person does not have to guess which notes are trustworthy. They can see which procedures were tested recently and which ones are carrying a hopeful "last reviewed" date.

Treat the fix as part of the check

A drift check that finds problems but never fixes them is just a more organised worry. Keep the repair small. If the button moved, update the step. If the owner changed, change the name. If the procedure no longer works at all, mark it as broken and decide whether to rewrite it or retire it.

Do not turn every finding into a project. Most drift is boring: a renamed menu, a new approval step, a link that now points to a login page. Fix the small things while the tester still remembers them. Save the bigger questions, such as whether the procedure should exist at all, for a separate conversation.

Put it on the calendar like a fire drill

Once a quarter is usually enough for small UK teams. Pick a quiet week, give one person a couple of hours, and test the same five procedures. If a procedure has changed significantly, swap in a different one next time. The goal is coverage, not performance.

You can make it even lighter by pairing the check with something you already do: a renewal review, a new starter's first week, or the monthly seat sweep. The drift check does not need its own ceremony. It needs a habit.

What this is not

It is not a bid to document everything. It is not a sign that your team is chaotic. And it is not a reason to write a 40-page standards document about how to write runbooks.

It is a recognition that software is a moving target and documentation is only useful when it is tested. A runbook that has never been rehearsed is a rumour with formatting. A runbook that has been tested recently is operational evidence.

For small UK tech teams, that distinction matters. You do not need perfect documentation. You need five procedures you can trust, a dated record of when you last checked them, and a clear owner for the next fix. That is a drift check. It takes less time than the meeting where someone explains why the onboarding notes are out of date.