The Uptime Myth: Why the Most Reliable Leaders Are Built to Go Offline

Last week we ran the Bureaucracy Audit, a review of the approvals, sign-offs, and standing meetings that route through you, testing whether each one protects the work or protects you. That audit was about the steps you can see. This week is about something harder to point at: the standard your organisation holds its leaders to, and what it treats as a fault.

It's a typical Friday leaving do. A director is retiring after eleven years, and the CEO is giving the speech. There are the usual stories: the deal she rescued, the restructure she steered through. Then comes the line that gets the biggest round of applause: "In eleven years, she never once took a sick day." People clap. A few laugh along. No one asks what it cost her, or what the room has just been taught about what this organisation admires.

Where Uptime Came From

Uptime is a term from technology. It measures the percentage of time a system is available, and in the world of servers and networks it's tracked to several decimal places. Organisations borrowed a lot of that language without much thought. We talk about bandwidth, about being always on, about leaders who are plugged in and teams that run around the clock. Somewhere along the way, the measure crossed over too. A leader's reliability started to be judged the way a server's is: by how rarely they go down.

The trouble is that the borrowing stopped halfway. The language came across. The engineering didn't.

How Real Systems Stay Up

No engineer builds a reliable system by insisting that a single server never fails. They assume it will. Reliability comes from what's built around it: a second component ready to take over (failover), more than one route to the same result (redundancy), and maintenance windows, planned in advance and announced to everyone affected, when parts of the system are taken offline on purpose to be looked after.

A system that depends on one component never stopping has a name in engineering: a single point of failure. It's treated as a design flaw, and the fix is never to tell that component to try harder. It's to change the system so it can survive the component going down.

Apply that to leadership and the picture flips. The leader who can never go offline isn't the most reliable part of the organisation. They're its most obvious single point of failure.

What the Uptime Myth Is

The Uptime Myth is the organisational belief that a leader's reliability is measured by how rarely they go offline, which treats every absence, off day, or visible limit as a fault in the leader rather than a gap in the system around them.

It rarely appears in a policy. Most organisations have reasonable leave entitlements and a wellbeing page on the intranet. The myth lives in the culture instead, in what gets rewarded and repeated. It's the applause line at the leaving do. It's the performance review that praises someone for "always being there". It's the email that starts "I know you're on leave, but". It's the holiday that gets taken, technically, with a laptop in the suitcase. It's the succession plan with one name on it, and the deputy who has the title but not the authority to decide anything while you're away.

Each of these maybe makes sense on its own. Together, they set a standard nobody wrote down - leaders don't go offline, and the ones who do aren't quite leaders.

Where the Myth Meets Your Own Rules

Over the past two articles we've looked at the beliefs that keep you reachable and the processes that route through you. The Uptime Myth is what happens when those individual patterns get rewarded by the whole organisation.

Earlier in the series we looked at the Over-Functioning Mandate, the rule that ties your safety or worth to your visible output and insists rest has to be earned. On its own, the Mandate is a private rule. Inside an organisation that runs on the Uptime Myth, it gets confirmed from every direction. The culture says what the rule says, so the rule never gets questioned. What everyone else sees is the High-Performance Illusion, the polished, always-on appearance of elite performance that masks an over-functioning script and a chronic threat response underneath. The organisation sees the surface and calls it commitment. It doesn't see the cost, and after long enough, you may have stopped seeing it as well.

The cost doesn't stop with you. A culture that treats downtime as a fault teaches people to hide it. Leaders work through illness, cancel leave, and carry on through bereavements and family crises, so problems that could have been planned for arrive as emergencies instead. And because people read a leader's behaviour as the real policy, every leader who never goes offline teaches the next layer down the same standard. The myth doesn't just run on you. It runs through you.

Why Uptime Costs More for Queer Leaders

For many LGBTQ+ executives, the Uptime Myth carries extra weight, for three reasons.

The first is how downtime gets read. If you've spent a career in rooms where your competence was scrutinised harder than your peers', a visible off day doesn't feel like an off day. It feels like evidence. That's the Existential Perfectionism Trap, the belief that your right to space, authority, and safety depends on flawless execution, and the Uptime Myth hands it a convenient measure. Every hour you're visibly available is an hour nobody can use against you.

The second is the reasons for downtime. Many queer leaders carry things outside work that are hard to explain at work: family relationships that don't map neatly onto a compassionate leave policy, chosen family who don't appear on any form as next of kin, and personal matters you'd rather not disclose to a manager just to get the time to deal with them. When a culture treats absence as something that needs justifying, the people with the least explainable reasons pay the most. That stacks on the Identity Tax, the extra energy cost of code-switching and hyper-vigilance your peers simply don't pay. You're already running extra load, and the myth asks you to run it without a maintenance window.

The third is that many queer leaders are a single point of failure in a second system. If you're the only out senior leader, you may also be the sponsor of the LGBTQ+ network, the person new joiners are told to talk to, and the face on the careers page. If you go offline, that whole structure goes with you. That's a flaw in the organisation's design, not a reason for you never to stop. It also gives you a useful argument: building redundancy into that role strengthens the organisation's inclusion work, not just your capacity.

Two Ways to Test the Myth

Both exercises borrow from the engineers. Neither asks you to become less dependable. They ask you to move dependability out of your attendance and into the way the organisation is built.

The Single Point of Failure Map

Execution: List everything in your organisation that would stall, slow down, or stop if you were completely unreachable for two weeks: decisions only you can make, relationships only you hold, information that lives only in your head or your inbox, and roles you carry beyond your job title.

Action: For each item, name who would take it over, what they would need to do it well (authority, documents, introductions), and whether they have that today. Where last week's audit asked whether a step should exist at all, this asks what happens to the steps that should, when you're not there.

Target: A written map of where the organisation depends on your uptime, with a named owner for the three items that would cause the most disruption, and a date by which each owner has what they need.

The Maintenance Window

Execution: Schedule one genuine offline period: a full working day to start with, building to a full week of leave. Put it in the diary at least three weeks ahead, the way an engineering team announces planned maintenance.

Action: Before it starts, tell the people affected who holds what while you're away, and agree one specific break-glass condition: the single type of situation that justifies contacting you. Then go fully offline, with no "just checking". When you return, write down factually what happened: what waited, what got decided without you, what went wrong, and what it actually cost.

Target: Evidence from the organisation you're in now about whether it can run without you for a defined period, and a record you can use to make the next maintenance window longer.

Reliability Is a Property of the System

The aim here is not to care less about being dependable. Dependability is one of the most valuable things a senior leader offers. But the leaders people can genuinely depend on aren't the ones who never stop. They're the ones whose teams, deputies, and decisions keep working in their absence. Uptime is a measure for servers. For leaders, the better measure is what still runs when you're offline, and you're allowed to build an organisation that passes that test.

Next week we look at trust without a chain of command, and what holds a team together when authority isn't the thing doing the holding.

Message me to schedule a confidential consultation to find out how I can help you build an organisation that stays reliable when you step away.