TL;DR

If your agile transformation feels like “even more meetings,” that’s often not a mindset problem. It’s a structural one. Frequent context switching creates switching costs. People are busy, but delivery slows down. Scrum can improve this—but only if you don’t pile it on top of project governance. The lever is calendar and coordination design: protect focus blocks, batch synchronization, make status asynchronous, and remove double steering. Done well, throughput, quality, and satisfaction rise together.

Maker Time, Manager Time, and the Hidden Cost of Context Switching

You may know the pattern. Calendars are packed. Teams are “aligned” all day. Planning, syncing, reporting everywhere. And still delivery feels sluggish. Stories get started and then sit. Removing blockers often means scheduling yet another meeting. Many Scrum Masters experience this as “Agile = meeting machine.” Many managers experience it as “People are busy, but not enough ships.”

This is exactly where it helps to zoom in. Often the problem is not motivation. Not discipline. Not missing agile values. It is an invisible cost category that transformations rarely address explicitly: switching costs caused by fragmentation. Once you understand that mechanism, you can turn vague meeting frustration into a precise systems conversation. You stop debating preferences. You start debating impact.

In his 2009 essay “Maker’s Schedule, Manager’s Schedule,” Paul Graham describes a pattern many knowledge workers immediately recognize. Some work fits neatly into hourly slots. Other work becomes productive only when it gets longer, uninterrupted time windows. Graham frames this as “manager schedule” versus “maker schedule.” Managers organize, decide, synchronize. Makers build, write, engineer, design. The expensive productivity killer shows up when a calendar optimized for coordination fragments the time of people who need larger blocks to build context and produce real work.
Source: https://paulgraham.com/makersschedule.html

The obvious question is whether this is just a clever observation—or whether science backs it up. The framing is essayistic. The mechanisms are well supported. Research on task switching, multitasking, and interruptions consistently shows: frequent switching costs time, increases error probability, and raises stress—even when people subjectively feel they “handle it just fine.”

Switching Costs Instead of Multitasking

In everyday language, “multitasking” often means “doing several demanding cognitive tasks at the same time.” For complex knowledge work, that is rarely what actually happens. What happens is rapid switching. In psychology, this is captured by “task switching costs”: additional time and mental energy required when moving from one task to another. The brain does not run multiple complex thinking processes in parallel without loss. It alternates quickly. That alternation creates systematic overhead: rules must be reconfigured, relevant information must be reactivated, irrelevant information inhibited, and the internal working context rebuilt.

Juliette Lagerweij explains this clearly via classic experimental logic: compare blocks of the same task with blocks that require switching between task types. The difference shows delays and increased error rates.
Source: https://www.psohub.com/de/blog/der-multitasking-mythos-die-sogenannten-wechselkosten

A well-known complementary perspective comes from Stanford research on media multitasking. In the widely cited study by Ophir, Nass, and Wagner (2009), “heavy media multitaskers” did not show a multitasking superpower. If anything, they performed worse at filtering irrelevant information and controlling interference. This suggests that frequent parallel stimulus handling may reinforce distractibility rather than improve cognitive control.
Source: https://news.stanford.edu/stories/2009/08/multitask-research-study-082409

For Scrum Masters and managers, the practical point matters most: switching costs are not “soft psychology.” They are an organizational cost category. They appear whenever work is organized so that people must constantly jump between topics, tickets, syncs, and shifting priorities.

Interruptions: Time Loss and a Stress Multiplier

Graham focuses especially on meetings, because they carve days into hourly blocks and reinforce the manager schedule. His point is not “meetings are evil.” It is this: for makers, a meeting often costs more than the meeting itself. It breaks a larger block. It prevents deep entry. And it makes resumption expensive.

This is where interruption research is particularly helpful. Mark, Gudith, and Klocke (CHI 2008) studied interruptions experimentally and captured not only performance but also strain measures such as time pressure, effort, and frustration. A central finding was that interruptions were associated with higher subjective stress and frustration—even when some tasks were completed faster. Productivity can sometimes be “saved” in the short term. The bill often arrives through strain, quality volatility, or exhaustion.

