Just a
Quick One

On the meeting, the touch base, the calendar that ate the working day, and what the psychological literature says about the cost of the interrupt

Consider the phrase itself. Touch base. It arrives by calendar invitation or by instant message or by the head appearing around the partition wall, always with the implication of brevity, always with the vocabulary of sport — a momentary grounding, a quick tap of the bag, and then back to the game. The phrase is doing a great deal of work for its syllable count. It is simultaneously minimising the imposition, implying reciprocity, and constructing the fiction that the communication about to occur is not so much a meeting as a casual coordination, something that reasonable people in a functioning organisation do naturally, without cost, in the margins of their day. The phrase is grammatically modest and substantively dishonest, and it has colonised the calendar of the modern knowledge worker with such thoroughness that its dishonesty has become invisible, which is the most successful thing a dishonesty can achieve.

The touch base lasts thirty minutes. It was scheduled for fifteen. It begins with three minutes of waiting for the third participant to join the call, two minutes of small talk about nothing in particular, and then arrives at its substance, which is typically one of three things: a status update that could have been a written message, a question that could have been answered asynchronously, or an anxiety on the part of the person who called it — an unease about not knowing what is happening, a need to feel connected to work they are not performing — that the meeting addresses by providing the sensation of progress without any of its content. The meeting ends. The participants return to what they were doing. Something has been consumed that cannot be returned, and the consumption has been recorded nowhere.

The psychological literature on the cost of interruption is not recent, not obscure, and not ambiguous. It has been accumulating for three decades with a consistency that stands in striking contrast to the industry's consistent refusal to act on it. Its findings are not complicated. They are simply inconvenient for everyone whose job title does not include the word "engineer."

In 2005, Gloria Mark and her colleagues at the University of California, Irvine, conducted the study that produced the figure that has since made its way, in simplified form, into countless productivity articles and management presentations and been ignored, in its full implications, by the organisations that most needed to understand it. The finding was precise: it takes an average of twenty-three minutes and fifteen seconds to return to the original task after an interruption. Not to complete the task. Not to recover full cognitive immersion in the task. Simply to return to it — to get back to the screen, to reopen the document, to remember where the thread was. The return itself is followed by a period of degraded performance that the twenty-three-minute figure does not fully capture, because the figure measures resumption, not restoration.¹

The same research programme found, in subsequent studies, that workers interrupted by others were not simply set back by the duration of the interruption. They were set back by the interruption's cognitive trace. The interrupted task does not pause cleanly. It bleeds. It leaves what the researcher Sophie Leroy, in a 2009 paper that deserves to be read by every person who has ever put a recurring meeting in someone else's calendar, named attention residue: the portion of working memory that remains allocated to the interrupted task while the interrupting task is being performed. The person who has been asked to join a quick call is not, during the call, fully present in the call. Part of their cognitive resource — unmeasured, unacknowledged, paid for by the employer and consumed by the meeting — is still holding the state of the problem that was interrupted. The problem does not pause. It persists in partial form, badly, inefficiently, consuming working memory that neither the interrupted task nor the interrupting task can fully use. The meeting gets less than a whole person. The work gets less than a whole person. Neither party knows this is happening. The calendar shows only the meeting.²

Leroy's attention residue concept maps onto a body of working memory research that had been developing independently for decades. Alan Baddeley's model of working memory, developed through the 1970s and 1980s and extended substantially in subsequent decades, described working memory not as a simple buffer but as a set of interacting subsystems — the phonological loop, the visuospatial sketchpad, the episodic buffer, the central executive — whose collective capacity is limited, whose contents are subject to interference and decay, and whose effective functioning depends critically on the absence of competing demands for the central executive's attentional resources. An interruption is, in Baddeley's framework, a competing demand for the central executive. The framework does not accommodate the concept of a "quick" interruption whose cost is proportional to its duration. The cost of the demand on the central executive is not a function of how long the interruption lasts. It is a function of the depth of the cognitive state that the interruption displaces.³

