On a Wednesday in late November, a software engineer the researcher calls Andy logged his working day. From the moment he arrived at 8:00, colleagues, a meeting and a status check kept breaking it up.
At 3:05 a colleague came back with an ethernet card Andy had already wrestled with twice that day. It took an hour and a half.
His longest block of solo work that day began at 4:50 p.m. It ran until 8:15, when he went home.
Two clocks in one office
One meeting in the middle of an afternoon can cost a maker the whole afternoon.
Paul Graham, a programmer, essayist and startup investor at Y Combinator, named the problem in a July 2009 essay, “Maker’s Schedule, Manager’s Schedule.” The manager’s schedule, he wrote, is the appointment book, “with each day cut into one hour intervals.” Meeting someone is just a matter of finding an open slot. Programmers and writers work differently. “They generally prefer to use time in units of half a day at least,” he wrote. “A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in.”
A manager’s day is a stack of index cards: finish one, pick up the next. A maker’s day is a jigsaw spread across the table. Clear it away for a meeting, and when you come back you first have to find your train of thought again.
Graham saw a second cost, one that starts before the meeting does. “If I know the afternoon is going to be broken up,” he wrote, “I’m slightly less likely to start something ambitious in the morning.” His fix at Y Combinator was to hold office hours for founders at the end of his working day, so that even on busy days, in his words, they “compress the day, but they never interrupt it.”
What three quiet mornings bought
The researcher who studied Andy’s team, Leslie Perlow, tried something with the engineers. Three days a week, until noon, nobody interrupted anybody.
The team’s product, a color laser printer, launched on time, only the second on-time launch in the division’s history. The division’s vice president credited the quiet-time study: “I do not think we could have made the deadline without this project.” That is his judgment, from one team and one product. Perlow herself wrote that the results did not show quiet time was the ideal way to structure the work, only that changing the timing of work could help.
A year later, the next product had slipped, and managers tried quiet time again. One engineer voiced a sentiment Perlow heard from many: “Quiet time alone doesn’t work…. We had no incentive to abide by quiet time…. No one did.” In her account, engineers were rewarded for individual heroics in a constant stream of crises, and fixing one crisis often meant interrupting a colleague. The schedule had changed, but the rewards hadn’t.
There is a limit on the other side too. Perlow also found that much of the interrupting was part of the job: “No engineer could successfully complete his or her deliverables merely by sitting alone in front of a computer, writing code.” Graham agrees that makers need some meetings. “All we ask from those on the manager’s schedule is that they understand the cost.”
Shopify tried a bigger version in January 2023, deleting every recurring meeting with three or more people from its staff’s calendars and making Wednesdays meeting-free again.
The check-in that splits the week
Imagine you’re a data analyst with a forecasting model due at the end of the month. Your manager likes a thirty-minute check-in at 2 p.m. on Tuesdays and Thursdays. Each one is short. Each one also splits the afternoon into an hour before it and three after, and the hardest part of the model needs the whole afternoon in one piece.
You ask to move both check-ins to 4:30, and to answer status questions in one written note on Friday. Your manager still gets her updates. You get two long afternoons a week back, and the model is the first thing you open on each of them.
When the agent is the one knocking
An AI coding agent can put you on the manager’s schedule without anyone booking a meeting. In an October 2025 post, Anthropic described Claude Code’s default setup at the time as read-only, asking permission before it modified files or ran most commands. (The tool now offers several permission modes.) Constantly clicking approve, the company’s engineers wrote, “slows down development cycles and can lead to ‘approval fatigue’, where users might not pay close attention to what they’re approving.”
That is Andy’s day with a new interrupter. Each prompt is small, and each one breaks whatever you were doing. By Anthropic’s account, a long run of them can also wear down how closely you read each one.
The fix in that post works like Perlow’s quiet mornings: set a boundary once, then stop knocking. It put the agent’s bash tool, the part that runs commands, inside a sandbox that blocked changes to files outside the working directory and let network traffic reach only approved domains, and that notified you when a command tried to go further. In the company’s internal use, it said, sandboxing cut permission prompts by 84 percent.
You can check the trade yourself. Count the prompts you approve in one hour of normal work. Then look up what your agent is actually allowed to write and which hosts it can reach, in its permission settings, not in your instructions; naming a project folder in a prompt is not isolation. Try the setup on a copy of the project first, and when your block is over, read everything the agent changed in one sitting.