The Hidden Cost of Always-On Culture (And How I Fixed It)

My phone buzzed at 11:47 PM on a Tuesday. A Slack message from a client in London. "Quick question about the API integration — can you take a look?"

I was in bed. My wife was asleep. I picked up the phone, squinted at the screen, typed a response, got sucked into a thirty-minute debugging conversation, and then lay awake for another hour because my brain had switched back into work mode.

This was not an emergency. Nobody's production system was down. Nobody was losing money. It was a "quick question" that could have waited eight hours for a response without any consequence whatsoever. But I answered it because that's what always-on culture trains you to do. Be responsive. Be available. Show that you care about the work.

I did this for years. It nearly broke me.

---

The Costs You Don't Notice Until You Add Them Up

The obvious cost of always-on culture is burnout, and I'll talk about that. But the costs I didn't notice for a long time were subtler and, in some ways, worse.

Degraded decision quality. When you're always partially engaged with work, you're never fully resting. And when you're never fully resting, your cognitive performance degrades in ways that are invisible from the inside. I wasn't making catastrophic mistakes — I was making slightly worse decisions, consistently, across everything. Choosing the expedient architecture instead of the right one. Writing code that worked but wasn't maintainable. Missing edge cases I would have caught if I'd been sharp.

The research backs this up. Chronic partial sleep deprivation — the kind you get from waking up to check Slack at midnight — impairs judgment at roughly the same level as moderate alcohol intoxication. I was essentially showing up to work slightly drunk, every day, for years. I just didn't realize it because the impairment was gradual.

Relationship erosion. My wife stopped telling me about her day because she knew I was mentally composing a response to a work message while she talked. She didn't say this angrily. She said it matter-of-factly, which was worse. "You're not really here," she said one evening. "You're looking at me but you're thinking about that deployment."

She was right. I was thinking about that deployment.

Lost capacity for deep work. The most valuable work I do — system architecture, complex debugging, writing — requires sustained concentration. Always-on culture is the enemy of sustained concentration. Every notification is a context switch, and every context switch has a recovery cost. Studies suggest it takes 23 minutes to fully recover focus after an interruption. When you're getting pinged every 15 minutes, you never reach full depth.

I spent years producing shallow work and blaming myself for not being as productive as I used to be. The problem wasn't me. The problem was that I'd made myself constantly available and was paying for it with the cognitive capacity I needed to do my best work.

---

The Breaking Point

The breaking point came on a Saturday morning in Alaska. I was supposed to be fishing — one of the few activities I do that genuinely clears my head. I was standing in the Susitna River with my waders on and my rod in one hand and my phone in a waterproof case in my pocket. Because what if someone needed me.

A notification vibrated against my thigh. I looked. It was a non-urgent PR comment. I started mentally drafting a response while holding a fishing rod in a river in one of the most beautiful places on Earth.

That was the moment I thought: this is insane. I am standing in a river in Alaska and I am thinking about a pull request comment.

I put the phone in my truck. I fished for three hours without looking at it. When I got home, I answered the PR comment. The world had not ended. The project had not collapsed. Nobody had even noticed a three-hour delay.

That was two years ago. Here's what I changed and how.

---

The System I Built

I didn't just "decide to unplug." I've tried willpower-based approaches to work-life balance and they don't stick, at least not for me. What works is systems — concrete rules with concrete enforcement mechanisms.

Rule 1: Work has operating hours.

I set my work hours to 7 AM - 5 PM Alaska Time. Outside those hours, I don't respond to work messages. Period. Not "unless it's urgent." Not "unless it's a quick question." Not at all.

I communicated this clearly to every client and collaborator. I put it in my contracts. I put it in my email signature. I set up auto-responses:

// Auto-response configuration I built for my notification system
var workHours = {
  start: 7,  // 7 AM
  end: 17,   // 5 PM
  timezone: 'America/Anchorage',
  days: ['Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday']
};

var autoResponse = function(message) {
  var now = new Date();
  var hour = parseInt(now.toLocaleString('en-US', {
    timeZone: workHours.timezone,
    hour: 'numeric',
    hour12: false
  }));
  var day = now.toLocaleString('en-US', {
    timeZone: workHours.timezone,
    weekday: 'long'
  });

  var isWorkTime = hour >= workHours.start &&
                   hour < workHours.end &&
                   workHours.days.indexOf(day) !== -1;

  if (!isWorkTime) {
    return {
      send: true,
      text: 'Thanks for your message. I respond to messages during work hours ' +
            '(7 AM - 5 PM Alaska Time, Mon-Fri). I\'ll get back to you then. ' +
            'For genuine emergencies, call my phone directly.'
    };
  }

  return { send: false };
};

