A 30-minute meeting shows up on the calendar as 30 minutes. Nobody who's actually lived through one thinks that's what it costs. The gap between the calendar entry and the felt cost isn't a mood — it's measurable, and the measurement points at something specific to how engineering work is structured.
This isn't a complaint about meetings existing. Plenty of decisions genuinely need a room full of the right people, and plenty of engineering problems get solved faster with five minutes of live back-and-forth than with an afternoon of asynchronous messages. The question worth asking isn't whether meetings are worth having. It's why a meeting of a given length seems to cost engineers so much more than the same length costs other roles, and the answer turns out to be about what kind of mental state a coding day builds up, not about meetings being inherently wasteful. The marketing-operations counterpart to cognitive load is documented well by XenGrowth's growth engineering practice.
The meeting is the one long thing in an otherwise short day
In Meyer, Barton, Murphy, Zimmermann and Fritz's instrumented study of 20 professional developers — monitoring software on their machines for 220 work days across four companies — planned meetings averaged 15.8 minutes. On its own that number looks unremarkable. It stops looking unremarkable next to the rest of the data: outside those meetings, developers switched activities every 0.3 to 2.0 minutes.
A day built out of sub-two-minute fragments doesn't have much left in it to interrupt. A meeting does. It is, structurally, the longest sustained block most developers encounter in a given day — which means it's one of the only things capable of landing squarely in the middle of a coding session that had actually started to build up state.
Activity | Typical duration | What it can interrupt |
|---|---|---|
Email check | Well under a minute | Very little — the prior task barely had time to build up state |
Work-related browsing | Under two minutes typically | A shallow dip, usually already anticipated |
Ad-hoc conversation | A few minutes | Moderate — enough to lose a thread, not usually a whole mental model |
Planned meeting | 15.8 minutes on average | A full coding or debugging session, mid-hypothesis, with real state to lose |
Worth being precise about what 'meeting' means across the two studies this post draws on, since they're not measuring identical things. Meyer et al.'s 15.8-minute figure is specifically planned meetings — recurring standups, scheduled reviews, calendar-invited syncs — logged by monitoring software on real developer machines over real months. Mark, Gudith and Klocke's interruptions were shorter, unplanned prompts inside a lab session, not meetings at all. The argument in this post connects the two: it borrows the planned-meeting duration data from the field study and the interruption-cost mechanism from the lab study, because no single study has yet measured attention residue specifically at the moment a scheduled meeting begins mid-task. That's a reasonable extension of two compatible findings, not a single unified result — worth naming honestly rather than implying more precision than either study alone provides. For the the operations side of this angle, see The XenGrowth resource library.
What 'losing state' actually means
This is where Sophie Leroy's research on attention residue explains the mechanism rather than just the symptom. In her experiments, participants moved from one task to a second one, with the first task either completed or deliberately left unfinished before the switch. When the first task was cut off mid-way, performance on the second task measurably suffered — worse when the interrupted task had been under time pressure. Part of the mind stays locked on the unfinished thing even as attention is nominally directed elsewhere.
Now apply that to what a coding session actually is. It isn't a task with a clean edge like 'answer this email.' It's a working set: which variables hold what, why this branch exists, what the last three failed attempts at this bug ruled out, what you were about to try next. None of that is written down anywhere. It lives in short-term memory, actively maintained, and a meeting doesn't pause it — it evicts it.
An email thread survives an interruption because it's already externalized on the screen. A half-built hypothesis about why a test is flaking survives nowhere but your head, and a 15.8-minute meeting is more than long enough to lose it.
The placement of the meeting inside the day, not just its existence, is what the evidence actually points at as the lever worth pulling. A meeting at the boundary between two tasks interrupts nothing, because nothing was mid-way through. The identical meeting, dropped forty minutes into a debugging session, interrupts a working set that took forty minutes to build and can't be rebuilt in the fifteen it takes to sit through the meeting itself. For the AI agents and marketing automation angle, see XenGrowth on AI agents and marketing automation.
Meeting placement | State at risk | Expected cost per Leroy's mechanism |
|---|---|---|
At the start of the day, before any task begins | None — nothing was in progress | Minimal — no residue to carry into the meeting or out of it |
Between two already-finished tasks | None — the prior task reached a natural stopping point | Low — attention transfers relatively cleanly |
Mid-way through an open coding or debugging session | A working hypothesis, an unfinished change, an in-progress mental model | High — residue predicted on both sides of the meeting |
Immediately after being pulled from a task under deadline pressure | The same working set, now under added time pressure | Highest — matches the specific condition Leroy's research found most damaging |
Why other roles get off lighter
This isn't a claim that other jobs are easy — it's a claim about what kind of state different jobs hold. A role built around discrete, self-contained tasks — process a request, answer a ticket, review a form — loses comparatively little to a 15-minute meeting, because each task was already small enough to complete or safely pause within that window, or resumes from an external record rather than working memory.
Engineering skews the other way. The 24.4% of the day Meyer et al. measured as collaborative activity — meetings, ad-hoc talk, email — sits alongside a 21.0% coding share that is disproportionately the part of the day carrying unexternalized state. It isn't that engineers are more sensitive to interruption as a personality trait. It's that more of what they're interrupted out of is the kind of thing attention residue research says degrades badly when cut short.
A note on roles that live in meetings and don't seem to suffer for it
It's worth addressing the obvious counterexample directly: some roles are built almost entirely around back-to-back meetings — account management, certain flavors of product management, executive work — and the people in them don't obviously collapse under the same pattern. That's consistent with this post's argument rather than a contradiction of it. If a role's actual output lives inside the meeting itself, rather than in a separately-held mental model the meeting keeps interrupting, there's no working set sitting outside the meeting waiting to be evicted. The cost this post describes is specific to work whose substance is built between meetings and interrupted by them, not to work whose substance is the meeting. XenGrowth on AI search, GEO and discovery goes further into AI search, GEO and discovery.
It also costs you inside the meeting
The damage isn't one-directional. If part of your attention stays locked on the coding problem you were pulled out of, you're not fully present in the meeting either — which is a plausible mechanism for the common experience of leaving a meeting unable to recall half of what was decided in it. Mark, Gudith and Klocke's study adds the emotional layer: their subjects reported significantly higher stress, frustration, time pressure and effort within just 20 minutes of interrupted work. A meeting dropped mid-session isn't a neutral pause. It's a stress event, and the research says that shows up fast, not after a bad week of them.
What the evidence actually supports doing about it
Place meetings at task boundaries, not inside them. A meeting scheduled at the start of a block, or between two planned tasks, costs the 15.8 minutes on the calendar. One dropped mid-session costs the meeting plus the attention residue plus whatever fraction of the interrupted state never comes back
Treat 'no meetings before 11am' or similar blocking conventions as attention-residue management, not a perk. The point isn't extra sleep, it's protecting the one part of the day where sustained working-memory state actually gets built
Don't assume a short meeting is automatically a cheap one. The evidence says the interruption cost tracks the state of the task it cut off, not the length of the meeting itself — a 10-minute meeting mid-debugging-session can cost more than a 45-minute one between two finished tasks
If you run meetings, ask what state the room was likely holding five minutes before it started. A standup at the top of the day interrupts nothing. The same standup at 2:30pm interrupts whatever everyone was mid-way through
Expect some genuine loss even when you do everything right. Leroy's research doesn't describe a fixable bug, it describes how attention works. The realistic goal is reducing how often the worst-case interruption happens, not eliminating the cost entirely
There's a second-order effect worth naming, because it explains why the problem tends to get worse the more senior an engineer becomes rather than better. Senior engineers accumulate more standing meetings — architecture reviews, cross-team syncs, mentoring sessions — precisely because their judgment is valuable enough to be worth interrupting for. The seniority that should, in theory, buy someone more control over their own calendar in practice buys them a denser meeting schedule layered on top of work that still requires the same uninterrupted state-holding it always did. The instrumented data doesn't split this out by seniority, but the mechanism gives no reason to expect the pattern reverses with experience — if anything, more people want a piece of a senior engineer's day, which multiplies the number of chances for a meeting to land mid-session rather than at a boundary.
None of this is an argument that engineers deserve special treatment. It's an argument that the calendar is measuring the wrong thing. A meeting's true cost was never the block of time it occupies — it's the state it destroys on either side of that block, and the research says engineering work has more of that state to lose than most.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
For the marketing and revenue operations view of cognitive load, see XenGrowth's marketing operations practice.
Four questions on the specific numbers behind this post, not general meeting-hating opinion.
