"When you're operating on the maker's schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in."

Maker's Schedule, Manager's Schedule: the scheduling politics of focus work

Paul Graham's "Maker's Schedule, Manager's Schedule" (July 2009, paulgraham.com/makersschedule.html) is the most widely read piece on this topic and among the most widely linked essays in technology management. The argument in two sentences:

Managers work in one-hour appointment slots. Makers (programmers, writers, designers) need half-day or whole-day unbroken blocks. A manager can accept a 10am meeting and an 11am meeting and do productive work in the 9am hour between them. A maker who accepts both meetings has fragmented their entire morning into three pieces too short for hard work.

Graham's insight is that the scheduling conflict between makers and managers is not about one party being inconsiderate. It is about two fundamentally different relationships to time. A manager scheduling an 11am meeting with an engineer is doing what is normal on a manager's schedule. The manager probably does not realise, and the engineer probably does not say, that the 11am time slot is destroying the engineer's morning. The scheduling conflict is structural, not interpersonal.

The diagram below illustrates Graham's insight in a form he never published. Graham's essay is cited thousands of times but rarely accompanied by a concrete calendar illustration. Here is one:

The mechanism: a maker does not simply lose the 11am meeting slot. They lose 30-45 minutes before the meeting (transition: finishing current work, preparing, anticipating interruption) and 23+ minutes after the meeting (refocus: loading the original mental model back into working memory). The total cost of a one-hour 11am meeting on a maker's schedule is approximately 2-2.5 hours of productive time - not the 1 hour the calendar shows.

This is an important counterpoint that Graham does not make explicit enough. A manager with eight one-hour-blocked meetings from 9am to 5pm is operating at exactly the intended cadence of the manager's schedule. Managers' work is coordination, decision-making, and context-sharing, which are naturally meeting-shaped. A VP Engineering who runs eight meetings a day is doing their job well.

The problem arises when the manager's natural cadence is imposed on engineers who work on a maker's schedule. The senior engineering manager who books a standing 11am sync with every direct report is creating a maker-schedule disaster six times over, without being aware of it.

Five operational rules for engineering teams where makers and managers coexist:

For managers, a full calendar is the job. For engineers, a full calendar is a failure of scheduling discipline somewhere upstream. When an engineer has seven meetings in a week, the first diagnostic question is not "can the engineer manage their time better?" It is "who scheduled these meetings, and why?"

Two or three of those seven meetings are typically upstream-manager fault: a standup at the wrong time, a recurring sync that could be a weekly written post, a design review that could be async comments on a Figma file. The engineer is not the right person to solve this; the engineering manager is.

The most predictable failure mode in engineering-team career development: a senior individual contributor is promoted to engineering manager. Their calendar shifts overnight from maker to manager: coordination meetings, 1:1s, planning sessions, hiring panels. But their expectations of themselves, and often their manager's expectations of them, have not shifted. They are still expected to write code, review architectures, and contribute technical output at senior-IC levels.

The result is predictable. They write code at 10pm and 6am, because those are the only uninterrupted maker-schedule hours they have. They burn out in 12-18 months. Their team sees an exhausted manager who never has time for them and a codebase whose commits are happening in the middle of the night.

The conversation that prevents this is explicit and structural: "Your calendar just changed. Your relationship to code just changed. You are now primarily a multiplier, not an individual contributor. Here is what your calendar looks like now, and here is why." Most organisations do not have this conversation. Most burnouts in newly-promoted engineering managers are downstream of this omission.

If the team's calendars are fragmented, that is an operations design problem. It is not each engineer's responsibility to solve it individually. VPs and directors of engineering who observe a team whose average meeting load exceeds eight hours per week, or whose morning hours are systematically fragmented, should treat this as an infrastructure problem, not a time-management coaching opportunity.

"A single meeting can blow a whole afternoon." - Paul Graham (2009). It has been 17 years. The problem is still there.