I once sat through a 90-minute sprint planning session where the loudest person in the room spent 40 minutes debating whether a button should say “Submit” or “Save.” The ticket was already groomed. Acceptance criteria? Crystal clear. The designer had signed off. But there we were—fifteen engineers and a product manager—watching two people argue about a word that was going to be A/B tested anyway. That meeting burned about $2,500 in salary time. Three weeks later, someone changed the button back. Nobody remembers why.
This isn’t a one-off horror story. It’s the standard operating rhythm in most engineering orgs. We’ve normalized synchronous communication to the point where a developer’s calendar looks like Tetris played by someone mid-panic attack. And then we act surprised when nothing ships.
The Meeting Industrial Complex
Meetings aren’t the enemy. A tight whiteboard session can crack a nasty architecture problem in half an hour. A quick standup can surface a blocker that would otherwise fester for days. But somewhere along the way, we confused “collaboration” with “constant interruption.” We built a culture where the default response to any uncertainty is “let’s hop on a call.”
Here’s what that actually looks like. You carve out two hours for deep work. You open your IDE. You start loading the mental model of the codebase into your head—a process that takes a solid 20 minutes of uninterrupted thought. Then Slack dings. A calendar reminder pops up. “Quick sync on the API contract.” You join. It’s not quick. It’s 45 minutes of people reading aloud a document they could have read on their own. You return to your desk. The mental model is gone. You spend another 20 minutes rebuilding it. You get maybe 15 minutes of real progress before the next interruption. That’s not work. That’s cognitive whiplash.
Engineering is a deep-thinking discipline. The best code comes from sustained focus, not from fragmented attention sprinkled between standups, status updates, and “alignment” meetings that align nothing except everyone’s desire to escape. Yet we schedule engineering time like we’re running a support hotline. It’s ridiculous.
The Real Price of Synchronous Everything
Let’s talk numbers, because engineers perk up when numbers enter the chat. A single one-hour meeting with six engineers doesn’t cost one hour. It costs six hours of focused work time, plus the context-switching tax. Research on task interruption says it takes an average of 23 minutes to regain deep focus after a distraction. If each of those six engineers loses just 20 minutes of flow state before and after the meeting, that’s another four hours vaporized. One meeting. Ten hours of real work, gone. Now multiply that by the number of recurring meetings on your calendar this week. Feel sick yet?
But the damage goes deeper than time. Meetings breed performative productivity. People talk to be heard, not to move work forward. Decisions get made by whoever shouts loudest, not whoever thought hardest. Introverts, careful thinkers, and anyone who needs time to process information get steamrolled. The meeting ends with a vague consensus nobody actually agreed to, and everyone leaves drained. This isn’t collaboration. It’s group therapy for the indecisive.
Async Communication Is a Skill, Not a Tool
When people hear “async-first,” they picture Slack messages at 2 a.m. and a chaotic trail of threads nobody reads. That’s not async. That’s just synchronous communication with a time delay and worse formatting. Real async communication is structured, thoughtful, and designed for consumption by humans who aren’t occupying the same mental space as you.
An effective async update has a clear decision requested, context that doesn’t assume the reader attended the last three meetings, and a deadline for input. It’s not a brain dump. It’s a crafted artifact. Writing it forces clarity. Reading it allows processing time. The result? Better decisions made by people who actually had a moment to think.
This shift demands a cultural change, not just a tool swap. It means rewarding written communication skills. It means managers stop reaching for “can we jump on a quick call” as their first resort. It means treating uninterrupted time as sacred, not as empty space to fill with another sync.
Which Meetings to Kill First
Not all meetings deserve the axe. But plenty do. Start with the ones that exist purely out of habit.
Daily Standups That Are Just Status Dumps
If your standup is a round-robin where each person recites what they did yesterday and what they’ll do today, kill it. That information belongs in a channel, a thread, or a tool. The only reason to stand in a circle—physical or virtual—is to surface blockers and coordinate unblocking. If nobody has a blocker, end the meeting in 90 seconds. If people are just reporting status to a manager, that manager needs to learn to read.
Planning Meetings That Should Be Documents
Technical planning doesn’t need a conference room. It needs a collaborative document, a deadline for comments, and a final review window. Async planning produces better designs because people have time to think through edge cases instead of nodding along to avoid extending the meeting. The loudest-voice problem disappears. The document becomes the source of truth, not someone’s hazy memory of what was said.
“Sync” Meetings That Sync Nothing
If a meeting title contains the word “sync,” “alignment,” or “touch base,” assume it’s worthless until proven otherwise. These meetings are often therapy sessions for managers who feel out of the loop. The cure is better written updates, not stealing an hour from six engineers. If a manager can’t stay informed through async channels, the problem is the manager’s information diet, not the team’s communication frequency.
Building an Async-First Engineering Culture
Shifting to async isn’t about installing a new tool. It’s about changing defaults. The default for sharing information becomes a document, not a meeting. The default for getting feedback becomes a comment thread with a deadline, not a calendar invite. The default for decision-making becomes a written proposal with a clear owner, not a group discussion that diffuses responsibility.
This requires explicit norms. Here are a few that actually work:
- No-meeting blocks. Every engineer gets at least four contiguous hours per day with zero meetings. This is non-negotiable. It’s protected by the team, not just by individual calendar blocks that others ignore.
- Writing-first proposals. Any technical decision affecting more than two people starts as a written document. Discussion happens in comments. A meeting only happens if the async thread deadlocks—and that should be rare.
- Decision deadlines. Async discussions need end dates. “Please provide input by Thursday 5pm. Decision will be made Friday morning.” Without deadlines, async threads become zombie discussions that stagger on forever.
- Recording and notes for any meeting that survives. If a meeting absolutely must happen, it gets recorded. Written notes get posted within two hours. People who weren’t there can catch up without scheduling a second meeting to recap the first one.
The Manager’s Role in Killing Meetings
Managers are often the biggest source of unnecessary meetings. Not because they’re malicious, but because their job involves coordination and they default to the easiest coordination method: getting everyone in a room. Breaking this habit requires managers to do harder work. Writing clear context. Reading threads thoroughly. Trusting that work is happening even when they can’t see it in real time.
A good engineering manager in an async culture spends more time editing documents than attending meetings. They amplify signals, not noise. They protect their team’s focus time like a bouncer at an exclusive club. If someone tries to schedule a meeting that could be an email, the manager pushes back. If a stakeholder demands a “quick sync,” the manager asks for an agenda and a written summary first.
This is uncomfortable at first. People will complain that they feel “out of the loop.” That’s a sign the written communication isn’t good enough yet, not a sign that you need more meetings. Fix the writing. Don’t add the meeting.
When Meetings Actually Make Sense
Let’s be fair. Some problems are genuinely synchronous. Complex debugging sessions where two brains on one screen find the bug faster. High-stakes incident response where seconds matter. Relationship-building conversations where tone and trust can’t be conveyed in text. Creative brainstorming where the energy of rapid back-and-forth sparks ideas that wouldn’t emerge in a comment thread.
The key is intentionality. A meeting should be the exception, not the rule. It should have a clear purpose, a tight agenda, and a defined outcome. It should end the moment that outcome is achieved, not when the calendar slot expires. And it should be scheduled sparingly, like a surgery, not like a daily vitamin.
What Happens When You Actually Cut Meetings
Teams that go async-first report the same things. Ship velocity increases. Engineers report higher job satisfaction. Design quality improves because people have time to think. Decisions stick because they were made deliberately, not in a rushed Zoom call where half the participants were checking Slack.
But the most interesting change is cultural. The team stops equating responsiveness with competence. The engineer who replies to a thread six hours later with a thorough, well-reasoned analysis is valued more than the one who fires off a half-baked opinion in real time. Deep work becomes the norm, not a luxury. The calendar stops being a weapon and starts being a tool.
This doesn’t mean the team goes silent. It means communication becomes richer, more deliberate, and more respectful of everyone’s time and cognitive load. The loudest voice loses its power. The best ideas win. And that button text debate? It happens in a document, takes ten minutes of reading, and ends with a decision that everyone can reference later. No meeting required.
Frequently Asked Questions
Won’t async communication slow down decision-making?
Only if you measure speed by how fast someone says something, not by how fast a good decision gets made and implemented. Synchronous meetings create an illusion of speed—a decision is “made” in 30 minutes—but that decision often unravels over the following days as people realize they didn’t actually agree or think through the implications. Async decisions take slightly longer to reach but dramatically less time to stick. Net speed goes up.
How do we handle urgent issues without meetings?
Urgent issues get urgent channels. A dedicated incident Slack channel with clear roles, a running document, and an optional voice bridge for those actively debugging. The key distinction: only people directly working the problem are synchronous. Everyone else follows along async. This prevents the common disaster pattern where fifteen people join a call and fourteen of them are just watching.
What if our company culture just loves meetings?
Culture is just a collection of habits reinforced by what leaders tolerate. If your company “loves meetings,” it’s because nobody with authority has said “this is wasteful” and meant it. Start small. Kill one recurring meeting and replace it with a written update. Show the results. Engineers will defend the new free time with their lives. Culture changes when the alternative is obviously better, not when someone gives a presentation about it.
Don’t junior engineers need more face time for mentoring?
Yes, mentoring benefits from synchronous interaction. But that’s a one-on-one or small group activity, not a team-wide meeting. Pair programming, scheduled office hours, and dedicated mentoring sessions are valuable. Dragging six junior engineers into a planning meeting where they say nothing is not mentoring. It’s hazing.
