There’s a version of this topic that gets written about constantly, and it’s usually terrible. It involves words like ‘mindfulness’ and ‘hustle culture’ and ends with advice to take more walks. That’s not what this is.
This is about the mechanics of how high-output cognitive work actually functions, why doing nothing is not the opposite of productivity but a necessary phase of it, and why the people who understand this protect their empty time with the same seriousness they’d protect a critical path dependency.
The Confusion Between Activity and Output
Software engineers understand this intuitively in systems but tend to ignore it in themselves. A CPU running at 100% utilization sounds efficient. In practice, a CPU pegged at 100% is a problem. It means the system can’t respond to new inputs, can’t handle spikes, and is probably thrashing, spending more time context-switching between tasks than completing any of them. The useful metric isn’t utilization. It’s throughput.
The same distinction applies to knowledge work. A calendar packed edge to edge with meetings, deep work blocks, and deliverables looks productive from the outside. What it actually represents is a system with no slack. No capacity to absorb an unexpected problem. No space for the non-linear thinking that produces the work worth doing in the first place.
The highest-output people I’ve worked with, the ones whose judgment you actually want in a room when something hard needs solving, almost universally have calendar habits that look strange to their managers. They block time that says nothing. They disappear for an hour mid-afternoon. They don’t answer every message the moment it arrives. This isn’t accidental.
What Neuroscience Says About Rest and Cognition
The default mode network (DMN) is a set of brain regions that become more active when you’re not focused on a specific external task. For a long time, neuroscientists thought this was the brain idling. The name ‘default mode’ reflects that assumption.
That assumption turned out to be wrong. Research from the last two decades shows the DMN is doing substantial work during apparent rest: consolidating memories, making sense of social information, running simulations about the future, and, critically, finding connections between ideas that focused attention tends to miss. This is the neural substrate of insight. The ‘aha moment’ that arrives in the shower or on a run isn’t a mystical event. It’s the DMN finishing a computation that your focused work started.
Focused attention and diffuse processing are not competing modes. They’re sequential phases. You load the problem with focused work, then the DMN processes it during rest, then you return with focused attention to evaluate and execute what emerged. Short-circuit the rest phase consistently, and you don’t just miss insights. You degrade the quality of the focused work itself, because the mental models you’re working from never get properly updated.
This is why the advice to ‘just push through’ when you’re stuck on a hard problem is so often wrong. Pushing through applies to execution tasks where the path is clear and you’re just lacking will. For problems that require genuine insight, the efficient move is to stop, let the DMN run, and come back.
Why Scheduling Nothing Is Different From Hoping You’ll Rest
The obvious objection is: fine, but I do rest. I watch TV, I sleep, I take weekends.
The problem is that unstructured rest in the context of a hyperconnected work life usually isn’t rest at all. Checking Slack while watching TV is not rest for the DMN. Thinking about tomorrow’s presentation while lying in bed is not rest. The DMN needs genuine disengagement from the problem space, not just a reduction in active effort.
The reason high-output workers schedule empty time explicitly, rather than hoping it’ll happen organically, is the same reason any important work gets scheduled: if it’s not on the calendar, the environment will fill that space with something else. A two-hour gap in your afternoon will be claimed by a meeting, an email backlog, or your own anxiety about looking busy.
Scheduling the empty time is an act of environmental design. You’re acknowledging that your operating environment will always apply pressure to fill any visible slack, so you have to make the slack invisible to that pressure by treating it as committed time.
This is also why the form matters. A calendar block that says ‘thinking time’ or ‘focus time’ is not the same as genuine rest. That block invites you to sit down with a specific problem and stare at it, which is focused attention, not DMN processing. The blocks that work tend to involve low-demand physical activity (walking, light exercise), or genuinely unrelated engagement (reading something with no professional application), or simply nothing.
The Compounding Effect Over Long Horizons
The case for scheduled rest gets stronger the longer the time horizon you’re considering.
In any given week, the difference between a developer who takes afternoon walks and one who doesn’t might be imperceptible. The one who doesn’t might even ship more code in the short term. But over quarters and years, the person who’s consistently allowed their DMN to process hard problems is building better mental models. They’re making fewer architectural decisions they’ll have to undo. They’re catching the class of bug that comes from not seeing the whole system clearly.
Software teams understand this at the macro level. Technical debt is the canonical example: moving fast without reflection creates future costs that compound. The same mechanism operates at the individual cognitive level. A developer who never lets their thinking rest is accumulating a kind of cognitive technical debt, a backlog of half-processed problems and unexamined assumptions that quietly degrades the quality of every subsequent decision.
The engineers who’ve been most consistently right in my experience, not just smart but right, tend to have thought about the same problems more than once, in different contexts, at different times. That repetition with rest in between is how mental models actually mature.
What This Looks Like in Practice
The implementation details matter, because ‘schedule time to do nothing’ is advice that can be misapplied badly.
The effective version is not: block two hours and then feel guilty about not using them productively. Guilt reinstates the very cognitive pressure you’re trying to relieve.
The effective version looks more like this. Identify the one or two problems you’re genuinely stuck on, or the decisions where your thinking hasn’t crystallized. Load them with a focused session in the morning: read the relevant code, write out what you know and don’t know, articulate the specific question you can’t answer. Then, separately, later in the day, do something genuinely low-demand with no agenda around the problem. Don’t try to think about it. The DMN doesn’t need instructions.
Calendar-wise, this means blocking a 45-minute to hour-long slot that you treat with the same firmness you’d treat a one-on-one with your VP. Not a slot you’ll cancel if something comes up. A slot that exists specifically because something will always come up otherwise.
The objection from people managing others is always about optics. What does it look like if your team sees you blocking empty time? The honest answer is that it looks like what it is: someone who understands how their own cognition works and is optimizing for output rather than activity. The teams worth working on recognize this. The ones that don’t are optimizing for something other than results.
The Connection to Decision Quality
There’s a downstream effect on decision quality that doesn’t get talked about enough. Decisions made under continuous cognitive load, without genuine rest phases, exhibit predictable failure modes. They over-index on the most recent input. They’re more susceptible to framing effects. They collapse toward default patterns rather than engaging with the specific shape of the current problem.
This is not a matter of intelligence or effort. It’s a matter of the brain not having had time to run its consolidation processes. A senior engineer making architecture decisions in a state of accumulated cognitive fatigue is not the same engineer making those decisions after genuine rest, even if they’d score identically on any capability test you administered.
This is the version of the argument that should resonate with anyone who’s ever made a decision they regretted not because they lacked information, but because they weren’t thinking clearly. The information was there. The processing capacity wasn’t.
Scheduled empty time is, among other things, a way of ensuring that your most consequential decisions get made by the version of you with full processing capacity rather than the version running on fumes.
What This Means
Scheduling empty time is not about wellness or work-life balance, though it may incidentally improve both. It’s about understanding that cognitive output is a function of focused work and rest in combination, not just focused work alone.
The DMN is doing real work during apparent idleness. That work is not optional for high-quality thinking. It’s where insight, model-updating, and genuine problem-solving happen.
The practical implication is that if you want to consistently produce good work, you need to treat rest with the same scheduling discipline you apply to everything else. Not because you deserve it, but because the rest phase is a functional part of the work.
Protect those blocks. Treat canceling them as a cost, not a free move. And stop treating a fully packed calendar as evidence of effectiveness. A system with no slack isn’t running at full capacity. It’s one unexpected input away from falling over.
