The Cost of Always Being Available

Somewhere along the way, availability stopped being a courtesy and became an expectation. I noticed it in myself first: the reflexive glance at a phone during dinner, the half-formed reply drafted in my head while someone was still talking, the quiet pride I took in being the person who answered fast. In a payments business, where an incident at 2am can cascade into failed settlements by morning, that instinct feels not just useful but virtuous. For a long time I treated my own responsiveness as a competitive advantage.

It took me years to understand the bill that comes due for that posture. Always being available is not free. It is a cost paid in attention, in judgment, in the health of the people around you, and ultimately in the quality of the systems you build. This is a reckoning with that cost, and an attempt to describe what I have changed.

The Myth of the Responsive Leader

Early in my career I conflated speed with seniority. The engineers I admired most seemed to be everywhere at once: in the incident channel, in the design review, in the hallway conversation that decided the architecture. I assumed that being reachable was a measure of how much I cared, and I built a reputation on it. When a message arrived, I answered. When a meeting overran, I stayed. When a release wobbled at midnight, I was the first set of eyes on the dashboard.

What I did not see was that my availability was creating a particular shape of organisation. People learned to route decisions through me because I was always there to make them. That felt efficient in the moment, but it was a kind of centralisation by accident. I had become a single point of contact, and like any single point in a distributed system, I was also a single point of failure. The more available I made myself, the more the team depended on that availability, and the less resilient we became.

The myth is that the responsive leader is the strong one. In reality, a leader who must be present for every decision has built a system that cannot function without them. That is not strength. It is fragility wearing the costume of dedication.

Attention Is the Scarce Resource

We talk a great deal about time management, but time is not really the constraint. The constraint is attention, and attention does not behave like time. An hour can be sliced into twelve five-minute pieces and still add up to an hour. Attention cannot. When I interrupt deep thinking to answer a Slack message, the cost is not the ninety seconds the reply takes. It is the ten or fifteen minutes of reconstruction needed to get back to where I was, plus the subtle degradation in the quality of whatever I return to.

For an engineering leader, the work that matters most is precisely the work that requires sustained attention: thinking through a risk model, reading a regulatory requirement carefully enough to understand its implications, sitting with an architectural trade-off long enough to see the second-order effects. None of that survives a constant stream of interruptions. When I made myself perpetually available, I was implicitly deciding that everyone else's small needs took priority over the few hard problems that only I was positioned to think about.

The most expensive thing a senior leader can do is spend their best hours on questions that someone else could have answered.

What Availability Teaches Your Team

Every behaviour a leader models becomes a lesson, whether or not it was intended as one. When I replied to messages at eleven at night, I told my team that eleven at night was a reasonable time to expect a reply. When I jumped into an incident before the on-call engineer had finished their assessment, I told them I did not fully trust them to handle it. None of these messages were ones I would have chosen to send out loud. They were sent anyway, through behaviour.

The compounding effect is the worrying part. A team that watches its leader sacrifice boundaries will conclude that sacrificing boundaries is how you get ahead. The most ambitious people copy it first, and then it becomes the norm rather than the exception. You end up with an organisation that confuses presence with contribution, and that quietly punishes anyone who chooses to be unreachable for an evening. In a regulated environment, where careful judgment matters more than raw output, this is a particularly damaging culture to cultivate.

I have come to believe that one of the highest-leverage things a leader can do is to be visibly, deliberately unavailable at predictable times. Not absent, not negligent, but clearly off. It gives everyone else permission to do the same.

The Economics of Interruption

It helps to think about interruptions in terms that an engineer respects: throughput, latency, and contention. An always-available leader is a shared resource with no rate limiting. Every request gets serviced immediately, which sounds ideal until you realise that a system with no queue and no backpressure is a system that will eventually thrash under load. The work does not get done faster. It gets done worse, in smaller and more fragmented pieces.

There is also a hidden cost on the requesting side. When I am always available, there is no incentive for anyone to think a problem through before bringing it to me. Why spend twenty minutes investigating when the senior person will respond in two? Instant availability removes the friction that would otherwise force people to develop their own judgment. The friction was doing useful work. It was teaching.

When I started introducing deliberate latency into my own responsiveness, something interesting happened. A meaningful fraction of the questions that used to land on my desk simply evaporated. People answered them themselves, often better than I would have, because they were closer to the detail. The queue, it turned out, was a feature.

