In 2019, a mid-sized SaaS company in Austin was watching its engineering velocity quietly collapse. Features were shipping late, code review cycles were stretching from hours to days, and their senior engineers were increasingly unreachable during what the calendar showed as “free time.” The culprit wasn’t a bad sprint process or unclear requirements. It was a specific habit that had spread from the product team into engineering: when something felt uncertain, someone scheduled a meeting.
The team had about fourteen engineers, three product managers, and two designers. Their calendar audit, done as part of a broader post-mortem on a delayed product launch, showed the average engineer was attending eleven meetings per week. Most lasted thirty minutes to an hour. Most had been called to answer questions that, in retrospect, could have been answered with a written message.
The Setup
The company had a reasonable-sounding philosophy: “If it takes more than two back-and-forth messages, just hop on a call.” On the surface this seems efficient. In practice it created a systematic bias toward meetings, because the friction of crafting a clear written explanation was offloaded onto other people’s calendars instead.
Here’s where the math gets uncomfortable. A thirty-minute meeting with five engineers doesn’t cost thirty minutes of organizational time. It costs 2.5 hours, plus scheduling overhead, plus the recovery time on either side. Research on interruption and focus recovery, including work by Gloria Mark at UC Irvine, consistently finds that it takes over twenty minutes to fully return to a deep work task after being interrupted. A meeting at 2 PM doesn’t just take 30 minutes from 2:00 to 2:30. It effectively fragments the surrounding hour into unusable pieces.
The team started tracking this more carefully. They assigned rough hourly costs to their engineers based on fully-loaded salary, benefits, and overhead. A senior engineer cost them roughly $150 per hour in real terms. A thirty-minute five-person sync therefore cost $375 in direct labor. Add the fragmentation cost, and a conservative estimate put the true expense closer to $600 to $800 per meeting.
They were holding, by their count, about twenty-two meetings per week across the engineering organization.
What Happened
The team ran an experiment. For six weeks, they introduced a rule: before scheduling a meeting, the person requesting it had to write a “decision document.” This wasn’t a formal specification. It was a simple structured note, usually a few paragraphs, covering what question needed answering, what context was relevant, what options existed, and what they were leaning toward. Anyone who needed to weigh in could do so asynchronously within 24 hours. If there was genuine unresolved disagreement after that, a meeting was allowed.
The results weren’t subtle. Meeting count dropped from twenty-two per week to around nine. More importantly, the meetings that remained were substantively different. Instead of spending the first ten minutes establishing shared context (because everyone had already read the document), they started at the point of actual disagreement. Average meeting length fell from fifty minutes to about twenty-two.
Velocity went up measurably. Sprint completion rates improved by roughly a third. But the more interesting data point was qualitative: senior engineers reported feeling like they could finally do sustained thinking again. That’s not a soft metric. A senior engineer doing focused architecture work for two uninterrupted hours produces qualitatively different output than the same engineer doing six fragmented thirty-minute chunks. The output of the latter isn’t six-twelfths of the former. It might be closer to zero, because some problems require holding the entire context in your head simultaneously.
This is related to something worth understanding about how context switching doesn’t just slow you down, it rewrites what you were thinking. Each interruption isn’t just a pause. It partially resets the mental model you were building.
Why It Matters
The meeting-as-default is so entrenched in tech culture partly because it feels productive. You’re talking to people. Something is happening. The asynchronous alternative, writing a clear document that explains your thinking, feels like administrative overhead. It isn’t. It’s actually the work.
Writing forces precision in a way that talking does not. When you have to write down “here’s the problem, here are three options, here’s what I think we should do and why,” you often discover mid-paragraph that one of your options is clearly wrong, or that you haven’t actually thought through the second-order effects of your preferred choice. The meeting you were about to call might have run for an hour and ended without a decision because the ambiguity you were hoping other people would resolve was actually ambiguity in your own thinking.
There’s also an asymmetry that meeting schedulers rarely account for. The person calling the meeting has usually been thinking about the problem for some time. They’re ready to discuss it. Every attendee has to cold-start that context from zero. A five-person meeting where the organizer is at step ten of their mental model and everyone else starts at step zero is going to spend most of its time on steps one through nine. A written document lets everyone arrive at step nine before the conversation begins.
The Austin team also noticed a second-order effect they hadn’t anticipated: the decision documents became an institutional memory. Six months later, when a similar architectural question came up, someone found the original document in their internal wiki and the team could see not just what decision was made, but what options were considered and why some were rejected. That kind of reasoning, which typically evaporates after a meeting, turned out to be genuinely valuable.
What We Can Learn
The lesson here isn’t “stop having meetings.” Some problems genuinely require real-time back-and-forth. When you’re debugging an incident under time pressure, when there’s emotional conflict that needs human calibration, when you’re doing creative work that benefits from rapid iteration, synchronous conversation earns its cost. The issue is the default setting.
If your instinct when something feels uncertain is to schedule a meeting, you’re making a choice that looks free but isn’t. You’re purchasing the comfort of not having to write clearly, and paying for it with other people’s focused time.
The practical heuristic the Austin team landed on was this: a meeting is justified when the communication is inherently sequential, meaning one person’s response genuinely changes what the next person needs to say, and when that iteration needs to happen faster than async allows. Almost everything else can be a document.
The engineers in Austin who benefited most from the switch weren’t the ones who hated meetings on principle. They were the ones who had been quietly drowning in context-switching and couldn’t explain why they felt perpetually behind despite working long hours. If that sounds familiar, the math in your organization probably looks similar. Run the numbers on what your last week of meetings actually cost, not in meeting-hours, but in loaded salary times attendees times focus fragmentation. The number will be larger than you expect, and most of those meetings will have generated decisions that a document could have reached faster.
The meeting you’re about to schedule is not a neutral choice. It’s a cost transfer from your schedule to everyone else’s brain.
