The Setup
In 2020, when Basecamp published its second edition of It Doesn’t Have to Be Crazy at Work, Jason Fried and David Heinemeier Hansson were describing a company that had already been running a decades-long experiment most organizations would never attempt deliberately. No status meetings. No all-hands standups. No recurring calendar blocks consuming Tuesday and Thursday afternoons with the same fifteen people staring at the same slide deck.
This wasn’t a productivity stunt for a blog post. It was how the company had operated since its early days, and the product they built, a project management tool with millions of users, is evidence that the approach didn’t collapse into chaos.
But the more instructive story isn’t Basecamp itself. It’s what happened when one of their own product teams tried to reintroduce synchronous meetings during a specific project cycle, noticed the difference, and then deliberately removed them again.
What Happened
The team was building a significant new feature. Someone proposed a short daily sync, just fifteen minutes, to keep everyone aligned. The team agreed. It seemed reasonable.
What followed was textbook: the fifteen minutes expanded. People came to the meeting instead of writing things down, because why write it down if you can just say it tomorrow? Decisions that could have been made by one person with enough context got deferred to the group. The async threads in Basecamp’s own tool got shorter and less substantive, because the real conversation was happening verbally, undocumented.
By the third week, the team noticed that their actual output, the written specs, the design mockups, the code commits, had slowed. Not because people were working less. Because the work itself had migrated into conversations that left no artifacts.
When they canceled the daily sync and returned to written-first communication, the pace recovered. More importantly, the quality of decisions improved. Written communication forced people to think before speaking. It created a record. It let someone in a different timezone contribute on equal footing.
This isn’t a dramatic story. Nobody got fired. The feature shipped. But that’s exactly why it’s instructive: it’s mundane enough to be happening in your company right now.
Why This Happens
Meetings create the sensation of progress. You talk, someone nods, a decision is verbally affirmed, and you leave feeling like something was accomplished. The problem is that sensation and substance come apart under load.
Think about what a meeting actually produces. If it’s run well, you might get a decision and a vague shared memory of that decision. If it’s run poorly, you get a shared memory that different participants will reconstruct differently when they try to act on it. Compare that to an async written proposal: the reasoning is explicit, the decision is recorded, the dissenting views are captured, and anyone who joins the project six months later can read the thread and understand why things are the way they are.
This is what engineers sometimes call the “bus factor” problem applied to knowledge rather than people. If a decision lives only in the heads of the people who were in the room, the organization is one resignation away from losing it. Written communication is a form of fault tolerance.
There’s also a coordination tax that meetings impose that rarely gets priced correctly. If you schedule eight people for a one-hour meeting, you haven’t spent one hour. You’ve spent eight hours of collective focus time, plus the context-switching penalty each person pays going into and out of the meeting. Research on interruption recovery suggests the real cost of a single interruption can stretch well past twenty minutes. A recurring daily standup for a team of ten isn’t five hours of meeting time per week. It’s closer to a full week of lost deep work across the team, every single week.
The Counterargument Worth Engaging
The standard defense of meetings is that some communication genuinely requires synchrony. Emotional conflicts. Ambiguous creative direction. Anything where real-time iteration and human tone matter.
This is correct, and it’s not what this article is arguing against.
The problem is that this legitimate use case bleeds into everything else. Once a team accepts that some things require meetings, the path of least resistance is to route all uncertain or moderately complex things through meetings too. Meetings become the default, not the exception.
Basecamp’s model isn’t “no meetings ever.” It’s “meetings are a last resort after written communication has failed or is genuinely insufficient.” That’s a very different policy, and it’s one that most teams have exactly backwards.
See also why teams keep scheduling meetings that should have been documents for a more granular breakdown of the specific failure modes.
What We Can Learn
The Basecamp story points to something that software teams, in particular, should recognize intuitively: the work that matters leaves artifacts.
A code review is an artifact. A design doc is an artifact. A bug report is an artifact. These things persist, accumulate, and compound. You can reference them. You can onboard someone with them. You can audit them when something goes wrong.
A meeting, unless it is recorded and transcribed and that transcript is actually read (it won’t be), leaves almost nothing. The closest thing to an artifact it produces is the follow-up email that summarizes what was decided, which means the meeting’s actual value resided in that email, and you probably could have just written the email first and skipped the meeting entirely.
The practical implication isn’t radical. It’s this: before scheduling a meeting, write down what you would say in the meeting. Then ask whether sending that document and waiting for written responses would resolve the issue. Often it will. When it doesn’t, you’ll have a better meeting, because everyone arrives with shared context instead of spending the first fifteen minutes establishing it.
The meeting you canceled didn’t just save an hour on everyone’s calendar. It forced the work that the meeting would have consumed back into a form that your future colleagues can actually use.
That’s not a productivity trick. It’s just good engineering discipline applied to communication.
