Somewhere in your organisation is a person who understands one particular firewall better than the job description suggests. When it plays up on a Friday evening, they’re the one who gets the call. Not because it’s their responsibility. Because three years ago they configured it, and nobody has had the time to document what they know since.
For a surprising number of organisations, that’s simply how things work.
Ask an IT Director whether the organisation has a managed service and they’ll say no. Ask what happens when the network drops over a bank holiday, or when two things fail in the same week and the one person who understands the finance system integration is on leave, and a different answer starts to form. There’s coverage. It’s just never been written down, priced, or agreed by anyone. It runs on memory and goodwill, and it depends entirely on the right person being reachable at the right moment, which is also why nobody on that team has taken a full week off in a while without checking their phone.
Give that arrangement its proper name. It’s a managed service. It was simply never designed as one.
How it happens without anyone deciding it
It rarely arrives as a single moment. A new site opens, and someone takes on monitoring for it informally, because there’s no one else free yet, and the arrangement is never revisited once the site settles into normal running. A cloud service gets adopted for one team, and whoever set it up becomes its de facto owner, because writing a proper support plan wasn’t anyone’s job that quarter. Someone leaves, and their responsibilities get redistributed among people already at capacity, because backfilling takes months and the work can’t wait that long.
None of these individual choices looks significant at the time. Each one is a sensible response to an immediate problem. But enough of them, made over enough years, add up to the exact shape of a managed service: defined areas of responsibility, informal escalation paths, specialist knowledge concentrated in one or two people, a working rhythm that holds up as long as nothing unusual happens. What’s missing is the part that would have made it a decision rather than an accumulation. Nobody sat down and asked whether this was the right way to run it, because nobody sat down at all.
The cost hides in plain sight
Nobody puts a number against the engineer who has given up a second weekend this month, working through a problem that shouldn’t have been theirs to solve alone. Nobody totals the specialist contractor brought in at short notice, at a premium, because the in-house team never needed that particular skill until now, urgently, on a Tuesday. Nobody logs the infrastructure upgrade that slipped another quarter because the two people meant to deliver it spent the sprint firefighting instead, and BAU won again, the way it usually does.
Add it up and the number is real. It has just never appeared on a single line, so nobody has been forced to look at it directly.
Monday morning tells its own story
Ask what a typical Monday looks like and most IT teams describe some version of the same thing: a list of things that happened over the weekend, discovered not by monitoring but by someone noticing, complaining, or failing to log in. The alert that would have flagged it existed. Nobody was watching it at two in the morning. The connectivity issue at the regional site was visible for hours before anyone at head office knew about it.
None of this looks dramatic from the inside. It looks like Monday. That’s precisely the problem: a pattern repeated often enough stops registering as a pattern at all.
The person who already knows
Somebody in the organisation understands this gap with complete clarity, usually the IT Director or CTO, and they carry a specific, quiet pressure because of it. They can describe exactly where the coverage is thin. They know which system failing outside office hours would be genuinely serious.
What they don’t have is a way to say any of this to a CFO in language that survives a budget conversation. It is straightforward to ask for money after something has broken. It is far harder to ask for it against something that hasn’t happened yet, particularly when the current model, whatever it’s quietly costing, hasn’t yet produced a visible failure. Asking a board to fund the prevention of a problem nobody has seen is one of the hardest conversations in any organisation, and the discomfort of having that conversation, more than any absence of a business case, is often what keeps the current model running another year.
So the gap sits there. Understood, unaddressed, waiting for an incident, an audit, or a departure to force the question that should have been asked on a quieter day.
Built by need. Redesigned by choice.
None of this happened through anyone’s failure. It happened because growth outpaced planning, one reasonable decision at a time, and nobody ever stepped back far enough to see the shape those decisions had made together.
That’s the real distinction worth sitting with: not whether an organisation has a managed service, because it almost certainly already does, but whether that service was built on purpose or simply arrived, unannounced, while everyone was busy running the organisation day to day.
