The Meeting Industrial Complex Has Eaten Engineering
I once sat in a sprint planning session that dragged on for four hours. Four. Hours. We weren’t designing a Mars rover. We were deciding how many story points to assign a button color change. By the end, two engineers had their cameras off and were probably doing actual work, one was locked in a semantic debate about the definition of “medium” versus “large,” and the scrum master was drawing overlapping circles on a virtual whiteboard like a cult leader explaining the afterlife. The button shipped three weeks late anyway.
This isn’t a one-off horror story. It’s the standard operating system for most engineering teams. We’ve built a culture where the meeting is the unit of progress, and it’s suffocating throughput, morale, and the very reason most of us got into this field: to build things, not to talk about building things.
The Synchronous Tax
Every meeting carries a hidden cost that nobody puts on the balance sheet. It’s not just the 30 minutes blocked on your calendar. It’s the context-switching penalty, the shattered focus, the mental overhead of preparing to look engaged while secretly hoping nobody asks you a question you can’t answer without three more browser tabs. For a team of six engineers, a one-hour meeting isn’t one hour. It’s six hours of productive time vaporized, plus the 15-20 minutes it takes each person to rebuild the mental model they had before the interruption. That’s a full workday. Gone. In exchange for a status update that could have been a three-line Slack message.
Managers love meetings because meetings feel like work. You can point to a calendar packed with colored blocks and say, “Look at all the collaboration happening.” But collaboration isn’t a spectator sport. The best collaboration I’ve ever seen happened in a GitHub pull request thread at 11 p.m., with two engineers arguing about edge cases in a database migration. No facilitator. No timer. No icebreaker about what kind of pizza you’d be.
Async Should Be the Default, Not the Backup
Here’s a radical idea: treat synchronous communication as a last resort, not the first move. The default should be written, persistent, searchable communication. Think RFCs, design docs, detailed PR descriptions, and yes, Slack messages that are more than a thumbs-up emoji. When you write things down, you’re forced to clarify your own thinking. You can’t hide behind nodding and saying “makes sense” while secretly wondering if you left the stove on. Written communication scales. It respects time zones. It lets people think before they respond, which is a wildly underrated feature of human interaction.
I’ve seen teams try to fix meetings with better agendas, stricter timeboxes, or a talking stick. That’s like putting a spoiler on a car that’s already on fire. The problem isn’t the meeting structure. The problem is the meeting. If the information can be conveyed without real-time verbal back-and-forth, skip the call. Write it down.
The Art of Writing Things Down Like a Grown-Up
Most engineers are terrible at writing. Not because they can’t, but because they’ve been conditioned to think writing is something you do after the real work is done, like documentation or post-mortems. That’s backwards. Writing is the work. A well-structured design doc prevents more bad code than a thousand code reviews. A clear, concise project update eliminates the need for a status meeting entirely.
Here’s what good async communication looks like:
- Decisions are recorded with context. Not just “we chose PostgreSQL,” but “we chose PostgreSQL because the team already knows it, it handles our expected write load, and the managed offering fits our budget. We considered DynamoDB but rejected it due to complex query patterns.”
- Status updates are pull, not push. A dashboard or a weekly written digest that people can read when they need to, not a meeting they’re forced to attend at 9:15 a.m. like a hostage situation.
- Discussions happen in the open, in threads. Not in DMs, not in hallway conversations, not in a “quick sync” that excludes the one person who actually knows the answer.
Meetings You Can Kill Right Now
Start with the obvious corpses. The daily standup where everyone recites what they did yesterday in a monotone while staring at Jira. Replace it with a Slack bot that posts a thread every morning. People reply with bullet points. Done. You just saved 2.5 hours per person per week. The sprint retro that’s really just a group therapy session with no action items. Replace it with a shared document where people can add kudos, gripes, and proposals throughout the sprint. Discuss only the proposals that need discussion, async, and then vote.
The “alignment” meeting that exists because two teams don’t trust each other. This one’s trickier because it’s a people problem, not a process problem. But the fix is still written communication: a shared RFC process, a public decision log, and a cultural norm that if it’s not written down, it didn’t happen. Trust is built through transparency, not through forced face time.
When You Actually Need to Talk
I’m not saying you should never talk to another human. Some things need real-time conversation. Brainstorming sessions for genuinely novel problems, where the ideas are too half-formed to write down. High-stakes technical debates where diagrams need to be drawn and redrawn in real time. One-on-ones between managers and reports, because those are about human connection, not information transfer. And yes, the occasional team hangout, because you should actually like the people you work with.
But these should be the exception, clearly labeled, and treated as a deliberate choice. The default invitation should be: “Here’s a document. Read it, comment on it, and we’ll only meet if there’s unresolved conflict.” If you can’t articulate the purpose of a meeting in one sentence without using the word “align,” cancel it.
The Cultural Shift
Moving to async-first isn’t a tooling problem. Slack, Notion, Linear, GitHub—they all handle async workflows just fine. The problem is cultural. It’s the manager who feels useless if they’re not facilitating. The engineer who equates visibility with verbal participation. The organization that rewards “being in the room” over shipping working software.
Fixing this requires leadership to model the behavior. If your CTO sends a weekly written update instead of holding an all-hands, people will follow. If your team lead responds to questions with links to documents instead of scheduling a call, the norm shifts. And if you, as an individual contributor, start writing things down and politely declining meetings that lack an agenda, you’ll be surprised how quickly the culture adapts. Most people hate meetings. They just need permission to stop.
FAQ
Won’t async communication make it harder to build team rapport?
Only if you believe rapport is built exclusively through forced small talk in standups. Real rapport comes from working together effectively, respecting each other’s time, and occasionally sharing a meme in a Slack channel. You can still have virtual coffee chats or team retreats. Just don’t confuse socializing with status reporting.
What if someone doesn’t read the async updates?
Then they’re not doing their job, and that’s a performance issue, not a communication failure. If a person can’t be bothered to read a document that’s directly relevant to their work, a meeting won’t fix that. It’ll just waste everyone else’s time while that person nods along.
How do we handle urgent issues if we’re async-first?
Urgent issues are the exception that justifies synchronous communication. If production is down, you get on a call. If a decision is blocking a release, you escalate. Async doesn’t mean slow. It means deliberate. You can still have a “break glass in case of emergency” protocol. Just don’t treat every sprint planning session like a production outage.
The Bottom Line
Your calendar is not a scoreboard. The number of meetings you attend is inversely correlated with the amount of work you actually ship. The best engineering cultures I’ve seen treat meetings like a necessary evil, not a virtue signal. They write things down. They default to asynchronous. They respect the fact that the best code is written when nobody is talking to you.
So here’s my advice: block off four hours tomorrow morning. Put your Slack on Do Not Disturb. Close your email. And build something. Then write a two-paragraph summary of what you did and post it in a public channel. Congratulations, you just held a meeting with your entire team, and nobody had to wear pants.
