Recently I was talking to the CTO of a scale-up in the television sector. He hadn't taken a holiday in two years. Not even a short one or a long weekend trip to the Ardennes. Two years. He knew it was a problem, and he also knew he was the only person who could fix it. Yet he couldn't find the time to actually fix it.

We can give that loop a name. We see it, in various forms, in over 60% of the companies we audit: let's call it the prisoner pattern.

The CTO doing five jobs simultaneously: architect, firefighter, tech lead, people manager, and occasionally sales support when a client wants someone technical on the call. Who writes the feature because explaining it to someone else would take longer. Who merges the pull request because the review queue is already at twelve. Who owns the production incident because the context lives only in their head.

Not because they want to. Because the company's survival, at some point, required exactly that from them. And nobody told them when to stop.

The word "prisoner" matters. A prisoner didn't build their own cage. The bars accumulate from decisions that were entirely reasonable at the time: the MVP that needed one person to do everything, the deadline that held because someone worked through the weekend, the client relationship that stuck because one engineer made themselves permanently available.

The tell

Over 70% of our audits show key person risk, but the sharper tell is what happens when their own system starts to slow them down.

The CTO who goes around their own code review process because there's a fire, who skips the sprint ceremony because something urgent came up, who merges directly to main just this once because the normal path would take two days and this needs to be live by morning. The prisoner is rattling the bars. When you find yourself bypassing the system you designed, the system is already too slow for the pace you're running at.

Over 50% of our audits show no product metrics, because the person who should be thinking about metrics is keeping the servers up. 80+% show no automated testing culture, because the person who should be establishing that culture is writing features.

AI is making this harder to ignore. For years, the overloaded CTO could point at complexity as justification: the codebase too specialised, the team too junior, the domain too nuanced for anyone else to handle. We've written about how AI is changing what development teams can do and what it means when vibe coding enters production. When a developer with the right tooling can do in an afternoon what used to take a senior engineer a week, "I'm the only one who can do this" stops being a structural truth and starts being a habit.

The prisoner who hasn't noticed the door is unlocked.

The exit

The popular prescription is: delegate more. Better calendar hygiene. Direct reports. Step back from the keyboard. That advice isn't wrong, but it skips the harder thing.

Moving from doing to enabling is a skill shift and an identity shift at once. The thing that made them indispensable is precisely what they have to let go of. And that's hard when the company still occasionally needs the old version of you at full throttle.

Which brings me back to the CTO not taking holidays. Would two laptopless weeks in Bali actually help? Possibly. A forced absence is a useful test: the team either copes, or they don't, and either answer tells you something important. The problem is that "takes a holiday" is still a scheduling solution to an identity problem. You come back, and if nothing structurally changed, you'll be back inside the cage within a week.

You're overloaded because you were very good at exactly the right thing for exactly too long.

The exit exists. Pick one thing this week you could hand off permanently and never take back. You've got to break free, as Freddie knew. And then, maybe, finally book that holiday to Bali and hope your flight won't get cancelled.

Follow our bi-weekly SaaS show

Fast, honest insights from the trenches of SaaS. Andreas and Sjimi, partners at madewithlove, share what they’re seeing inside real SaaS teams and products every two weeks.