The WFH Availability Trap: Why Being Always On Is Destroying You

Kafka’s The Metamorphosis begins with Gregor Samsa waking up one morning to discover he’s become a giant insect. The story is usually read as an allegory for alienated labor — the worker as something less than human, consumed by his function. But there’s a specific detail that reads differently when you’ve been working from home for a few years:

Before the transformation, Gregor was the sole earner for his family. His income sustained everyone. They depended completely on his output. And that dependence — the weight of being essential to everyone around him — contributed to the condition that made him something that could no longer function.

Strong beasts of burden, infinitely available, eventually stop functioning. The load doesn’t have to be malicious to be crushing.

The WFH Availability Dynamic #

Remote work has been largely positive for the industry. Commutes eliminated, flexibility increased, access to roles expanded. Most developers who’ve worked remotely for a few years don’t want to go back.

But there’s a dark side that doesn’t get talked about enough: the collapse of the boundary between available and unavailable.

In an office, there was a physical signal — leaving the building — that marked the end of the workday. It was imperfect, but it existed. Remote work eliminated that signal and replaced it with nothing. The laptop is always there. The Slack notification is always one ping away. The “quick question” can arrive at any hour.

For developers who are good at their jobs and genuinely care about their work, this creates an insidious dynamic: the better you are at being available, the more available you’re expected to be, and the more available you become. The system expands to fill your availability.

This is not a malicious conspiracy by your employer. It’s an emergent property of an environment with no natural stopping point. The employer optimizes for responsiveness because it can. The developer optimizes for being a good team member. Both are rational. The result is an always-on condition that neither person explicitly chose.

What It Actually Costs You #

Deep work becomes impossible. The ability to do serious, uninterrupted cognitive work — the kind that produces good architecture, elegant code, real solutions to hard problems — requires extended, uninterrupted blocks of focus. A developer who is responsive to messages throughout the day is structurally unable to maintain those blocks. The interruptions fragment the thinking.

Recovery time disappears. The brain needs time to not be working on work problems. This is not indulgence — it’s how cognitive recovery functions. Developers who are always half-processing work, always somewhat on-call, always within reach of the job, don’t fully recover. The deficit accumulates. The work gets worse. The satisfaction decreases. Burnout is not a sudden event; it’s a slow drain.

Everything starts to feel like work. When work is always present — always a Slack message away, always capable of intruding — the space that used to belong to not-work slowly gets colonized. Hobbies feel less engaging because the brain is still partially occupied elsewhere. Relationships suffer because you’re not fully present. The quality of the non-work parts of life decreases.

The Fix Is Structural, Not Motivational #

Telling yourself to be better at disconnecting doesn’t work. The availability pressure is real and it reasserts itself. What works is changing the structure.

Define your hours and communicate them. This sounds obvious and most people don’t do it. Set a clear window — “I’m available 9-5 eastern, I check messages morning and afternoon and don’t respond after 6” — and tell your team. Put it in your Slack status. This does two things: it manages expectations and it creates a social contract that’s harder to violate than a personal intention.

Create a physical shutdown ritual. Since remote work removed the physical signal of leaving the building, create a substitute. A walk, a workout, changing clothes, making a specific drink — some physical action that marks the transition from work to not-work. It sounds psychological because it is. It works because your brain is a pattern-matching machine and rituals give it a cue.

Turn off notifications after hours. Not muted — off. On your laptop, on your phone. If there’s a real emergency, someone will find a way to reach you. The notification that feels urgent at 9pm is almost never actually urgent. The anxiety it generates is real regardless.

Stop performing availability. A lot of developers are available not because the work requires it but because they want to be perceived as responsive and committed. This is understandable and counterproductive. Responding to every message immediately doesn’t make you better at your job — it makes you someone who is always in reactive mode, which is the enemy of good engineering work.

The Gregor Samsa Outcome #

Kafka’s metaphor is unsubtle: the infinitely available worker eventually becomes something that can’t function. The family, initially devastated, eventually realizes they can manage without him — and their grief gives way to something like relief.

Don’t wait for the transformation. The version where you proactively build boundaries and protect your capacity is better for you, better for your work, and — though it seems counterintuitive — better for the team that depends on you.

The best engineers are not the most available ones. They’re the ones who show up rested, focused, and capable of sustained high-quality work. Those conditions require space. Build the space.