switch it off and wait for the complaint

Every company that has existed for more than three years contains settings nobody understands. A group with four members and no obvious purpose. An organisational unit with one policy overridden and no note explaining why. An application grant from 2022 that somebody approved for a trial. A sharing exception on one shared drive.

The person who made each of those has left. The documentation, if it existed, is stale. The last admin guide describes how that happens. And the reason none of it gets removed is always the same sentence: we do not know what it does, so we should find out before we touch it.

That sentence is how these things reach their tenth birthday. In most cases the better response is to switch the thing off and wait for somebody to complain.

That sounds reckless. The argument has a specific shape, and recklessness is not part of it.

the fence is not your fence

You know the parable. There is a fence across a road, a reformer wants it removed, and the answer is: go away and think, and when you can tell me what it is for, I may allow you to destroy it.

Chesterton wrote that in 1929, and his actual wording is worth reading, because he does allow destruction. He sets a condition, and he attaches no deadline to going away to think.

Now notice what the parable assumes, because all three assumptions fail in an admin console.

It assumes removal is expensive. A fence taken down is a fence rebuilt with labour and materials. A group emptied of members is a group refilled in ten seconds.

It assumes investigation is cheap. In the parable you can walk to the village and ask. In your company the person who made the setting left years ago, the wiki page is wrong, and the investigation has no defined end. You can spend three hours and know nothing more than when you started.

And it assumes the fence is doing something continuously. Some of your settings are. Many hold up a process that stopped running years ago.

Applying a parable about irreversible removal to a reversible system is the real error here, and it is what keeps a 2017 group alive in 2026.

what leaving it in place looks like

There is a documented case, and it is the one to reach for when somebody tells you removal is the risky direction.

Knight Capital had code called Power Peg that stopped being used in 2003. It was never removed. It stayed present and callable. Nine years later, a deployment repurposed a flag that had once activated it, and the dormant code ran. The US Securities and Exchange Commission’s order records losses of roughly 460 million dollars in about forty-five minutes.

That is trading code. The mechanism transfers exactly to access rules. A thing nobody understood, left in place because removing it seemed riskier than leaving it, and the risk arriving through the door nobody was watching.

Now the other direction. Public postmortems that blame a material incident on somebody removing an access rule they did not understand are hard to find.

That proves little on its own: the failure mode is unglamorous enough that nobody writes it up. But look at the reporting asymmetry, because that is the real argument. Leaving a thing in place, when it goes wrong, produces regulatory orders and case studies and a decade of citation. Removing a thing, when it goes wrong, produces a message in a channel and somebody switching it back on within the hour. Those two failures are nowhere near each other in cost, and people reason about them as though they were, because only one of them generates a story.

the research says the defaults are the risk

There is engineering research on this worth knowing.

A 2015 study of configuration in large software systems, presented at ESEC/FSE, found that up to 54.1% of parameters were rarely set by any user, that only between 6.1% and 16.7% were set by a majority, and that 53.3% of the configuration errors it studied came from wrongly staying on a default.

Read that last figure next to the instinct this guide is arguing with. The largest single source of configuration error in that study was somebody leaving something alone.

the safe version, which is the whole method

Here is the version worth defending, and every word of it matters.

Write down the current state first. This is step zero, and skipping it turns the method into vandalism. Before you touch anything, record what it is now: who is in the group, what the override is set to, which scopes the grant holds, who the drive is shared with. Ten seconds to refill a group is only true if you know what was in it. A screenshot or a spreadsheet, either is fine, kept in the same folder as your quarterly export from the log export guide.

Then disable, never delete. Empty the group and keep the group. Turn the service off for the organisational unit and leave the unit. Move the application grant to blocked. Suspend the account. All of those toggle back in seconds with no data destroyed.

Say nothing. No announcement, and above all no message asking whether anybody still needs this. The honest answer to that question is always “possibly”, so you will get a yes from somebody protecting an option they have not used in years. The complaint is the signal, and asking in advance destroys it.

Wait a full business cycle, and make it a real one. Month end and quarter end, because the settings that bite are the ones that fire on a schedule. Two cycles before you delete anything permanently.

Write down what the complainer says. This is the part everybody misses. When somebody comes to you and says the thing broke, you have just recovered the documentation, for free, from the only place it was ever stored: somebody’s head. That sentence is the artifact.

And carve out the silent ones. This method is unsafe for anything on a path that only runs under stress. Backups, log shipping, an alert route, a break-glass account, an auditor’s read-only access. None of those complain, and you find out at the worst possible moment.

So the test before you disable anything is one question: would a human notice this failing within a month? If yes, disable it and wait. If no, investigate properly, and accept that the investigation is the price of the category.

the switch-off pass

1. 1record the current stateMembers, settings, scopes, sharing. Screenshot or spreadsheet.
2. 2would somebody notice within a month?If not, it is on the silent list. Investigate it instead.
3. 3disable, say nothingEmpty, block, suspend. Never delete.
4. 4wait two cyclesIncluding a month end and a quarter end.
5. 5keep the complaintSwitch it back on the same hour and write down why it mattered. Delete what nobody defended.

where this sits next to ownership

The ownership guide argues that undocumented ownership is fixed by writing it down, because the knowledge exists in somebody’s head and nobody has recorded it. Its quarterly routine also disables anything nobody claims within five days.

So this is the same instrument pointed at a different object, and the object changes the method. With ownership, you know what question to ask and who to ask. With state, you have neither, and asking people to document a rule they do not understand produces a document saying the rule exists, which you already knew.

Your company’s memory of why that setting exists is spread across the people who would be inconvenienced by its absence, and breakage is the only query language it accepts.

the pass

Pick ten things nobody understands. Groups with unclear purpose, organisational unit overrides, application grants, sharing exceptions on drives, policy settings on a unit nobody can explain.

Leave out forwarding rules and anything else on the silent list above. A broken forward produces no complaint from either end, which is exactly the carve-out this method depends on.

For each, ask the one question: would somebody notice within a month?

Disable everything that passes. Log the date and what you disabled, in the same file as your quarterly export, because in two cycles you need to remember what you did.

Wait. Do not chase.

Delete what nobody defended. Document what somebody did defend, in their words.

Ten items, an afternoon, and you will end the quarter knowing more about your own environment than three hours of investigation would have told you, because the investigation asks a system that does not know, and this asks the people who do.

One warning about the temperament this needs. The method works only if you are genuinely willing to switch things back on without arguing. The moment somebody complains and the response is a discussion about whether they really need it, you have turned a cheap information-gathering exercise into a political one, and nobody will report the next breakage. Turn it back on the same hour, cheerfully, and write down what they said. You paid for that sentence with a day of mild inconvenience, and it is the only documentation that exists.