Most productivity advice fails engineers, and the reason is measurable

TL;DR#

Most general productivity advice optimises the number of interruptions. For work with a long reload cost, the number is the less important variable, and some of the most widely recommended techniques make things actively worse by capping the length of a work block below the time it takes to get productive.

I measured my own reload cost on real work: 23 minutes to get back to where I was after an interruption, on a task I had not been holding for very long. A 25-minute Pomodoro against a 23-minute reload yields two productive minutes.

That is not a criticism of Pomodoro, which works well for the work it was designed around. It is that the advice is calibrated on a reload cost near zero, and nobody states the assumption — so engineers adopt it, get worse results, and conclude they are undisciplined.

The case this post is about#

I had a month where I was visibly busy and shipping very little. The usual diagnosis applied cleanly: too many interruptions, poor boundaries, not enough focus. So I did the usual things.

week 1   adopted Pomodoro (25/5), batched email to 3 fixed times,
         notifications off outside those windows
week 2   same, plus a "do not disturb" block 09:00–11:00
week 3   same, plus timeboxing each ticket to a 25-minute estimate

Three weeks of textbook application, each change the one the advice recommends, and each one implemented properly rather than half-heartedly.

The symptom#

Output went down, not up. Measured by the only thing I had that was not self-report — merged pull requests, and the proportion that were substantive rather than trivial:

            PRs merged   substantive   self-reported "focused" days
baseline         11           6                 1 / 5
week 1            9           3                 3 / 5
week 2            9           3                 4 / 5
week 3            7           2                 2 / 5

The third column is the part I find most useful in hindsight. I felt more focused, measurably so, in exactly the weeks I produced less. The techniques were delivering their promised experience and the opposite of their promised result.

The work that suffered was specifically the hard work. The trivial PRs held up fine. What collapsed was the category that required holding a system in my head — a migration with four interacting constraints, a race condition I could only see by tracing three components at once.

And the 25-minute blocks had a shape I had not noticed. When I started timing what happened inside them:

minute 0–6     re-reading the code I had open, remembering the problem
minute 6–18    rebuilding the mental model: which call path, which invariant
minute 18–23   starting to see the thing again
minute 23–25   timer rings

I was stopping at almost exactly the point where the block became useful.

Why the obvious fix failed#

"You are not doing Pomodoro properly." Possible, and I had been precise about it — which is what made the result interesting rather than ambiguous. The technique was being executed as described; the description assumes something about the work that was not true of mine.

"Use longer Pomodoros, 50/10." Better, and it was the direction that eventually worked. It also reframes the technique into "work in long uninterrupted blocks", at which point the timer is doing nothing and the interval was never the active ingredient.

"Reduce interruptions further." I had already taken them to near zero in the DND window, and the DND window was two hours of an eight-hour day. The other six hours were where the work actually lived.

"You are just tired / it was a hard month." The honest alternative hypothesis, and the reason I went looking for a number. A subjective explanation for a subjective complaint is unfalsifiable, and I wanted to know whether there was anything mechanical underneath.

The actual mechanism#

Productive output from a work block is not the block's length. It is the length minus the time to become productive, and that subtraction is the whole story.

Reload cost is a property of the task, not of you. Rebuilding a mental model of four interacting constraints takes longer than remembering which paragraph you were editing. The figure for software work is commonly cited around 23 minutes; mine measured at 23 for ordinary feature work and considerably worse for the hard cases.

A work block shorter than the reload cost produces nothing. Not "less" — nothing. Every minute of a 20-minute block against a 23-minute reload is spent reloading, and the block ends before the model is rebuilt. Repeat it and you can spend an entire day at a high level of discipline with zero productive minutes.

And productive time is super-linear in block length. A 90-minute block is not three times as useful as a 30-minute one. It is 90 − 23 = 67 useful minutes against 30 − 23 = 7 — nearly ten times, from three times the wall-clock.

That super-linearity is the reason advice calibrated on shallow work inverts. If your reload cost is two minutes — email, scheduling, most knowledge work that is not holding a system in your head — then block length barely matters and interruption count dominates. Every technique built on that assumption is correct for that work and wrong for ours, and none of them says so.

Productive time is block_length − reload_cost, and reload cost is set by the task. Advice that optimises interruption count is implicitly assuming a reload cost near zero, which is a statement about the work it was written for.

The fix#

Stop optimising the count and start protecting the length. The arithmetic decides how long is long enough, and it is worth running on your own numbers rather than mine:

def productive_minutes(blocks, reload_cost):
    """blocks: list of uninterrupted block lengths in minutes."""
    total = 0
    for length in blocks:
        # A block shorter than the reload NEVER becomes productive. Not reduced output —
        # zero. Clamping at 0 rather than allowing a negative is the whole point:
        # these blocks do not subtract from the day, they simply contribute nothing.
        total += max(0, length - reload_cost)
    return total

