I sat through a meeting last week that was so long my smartwatch thought I’d died. Two hours of screen-shared Jira, the PM dragging tickets around like a toddler with refrigerator magnets. I muted, made a pour-over, and came back to find them still debating whether something was a 3 or a 5. Nothing had changed except my blood pressure and the temperature of my coffee.
This is the state of engineering culture in most shops. We’ve confused motion with progress. We’ve built a cathedral of ceremonies around the actual work and then act surprised when nothing ships. The people aren’t the problem. The problem is the synchronous-first, meeting-glutted operating system we’ve all accepted as normal. It’s broken. The fix is simpler than you think: treat meetings as a bug, not a feature.
The Meeting Industrial Complex
Walk into any mid-sized tech company and you’ll see the same disaster. Calendars so packed with colored blocks they look like a Tetris board mid-collapse. Engineers who carve out “focus time” from 6 AM to 9 AM because that’s the only window not colonized by standups, retros, grooming, sprint reviews, and the mysterious “sync” that has no agenda but somehow runs 45 minutes. We’ve created a professional class whose primary job is attending meetings about the work they can’t do because they’re in meetings.
This isn’t a blanket rant against meetings. A tight, well-run meeting with a real decision to make and the right people in the room is a beautiful thing. It’s a high-bandwidth, low-latency protocol for resolving ambiguity. The trouble is, most meetings aren’t that. They’re status broadcasts. FYI delivery mechanisms. A manager’s anxiety projected onto a calendar invite. And the cost isn’t just the 30 minutes on the schedule. It’s the context-switching tax, the mental ramp-up and ramp-down, the fragmentation of a day into slices too small to hold a real thought.
The Real Cost of Synchronous-First Culture
Let’s talk about context switching, because it’s the silent killer of engineering productivity. Research out of UC Irvine found it takes an average of 23 minutes and 15 seconds to get back into deep focus after an interruption. If you’ve got a 10 AM standup and an 11 AM design review, the block between them is effectively useless for complex problem-solving. You spend 15 minutes winding down from the first meeting, 15 minutes checking Slack and email, and then you’ve got maybe 20 minutes of shallow work before you need to mentally prep for the next one. Multiply that across a week, and you’ve lost entire days to the seams between meetings.
But the damage goes deeper than lost time. Synchronous-first cultures reward the wrong behaviors. They reward people who are good at thinking on their feet, who can sound smart in the moment, who dominate conversations. They punish the quiet thinkers, the people who need to sit with a problem, the non-native speakers, the introverts, the folks who do their best work in writing. You end up optimizing your team for performance art instead of engineering. The loudest voice wins, not the best idea.
There’s also the time zone problem. If your team is spread across more than two time zones, synchronous meetings are a tax on someone’s personal life. The engineer in Berlin has to stay late. The engineer in San Francisco has to wake up early. The engineer in Bangalore is dialing in at 10 PM. You’re burning people out not with work, but with the logistics of talking about work. It’s absurd.
What Async Actually Looks Like
Asynchronous communication isn’t just “fewer meetings.” It’s a deliberate practice of writing things down, sharing them in a persistent medium, and giving people time to read, think, and respond. It’s treating communication like code: versioned, reviewable, and open to comment threads. The tools are simple. Documents instead of presentations. Threaded discussions instead of round-robin status updates. Recorded demos instead of live walkthroughs.
Here’s a concrete example. Instead of a daily standup where ten people spend fifteen minutes each morning reciting what they did yesterday, you use a Slack channel or a GitHub Discussion. Everyone posts their update by 10 AM in their own time zone. The update includes what they accomplished, what they’re working on today, and any blockers. If someone has a blocker, they tag the person who can help, and that conversation happens in a thread. The whole thing takes five minutes to write and zero minutes of synchronized time. The information is searchable, linkable, and doesn’t evaporate the moment the meeting ends.
Design reviews go the same way. Instead of booking a conference room and projecting Figma mockups while people struggle to stay awake, you record a five-minute Loom video walking through the design decisions. You post it with a written summary and a link to the Figma file. Reviewers leave comments over the next 24 hours. The designer responds in threads. Decisions are documented. Nobody had to find a time when eight busy people were all free at once.
This isn’t a utopian fantasy. Companies like GitLab, Basecamp, and Automattic have been operating this way for years, with teams spread across dozens of countries. Their internal handbooks are public. Their processes are transparent. They ship real products. The async model isn’t just viable; it’s a competitive advantage. It lets you hire the best people anywhere, not just within commuting distance of an office. It gives engineers long stretches of uninterrupted time to actually engineer. It forces clarity of thought because you can’t hide fuzzy logic behind confident body language.
The Objections (and Why They’re Mostly Nonsense)
Whenever I bring this up, the objections roll in like predictable clockwork. Let’s address the greatest hits.
“But we need real-time collaboration for creative work!” No, you need real-time communication for certain types of creative work, and that’s fine. Pair programming, brainstorming sessions, and crisis response all benefit from synchronous interaction. The key is to make those the exception, not the default. Schedule them intentionally, with a clear purpose and a hard stop. The rest of the time, let people work. The best ideas often come after a period of individual deep thought, not in the first five minutes of a whiteboard session.
“Async will slow everything down!” This is the most common fear, and it’s exactly backwards. What slows things down is the meeting itself. The scheduling delay. The time spent waiting for everyone to be available. The meeting that could have been an email but now consumes 30 minutes of ten people’s time. Async communication has lower latency for information sharing. The question isn’t “how fast can we get everyone in a room?” It’s “how fast can we get the right information to the right person so they can act?” A well-written document or a clear Slack message is faster than any meeting invite.
“We’ll lose team cohesion and culture!” Culture isn’t built in meetings. It’s built in how decisions are made, how conflicts are resolved, how people treat each other. If your team culture depends on seeing faces in a grid every morning, you don’t have a culture; you have a hostage situation. Async teams build culture through deliberate practices: well-maintained documentation, thoughtful code reviews, occasional in-person or virtual social events, and a shared commitment to clear, kind communication. The best culture I’ve ever experienced was on a fully remote, async-first team where everyone wrote like they were trying to be understood by someone reading six months later. That’s respect.
“But my manager needs to see that I’m working!” This is the quiet part said out loud. Many meetings exist because of a fundamental lack of trust. If a manager can’t tell whether an engineer is productive without watching them talk about productivity in a daily circle, that’s a management failure, not a communication failure. Output should be visible in the work itself: commits, pull requests, documentation, shipped features. If you need a meeting to prove you’re working, you’re not measuring the right things.
The Migration Path
You can’t flip a switch and go fully async overnight. The habits are too ingrained, and the organizational scar tissue from years of meeting culture is thick. But you can start carving out async spaces and let them prove their value.
Step one: kill the status meeting. Replace it with a written async update. Give it two weeks. Watch how much time frees up. Watch how the quality of status information improves because people can include links, screenshots, and actual detail instead of mumbling through a verbal summary while their dog barks in the background.
Step two: introduce “async-first” for all non-urgent decisions. When someone proposes a meeting, ask: “Can we handle this in a document or a thread first?” If the answer is yes, do that. If the discussion gets stuck or heated, then escalate to a focused synchronous conversation. You’ll find that 80% of what used to be meetings resolves perfectly well in writing.
Step three: protect focus time aggressively. Make it a team norm that mornings are meeting-free. Or Tuesdays and Thursdays. Whatever works. The point is to create large, contiguous blocks of time where engineers can sink into complex work without interruption. Treat these blocks as sacred. No “quick syncs,” no “can you hop on a call for five minutes?” If it’s truly urgent, it can be a Slack message. If it’s not, it can wait.
Step four: invest in writing skills. Async communication lives and dies on the quality of the writing. If your team can’t write clear, concise, well-structured documents, they’ll struggle. This doesn’t mean everyone needs to be a novelist. It means learning to lead with the conclusion, use bullet points effectively, and anticipate questions. Run writing workshops. Share examples of good internal docs. Make writing a valued skill in performance reviews.
The Deeper Problem: Engineering Culture as a System
Here’s the thing I keep coming back to. The meeting problem isn’t isolated. It’s a symptom of a deeper dysfunction in how we think about engineering work. We treat software development like a factory process that needs constant oversight and coordination. But it’s not a factory. It’s a creative, intellectual discipline where the primary unit of progress is a focused human mind solving a hard problem. Every interruption, every unnecessary synchronization point, is a tax on that mind.
The best engineering cultures I’ve seen treat communication overhead as a system performance issue. They profile their team’s time like they’d profile a slow database query. They look for bottlenecks, for unnecessary joins, for queries that could be cached. A daily standup is a full table scan of the engineering team. A sprint planning meeting is a distributed transaction with a two-phase commit that never resolves. The metaphors write themselves because the underlying dynamics are the same. Coordination is expensive. Synchronization is a bottleneck. Throughput suffers when you lock too often.
So the next time you’re sitting in a meeting that feels like a waste of time, don’t just suffer through it. Ask yourself: what is this meeting actually doing? Is it sharing information that could be written down? Is it making a decision that could be made in a thread? Is it building relationships that could be built elsewhere? If the answer is yes, propose the alternative. Be the person who writes the doc instead of scheduling the call. Be the engineer who treats process overhead as a bug to be fixed, not a ritual to be endured.
The goal isn’t zero meetings. The goal is meetings that earn their existence. Meetings that are so useful, so focused, so well-run that people actually want to attend. The rest is just noise. And we’ve all got enough noise in our heads already. We don’t need a calendar full of it too.
Frequently Asked Questions
What’s the one meeting we should absolutely keep?
Keep the meeting that makes a decision. Not the one that shares information, not the one that “aligns,” not the one that “gets everyone on the same page.” Keep the meeting where, at the end, something is different than it was at the start. A design choice is made. A bug fix strategy is agreed upon. A feature is cut. If the meeting ends and the only output is “we’ll follow up,” it should have been an email. Or better, a document with a comment thread.
How do we handle urgent issues without real-time meetings?
Urgent issues deserve real-time attention. That’s what incident response channels, on-call rotations, and emergency video bridges are for. The key is to have clear definitions of what counts as urgent. A production outage is urgent. A question about next sprint’s ticket priority is not. Most things that feel urgent in the moment are just someone else’s poor planning arriving in your inbox. Separate the signal from the noise with explicit severity levels and response expectations. P0: drop everything, get on a call. P1: respond within an hour, async is fine. P2: respond by end of day. P3: this week. Most “urgent” pings are P3s in disguise.
Won’t async communication lead to more misunderstandings?
It can, if done poorly. But so can synchronous communication. How many times have you left a meeting thinking everyone agreed, only to find out later that three people had completely different interpretations? Async communication actually reduces misunderstandings when done well because it creates a written record. You can re-read. You can ask clarifying questions in a thread. You can’t rewind a spoken conversation. The key is to write with precision and read with generosity. Assume good intent, ask for clarification when needed, and default to over-communicating rather than under-communicating. The extra few minutes spent writing clearly pay off in hours of avoided confusion.
What if leadership won’t buy into this?
Start small and show results. Don’t ask for permission to change the whole company’s communication culture. Just change your team’s. Run the experiment. Track the metrics that matter: features shipped, bugs closed, team satisfaction scores. When you can show that your team is more productive and happier with fewer meetings, you’ve got a case study, not a theory. Leadership responds to data, not manifestos. Be the data point. Then share the playbook. Culture change in engineering doesn’t come from top-down mandates. It comes from teams that try something better, prove it works, and let the results speak for themselves.
