Paul Graham identified the problem in 2009. Nobody has fixed it yet.
In 2009, Paul Graham published a short essay called "Maker's Schedule, Manager's Schedule." It is one of the most-shared pieces of writing in tech culture, routinely cited in discussions of meeting culture, deep work, and knowledge worker productivity. Almost everyone who has read it agrees with it.
Almost nothing has changed as a result.
The essay's core observation is simple: there are two fundamentally different relationships to time. Managers work in one-hour units — their calendar is a grid of appointments, and a meeting at 2pm affects only that hour. Makers — programmers, writers, designers, researchers, anyone whose work requires sustained concentration — work in half-day units. A single meeting at 2pm doesn't just consume that hour. It fragments the entire afternoon, because the anticipation of the meeting prevents the kind of deep focus that the preceding two or three hours could have supported.
Graham was describing a real phenomenon, and the research on flow states, attention recovery, and cognitive switching costs has largely validated his intuition. What he didn't address — what nobody building productivity software has adequately addressed — is that the problem isn't just meetings. It's the entire architecture of the task list.
Tasks Are Not Interchangeable Units of Time
The dominant mental model behind every to-do list ever built is that tasks are interchangeable units that can be arranged and executed in any order, and that productivity is a function of how many units you process in a given time period. This model is false, and its falseness has consequences that compound daily for anyone doing creative or analytical work.
Tasks differ along at least four dimensions that matter enormously for how they should be sequenced:
Cognitive load. Some tasks require sustained concentration and working memory — writing, analysis, programming, strategic thinking. Others require attention but not concentration — email, scheduling, administrative work. Still others are nearly automatic — filing, routine data entry, answering simple questions. These cannot be interleaved without cost. Switching from a high-load task to a low-load one and back again requires cognitive reconfiguration — the brain must build a new context model with each switch — and this reconfiguration takes time and consumes resources.
Flow dependency. Some tasks can only be done well after a runway — a period of lower-intensity preparation that brings the relevant context into working memory, quiets the noise of everything else, and allows genuine concentration to develop. Graham's maker requires multiple uninterrupted hours not because the work is necessarily slow but because the first hour is largely runway. You cannot get a running start in the ten minutes between meetings.
Sequential dependency. Some tasks must follow others in a specific order because their output is the input for the next stage. A to-do list that treats all tasks as parallel and independent cannot represent these dependencies adequately, which means it routinely suggests doing things in the wrong order.
Energy alignment. Different tasks are better suited to different cognitive states. Tasks requiring creative generation tend to go well in the early morning when the prefrontal cortex is fresh and the inhibitory systems that filter "impractical" ideas are relatively quiet. Tasks requiring critical analysis tend to go better mid-morning. Administrative tasks can be deferred to afternoon energy dips. A task list that is indifferent to energy alignment is recommending work in random order relative to the cognitive state that would produce the best outcome.
How the Notification Layer Destroys the Maker
The problem Graham identified has been significantly worsened by the notification environment that has developed since 2009. A maker in 2026 faces not just the meeting at 2pm — they face a constant low-level interruption stream from Slack, email, task management apps, calendar alerts, and AI assistants, each of which creates the same anticipatory fragmentation that Graham identified in meetings.
Research on attention recovery consistently finds that interruptions cost more than they appear to. A notification that takes three seconds to read and dismiss can disrupt a flow state for fifteen minutes or more, because flow is not a light switch — it is a state that requires gradual establishment and is disrupted suddenly. The economics are asymmetric: attention is slow to accumulate and fast to dissipate.
A productivity app that sends a reminder about an administrative task while you are in the middle of a deep work session is not helping you. It is making a small interruption that costs you a disproportionate amount of your most productive time — all to surface something that could have been surfaced two hours later without any loss.
The timing of a nudge is not a minor feature. It is a primary determinant of whether the nudge helps or hurts.
The Calendar Is Not the Answer
The standard advice for protecting maker time is to block it on a calendar — to schedule deep work the way you would schedule a meeting, making it visible and defensible. This advice is correct as far as it goes. Calendar blocking does reduce interruptions, and it does create a social contract around protected time.
But it doesn't solve the sequencing problem within a work block. A two-hour deep work block with a disorganized task queue still requires the maker to decide, in the moment, what to work on — which is itself a cognitively expensive decision that partially consumes the resources that should be going to the work.
Research on decision fatigue consistently finds that the quality of decisions degrades over the course of a day, particularly when people are making many small decisions. Choosing what to work on next, dozens of times per day, is exactly the kind of low-value decision that consumes cognitive resources without producing meaningful output. The ideal productivity system would largely eliminate this decision — presenting the right task at the right time in the right cognitive context, so that the maker arrives at their deep work block with a clear, pre-sequenced queue rather than an undifferentiated list.
What Behaviorally Intelligent Task Delivery Looks Like
A system genuinely designed for maker productivity would treat task delivery as a first-class design problem, not an afterthought.
It would know the difference between a maker task and a manager task — and it would not surface a maker task during a manager hour, or a manager task during a maker block. It would understand that the first hour of a work session is runway and protect it accordingly, rather than firing a reminder in the first ten minutes about something that could wait.
It would sequence tasks within a work block based on cognitive load and flow dependency — leading with the highest-load work when energy is highest, transitioning to medium-load tasks as energy declines, and batching administrative work into the natural energy valleys of the day.
It would be aware of the upcoming schedule — knowing that a 2pm meeting fragments the afternoon — and adjust its suggestions accordingly, surfacing work in the morning that can be meaningfully completed before the fragmentation hits.
And it would vary its timing and framing based on what has historically produced action versus what has been ignored. A nudge that fires at 9am every day for a task that you've consistently deferred has learned nothing. A system that notices the deferral pattern and adjusts — trying a different time, a different framing, a different contextual hook — is doing something qualitatively different.
This is not science fiction. It is applied behavioral science. The reason it doesn't exist yet is not that it's too hard to build. It's that most productivity software was designed around the manager's schedule, not the maker's — optimizing for organizational visibility and feature completeness rather than for the cognitive reality of people trying to produce work that requires genuine concentration.
Graham described the problem fifteen years ago. The software industry heard him, nodded, and kept building the same things.
Yuko is building the first AI nudge engine that understands the difference between a maker task and a manager task — delivering the right work at the right cognitive moment. Learn more at yuko.ai