That connects neatly to Graham’s intuition. The damage is not only the “lost hour.” The key cost is resumption: reconstructing where you were, which assumptions held, which alternatives were discarded, and what the next logical step is. In complex knowledge work, that context often lives partly in people’s heads, not fully in tickets or documents. That’s why fragmentation becomes a systemic productivity problem—and often a cultural problem when organizations implicitly expect everyone to “just switch quickly.”

Project Organization vs. Agile Organization: Two Coordination Logics

In a classic project organization, the manager schedule is not just a preference of certain roles. It is the operating system. Projects are temporary. They are held together via dependencies, budgets, milestones, governance bodies, and reporting. That creates calendars that naturally think in hours, slots, and synchronization points. The more work runs through handoffs and coordination, the more coordination rhythms dominate. Once they dominate, switching costs rise. People spend more time transferring context than using it to produce value.

Agile organization is often misunderstood as “less planning” or “more flexibility.” The deeper difference is how coordination is produced. Project organizations coordinate primarily through plans, milestones, handoffs, and committees. Agile organizations coordinate primarily through stable teams, clear product or value-stream accountability, and short feedback cycles. That changes the calendar fundamentally. Coordination shifts inward to teams that can deliver end-to-end. External alignment, handoffs, and status meetings decrease. Maker time emerges not because people suddenly gain heroic self-discipline, but because the organization produces fewer triggers that fragment work into coordination slices.

You can see the difference in two patterns:

Project organization: work is often “assigned.” Execution is distributed. Dependencies are managed through interfaces. That creates a constant need for status: Where are we? Who blocks whom? What is the risk? Because truth is spread across the system, synchronization becomes insurance.

Agile organization: work is ideally “pulled.” Teams manage WIP, deliver in small increments, and show progress as product increments—not as slide decks. Synchronization becomes less of an insurance policy because transparency lives in the flow. Scrum events, Kanban policies, and agile metrics are then not primarily “meeting culture.” They replace project-style steering through status communication.

Why Agile Transformations Often Create More Fragmentation

Here is the uncomfortable part: agile does not automatically solve the problem. Many companies run “agile projects.” They keep the project logic and paste agile rituals on top. Then a paradox appears. Project reporting, steering committees, dependency rounds, and gate decisions continue. And on top of that come plannings, refinements, dailies, reviews, and multi-level syncs. The outcome is not fewer context switches—it is more. Scrum gets blamed as a meeting machine, not because Scrum inherently demands too many meetings, but because two operating systems are steering the same work at the same time.

If you are mid-transformation, this is a key insight: instead of starting with values, start with a cost model. Every handoff, every reporting format, every governance body is a potential source of switching costs. Agile organizations try to reduce these costs by bundling responsibility, decoupling work, and shortening feedback loops. Project organizations accept these costs as the price of controllability in temporary, uncertain setups. That can be necessary. But it is expensive. And when “project mode” becomes permanent, the organization remains stuck in a manager schedule even though it actually wants continuous product development.

Practical Example: Pinterest and No-Meeting Days

Pinterest translated Graham’s observation into a field experiment. As the company grew, days became more fragmented and engineers lost uninterrupted focus windows. As a countermeasure, they tested a schedule with three no-meeting days per week for individual contributors. The message was not “meetings are bad.” It was: the organization redesigns the calendar so that maker time becomes structurally possible again. Pinterest reports that more than 90% of surveyed engineers perceived a productivity increase.
Source: https://medium.com/pinterest-engineering/three-day-no-meeting-schedule-for-engineers-fca9f857a567

The right framing is: this is not a randomized experiment. It is an organizational intervention with self-report data. Still, it is a powerful pattern because it converts a theoretical mechanism into a clear policy: focus blocks are not negotiated individually—they are protected systemically.

What This Means in Practice

This is the real payoff for Scrum Masters and managers: you get levers that can work immediately, without a re-org. And you get arguments that are structural, not moral.

1) Separate project work from product work

If something is truly project work, treat it as a project. Batch synchronization deliberately. Bundle committees. Define fixed office hours for alignment. Protect contiguous delivery windows. Reduce ad-hoc meetings via clear triage channels. Measure not only lead time but also fragmentation.

2) If it’s product work, organize it like product work