This is the place at which the general literature on interruption and the specific situation of the software developer diverge from each other, because the cognitive state that a software developer builds and inhabits while working on a hard problem is among the deepest and most structurally complex states that any professional occupation requires of a human mind. The claim is not rhetorical. It follows from what the work actually demands.

A software developer working on a non-trivial problem — a concurrency issue in a distributed system, a performance regression across an abstraction boundary, a security vulnerability whose surface is exposed three layers below its cause — is not consulting a document or executing a procedure. They are constructing and maintaining, in working memory, a live model of an abstract system: its current state, its desired state, the causal chain between them, the constraints imposed by the language runtime, the framework, the operating system, and the hardware, the history of decisions that produced the current structure, and the implications of the proposed change for every other part of the system that touches it. This model does not exist anywhere outside the developer's mind. It cannot be saved to disk and resumed. It cannot be delegated to a colleague mid-construction. It is built, expensively, over a period of time that varies by problem but is rarely less than fifteen minutes and is often measured in hours, and it is the only instrument that can produce the diagnosis, the design, or the solution that the work requires. Without it, the work cannot be done. With it interrupted, the work must be started again.⁴

Tom DeMarco and Timothy Lister measured this in 1984, in what they called the Coding War Games — a productivity study involving more than six hundred developers from ninety-two companies, in which participants completed a benchmark programming task under their normal working conditions and the results were analysed against environmental and organisational variables. The variable that best predicted individual performance was not experience, not programming language, not compensation, not company size. It was the degree to which the developer had been able to work without interruption. Developers in the top performance quartile reported, on average, significantly more uninterrupted working time than those in the bottom quartile — not slightly more, not marginally more, but roughly twice as much. The study was published in Peopleware in 1987, a book whose recommendations about the working environment for software developers have been continuously confirmed by subsequent research and continuously ignored by the organisations that employ software developers, which is its own form of finding.⁵

DeMarco and Lister described what they called the "flow state" — borrowing the term from Csikszentmihalyi, who had developed it through decades of psychological research — as the cognitive condition necessary for productive work on complex problems: a state of total immersion in the task, characterised by the dissolution of self-consciousness, the compression of time perception, the experience of effortless concentration, and the alignment of all cognitive resources with the problem at hand. Csikszentmihalyi's empirical research, which had begun in the 1960s and produced a sustained programme of study across dozens of disciplines, found that flow states require clear goals, immediate feedback, a balance between challenge and skill, and — critically — freedom from distraction. Flow is not a luxury. It is the operating condition under which difficult creative and analytical work is performed. It is not achieved accidentally. It is achieved only when the conditions that produce it are deliberately maintained. The meeting destroys those conditions by design.⁶

DeMarco and Lister introduced the E-Factor — the "environmental factor," calculated as the ratio of uninterrupted hours to elapsed hours in a working day — as a measure of the degree to which a working environment actually permitted the work it was ostensibly organised to produce. The average E-Factor they measured was approximately 0.38, meaning that the average developer, in an average environment, had access to roughly thirty-eight percent of their working day as uninterrupted time. The rest was meetings, interruptions, conversations, coordination, the various ceremonies of organisational life. In the four decades since that measurement was taken, the E-Factor of the average software developer has almost certainly worsened, because the period has seen the invention of email, the instant message, the corporate Slack workspace, the daily standup, the sprint ceremony cycle, and the video call — each of which was introduced as a productivity tool and each of which functions, in aggregate, as an interruption engine running continuously and in parallel with whatever the developer is attempting to build.⁷

The specific arithmetic of a developer's day in a contemporary technology organisation is worth constructing, because organisations rarely construct it, preferring instead to think of meetings as gaps in the working day rather than as the primary structure that the working day is organised around. Begin with eight hours. Remove the daily standup — fifteen minutes, scheduled at nine-thirty, which means that no serious cognitive work begins before nine-thirty and that the work that begins after nine-thirty does so with the interruption already on the horizon, which itself imposes an attentional cost, because a deadline — even a trivial social deadline, even a fifteen-minute check-in — is a background process. Remove one sprint ceremony, recurring weekly, averaged across the working day: thirty minutes. Remove one touch-base, scheduled by a manager who has not asked whether the scheduling was convenient: thirty minutes. Remove the notification that arrives during the period between the touch-base and the afternoon — a Slack message, marked urgent, requiring an immediate response that could have been asynchronous — and remove the cognitive reset it requires: twenty-three minutes of recovery that the research has measured, plus the attention residue that the research has also measured and that the organisation has not. What remains of eight hours is not six hours. It is, in practice, closer to four — and those four hours are not contiguous. They are distributed across the day in fragments between the meetings, and a fragment is not a flow state. A fragment is the beginning of a flow state, halted before it achieves the immersion that makes it useful.⁸