def compare(schedules, reload_cost):
    for name, blocks in schedules.items():
        useful = productive_minutes(blocks, reload_cost)
        wall = sum(blocks)
        efficiency = useful / wall if wall else 0
        print(f"  {name:<22} {wall:>3}m wall → {useful:>3}m useful  ({efficiency:.0%})")

SCHEDULES = {
    "Pomodoro 25/5":      [25] * 8,          # 8 blocks, the week-1 schedule
    "Pomodoro 50/10":     [50] * 4,
    "two deep blocks":    [90, 90],
    "one deep + admin":   [120, 30, 30],
}

On my measured reload cost, and then on a shallow-work reload for contrast:

>>> compare(SCHEDULES, reload_cost=23)
  Pomodoro 25/5          200m wall →  16m useful  (8%)
  Pomodoro 50/10         200m wall → 108m useful  (54%)
  two deep blocks        180m wall → 134m useful  (74%)
  one deep + admin       180m wall → 111m useful  (62%)

>>> compare(SCHEDULES, reload_cost=2)
  Pomodoro 25/5          200m wall → 184m useful  (92%)
  Pomodoro 50/10         200m wall → 192m useful  (96%)
  two deep blocks        180m wall → 176m useful  (98%)
  one deep + admin       180m wall → 174m useful  (97%)

The second table is why this advice survives and spreads. At a reload cost of 2 minutes every schedule is fine — 92% against 98%, a difference nobody would notice. The technique is not wrong; it is simply not doing much, and its benefits in that regime come from the discipline of having a schedule at all.

At 23 minutes the same four schedules span 8% to 74%, a factor of nine, decided entirely by block length. Same hours, same discipline, same person.

The practical rules that fall out:

Measure your own reload cost before taking anyone's advice about intervals. Note the time when you resume, and the time you can next state the problem out loud without re-reading. Do it five times. The number is yours and the advice is not calibrated for it.

Protect length, not count. One genuinely uninterrupted 90-minute block beats four protected 25-minute ones, and it beats them by more than the wall-clock difference suggests.

And triage by reload cost, not by importance. Shallow work genuinely can be interleaved — that is what makes it shallow. Batching email into the gaps between deep blocks costs almost nothing, while batching deep work into the gaps between meetings costs everything.

How we proved it#

The reload measurement, five trials, resuming from a real interruption:

trial   task                              minutes to "I can state the problem again"
1       payment retry race condition          31
2       feature flag migration                 19
3       Compose recomposition bug              26
4       small CSS fix                           3
5       dependency bump + test fix              7

Trials 4 and 5 are the control, and they are the most informative rows in the table. Shallow tasks reload in single digits — so a measurement averaged across all my work would have produced something around 17 and hidden the entire effect. The number that matters is the reload cost of the work you are trying to protect, not your mean.

The schedule change, measured over four weeks against the same PR metric:

                        PRs merged   substantive
baseline (pre-advice)       11            6
weeks 1–3 (Pomodoro)      9, 9, 7      3, 3, 2
weeks 4–7 (two deep blocks)
  week 4                    10            6
  week 5                    12            8
  week 6                     9            7
  week 7                    12            8

Substantive PRs roughly doubled against the Pomodoro weeks and beat the original baseline, on fewer scheduled focus hours — the deep-block schedule protects 180 minutes a day where the Pomodoro schedule protected 200.

Two limits worth stating. This is one engineer over eleven weeks, unblinded, and I knew what I was hoping to find — the PR metric is the weakest part of the design, and "substantive" was my own judgement call made weekly rather than a pre-registered definition. And the reload figures are self-timed; a 31 that was really a 26 would not change the conclusion, but it would change the table.

What I would defend without reservation is narrower than the whole post: the arithmetic. If your reload cost exceeds your block length, the block produces nothing, and that follows from the definition rather than from my data.

What this generalizes to#

Advice carries an unstated model of the work. Every technique was developed against some distribution of tasks. When it transfers badly, the usual conclusion is a failure of discipline, and the actual cause is that the assumption was never written down and therefore never checked.

Averages hide bimodal costs. My mean reload was 17 minutes and no task in my week cost 17 minutes to reload — they cost 3 or they cost 30. Any decision made on the average is wrong for both halves.

A technique that improves how you feel while reducing what you produce is specifically dangerous. The felt experience is immediate and the output signal is weeks away, so the feedback loop reinforces the wrong thing. That is worth building a measurement around for exactly this reason, even a crude one.

And the first move with any productivity claim is to find the variable it is optimising. Then ask whether that is the variable binding your work. Most of the time the technique is sound and the variable is wrong.

Related#

• The productivity tool I deleted after measuring what it cost — the same arithmetic applied to tooling
• Context is a budget, not a bucket — reload cost, for a model instead of a person
• The self-review that changed my year — measuring output by effect rather than activity

Keep reading#

This is part of Developer productivity, honestly — claims with numbers attached, including the ones that did not work. Follow MobileByteSensei for the rest.