Context Switching: Why an Eleven-Hour Day Moves Nothing
What it actually looks like
You opened the file at 9:40. You are back in it at 11:15, reading your own code the way you would read a stranger's — scrolling up to remember what the function was supposed to do, finding the comment you left yourself, not trusting it.
Between those two moments you did real things. A support ticket. A contract question. Two Slack threads, one of which you resolved in under a minute and felt good about. None of them took long. Together they took the morning.
Your first genuine hour of work happens at eleven at night. Not because you are sharper then — you are demonstrably not — but because it is the first hour of the day when nobody wants anything from you. You have started calling yourself a night person. You were not one three years ago.
There are more open tabs than you can read the titles of. You do not close them because each one is a thread you intend to pick up, and closing it feels like dropping something. The browser has become a to-do list you cannot sort.
You check the messages when the work gets hard. Not consciously. You hit the part of the problem where you have to hold four things in your head at once, and your hand moves. You are back in ninety seconds, and the four things are gone.
And you finish the day tired in a way that does not match anything you could point at. Nothing was heavy. You are wrung out anyway, and you go to bed with the specific unease of someone who worked all day and cannot say at what.
Who this happens to
This is common among founders who are genuinely good at being responsive.
Fast replies built something real for you. Early customers stayed because you answered on a Sunday. Your team is not blocked, ever, because you are always there. That responsiveness was a competitive advantage when the company was small enough for you to be its nervous system, and nobody sends a memo when it stops being one.
It is common in solo founders and small teams for a structural reason rather than a personal one: you are the engineer, the salesperson and the support desk, and those three roles want different states of mind. Switching is not a bad habit you picked up. It is written into the job as currently designed.
It happens to people who work in an always-on chat, where the norm is a reply in minutes and the absence of one reads as a problem. And it is common in people whose attention runs fast and wide — who notice everything, connect things other people miss, and have never had a comfortable relationship with sitting still inside one narrow problem for two hours. That attention is an asset in a discovery conversation. It is expensive in a build.
What sets it off
The obvious trigger is the ping, and it is the least interesting one.
The real trigger is the boundary you never drew. When every hour is equally interruptible, every hour gets interrupted — not because people are inconsiderate, but because nothing told them otherwise. A calendar with no protected block does not read as "focused work happening here." It reads as available.
Wearing three roles inside one day sets it off. A support ticket arriving at 10:05 does not feel like an interruption; it feels like your job, because it is. The cost is not that you answered it. The cost is that answering it required you to become a different person for four minutes, and the person you were before had a data model loaded that nobody saved.
And the trigger almost nobody counts: you. Watch the next time you reach for another window. It will not be at a natural stopping point. It will be at the exact moment the work turned genuinely difficult — the part with the four variables, the part where you might be wrong. The interruption arrived from outside far less often than it feels like it did.
Why it keeps happening
The mechanism is a rebuild cost that never appears on any clock.
Complex work runs on a mental model you have to load: what the code does, why it does it that way, what you had ruled out, where you were heading next. That model lives in working memory, which is small and volatile. It does not persist while you answer a message. It has to be rebuilt from the file, from scratch, every time — and the rebuild is slower than the switch that destroyed it, by a wide margin.
Twenty switches a day can quietly delete most of your real capacity while leaving the day looking full. Nothing was wasted, in the sense that every individual thing was legitimate. The waste is entirely in the seams, and the seams are not on the calendar, so they are not in your accounting of where the time went.
Then there is why the switching is so hard to stop, which is that it pays. Each glance offers a small, reliable return: relief from a difficult problem, a hit of novelty, and something even better — the feeling of being on top of things. You are following a working incentive gradient, not failing to concentrate. That is why "have more discipline" has never once worked on this.
Underneath both is a belief worth saying out loud: staying reachable is what makes me a good founder. It is worth testing, because responsiveness is legible to everyone and deep work is legible to no one. Nobody thanks you on Thursday for the two undisturbed hours on Tuesday that made the hard thing possible. They notice the slow reply immediately.
So ask the honest version. When was the last message that genuinely could not have waited ninety minutes? Most founders, pressed on this, cannot name one from the past month. If that is true for you, then "available" is costing you your best hours to guard against something that almost never arrives.
What actually helps
Take one block, today, and defend it like a customer call. Sixty to ninety minutes. Phone in another room — not face down, another room. One tab, one file, one problem. The length matters less than the fact that it is declared and has an edge: your attention needs to know the block ends, or it will keep checking whether it has been forgotten.
Batch the world into its own window instead of letting it live in yours. Two or three fixed times a day for messages, tickets and email, on the calendar, visible to whoever needs to see it. You are not becoming unreachable. You are moving from a system where everyone can reach you at any moment to one where everyone can reach you at a known moment, which is what people actually want and almost never get.
Keep a note beside you for your own interruptions. When the thought arrives mid-build — check the metric, fix the dependency, look up the thing — write it on the note and stay where you are. Most of what the impulse wanted was to be recorded, not acted on. Deal with the list at the end of the block. Half of it will have expired.
Give the block one action that starts it. Same first move every time: close everything, full-screen the editor, open the one file. A repeated cue gets faster at producing the state it precedes, and this is the cheapest way to shorten the load-in you currently pay in full every morning.
Then write one line when the block ends: what moved. Not a log, one sentence. It builds the only evidence that will ever change your mind about this — a week of days where you can name what happened, next to the memory of a hundred days where you could not.