Chris Parnin and Spencer Scaffidi, researching programmer task management and interruption specifically — rather than the broader population of knowledge workers that most interruption research addressed — found that programmers interrupted during programming tasks required on average fifteen minutes to begin making progress again on a complex task, and that they could recall, on return, only a fraction of the mental state they had been holding before the interruption. The mental model of the system — the live representation of the code's structure, the state of the debugging session, the chain of reasoning about the failure mode — degraded rapidly and unevenly, with certain categories of context (variable state, call stack position, hypothesis under investigation) decaying faster than others (high-level goals, general approach). The return to the task was not a continuation. It was a reconstruction, partial and imperfect, of a structure that had taken considerable effort to build and had been evacuated in seconds.⁹

The Zeigarnik effect, documented by the Soviet psychologist Bluma Zeigarnik in 1927 and subsequently replicated in numerous variations, describes the finding that uncompleted tasks occupy working memory more persistently than completed ones — that the mind, confronted with an interrupted task, continues to allocate cognitive resources to it involuntarily, producing intrusive thoughts, background rehearsal, and a diffuse attentional pull toward the unfinished business that persists until either the task is completed or the mind is given some other equivalent resolution. Zeigarnik's original study used simple laboratory tasks. The subsequent literature extended the effect to complex, open-ended problems of the kind that professional work typically involves. For a software developer interrupted mid-investigation, the Zeigarnik effect does not politely wait until after the meeting. It operates during the meeting, filling the silence between the meeting's sentences with fragments of the interrupted model, consuming the attentional resources that the meeting requires to be useful and producing the characteristic cognitive dissociation of the person who is visibly present and substantially elsewhere.¹⁰

Daniel Kahneman's distinction between System 1 and System 2 thinking — the automatic, associative, effortless cognition of System 1, and the deliberate, effortful, serially focused cognition of System 2 — provides another framework for understanding the asymmetry between what the meeting costs and what the meeting produces. The meeting, as a social and communicative event, is largely a System 1 activity: it involves language comprehension, social inference, attentional tracking of a conversation, the rapid pattern-matching of faces and tones that allows us to infer mood and intention. These are not trivial cognitive activities, but they are ones that the human mind has evolved to perform automatically, in parallel, without significant depletion of the attentional resources that System 2 demands. The software problem, by contrast, is a System 2 activity in its purest form: it requires deliberate, sustained, serial attention of a kind that cannot be multitasked, cannot be time-sliced without loss, and depletes the cognitive resources available for further System 2 work as those resources are consumed. Moving a developer from the software problem to the meeting moves them from System 2 to System 1 and back. The transition cost in each direction is not zero, and it is not symmetric: entering System 2 from System 1 requires effortful re-immersion; exiting System 2 to System 1 is instantaneous and involuntary. The meeting can be joined with a single click. The flow state cannot.¹¹

The asymmetry between who calls the meeting and who bears its cost is the structural feature of the modern organisation's use of developer time that the research illuminates and the organisation declines to examine. The meeting is called by a manager, a product owner, a Scrum Master, a stakeholder, a business analyst, any of the population of roles whose job is characterised by coordination and communication and whose working day is therefore largely composed of synchronous interaction — people for whom the meeting is not an interruption of work but is itself the primary medium of work. For these roles, the meeting is productive in exactly the way that a coding session is productive for a developer: it is the environment in which the role's primary cognitive activities occur, in which information is gathered and synthesised and distributed, in which decisions are made and commitments are recorded. The meeting is their flow state, to the extent that their work admits one. It is entirely rational for them to call more of them.