Incidents and the Hero Trap

Payments infrastructure has real incidents with real consequences. A settlement file that does not reconcile, a gateway that starts timing out during peak volume, a reconciliation discrepancy that has to be explained to a regulator. In those moments, the instinct to be the hero is overwhelming. I know the system, I can see the problem, and I can fix it faster than anyone. So why would I not?

The answer is that the hero trap optimises for the wrong thing. If I personally resolve an incident, the incident is over, but the organisation has learned nothing about how to resolve it without me. The next time it happens, and at three in the morning when I am unreachable, the team is no better equipped than before. The heroics felt like service, but they were quietly hollowing out the team's capability. I was building a dependency on myself and calling it commitment.

What I try to do now during an incident is to resist the urge to take the keyboard. I ask questions instead of giving answers. I let the on-call engineer drive even when I can see the path, intervening only when there is genuine risk. It is slower in the moment and far better over time. The measure of a resilient incident response is not how fast the most senior person can fix things. It is how well the system holds when that person is asleep.

Boundaries as an Engineering Discipline

I find it useful to treat my own availability as a system to be designed rather than a personality trait to be indulged. Systems have interfaces, contracts, and explicit failure modes. So should the way I make myself reachable. The goal is not to be hard to reach. It is to be reachable in ways that are legible and sustainable, so that nobody has to guess whether a midnight message will be answered or wonder whether silence means something is wrong.

In practice, the boundaries I have found most durable are these:

• A clear escalation path that does not depend on any one individual, so that a true emergency reaches someone qualified without needing to reach me specifically.
• Explicit response-time expectations for different channels, so that nobody treats a non-urgent message as an emergency by default.
• Protected blocks of deep-work time that are visible on my calendar and genuinely respected, not quietly overwritten.
• A standing agreement that being off means being off, with the on-call rotation carrying the real load rather than informal hero coverage.
• A habit of writing decisions down, so that people can find answers asynchronously instead of needing me live.

None of these are complicated. What makes them work is consistency. A boundary that holds nine times out of ten and then collapses the moment someone applies pressure is not a boundary. It is a suggestion, and people learn quickly which suggestions can be ignored.

Documentation as the Antidote to Presence

The single most effective thing I have done to reduce my own indispensability is to write things down relentlessly. When a decision is captured in a document, it stops needing to live in my head, and it stops requiring my presence to be consulted. A well-maintained set of runbooks, architecture decision records, and incident write-ups does more to scale a leader than any amount of personal availability ever could.

This matters especially in fintech, where the reasoning behind a control is often as important as the control itself. When an auditor or a regulator asks why a particular reconciliation threshold exists, the answer should not depend on whether I happen to be in the room. It should be written down, with the context and the trade-offs that produced it. Documentation turns institutional knowledge from something fragile and personal into something durable and shared.

There is an honesty to good documentation as well. Writing a thing down forces you to confront whether you actually understand it. More than once I have started to document a decision only to find my reasoning was thinner than I assumed.

Redefining What Good Leadership Looks Like

I had to change my own internal scorecard. For a long time the metric I quietly tracked was responsiveness, and it always rewarded the same behaviour: be there, answer fast, never miss a thing. The metric I try to use now is closer to absence. How long can I be away before something breaks? How many decisions get made well without me? How rarely does my name appear as the bottleneck in a postmortem?

By that measure, the best week is not the one where I solved the most problems. It is the one where the team solved problems I never even heard about, because the systems and the people were equipped to handle them. That is a harder thing to take pride in, because there is no dopamine hit from a quick save, no visible evidence of heroics. But it is the real work of leadership, and it only happens when you stop confusing your own presence with the health of the organisation.

The shift is uncomfortable. It requires giving up a version of yourself that felt valuable and important. But the value was always somewhat illusory, propped up by a dependency I had engineered without meaning to.

Conclusion

Always being available is a seductive habit because it feels like generosity. It looks like care, like commitment, like the behaviour of someone who takes their responsibilities seriously. The hard truth is that it often produces the opposite of what it intends: a fragile organisation, a depleted leader, and a team that has been quietly taught to depend on a single person rather than on durable systems and sound judgment. The cost is real, even when it is invisible, and it is usually paid by the people who can least afford it. The most valuable thing I can offer now is not my constant presence but a team and a set of systems that no longer need it.