Nobody wanted to be the one who deleted the wrong file
a company whose product files live on a shared drive ·
Abstract
Every product has a folder on the shared drive, and every folder holds the files that belong to it. Pictures, technical files, documents. Several teams have been filing things there for years.
They wanted it cleaned up. Files had built up whose names no longer said what they were, and the ask was to find those and get rid of them. That part was never the difficulty.
Problem
Nothing about the drive looked broken. Every folder was there and every one had files in it. What had quietly stopped being true was that the names meant anything.
A picture filed under the wrong product. A technical file carrying the wrong prefix. Documents nobody could classify at all. Each one trivial on its own, and together the reason nobody could trust the drive to answer a question.
The rules for what belongs where were knowable. A script could have swept the whole thing. So the interesting question isn't why the drive was messy. It's why it stayed messy, for years, when everyone knew and everyone agreed it shouldn't be.
Deleting was never the risky part. Approving was.
A wrong deletion here is silent. The file goes, nobody notices, and by the time someone needs it there's no record of what it was or that it was ever there. Whoever signs off on a list of filenames is taking that risk personally, for files they have no realistic way to check one by one.
So nobody signed off. Not out of laziness. Out of an entirely correct reading of the downside.
Then there's how people actually review a long list. It takes more than one sitting. Somebody opens it, works down it, gets pulled into something else, and comes back to it later. Meanwhile other people are still adding files to the same drive, because it's a shared drive and that's what it's for.
And a list of proposed deletions looks exactly like a list of completed ones. Hand someone a document full of filenames and their first instinct is that something has already happened to them.
Solution
We split the job in two, and the split is the whole thing.
The first half only looks. It walks every folder, checks each file against the rules, and produces a document listing what it found and why each file failed. Nothing is touched. The cover page says so, in those words, because a reader who assumes the work is already done won't read the list properly.
Then a person decides. Their approval is bound to what they actually read: if the drive has moved on since they looked at it, the approval no longer holds and nothing is deleted. They review the current state instead.
That's what made it signable. The reviewer isn't taking responsibility for a category of files, they're taking it for a specific set they saw, and nothing quietly widens that set behind them.
The second half doesn't trust the first. It checks everything again from scratch rather than acting on findings that have since aged. Anything it does remove can be brought back.
One more refusal is worth mentioning. A folder that doesn't fit the rules is left alone and reported, not forced through them. The rules describe the normal case. The odd ones are exactly where deleting on a rule is most likely to be wrong.
None of that made the cleaning cleverer. It made the approving possible, which is what had been stuck.
The drive gets cleaned now. It didn't before, and the reason was never technical.
The system described here is one we built and run. The situation around it is drawn rather than reported, because the details that would make it specific are the ones that would identify a client.
← All use cases