In 2020, Shopify did something that felt radical at the time. They canceled all recurring meetings with more than two people for a month and told teams to rebuild their communication habits from scratch. The stated goal was to reset a calendar culture that had grown out of control. What they discovered, accidentally, was something more interesting: a lot of decisions that had been living inside meetings moved into written channels instead, and the quality of those decisions improved.

Shopify is not a small experiment. They had thousands of engineers, product managers, and designers affected by this. And the finding wasn’t that meetings are bad. It was that meetings had become a container for work that didn’t require synchronous time, and once you removed that container, the work found a better one.

That observation is worth sitting with for a moment, because it cuts against most productivity advice, which frames meeting reduction as a gift of time. More focus hours, fewer interruptions. That framing is correct but incomplete. The deeper finding is structural: meetings don’t just consume time, they actively prevent certain kinds of thinking from happening at all.

The Setup

Consider a mid-sized software company running a two-week sprint cycle. At the start of each sprint, the team holds a planning meeting. Developers, a product manager, a designer, maybe a tech lead. An hour, sometimes two. Tickets get discussed, estimates get argued over, someone raises a concern about a dependency, someone else says they’ll look into it, the concern gets tabled.

This is not a dysfunctional team. This is almost every team.

Now here is what happens to that tabled concern. It lives in someone’s head until the next standup, where there isn’t enough time to resolve it, so it gets kicked to a Slack message, which spawns a thread, which someone important doesn’t see until three days later. The dependency issue surfaces again mid-sprint as a blocker. A hasty call gets scheduled. Two engineers lose half an afternoon.

The original meeting created the impression of coordination while actually deferring it. The concern was raised, which felt like progress, but raising it in a synchronous context gave everyone permission to stop thinking about it. The meeting became a pressure-release valve rather than a decision-making environment.

Diagram comparing synchronous meeting-based decision flow versus asynchronous document-based decision flow
The same decision routed through a meeting versus through async threads. The bottleneck in the left path isn't the meeting itself. It's the mandatory synchronization point.

What Happened

Back to Shopify. After their meeting reset, they published some internal observations (reported in coverage from The Verge and other outlets at the time). One pattern that emerged was that forcing decisions into written form changed the quality of the questions being asked. When you have to type out a proposal, you tend to think it through more carefully than when you’re speaking off the cuff in a room. The act of writing is itself a compression algorithm for fuzzy thinking.

This isn’t unique to Shopify. Basecamp (now 37signals) has operated on async-first principles for years and written publicly about it. Their position, argued in detail in their book It Doesn’t Have to Be Crazy at Work, is that real-time communication creates urgency that isn’t warranted by the actual importance of most decisions. You feel productive because you’re responding. You feel collaborative because you’re present. But presence and productivity are not the same variable.

What’s notable about both cases is that neither company eliminated synchronous communication. They changed the default. Instead of defaulting to a meeting when a decision needed to be made, they defaulted to a written thread. Meetings became the exception, reserved for situations where the back-and-forth of real-time dialogue was actually load-bearing.

The distinction matters. If two people have a genuine disagreement that requires rapid iteration to resolve, a ten-minute call beats a forty-message thread. The goal isn’t to remove meetings. It’s to stop using meetings as the default tool for problems they’re not well-suited to solve.

Why It Matters

There’s a cognitive cost to synchronous communication that doesn’t get discussed enough. When you’re in a meeting, you’re doing at least three things simultaneously: processing what someone just said, formulating your response, and tracking where the conversation is relative to the agenda. This is not deep work. It’s context-switching disguised as collaboration.

Deep work, the kind that produces actual output, requires something closer to the opposite: uninterrupted time with a problem, space to be wrong privately before being right publicly, and the ability to stop and restart on your own schedule. Meetings are structurally hostile to all three.

The software development world has been circling this problem for a while. The concept of flow state in programming is well-documented: it takes roughly fifteen to twenty minutes to reach deep focus, and any interruption resets the clock. A one-hour meeting in the middle of a workday doesn’t just cost one hour. It often costs the productive capacity of the entire surrounding block.

But here’s the thing most productivity discussions miss. It’s not just about the individual. When a team defaults to meetings for decisions, it creates a shared dependency on synchronous availability that degrades everyone’s ability to do focused work. The meeting-first culture is a distributed system with a coordination bottleneck. Every significant decision has to pass through a shared synchronous channel, and that channel has limited bandwidth.

What We Can Learn

The Shopify experiment, and the broader async-first movement, points to a few concrete things worth operationalizing.

First, separate decision-making from discussion. Most meetings try to do both simultaneously, which means neither happens well. Write the proposal or the options doc first, let people respond asynchronously, and only convene synchronously if the written discussion reveals a genuine impasse. This is how architecture review processes work in mature engineering organizations, and it works because it forces clarity before conversation.

Second, treat meeting attendance as a cost, not a courtesy. If you’re in a meeting where your presence is informational rather than interactive, you are subsidizing someone else’s feeling of inclusion at the cost of your own focus. A well-written summary after the fact does the same informational work at a fraction of the cost to everyone involved. The document you share is not always the document people read, but a written record is still better than no record at all.

Third, notice what happens to the meetings you cancel. If the work simply doesn’t get done, the meeting was necessary. If the work gets done anyway, through a Slack thread or a shared doc or a quick one-on-one, you’ve just discovered that the meeting was a habit, not a requirement. Most teams, when they actually run this experiment, find more of the latter than they expected.

The canceled meeting that produced three thoughtful async responses and a clear decision isn’t invisible productivity. It’s just quieter than the meeting that produced a lot of nodding and a follow-up calendar invite. Quieter doesn’t mean less. In this case, it usually means more.