That means stable, cross-functional teams with end-to-end ownership. Clear product goals instead of milestone plans. Visibility through increments, not status decks. Less external coordination, more internal autonomy. This is the structural basis for maker time—without requiring heroics.

3) Reduce double steering in hybrid setups

The biggest source of switching costs is often not Scrum, SAFe, or Kanban. It is running project governance and agile delivery steering in parallel for the same work. The way out is not “another meeting to reduce meetings.” It is simplifying governance. Decide which questions truly need a committee. Put everything else into transparent, preferably asynchronous decision formats. Use reviews as steering points, not as shows. And when you plan at program level, plan in batches: infrequent, concentrated, with solid pre-work. This is the agile equivalent of “office hours”: coordination in blocks, delivery in flow.

Concrete Practices at Team and Individual Level

1) Meeting batching and office hours instead of constant slicing.
Bundle meetings and place them in fixed windows so maker time is not perforated all day.

2) Explicit focus blocks in the team calendar.
No-meeting mornings or fixed deep-work half-days. The key is reliability, not ritual.

3) Asynchronous by default, synchronous by exception.
Handle status and information questions in writing. Use a simple structure: context, decision point, question. Recipients switch context intentionally instead of reflexively.

4) Interruption design: triage channels and response SLOs.
Not every signal is a page. Not every question is a meeting. Define channels, response times, and escalation rules.

5) Preserve context with short resume notes.
Before every switch, take 60–90 seconds to note: current state, next smallest step, critical assumption. This reduces resumption cost because context is not held entirely in your head.

Closing Thought

The debate “project organization vs. agile organization” is less ideological than it looks. It is a question of context switching and coordination costs. Project organizations generate many switches because they must coordinate across interfaces. Agile organizations try to avoid switching by pulling responsibility and feedback into stable value streams. That makes the core point tangible: agile is not only a mindset. It is an organizational design that takes the cognitive realities of human work seriously.

Start Monday: 7 Small Steps With Big Leverage

1. Block two half-days per week as team-wide focus time. No meetings. No “exceptions.”
2. Define two fixed meeting windows per week for everything that must be synchronous.
3. Replace status rounds with an async update format: progress, risk, decision needed.
4. Introduce interruption triage: what is a page, what is a ticket, what can wait.
5. Make double steering visible: which governance bodies steer the same work as the backlog. Remove one.
6. Limit WIP visibly: start less in parallel, finish more.
7. Measure not only output, but fragmentation: how often teams switch topics per day, and what drives it.

---

References

American Psychological Association. (n.d.). Multitasking: Switching costs. https://www.apa.org/topics/research/multitasking

Cain, M. S., Leonard, J. A., Gabrieli, J. D. E., & Finn, A. S. (2017). Cognitive control in media multitaskers: Two replication studies and a meta-analysis. Psychonomic Bulletin & Review, 24(5), 1556–1562. https://doi.org/10.3758/s13423-017-1275-9

Jeong, S.-H., & Hwang, Y. (2016). Media multitasking effects on cognitive vs. attitudinal outcomes: A meta-analysis. Human Communication Research, 42(4), 599–618. https://doi.org/10.1111/hcre.12089

Monsell, S. (2003). Task switching. Trends in Cognitive Sciences, 7(3), 134–140. https://doi.org/10.1016/S1364-6613(03)00028-7

Ophir, E., Nass, C., & Wagner, A. D. (2009). Cognitive control in media multitaskers. Proceedings of the National Academy of Sciences, 106(37), 15583–15587. https://doi.org/10.1073/pnas.0903620106

Pashler, H. (1994). Dual-task interference in simple tasks: Data and theory. Psychological Bulletin, 116(2), 220–244.

van der Schuur, W. A., Baumgartner, S. E., Sumter, S. R., & Valkenburg, P. M. (2021). “Cognitive control in media multitaskers” ten years on: A meta-analysis. Cyberpsychology: Journal of Psychosocial Research on Cyberspace, 15(2), Article 7. https://doi.org/10.5817/CP2021-2-7

Rubinstein, J. S., Meyer, D. E., & Evans, J. E. (2001). Executive control of cognitive processes in task switching. Journal of Experimental Psychology: Human Perception and Performance, 27(4), 763–797.