Part IV · Chapter 8 · The Second Year · lesson 10
What you would tell the person who inherits this
11 min
Builds on The control whose owner changed teams in April
Part IV · Chapter 8 · The Second Year · lesson 10
11 min
Builds on The control whose owner changed teams in April
You are leaving in three weeks. The handover meeting is an hour, on a Thursday, and the person taking this over has a full job already.
They will inherit eleven policies, a register, an evidence folder and a certificate. None of that is the thing you need to tell them.
What you need to tell them is six facts about how this actually runs here, every one of which is currently stored in your head, and every one of which is the reason the second year goes better for you than it will for them.
Predict
A policy is written for a reader who does not exist: a competent stranger with no context, who needs to know what is supposed to happen.
Everything that makes the programme actually run is about this particular company — which people, which tool, which quarter, which promise. That has no place in a policy, because a policy that names an individual engineer and a folder path is a policy that is wrong within months.
So the knowledge accumulates in one person, not through secrecy but because the documents have no slot for it. It is tacit for a structural reason, and it leaves in a single afternoon.
The remedy is not a better policy. It is a different document with a different reader: a letter to the next person, dated, written in the second person, which no auditor is the audience for.
One. Where the evidence actually is, including the two places it is not. The quarterly review exports are in a folder owned by a personal account rather than the team; they vanish when the account is deprovisioned. The pipeline logs roll off after ninety days, so the first quarter's are gone unless somebody pulled them, and somebody did, into a different folder, as a one-off.
Two. Which controls describe what the company already did. Of eleven, three were written to describe existing practice, two asked people to work differently, and six fell somewhere between. The three are robust and need almost no attention. The two will drift back towards the old behaviour within about two quarters unless somebody holds them, and knowing which two is worth more than any policy on the list.
Three. Which quarter is thin, and why. Last August the reviewer was on leave and the review happened three weeks late. It is inside the period, it is late, and there is a note about it. A sample is as likely to land on that instance as any other, so the next person should know before they are asked rather than after.
Four. Who actually does the work, as against whose name is in the field. The owner field says the head of engineering. The person who assembles the list every quarter is a specific engineer who has never been told they are part of a control, and who will be surprised to be asked about it in a walkthrough.
Five. Which supplier answer is softer than it reads. One of the companies inside your boundary carves out their own hosting provider, so their report does not cover the layer most of your risk lives in. Another answered a questionnaire with text written by their sales team. Both answers are on file and both are thinner than the file suggests.
Six. What you promised one specific customer that is in no policy. A notification commitment in a contract signed eighteen months ago. A statement about where data is stored, made in an email during a procurement conversation. Those are controls with owners and cadences and no rows, and the only person who knows they exist is the person who was in the meeting.
Something people say
“It is all documented, so the handover is a question of reading the documents.”
Why can the six facts not go into the policies?
One file, with a date at the top, written to a person rather than to a reader. Six headings and a paragraph under each. Rewritten, not amended, once a year — because an amended one accumulates the same problem the policies have, which is that nothing in it tells you which parts are still true.
Two honest limitations. It goes stale, like everything else here, and the fix is the date at the top rather than a promise to maintain it. And it is an inventory of where you are weakest, in one short document, which is the point track 2 made about the register and applies with more force to this: it lives wherever the register lives, under the same access, and not in a shared drive called Handover.
Check