Here's a test I'd put to any owner, and I'd include myself in it. Turn your phone off, properly off, and go somewhere with no signal for two weeks. Don't pre-warn everyone, don't set up a secret check-in at 6pm, don't leave a laptop in the bag "just in case".
Now, honestly: what breaks?
Most owners can answer that instantly, and the answer is usually specific. A payment that only they can approve. A system only they have the password to. A client who will only deal with them. A decision that has quietly required their sign-off for eleven years. If you can name those things in under thirty seconds, you don't have a work-life balance problem. You have an architecture problem, and it's sitting in your pocket.
Always-on isn't dedication. It's a design flaw.
There's a version of business ownership that treats permanent availability as evidence of how much you care. I understand the instinct, I've lived it, and for a while it's even true. In the early years somebody has to be the fallback for everything, and that somebody is you.
But what starts as necessity quietly becomes structure. Every time you personally unblock something, you remove the pressure that would have forced a proper fix. The approval never gets delegated because you were available. The process never gets written down because you were there to explain it. The system never gets documented because you knew it. You are, without deciding to, becoming load-bearing.
The test of a business isn't how fast the owner responds. It's what happens when they don't.
And I want to be blunt about the risk, because the polite version of this conversation is about burnout, and the burnout is real, but it isn't the only thing at stake. An organisation that can only function with one specific person available is one bad week from a crisis. People get ill. Family emergencies happen. If your continuity plan is "the owner is contactable", you don't have a continuity plan, you have a hope with a phone number.
Key-person dependency is usually an IT problem
This is the part people don't expect from me, and it's the reason a piece about switching off belongs on an IT company's blog.
When we map a client's environment, key-person risk shows up constantly, and almost always as something concrete and fixable rather than something cultural. The pattern repeats:
- Credentials that live in one head. The domain registrar, the accounting system, the old server, the social accounts. Not written down anywhere, or written down somewhere only that person can reach. This is the single most common one, and the most damaging, because it survives the person leaving.
- One administrator, no second. A single account with the keys to everything, tied to one individual. When they're unreachable, nothing that needs elevation can happen. When they leave badly, it's worse than that.
- Multi-factor tied to one personal phone. The control that protects the business is anchored to a device that goes on holiday with its owner. A business locked out of its own systems because the second factor is in a bag in another country is a real scenario, and the maddening part is that the security worked exactly as designed. That is the problem.
- Undocumented systems. The thing that runs the invoices, the integration somebody built in 2019, the spreadsheet the whole operation actually depends on. It works, so nobody asks how, and only one person could rebuild it.
- Approvals with one name on them. Payments, purchase orders, access requests, all routed to a person rather than a role.
Look at that list again. Not one of those is a personality trait. They're all configuration, documentation and process, which means they're all things you can put right in a few weeks without anyone having to change who they are.
The standard behind it: ISO 27001 is oddly good on this. It asks for information security roles and responsibilities to be defined and allocated (Annex A 5.2), for segregation of duties (5.3), for documented operating procedures (5.37), and for ICT readiness for business continuity (5.29, 5.30). Read them together and they describe an organisation where the work is attached to a role rather than a person. It's written as security guidance, but it's honestly just good business design.
Documentation is the thing that actually lets you leave
Everybody agrees documentation matters and almost nobody does it, because it's the definition of work that's easy to defer. Nothing breaks today if you skip it. That's exactly why it's the last thing standing between you and a genuine break.
I'd argue the value proposition is badly sold. Documentation is usually pitched as protection against someone leaving, which is a threat nobody wants to think about. Try the reverse: documentation is the thing that lets you go away. Same work, far better motivation, and considerably easier to get people to actually do.
You don't need a library. You need the short list of things that would genuinely stop the business, written down in a place more than one person can reach:
- Where the critical credentials live, in a proper shared password manager with defined access, not a spreadsheet and not a memory.
- A documented break-glass account, an emergency administrator that isn't tied to any individual, stored securely, access logged, tested occasionally so you know it works before you need it.
- The handful of runbooks that matter. What to do when the payment system fails, who to call for the line-of-business application, how the month-end actually runs.
- Named deputies. Not "someone will pick it up", an actual second person per critical function, who has the access to do it and has done it at least once.
- Approval limits that let the business keep moving at a sensible threshold without you.
That's a list you could work through in a month of small efforts. We wrote separately about why most documentation goes unread, and the short version applies here too: write the things somebody would need at 2am, not the things that look thorough in a folder.
What I'd actually do
If any of this landed, here's the sequence I'd suggest, in order of how much relief it buys per hour spent:
- Run the two-week test on paper first. Don't go anywhere yet. Just write the list of what would break. That list is your entire project plan, and it takes twenty minutes.
- Fix the credentials and the break-glass account. This is the highest-value item and it's mostly a single afternoon.
- Name a deputy per critical function, and make them do it once while you watch. Untested delegation isn't delegation, it's optimism.
- Then actually go. Start with a long weekend, fully off, and treat everything that breaks as free diagnostic information rather than as evidence you were needed.
That last point matters more than it sounds. The things that break while you're away are not proof you can't leave. They're the list of what to fix so that next time you can, and the only way to generate that list honestly is to be genuinely unreachable. A test you're secretly supervising doesn't test anything.
This is a large part of what IT advisory work actually is, by the way. Less exciting than it sounds, and more valuable: finding the places where a business depends on one person, one undocumented system or one unrepeatable process, and making them boring.
If the business only works when you're reachable, you haven't built a business yet. You've built a job that emails you.
I'd add one honest caveat. I'm not writing this from a position of having perfected it, and I'd be suspicious of anyone in my seat who claimed otherwise. Owners are the worst offenders here, myself included, because the habits that got the company off the ground are precisely the ones that stop it outgrowing you. Knowing that doesn't make the phone easier to switch off. It does make it clearer what you're actually fixing when you try.
If you want an outside read on where your business depends on one person, that's a conversation we have often and genuinely enjoy. It's free, and it tends to be more useful than owners expect, mostly because it's very hard to see this from the inside.
