Ninety minutes. That's the number. Work in 90-minute blocks, the advice goes, because that's your natural ultradian rhythm, discovered by sleep researcher Nathaniel Kleitman, and your brain simply performs on this cycle whether you like it or not. It's a satisfying story. It is also considerably more precise than the research behind it actually is.
This matters beyond trivia, because the number gets used to justify specific decisions: calendar policies, 'focus time' company norms, personal guilt when a session runs 40 minutes instead of the prescribed 90. If the underlying research doesn't actually support the precision the advice implies, those decisions are being made on a false floor. The commercial governance around deep work is covered properly by XenGrowth's work on go-to-market systems.
Where the 90-minute number actually comes from
Kleitman's real contribution was to sleep science: he identified a recurring cycle of roughly 90 to 120 minutes in sleep architecture, alternating stages of the brain's activity through the night. Later researchers proposed extending the same rhythm to waking hours — the idea that alertness and performance rise and fall on a similar cycle even while you're awake. That extension is a genuine area of research, not a fabrication. It is also, by the field's own account, considerably less settled than the sleep version: individual cycles are commonly reported anywhere from 75 to 120 minutes, and at least one review has specifically cautioned against treating any single short-cycle model as a universal law of waking performance.
None of that makes '90 minutes' a bad guess. It makes it a rounded midpoint of a real but individually variable range, presented with far more confidence than the underlying evidence supports. If your actual cycle runs closer to 75 minutes or closer to 120, forcing a 90-minute block onto it isn't science, it's a coincidence that happened to land on a memorable number.
Claim | Evidentiary status |
|---|---|
A roughly 90-to-120-minute cycle exists in sleep architecture | Well-established — Kleitman's original contribution, replicated extensively |
The same cycle continues, in some form, during waking hours | Genuinely studied, with real supporting findings, but less settled than the sleep version |
Individual waking cycles run exactly 90 minutes | Not supported — commonly reported range is roughly 75 to 120 minutes, varying by person |
This cycle should determine your work-block length specifically | An extrapolation from the above, not a direct finding of the underlying research |
Laid out this way, the honest version of the ultradian-rhythm claim is a real phenomenon wearing a much more precise number than the evidence assigns it. That's a common pattern with popular science generally — a genuine finding gets rounded to a clean, memorable figure somewhere between the lab and the listicle, and the rounding is where the false precision creeps in. For the the operations side of this angle, see The XenGrowth resource library.
The evidence that actually tells you something useful
Sophie Leroy's attention residue research doesn't answer 'how long should a block be' either, but it answers a more useful adjacent question: what makes the end of a block damaging. Across a series of experiments, she moved people from one task to another, sometimes letting them finish the first task, sometimes cutting it off mid-way. Performance on the second task suffered specifically when the first was left unfinished, and suffered more when that unfinished task had been under time pressure.
What ends the block | Effect on the next task, per Leroy's research |
|---|---|
A named stopping point reached (test passes, diff committed) | Minimal residue — attention transfers relatively cleanly |
The clock runs out mid-hypothesis, no stopping point defined | Measurable residue — part of attention stays locked on the unfinished task |
An external interruption cuts off an unfinished task under time pressure | The largest measured effect — worst of both: unplanned and unfinished |
That table implies something the 90-minute framing misses entirely: the damage isn't caused by a block running the 'wrong' length. It's caused by how the block ends. A 47-minute block that ends on a genuine stopping point should, by this research, leave you in better shape than a 90-minute block that ends mid-thought because a calendar reminder fired.
Where the Pomodoro Technique fits, and where it doesn't
It's worth placing the other popular block-length convention next to this evidence, because it makes a genuinely different claim. The Pomodoro Technique's 25-minute interval was never presented as a discovery about the brain's natural cycle — it's a self-imposed constraint designed to force regular breaks and make starting a task feel smaller. That's a legitimate and different goal from 'match your ultradian rhythm,' and the two shouldn't be evaluated against the same evidence. If your problem is starting, a short forced interval genuinely helps regardless of what your waking rest-activity cycle happens to be doing. If your problem is holding a complex mental model long enough to make progress on it, a 25-minute hard stop can work directly against you — cutting off a session at a fixed short interval is exactly the kind of arbitrary, unplanned ending Leroy's research associates with worse residue, unless the 25 minutes happens to land on a real stopping point by chance. There is a longer treatment of AI agents and marketing automation in XenGrowth on AI agents and marketing automation.
What the realistic baseline looks like
It's worth grounding all of this against what a normal engineering day actually looks like, because the deep-work conversation tends to happen as if 90-minute blocks were the default being optimized, rather than a rare event being fought for. Meyer, Barton, Murphy, Zimmermann and Fritz's instrumented study found developers switching activities every 0.3 to 2.0 minutes outside planned meetings. Their data does include one outlier worth naming: a single participant who coded for 135.7 minutes with no break longer than two minutes. The researchers were careful to call it an exception, not the median.
The exception in the data is more encouraging than the average. It's possible to hold a long block. It just isn't what the typical day looks like, which means the real fight usually isn't over the ideal length — it's over whether any protected block exists at all.
How to actually plan a stopping point, not just decide to have one
Naming a stopping point in advance is easy to say and easy to do badly, because the natural instinct is to name a vague one — 'make progress on the bug' isn't a stopping point, it's a direction. The stopping points that actually hold up under Leroy's research are the ones specific enough that you can check, without ambiguity, whether you've hit them: a named test passing, a specific function's behavior confirmed against three inputs, a diff that compiles and is ready for review. Vague stopping points fail exactly the way a clock-based ending fails — you run out of time or attention before reaching a fuzzy target, and the block ends on something unfinished by definition, because 'progress' was never a state you could actually complete.
Write the stopping point down before you start, not as an afterthought once you're already absorbed. Once you're deep in a problem, defining a clean exit becomes much harder to do well
Make it binary, not directional. 'This test passes' is checkable. 'I understand this better' is not, and it will not protect you from an unplanned, unfinished ending
If the task is genuinely open-ended — exploratory debugging with no obvious sub-goal — pick a time-boxed checkpoint instead, and treat reaching the checkpoint itself as the stopping point: 'write down my current three hypotheses' is checkable even when 'solve the bug' isn't
Plan for the block to end before the stopping point is reached sometimes, and have a one-sentence habit for that case too: jot down the specific next action, not a vague reminder to 'pick this back up later'
Treat the planned stopping point as more important than the planned duration. If you reach it in 30 minutes instead of the 90 you blocked out, stopping there is very likely the better outcome, not a wasted reservation
So what number should you actually use?
The honest answer is that the research doesn't hand you one, and treating 90 as gospel does more harm than admitting that. What it does support, clearly, is a shape: protect whatever contiguous time you can actually get, and design the end of that time around a task boundary rather than a clock. If your realistic protected time is 45 minutes, use 45 minutes and pick a stopping point that fits inside it. If you can genuinely hold two hours, the ultradian research gives you loose permission to run that long, but the same rule about ending on a boundary still applies — a two-hour block that ends mid-hypothesis is not obviously better than a 45-minute one that ends clean. XenGrowth on AI search, GEO and discovery covers the AI search, GEO and discovery side of this.
Where this actually pays off is in how you plan the block before you start it, not in which number you write on the calendar invite. Naming a stopping point in advance — 'done when this test passes,' not 'done in 90 minutes' — is the one piece of this whole conversation with research behind it strong enough to build a habit on.
There's a version of this advice that's actually harder to follow than picking a number, and it's worth admitting that directly. A fixed duration is simple: set a timer, work until it rings. A named stopping point requires you to think, before you've even started, about what 'done for now' looks like for a task you may not fully understand yet — which is a real cognitive cost, just one paid up front instead of at the end. The trade is worth it precisely because the research locates the damage at the end of the block, not the middle, and paying a small planning cost up front to avoid a larger residue cost at the exit is a good trade even when the planning itself feels like friction.
It's also worth being honest that some days won't allow any of this. If your calendar genuinely has no contiguous stretch longer than fifteen minutes, no amount of careful stopping-point design turns that into deep work — the fix that day is structural, not tactical, and belongs in a conversation about what's filling the calendar in the first place rather than in how you plan the fifteen minutes you do get.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
If deep work is part of a growth programme rather than a standalone build, XenGrowth, who work on the commercial side of this is the companion reading.
Five questions about the work in front of you today, not a personality test. The evidence supports ending on a stopping point far more strongly than it supports any specific minute count, so treat the outcome as a starting shape, not a rule.
