Open your team’s shared calendar. Go on, I’ll wait. What you’re looking at isn’t a schedule—it’s a crime scene. A Tetris grid of overlapping blocks, colour-coded chaos, and the quiet death of actual productivity. Stand-ups, backlog grooming, sprint reviews, retros, alignment check-ins, pre-meeting meetings, and the inevitable “quick sync” that metastasises into 45 minutes of rambling. We’ve built a communication monster, and then we wonder why the codebase is a mess and everyone’s burnt out by Wednesday.
I’m not a meeting abolitionist. I’m a pragmatist who’s spent too many years watching talented engineers stare blankly at a shared screen while someone drones through a slide deck. The problem isn’t the meeting itself; it’s the lazy assumption that synchronous, real-time chatter is the default way to share information, make decisions, and align a team. That assumption is a bug in our engineering culture, and it’s time we debugged it.
The Real Cost of “Got a Minute?”
Let’s do the grim maths on a single 30-minute meeting with five engineers. Raw time: 2.5 hours. But that’s the sticker price, not the real cost. The real cost is the context-switching tax. Studies on developer flow show it can take 15 to 23 minutes to fully re-immerse after an interruption. If that meeting sits at 10:30 a.m., it doesn’t just steal 30 minutes—it frags the entire morning. One half-hour block can easily torch 10 to 15 hours of real, focused output. Now multiply that by the three or four meetings peppered across the week. Your roadmap isn’t a plan; it’s a fantasy novel.
But the time theft is only half the story. The other half is the quality of the thinking. Synchronous meetings are a stage, and the performance favours the loudest voice, the quickest quip, and the most fluent speaker. The thoughtful engineer who needs 20 minutes of silence to turn a problem over in their head? They get steamrolled. The introvert who writes brilliantly but speaks cautiously? They never get the mic. You’re not harvesting the best ideas; you’re harvesting the fastest ones. That’s a lousy way to design systems, and a worse way to treat your people.
Async Is a Systems Architecture Choice
Engineers will happily wage holy wars over monoliths vs. microservices, or tabs vs. spaces, but we’re weirdly passive about our communication tools. We just accept the invite, grumble, and join the call. That’s insane. Asynchronous communication—writing things down, recording short walkthroughs, using threaded discussions—isn’t a soft skill. It’s the technical architecture for your team’s collective brain. Think of it as the difference between a blocking I/O call and an event-driven system. One halts the entire process until it gets a response. The other fires off a message and keeps working, handling the result when it’s ready. Which one scales better?
When you write a design doc instead of holding a design review meeting, you’re creating a persistent, searchable artifact. People read it when their brain is fresh, leave comments, and let ideas marinate. The decision doesn’t get crammed into a 45-minute window of groupthink; it evolves over a day or two, pulling in perspectives from different time zones and work schedules. That’s not just more inclusive. It’s more rigorous. You’re building a decision-making process that actually resembles engineering.
The Artifacts Are the Point
We tell ourselves a comforting lie: meetings are for alignment. But alignment doesn’t come from sitting in a room nodding along. It comes from a shared understanding of the problem, the constraints, and the proposed solution. A well-written RFC or a technical spec creates that shared understanding far better than a slide deck and a monologue ever could. The document becomes the source of truth. Six months later, when someone asks, “Why on earth did we build it this way?”, you can point to the doc. Try doing that with a Zoom recording that’s buried in a forgotten channel and will never, ever be watched.
If your team relies on meetings to make decisions, you’re building a culture with amnesia. Every important conversation should leave a trace. That trace—the written word—should be the primary medium, not a hasty summary email sent out after the fact by the one person who was actually paying attention.
Meetings as a Cultural Code Smell
When I see a team calendar that looks like a mosaic of recurring meetings, I don’t see a well-oiled machine. I see a pile of unresolved organisational bugs. Each meeting is a sticky plaster slapped over a broken process. Let’s autopsy the usual suspects.
The Daily Stand-up That Became a Status Report
The stand-up was meant to be a quick team huddle for coordination, not a daily interrogation where a project manager polls each developer on their progress. If your stand-up drags past 10 minutes and everyone’s giving updates to a single person, you don’t have a communication problem. You have a micromanagement problem. The fix isn’t a better stand-up format; it’s a project-tracking tool that actually works and a manager who knows how to read it. Kill the stand-up. Replace it with a Slack thread where people drop a sentence or two at the start of their day. If someone’s stuck, they’ll speak up. Trust them.
The Backlog Grooming That Never Ends
Grooming sessions are often a symptom of not doing the hard, boring work of writing clear tickets. If a ticket can’t be understood asynchronously, it’s a bad ticket. The product manager should write the ticket. The tech lead should add technical context. The team should ask questions in the comments. A two-hour meeting to discuss 30 tickets is a blaring siren that your tickets are too vague or your team doesn’t feel empowered to make small scoping decisions on their own. Write better tickets. Trust your engineers to use their judgement. If they can’t, you’ve got a hiring problem, not a meeting problem.
The “Quick Sync” That Multiplies
This one’s the most insidious. It starts with good intentions: “Let’s just hop on a call to sort this out.” It’s faster than writing an email, right? Wrong. It’s faster for the person calling the meeting, but it’s a tax on everyone else. And it sets a precedent. Soon, every minor ambiguity triggers a calendar invite. The team’s default response to any friction becomes “let’s schedule something.” You’re training your team to be helpless without a meeting. Instead, train them to write a short, structured problem statement. “Here’s what I’m trying to do, here’s where I’m stuck, here are the options I see.” That’s a skill. Build it.
How to Actually Make the Switch
Moving to an async-first culture isn’t about declaring “no more meetings” and hoping for the best. That’s like saying “no more bugs” and firing your QA team. You need to build the infrastructure and the habits. Here’s the practical, unsexy work.
1. Default to Written Proposals
Any decision that affects more than two people or spans more than a sprint should start as a written document. Use a template. Keep it short: problem statement, proposed solution, alternatives considered, open questions. Share it in a dedicated channel. Give people at least 24 hours to read and comment. Only schedule a meeting if the async discussion hits a genuine deadlock. You’ll find that 80% of the time, the deadlock resolves itself in the comments.
2. Record Short Videos for Complex Explanations
Sometimes, a wall of text is worse than a five-minute video. If you need to walk through a complex diagram or a code flow, use a screen recording tool. Keep it under 10 minutes. People can watch it at 1.5x speed, pause, rewind, and watch it when their brain is ready to absorb it. This is still asynchronous. It’s not a meeting. It’s a message you send.
3. Set Communication SLAs, Not Expectations of Immediacy
One reason people default to meetings is the fear of waiting hours for a reply. The fix is to agree on response times. For example: “We expect people to check and respond to async channels within half a day, not half a minute.” This gives everyone permission to focus without anxiety. If something is truly urgent, have a clear escalation path—a dedicated channel or a phone call. But “urgent” should mean “production is down,” not “I’m curious about your opinion on this variable name.”
4. Protect Maker Schedules Aggressively
Block out large, uninterrupted chunks of time on the team calendar. Call them “Focus Hours” or “No-Meeting Blocks.” Make it a cultural norm that you don’t schedule over them unless the building is on fire. This isn’t about being antisocial; it’s about respecting the fact that engineering is a creative, cognitive discipline. You wouldn’t interrupt a surgeon mid-surgery to ask about the weekend. Stop interrupting your engineers mid-thought.
The Social Contract of Async
Here’s the part that makes people squirm. Async communication demands a higher level of individual responsibility. You can’t hide in a meeting and pretend to be engaged. You have to actually read, think, and write. For some engineers, this is a relief. For others, it’s a nightmare. The ones who coasted by nodding along in meetings will suddenly be exposed. That’s a good thing. Your team’s performance should be measured by the quality of its output, not the quality of its theatre.
It also requires a different kind of trust. Managers have to trust that people are working even when they’re not visibly typing in a Slack channel. Engineers have to trust that their written contributions will be read and valued. This trust isn’t built overnight. It’s built by consistently showing that async processes lead to better outcomes. Start small. Replace one recurring meeting with an async process. Show that it works. Let the results speak for themselves.
When You Actually Do Need a Meeting
I’m not a purist. There are times when synchronous communication is the right tool. But those times are rarer than you think. A meeting is useful for:
- High-bandwidth, emotionally charged discussions: Giving hard feedback, resolving interpersonal conflict, or celebrating a win. These need human presence.
- Real-time collaborative debugging: When two or three people need to stare at the same screen and think out loud. This is a working session, not a status meeting.
- Kicking off a new initiative: A short, energetic call to build shared excitement and answer initial questions. But then immediately move to async for the details.
Notice the pattern: meetings are for connection and real-time collaboration, not for information dissemination or routine decision-making. If you’re using a meeting to read slides to people, you’re doing it wrong. Send the slides. If they have questions, they’ll ask.
FAQ
Won’t going async make the team feel disconnected and isolated?
It can, if you do it poorly. Async communication handles the work of the team, but you still need to invest in social connection. Schedule optional, purely social events—virtual coffee chats, gaming sessions, or in-person meetups if you’re colocated. The goal isn’t to eliminate all synchronous interaction; it’s to stop using work meetings as a substitute for team bonding. When work happens async, the synchronous time you do spend together can be higher quality and more focused on human connection.
How do we handle urgent issues without instant communication?
Define what “urgent” actually means. For most teams, it’s a production incident. Have a clear, well-documented incident response process that includes a dedicated real-time channel (like a war room) and an on-call rotation. For everything else, “urgent” is usually just “I want an answer now.” Train your team to distinguish between the two. If a non-incident request comes in, the response should be: “I’ll look at this during my next async check-in.” Over time, people learn that async doesn’t mean ignored; it means processed in a batched, thoughtful way.
What if management insists on keeping all the meetings?
This is the hardest scenario, because it’s a power problem, not a process problem. Start by gathering data. Track how much time the team spends in meetings and correlate it with output or team satisfaction. Present the data to management as a business case: “We’re losing X hours of potential focus time per week. I’d like to run an experiment where we replace Y meeting with an async process for one month and measure the results.” Frame it as a low-risk trial. If management still refuses, you’ve learned something important about the organisation’s values. At that point, you can decide whether to accept it or find a team that respects how engineers actually work.
The Bottom Line
Your team’s communication architecture is just as important as your system architecture. A system that relies on constant synchronous blocking calls is fragile, slow, and doesn’t scale. The same is true for your team. Most engineering teams don’t need more meetings; they need fewer, better meetings surrounded by a rich ecosystem of asynchronous practices. They need to treat writing, recording, and reading as first-class engineering activities. They need to stop confusing activity with progress.
So here’s your homework: look at your calendar for next week. Find one recurring meeting that exists mostly out of habit. Cancel it. Replace it with a written update or a short video. See what breaks. I’m betting nothing will. And if something does break, you’ve just found a process that needs a real fix, not a standing invite. That’s engineering. That’s debugging. That’s the job.
