Blog
How to actually reduce meetings (not just complain about them)

Executives spend 23 hours per week in meetings, a figure that has more than doubled since the 1960s. Workers waste 5 hours per week in meetings they themselves consider unproductive, doubled since 2019. Microsoft's data shows that 60% of time in their productivity suite goes to emails, chats, and meetings, with only 40% spent in creation tools. Workers are interrupted by meetings, messages, or notifications every 2 minutes on average.
Everyone knows this is a problem. Most solutions don't work because they treat the symptom (too many meetings) rather than the cause (undocumented context that can only be transferred synchronously).
"Have an agenda" doesn't reduce the number of meetings. "Make meetings shorter" just compresses the same coordination into less time. "Cancel all meetings for a week" produces a temporary improvement followed by a surge of rescheduling. These are cosmetic fixes applied to a structural problem.
Why meetings multiply
Meetings multiply because of a specific mechanism: as teams grow, the amount of context that needs to be shared grows faster than the team's ability to share it through informal channels. At five people, context circulates through proximity. At fifteen, it starts requiring deliberate effort. At thirty, the deliberate effort takes the form of meetings, because meetings are the default mechanism for synchronous context transfer.
Most meetings exist for one of four reasons:
Context transfer. "Here's what happened, here's where we are, here's what's coming." Standups, status updates, all-hands, sprint reviews. These exist to keep people informed.
Decision-making. "We need to choose between A and B." Architecture discussions, planning sessions, strategy debates. These exist to reach a conclusion through discussion.
Alignment. "Are we all on the same page?" Kickoffs, retros, cross-team syncs. These exist to ensure shared understanding.
Creative collaboration. Brainstorms, design sessions, pair programming, problem-solving. These exist to generate something new through interaction.
Only the last two categories require people to be in the same room (or call) at the same time. The first two, which account for the majority of meeting time in most organisations, can be handled asynchronously with the right infrastructure.
Replacing context-transfer meetings
A status meeting exists because the status isn't documented somewhere everyone can read it. A sprint review exists because the work that was shipped isn't visible outside the team. An all-hands Q&A exists because leadership context isn't shared in writing.
The async replacement for each of these is documentation that stays current:
Standups → project status docs. A self-writing wiki that tracks what's shipped, what's in progress, and what's blocked, generated from GitHub activity and project discussions, provides the same information as a standup without requiring everyone to be available at the same time. The fifteen-minute standup that five people attend costs 75 minutes of team time daily. A doc costs zero.
Sprint reviews → change logs. Documentation generated from merged PRs and release notes shows what was shipped and why, available to anyone who wants to read it, without a synchronous ceremony.
All-hands → written updates. Leadership context shared as a written update that people can read on their own time, with questions submitted and answered asynchronously. The all-hands that's actually needed (celebration, major announcements, Q&A on sensitive topics) happens less frequently and is more valuable because it's not competing with routine information transfer.
Replacing decision meetings with async processes
A decision meeting exists because the reasoning and options aren't documented well enough for people to evaluate them independently.
The async alternative: write a decision document that lays out the question, the options, the trade-offs, and a recommended approach. Share it with the decision-makers. Set a deadline for comments and objections. If there are no substantive objections, the decision is made. If there are, the objections are documented and either resolved in the thread or escalated to a short, focused synchronous discussion that starts from a shared understanding rather than spending the first twenty minutes establishing one.
This approach produces better decisions than meetings because the reasoning is documented, everyone has time to think before responding, and the decision record persists for future reference rather than disappearing into the memories of whoever attended.
Protecting the meetings that matter
The goal is not zero meetings. Some coordination is better synchronous: creative brainstorms, difficult conversations, relationship building, and complex decisions where real-time discussion produces better outcomes than async exchange.
These meetings improve when they're not competing with the meetings that should have been docs. A team that has four meetings per day, three of which are context transfer, has no energy left for the one meeting where genuine discussion matters. A team that handles context transfer through documentation can give its full attention to the meeting that actually needs it.
The practical framework: for each recurring meeting on your calendar, ask whether it's primarily transferring information in one direction (→ doc) or generating something new through interaction (→ meeting). If it's transferring information, the documentation infrastructure should replace it. If it's generating new thinking, protect it.
The documentation dependency
Every recommendation above depends on documentation that people trust and can find. If the docs are stale, people won't read them and the meetings will persist. If the docs are buried in a wiki nobody checks, they're functionally invisible.
This is why self-writing documentation is the prerequisite for meaningful meeting reduction. Docs that generate and maintain themselves from Slack, GitHub, and meeting recordings stay current without manual maintenance, which means they stay trusted, which means people actually read them, which means the context-transfer meetings they replace don't need to come back.
The meeting problem and the documentation problem are the same problem. Solve the documentation problem and the meeting problem resolves itself.
Frequently asked questions
Won't people miss important updates if we replace meetings with docs? If the docs are searchable, current, and pushed to the right people, the coverage is actually better than meetings, because docs reach everyone while meetings only reach attendees. The risk of missing updates is higher with meetings (you miss one and you're out of the loop) than with persistent, searchable documentation.
How do we handle the social aspect of meetings? Preserve it deliberately. Schedule social time that isn't disguised as a status update. The social bonding that happens in meetings is valuable, but it shouldn't require a thirty-minute standup to achieve. A weekly team coffee or a monthly team lunch serves the social function more effectively than five daily standups.
What about meetings with external stakeholders? External meetings (client calls, vendor reviews, partner syncs) often need to be synchronous for relationship reasons. The internal preparation and follow-up, however, can be heavily async: briefing docs before the meeting, meeting notes captured automatically during, action items tracked afterwards.
Related reading: Why meetings multiply, Work about work, The knowledge scaling problem, The meeting that should have been a doc. Related pages: Self-writing docs, For engineering teams.
Other blog posts:

The cost of misalignment between teams

How to do a competitive analysis (and keep it current)

What is product ops (and do you need it)?

How to keep product and engineering aligned without more meetings

Your user research is worth millions. You can't find any of it.

Why your product decisions keep getting relitigated

How to build a product knowledge base that people actually use

Sales can't find what marketing makes