The key phrase is "genuine emergencies, call my phone directly." In two years, nobody has called. Not once. Because nothing has actually been an emergency. The urgency was manufactured by the always-on expectation, not by the actual importance of the work.

Rule 2: Notifications are off by default.

I turned off all push notifications for work applications on my phone. Slack, email, GitHub — all silent. I check them during work hours on my own schedule, not when they demand my attention.

This felt terrifying for about a week. Then it felt like freedom.

Rule 3: Deep work gets scheduled, not squeezed in.

I block two hours every morning — 7 AM to 9 AM — for deep work. No meetings, no messages, no interruptions. This is when I do architecture, complex debugging, and writing. I put it on my calendar as a recurring event and I treat it like a meeting with a client: non-negotiable.

// My daily schedule structure
var dailySchedule = {
  deepWork: { start: '07:00', end: '09:00', rules: 'No interruptions. Phone in another room.' },
  collaborative: { start: '09:00', end: '12:00', rules: 'Meetings, code reviews, pair programming.' },
  lunch: { start: '12:00', end: '13:00', rules: 'Away from desk. Outside if possible.' },
  afternoon: { start: '13:00', end: '15:00', rules: 'Mixed work. Communications open.' },
  windDown: { start: '15:00', end: '17:00', rules: 'Admin, planning, non-critical comms.' },
  offline: { start: '17:00', end: '07:00', rules: 'Not working. Not thinking about work.' }
};

// The 'offline' block is the most important one
// Everything else is negotiable. That one isn't.

Rule 4: Weekends are not for catching up.

I used to spend Sunday evenings "getting ahead" on the week. Reviewing PRs, answering emails, planning sprints. I told myself this was strategic — that I was being proactive.

It was actually anxiety management. I was working on Sundays because the pile of Monday morning messages made me anxious, and working on Sunday reduced the anxiety temporarily. But it also meant I never fully disconnected, which increased the underlying anxiety over time. It was a trap disguised as productivity.

Now I don't work on weekends. If Monday morning has a pile of messages, I work through them Monday morning. That's what Monday morning is for.

---

What I Lost (And What I Gained)

I'll be honest about what this cost me professionally.

I lost some clients. Two clients explicitly told me they needed someone more responsive and took their work elsewhere. One of them was my highest-paying client at the time. That hurt financially and it hurt my ego.

I lost the illusion of indispensability. When you're always available, you feel needed. When you set boundaries, you discover that most of the "urgent" requests get resolved without you. That's a good thing operationally but it's uncomfortable psychologically. Nobody wants to find out they're less essential than they thought.

I respond slower. My average response time to non-urgent messages went from minutes to hours. Some people don't like that.

Here's what I gained:

Better work output. My code quality improved measurably. Fewer bugs in production. Better architecture decisions. More thoughtful code reviews. The two hours of deep work I do every morning produce more valuable output than the twelve hours of fragmented work I used to do.

My marriage improved. My wife told me, about three months after I made these changes: "You're back." That's the best review I've ever received for anything.

Physical health recovered. I sleep seven to eight hours now. I wasn't sleeping more than five or six before, and I didn't even realize it because the midnight Slack checks had become so normalized. Better sleep fixed a cascade of issues: better mood, more energy, fewer headaches, better concentration.

I actually enjoy programming again. This one surprised me. I'd been telling myself for years that I was burning out on software development. I wasn't. I was burning out on the context-switching, the manufactured urgency, the constant low-level stress of being always available. The programming itself was fine. The working conditions were the problem.

---

The Industry Problem

My situation wasn't unique. Always-on culture is endemic in software development, and it's getting worse. Remote work removed the natural boundary between office and home. Slack and Teams made asynchronous communication feel synchronous. The "hustle culture" narrative convinced a generation of developers that availability equals dedication.

I've talked to dozens of engineers about this. The pattern is remarkably consistent:

1. Start a new job or freelance practice with reasonable hours
2. Gradually extend availability to prove dedication or please clients
3. Normalize the extended availability until it becomes the baseline expectation
4. Experience degraded work quality, health issues, and relationship strain
5. Blame yourself for not being resilient enough
6. Either burn out completely or start setting boundaries

Step 5 is the dangerous one. The always-on culture is designed to make you feel like the problem is you — that you're not tough enough, not dedicated enough, not passionate enough. The truth is that human cognition has limits, and chronically exceeding those limits produces worse outcomes for everyone.

---

Practical Boundary-Setting for People Who Are Bad at It

If you're reading this and recognizing yourself, here's what I'd suggest. These aren't theoretical — they're the specific steps that worked for me and for engineers I've shared them with.

Start with one boundary. Don't overhaul everything at once. Pick one thing: no work after 8 PM, or no Slack on weekends, or no meetings before 10 AM. Enforce it for two weeks and observe what happens. Almost certainly, nothing bad will happen.

Communicate proactively. Don't just go silent. Tell people what you're doing and why. "I'm restructuring my schedule to protect deep work time, so I'll be responding to messages between 9 AM and 5 PM going forward." Most people will respect this. Some will admire it. A few won't like it, and those are the people whose expectations were unreasonable in the first place.

Automate the enforcement. Use scheduled Do Not Disturb. Use auto-responders. Use calendar blocking. Don't rely on willpower to enforce boundaries — willpower depletes, especially when you're tired and a client is asking for "just five minutes."

Accept the professional cost. You might lose a client. You might get passed over for a promotion that goes to someone who answers emails at midnight. That's a real cost and I won't pretend it isn't. But weigh it against the cost of degraded health, damaged relationships, and declining work quality. In my experience, the math heavily favors boundaries.

Track the results. Keep a simple log of your work quality, energy levels, and how you feel. After a month of enforced boundaries, compare it to the month before. The data will make the case better than any article can.

// Simple boundary effectiveness tracker
var boundaryLog = function(entry) {
  return {
    date: new Date().toISOString(),
    boundaryMaintained: entry.keptBoundary,  // boolean
    consequence: entry.whatHappened || 'nothing',
    energyLevel: entry.energy,  // 1-10
    workQuality: entry.quality,  // 1-10 self-assessment
    notes: entry.notes || ''
  };
};

// After 30 days, aggregate the data
var analyzeMonth = function(logs) {
  var boundaryDays = logs.filter(function(l) { return l.boundaryMaintained; });
  var noBoundaryDays = logs.filter(function(l) { return !l.boundaryMaintained; });

  var avgEnergy = function(entries) {
    var sum = entries.reduce(function(acc, e) { return acc + e.energyLevel; }, 0);
    return entries.length > 0 ? (sum / entries.length).toFixed(1) : 0;
  };

  return {
    daysWithBoundaries: boundaryDays.length,
    daysWithout: noBoundaryDays.length,
    avgEnergyWithBoundaries: avgEnergy(boundaryDays),
    avgEnergyWithout: avgEnergy(noBoundaryDays),
    consequencesThatMattered: logs.filter(function(l) {
      return l.consequence !== 'nothing';
    }).length
  };
};

// Spoiler: consequencesThatMattered is almost always close to zero

---

Two Years Later

It's been two years since I stood in that river and realized I'd let work colonize every waking moment of my life. I'm writing this from my cabin in Caswell Lakes at 6:45 PM on a weekday. My laptop is closed. I'm writing this on a notepad — actual paper — and I'll type it up tomorrow during work hours.

I make less money than I did at peak always-on. I have fewer clients. I respond slower to messages. By every metric that always-on culture values, I'm performing worse.

But my code is better. My architecture decisions are sharper. My clients get a version of me that's rested, focused, and capable of deep thought. My wife gets a husband who's actually present. I get to fish without a waterproof phone case.

The hidden cost of always-on culture isn't just burnout. It's the slow, invisible erosion of everything that makes you good at your work and everything that makes your life worth living outside of it. You don't notice it happening because each individual concession feels small — one late-night Slack response, one Sunday afternoon of "catching up," one more notification you could have ignored.

But they compound. They always compound.

Set the boundary. Accept the cost. The math works out. I promise.

---

Shane Larson is a software engineer and the founder of Grizzly Peak Software. He writes about software development, AI, and building real things from a cabin in Caswell Lakes, Alaska. You can find more of his work at grizzlypeaksoftware.com.