Paul Graham articulated this asymmetry in a 2009 essay that named it with unusual precision: the maker's schedule and the manager's schedule are not the same schedule. The manager's schedule is divided into one-hour blocks, each of which can be allocated independently to any task or meeting without significant loss, because the manager's cognitive activities do not require the deep immersion that hour-blocks interrupt. The maker's schedule is divided into half-days at minimum — ideally whole days — because the maker's cognitive activities require the time to build the state of immersion that makes them possible. A single meeting placed in the middle of a maker's day does not consume one hour. It consumes the day, because it divides the day into two fragments, each of which is too short to achieve the immersion that the work requires, and replaces a working day with two anxious approximations of one. The manager who schedules a ten o'clock meeting in a developer's calendar has not removed one hour from the developer's day. They have, in practical terms, removed most of it — and the calendar, which shows only the meeting's duration, does not record this. The cost is real. The account is empty.¹²

The open plan office is the architectural implementation of this asymmetry, scaled to the entire working environment. It is a space designed for the communication and coordination needs of managerial and collaborative roles — roles for whom visibility, accessibility, and spontaneous interaction are productive — and applied universally to all roles, including the ones for whom those same properties are actively destructive. The developer in the open plan office is not merely subject to the meetings on their calendar. They are subject to the continuous low-level interruption of the environment itself: the nearby conversation, the ringing phone, the colleague who stops to ask a question, the ambient noise of a room full of people performing the communicative activities that the space was designed to facilitate. Each of these is a smaller version of the meeting — briefer, softer, less formally scheduled — and each of them carries the same cognitive tax: the forced exit from System 2, the collapse of the mental model, the reset timer, the slow re-ascent toward the immersion that the next interruption will dissolve before it is complete.¹³

The Microsoft Research team of Mary Czerwinski, Eric Cutrell, and Eric Horvitz studied the timing of desktop notification interruptions in the early 2000s and found that the cost of an interruption was not constant but was a function of its timing relative to the interrupted task's cognitive state. Interruptions that arrived at natural breakpoints in a task — at the completion of a subtask, at the end of a defined step — were significantly less costly to recover from than interruptions that arrived mid-subtask, because the breakpoint interruption did not require the evacuation of a partially constructed cognitive structure. The finding has a direct implication for the design of working environments, and specifically for the synchronous notification systems that have become the primary coordination medium of the contemporary software organisation: a system that delivers notifications at arbitrary moments, at the volume and velocity of Slack or Microsoft Teams in a medium-sized engineering organisation, is a system that is overwhelmingly likely to deliver each notification at the worst possible moment — because the worst possible moment is any moment at which the recipient is doing something, and people who are paid to build software spend most of their day, or should spend most of their day, doing something.¹⁴

Slack, to its considerable credit, published research in partnership with academic institutions on meeting patterns and communication overhead in technology organisations. The findings, which its own product contributes to generating, confirmed what the academic literature had been documenting for years: that the proliferation of real-time messaging as the primary organisational communication medium was associated with increased interruption frequency, decreased periods of sustained focus, and self-reported decreases in the ability to complete complex work. The product that generated the problem also generated the data confirming the problem and sold, as a premium feature, the ability to configure focus modes that reduced the problem's most acute manifestations. The irony is not subtle. It does not seem to have been commercially inconvenient.¹⁵

Anders Ericsson's decades of research on expert performance — the empirical foundation of the ten-thousand-hour argument, though the popular formulation is a considerable simplification of the actual finding — documented that the cognitive work required to develop expert-level performance in complex domains is not merely time-consuming but qualitatively specific: it demands what Ericsson called deliberate practice, characterised by intense, focused engagement with problems at the edge of current competence, immediate feedback, and the explicit goal of improving performance rather than merely executing it. Deliberate practice, in Ericsson's data, was reliably associated with extended periods of uninterrupted concentration; expert musicians, chess players, and athletes limited deliberate practice sessions to periods of roughly ninety minutes to four hours, not because longer sessions were unavailable but because the cognitive intensity of genuine deliberate practice was not sustainable beyond those periods and because interruption within those periods destroyed the state required to make the practice deliberate rather than merely effortful. The implication for software development — where expert performance consists precisely in the ability to hold and manipulate complex abstract models under conditions of uncertainty — is not difficult to draw. The organisation that fragments a developer's day with hourly coordination ceremonies is not providing the conditions under which expertise develops or operates. It is providing the conditions under which something else happens, something that looks like development from a distance and is not, quite, on closer inspection.¹⁶

