The person everyone turns to

There’s a role that exists in almost every organisation, and it doesn’t have a consistent job title.

Sometimes it’s a sysadmin. Sometimes it’s a developer who’s been there long enough. Sometimes it’s whoever happened to fix something once and never quite escaped the reputation. But the role is always the same: the person everyone turns to when something goes wrong, when something needs explaining, when something needs sorting out quietly before anyone important notices.

If you work in IT, you probably know exactly who that person is in your organisation. There’s also a reasonable chance it’s you.

The work itself is only part of it.

There’s the visible work — the tickets, the deployments, the actual fixing of things. And then there’s everything else. The Slack message at 4pm that starts with “sorry to bother you but”. The question that was supposed to take five minutes and took forty-five. The problem that landed on your plate not because it was yours to solve but because you’re the person who solves things, and this is a thing that needs solving.

None of that second category shows up in a dashboard. It doesn’t generate a ticket. It doesn’t get measured or recognised or fed into any kind of capacity planning. It just happens, and you absorb it, and the expectation that you’ll continue absorbing it becomes quietly baked into how the team functions.

There’s a particular dynamic that builds up around being good at this.

The better you are at sorting things out, the more invisible the effort becomes. Problems get resolved before they escalate. Things that could have caused disruption don’t, because you caught them. Users are unblocked, systems keep running, nobody has to have an uncomfortable conversation with someone senior.

Which is great, until you realise that the reward for doing it well is that nobody notices it happened. And the consequence of nobody noticing is that the capacity required to do it never gets factored in anywhere. You just keep absorbing it, because you always have, because it works, because the system has quietly optimised around your willingness to pick things up.

This is different from a heavy workload.

A heavy workload is visible. You can point to it, escalate it, have a conversation about priorities. What makes the invisible labour difficult is precisely that it doesn’t show up anywhere. You can’t easily argue for resource or pushback on scope when the thing you’re struggling with isn’t formally part of your scope to begin with.

And there’s a social dimension to it that makes it harder still. A lot of this work runs on goodwill — people ask because they trust you, because you’ve helped before, because you’re approachable. Saying no feels like withdrawing something personal, not like managing a workload. So you don’t say no, and the pattern continues, and gradually the gap between what you’re doing and what anyone thinks you’re doing gets wider.

It compounds with everything else.

The attention fragmentation from constant interruptions. The low-level exhaustion of working with systems that feel increasingly out of your control. The burnout that comes from a field that has drifted from what made it interesting. All of that is harder to manage when you’re also absorbing the invisible labour of being the person the organisation leans on.

Because that role doesn’t come with reduced expectations elsewhere. The tickets still need working, the deployments still need doing, the actual job still exists alongside everything else you’re quietly carrying.

There isn’t a clean answer to this.

Some of it is about making the invisible work visible — tickets for everything, even the quick ones, not as bureaucracy but as evidence. Some of it is about boundaries, though that word has been so overused it’s almost lost meaning. Some of it is just about recognising the pattern for what it is, because it’s harder to address something you haven’t clearly named.

But underneath the practical stuff, there’s something worth sitting with. The reason this dynamic develops in the first place is usually that someone genuinely cares. They fix things because they don’t want things to be broken. They help because they find it satisfying to help. They absorb the invisible work because they’re invested in things going well.

That instinct isn’t the problem. It’s actually what makes good IT people good.

The problem is a working environment that treats that instinct as an infinite resource.

It isn’t.