Beyond the Rules: The Mailbox That Broke the Deal
Why the size of your inbox shouldn't be a deal-blocker.
One of the frustrating things about writing a book is realising ideas you could’ve included after handing in the manuscript. So, here’s an exclusive story for my newsletter readers — one I remembered recently that would’ve definitely made it into Humanizing Rules if I’d thought of it in time.
In a few of the larger organisations I’ve worked for, the size of email mailboxes was strictly limited. If your mailbox exceeded the limit, you were automatically blocked from sending emails until you brought it under control.
The logic made sense in theory; storage space isn’t infinite, and good email hygiene was the goal. Encourage people to file things properly, clear out old junk, and not treat their inbox as a data dump. Fair enough.
But here’s the problem.
The roles I had in those organisations often involved working on projects or deals. And the time you were most likely to hit the limit? Right at the end of a project, when you needed to be firing off emails late into the night, under intense time pressure, and usually sharing data-heavy attachments.
The very moment when you could least afford disruption was precisely when the system was designed to stop you in your tracks. Imagine doing an all-nighter, being on the brink of closing a complex deal… and suddenly you can’t send an email because your mailbox is a few megabytes over the limit.
You could get a dispensation. But that process was slow, bureaucratic, and useless in the middle of a critical deadline.
This wasn’t malicious design. The people who implemented the rule had good intentions. But they hadn’t really considered — or didn’t fully appreciate — the reality of the work people were doing. They were solving a storage problem, but in doing so, they were creating a productivity problem.
And a deeply irritating one at that.
How you can use this:
This is a classic example of what happens when rule designers don’t understand — or choose not to understand — the context in which their rules operate.
The rule worked in the sense that it enforced mailbox limits. But it also caused disruption at precisely the worst moments and didn’t feel helpful or manageable. It was punishment disguised as policy.
What would I have done instead?
Since they could clearly measure inbox size, they could also have spotted when someone suddenly received a flurry of mail and might need flexibility. Giving them a grace period — a window of time to sort it out without blocking them — would have turned something punitive into helpful. And if a dispensation is needed, they could've offered a one-off quick way out.
Now what?
This story got me thinking about how we often design tech systems for control rather than for humans. It reminded me of my podcast conversation with Sebastian Lees on Humanizing Technology. We talk about how technology can support people rather than frustrate them — and why human-centred design is the way forward.
Listen here → https://www.humanriskpodcast.com/sebastian-lees-on-humanizing-technology/