The content of the meetings is its own subject, related but distinct. The cost of the meeting in attentional terms is real regardless of what the meeting produces. But the meetings' outputs compound the injury because they are so systematically modest relative to what was sacrificed to obtain them.

The touch base, examined honestly, is almost always one of two things: a status update or a reassurance. The status update — who is doing what, how far along they are, when it will be done — is information that exists in the written record of any well-functioning project and that does not require thirty minutes of synchronous voice communication to transmit. The sender of the touch-base invitation knows this, at some level. The decision to call the meeting rather than to read the written record reveals the true purpose, which is not informational. It is relational. The manager who does not know what their team is working on has an anxiety that the written record does not fully relieve, because the written record does not perform reassurance. The meeting performs reassurance. The developer says that the work is going well and that it will be done by Thursday, and the manager hears this in real time, reads the face, registers the confidence or its absence, and the anxiety is addressed — not because new information was produced, but because the social act of producing it, synchronously, in the manager's presence, creates the experience of connection that the written record withholds. The developer has paid for this in the currency of the afternoon.¹⁷

The reassurance function of the meeting is not trivial. It reflects a genuine difficulty in the management of invisible work. Software development produces nothing visible until it produces something complete, and the intermediate states — the design being considered, the problem being debugged, the architecture being revised — are not accessible to anyone who cannot read code, which is typically everyone in the room at the touch base. The manager who cannot read the codebase cannot evaluate the work's progress from the work itself, which means they must evaluate it from the person performing it, which means they must meet with that person, which means they must interrupt the work to assess the work, which means the assessment costs more than it can possibly return, because the cost of the interruption is paid from the same account as the assessment's subject. The meeting is a tax on the work it is meant to monitor, levied at precisely the moment when the work is most in need of the conditions the tax destroys.¹⁸

The argument being made here is not that meetings are without value, that coordination is dispensable, or that software development should proceed in hermetic isolation from the people it serves and the organisations that commission it. These claims cannot be sustained and making them would require ignoring the genuine failures of the opposite pathology — the developer who disappears into a problem for six weeks and emerges with an impeccably constructed solution to the wrong question. Communication matters. The argument is more specific: that the form of communication the modern organisation has defaulted to — synchronous, frequent, scheduled in blocks small enough to guarantee inadequacy, populated by people who were not all necessary and who will leave without being certain what was decided — is the worst available form for the purposes of coordinating complex technical work, that its costs are disproportionately borne by the people doing the work rather than the people calling the meeting, and that the psychological research on this point is not ambiguous or recent or obscure. It is several decades old, comprehensively replicated, and universally ignored.

The alternative is not isolation. It is the recognition that synchronous communication is expensive, that its expense is cognitive rather than financial and therefore invisible in every ledger the organisation keeps, and that it should be used with the same deliberateness that any expensive resource demands. The written update, the asynchronous question, the documented decision — these are not inferior substitutes for the meeting. For the majority of coordination tasks that meetings currently perform, they are superior substitutes: they produce a record, they permit the recipient to engage at a natural breakpoint rather than at the moment of the sender's convenience, and they do not require twenty-three minutes of recovery. The meeting that genuinely requires real-time synchronous exchange — the design session in which ambiguity must be resolved in dialogue, the crisis in which information is moving faster than written communication can track — is a real category. It is not the category that most of the calendar contains. Most of the calendar contains the touch base, the quick sync, the status check, the standup. These are not meetings. They are the anxiety of the organisation about its own invisible work, made visible in the form of a calendar event, and distributed to the people doing the work as a thirty-minute cost that will be recorded nowhere and that no ledger will ever find.