You know the feeling. You’re 30 minutes into a daily standup that was supposed to take 15, and someone is narrating their Jira board like it’s a bedtime story. It’s not boredom that gets you. It’s the slow, creeping dread that your team’s most expensive resource—uninterrupted time to actually think—is being carved up by the very processes that were supposed to help. Meetings have become the default coordination mechanism in software engineering, and it’s a train wreck. Not because meetings are inherently evil, but because they’ve metastasized into a synchronous, real-time addiction that punishes deep work and rewards performative busyness. The alternative isn’t chaos. It’s asynchronous communication: a deliberate, written-first culture where information flows without dragging everyone into the same room at the same time. This isn’t a productivity hack. It’s a structural fix for a broken operating model.

Engineering teams are complex systems. When you treat coordination as a series of live, synchronous events, you introduce coupling that rivals the worst spaghetti code. Every meeting creates a dependency: you can’t start work until the meeting happens, you can’t make decisions without the meeting, and you can’t share context without yanking people away from their actual work. The result is a team that moves at the speed of its calendar, not its capability. Asynchronous communication decouples these dependencies. It lets information travel at the speed of reading, not the speed of scheduling. And it forces a discipline that most teams desperately need: the ability to write clearly, think before responding, and treat other people’s attention as the finite, non-renewable resource it is.

The Real Cost of Synchronous-By-Default

Let’s talk numbers, because engineers respect data. A single one-hour meeting with six engineers doesn’t cost one hour. It costs six hours of focused work, plus the cognitive switching costs before and after. Research on task switching shows it can take over 23 minutes to regain deep focus after an interruption. If your team has a morning standup, a mid-day sync, and an afternoon review, you’ve effectively capped anyone’s ability to do deep work at zero. You’re paying senior engineers to context-switch like a help desk, and that’s a terrible return on investment.

The damage goes deeper than lost time. Synchronous communication favors the loud, the quick-witted, and the native English speakers. It punishes introverts, remote workers in distant time zones, and anyone who needs time to process information before forming an opinion. Your meeting-heavy culture isn’t just inefficient; it’s exclusionary. You’re optimizing for consensus theater while the real thinking happens in the margins—or doesn’t happen at all because nobody has the uninterrupted blocks to do it.

How Meetings Become Organizational Scar Tissue

In code, we talk about technical debt: the accumulated shortcuts that slow down future development. Meetings are organizational debt. They’re added as a quick fix—“let’s sync on this”—and then never removed. Over time, they calcify into rituals that nobody questions. The weekly status meeting that started during a crisis three years ago? Still on the calendar. The cross-team alignment sync that was supposed to be temporary? Now it’s a recurring series with 15 attendees and no agenda. This is the organizational equivalent of a function with 47 parameters. It grew without design, and now it’s too politically dangerous to refactor.

Asynchronous communication forces you to confront this debt. When you can’t rely on a meeting to disseminate information, you have to write it down. That written record becomes searchable, linkable, and referenceable. It doesn’t disappear when someone leaves the company. It doesn’t require repeating the same update five times for five different audiences. It’s a single source of truth that scales horizontally, while meetings scale vertically—and poorly.

What Asynchronous Communication Actually Looks Like

This isn’t about replacing meetings with Slack. If you simply move the same chaotic, real-time chatter from a conference room to a chat app, you’ve accomplished nothing. True asynchronous communication is structured, written, and designed for consumption on the reader’s schedule, not the writer’s. It uses tools like long-form documents (design docs, RFCs, decision records), recorded video updates (Loom, short screencasts), and project management systems that track work status without requiring a verbal handoff.

The key shift is from “let’s meet to discuss” to “here’s a document, please comment by Thursday.” This respects the maker’s schedule, a concept Paul Graham articulated years ago that most companies still ignore. Makers—engineers, designers, writers—need long, uninterrupted blocks to produce value. Managers can operate on a manager’s schedule, chopped into one-hour slots. When you force makers onto a manager’s schedule, you get a team that’s great at attending meetings and terrible at shipping software.

Writing as a Core Engineering Skill

Here’s a hard truth: if your engineers can’t write clearly, your team has a communication problem that no number of meetings will fix. Asynchronous culture demands writing. Design documents, architecture decision records (ADRs), postmortems, project proposals—these are the artifacts of a healthy engineering organization. They force clarity. You can’t hand-wave through a written argument the way you can in a verbal discussion. If your reasoning is flawed, it shows up on the page. If your assumptions are unstated, they become visible gaps.

This is why companies like Amazon have institutionalized the six-page narrative memo. It’s not about bureaucracy. It’s about forcing rigorous thinking. A well-written document is a thinking tool, not just a communication tool. It lets the entire team examine the logic, poke at the edges, and build on the ideas without the time pressure of a live meeting. The comments and revisions become a permanent record of the decision-making process, which is invaluable when someone asks six months later, “Why did we build it this way?”

Identifying the Meetings You Should Kill First

Not all meetings are evil. Some require real-time collaboration: brainstorming sessions, complex technical discussions with multiple stakeholders, sensitive one-on-ones. The problem is that most recurring meetings don’t fall into these categories. They’re status updates, information broadcasts, and coordination overhead disguised as collaboration. Here’s a simple diagnostic: if the meeting could be replaced by an email, a document, or a five-minute video without losing fidelity, it should be.

Start with the daily standup. In most teams, it’s become a status report for the manager, not a coordination tool for the team. Replace it with a written check-in in your project management tool or a dedicated Slack channel. Each person posts what they worked on yesterday, what they’re working on today, and any blockers. The team reads it on their own time. If someone has a blocker, they can raise it immediately in a dedicated channel or schedule a focused conversation with the relevant person. You’ve just saved 30 minutes per person per day and eliminated the most common meeting complaint: “This could have been an email.”

Next, audit your recurring calendar. For every standing meeting, ask: what’s the output? If the answer is “alignment” or “visibility,” you have a process problem, not a meeting problem. Alignment comes from shared understanding, which comes from shared documents. Visibility comes from transparent work tracking, not from verbal updates. Kill the meeting and build the system that makes it unnecessary.

The Tools That Enable Async, Not Just More Noise

Tool choice matters, but it’s secondary to culture. You can’t Slack your way to asynchronous nirvana. That said, certain tools lower the friction. Long-form writing tools like Notion, Confluence, or Google Docs work for collaborative documents. Loom or other screen recording tools let you share complex ideas with visuals without scheduling a call. Project management tools like Linear, Jira, or Asana track work status so you don’t need a meeting to know what’s happening. The common thread: they all allow consumption on the reader’s schedule.

Version control platforms like GitHub or GitLab are inherently asynchronous. Pull requests, code reviews, and issue discussions happen without real-time coordination. This is the model to extend to the rest of your work. If your code collaboration is async but your planning and decision-making are synchronous, you’ve got an impedance mismatch that creates constant friction.

When Async Fails: The Edge Cases

Async isn’t a silver bullet. There are situations where synchronous communication is genuinely necessary. Complex technical discussions with multiple experts often benefit from real-time back-and-forth. Crisis situations demand immediate coordination. Relationship-building and trust formation can be harder without some face-to-face interaction. The goal isn’t to eliminate meetings entirely; it’s to make them the exception, not the rule.

The danger is when teams use these edge cases to justify the status quo. “We need our daily standup because sometimes there are blockers” is a failure of process design. If blockers only surface during a scheduled meeting, you have a deeper problem: people aren’t raising issues when they occur. Fix that cultural problem directly. Create a norm that blockers are escalated immediately, not saved for the next day’s meeting. The meeting is a bandage, not a cure.

Remote and Distributed Teams: Async Is Non-Negotiable

If your team spans time zones, synchronous-by-default is actively harmful. You’re forcing some team members to attend meetings at 6 a.m. or 10 p.m. regularly. This isn’t just inconvenient; it’s a fast track to burnout and attrition. Async communication is the only scalable way to include people across time zones without creating second-class team members. It also forces you to document decisions and context, which benefits everyone, including future hires who weren’t in the room when decisions were made.

Many companies claim to be remote-friendly while maintaining a synchronous culture centered on one time zone. That’s not remote-friendly. That’s office culture with a longer commute. True remote work requires rethinking how information flows, and async is the foundation. Without it, you’re just replicating the dysfunctions of a co-located team across Slack and Zoom, and the results are predictably worse.

Implementing Async Without Causing a Revolt

Shifting a team from synchronous to asynchronous communication is a cultural change, and cultural change is hard. If you announce on Friday that all meetings are canceled starting Monday, you’ll get chaos and resentment. Start with a pilot. Pick one recurring meeting—the daily standup is the easiest target—and replace it with a written process for two weeks. Gather feedback. Tweak the format. Show the team the time savings and the quality of information sharing. Let the results speak for themselves.

Invest in writing skills. Many engineers are terrible writers because nobody ever taught them and the culture never demanded it. Provide templates for async updates. Give feedback on clarity and conciseness. Make writing a valued skill in performance reviews. When people see that clear writing leads to fewer interruptions and more autonomy, they’ll adopt it willingly. When they see that verbose, unclear writing leads to more meetings to “clarify,” they’ll improve or they’ll self-select out.

Leadership’s Role in Modeling Async

This fails if leadership doesn’t model it. If the CTO sends a Slack message saying “let’s jump on a quick call” every time there’s a question, the culture won’t change. Leaders must write. They must share written updates, make decisions in documents, and respect their team’s focus time. They must stop using “I’m a verbal processor” as an excuse to hijack other people’s schedules. Verbal processing is fine—do it in a document, record a video, or talk to yourself. Don’t make it your team’s problem.

Leaders also need to protect the async experiment from organizational gravity. Other departments, other executives, and external stakeholders will still want meetings. That’s okay. The goal isn’t to refuse all meetings; it’s to make your team’s default communication mode async. When a meeting request comes in, the first question should be: “Can we handle this with a document first?” Over time, this shifts the entire organization’s expectations.

Measuring the Impact: What Improves When Meetings Die

You’ll know it’s working when you see these signals: pull requests get reviewed faster because people have uninterrupted time. On-call incidents get resolved more smoothly because documentation is current and searchable. New hires ramp up quicker because they can read the decision history instead of relying on tribal knowledge. Team satisfaction scores improve because people feel in control of their time. Shipping velocity increases not because people are working harder, but because they’re working with fewer interruptions.

One counterintuitive benefit: meetings that survive the purge become much better. When you reduce the total meeting load, the remaining synchronous time is treated as precious. People come prepared. Discussions are focused. Decisions actually get made. You’ve eliminated the organizational filler and kept the substance. That’s a meeting culture worth having.

Frequently Asked Questions

How do you handle urgent issues without real-time meetings?

Urgent issues should be rare in a well-run engineering team. If everything is urgent, you have a prioritization problem, not a communication problem. For genuine emergencies—production outages, security incidents—real-time coordination is appropriate. Define clear escalation paths: a dedicated incident channel, an on-call rotation, a war room protocol. The key is that these are exceptions, not the daily operating model. If you’re using “urgent” to justify constant interruptions, you’re misusing the word.

Won’t async communication slow down decision-making?

It depends on what you mean by “slow.” If you measure decision speed by how quickly a meeting can be scheduled, async might seem slower. But if you measure by how quickly a well-reasoned, documented decision is made and communicated to everyone who needs to know, async is often faster. Synchronous decisions are fast to make and slow to propagate. Async decisions take slightly longer to form but are instantly available to the entire organization. Over time, the async approach compounds: decisions build on each other, context accumulates, and the team gets faster because it’s not constantly reinventing understanding.

What about team bonding and culture? Don’t we need meetings for that?

Team bonding is important, but it doesn’t require status meetings. Separate social connection from work coordination. Schedule optional social events, virtual coffee chats, or in-person offsites for relationship-building. These are valuable and should be protected. But don’t confuse them with the daily coordination machinery. A daily standup is a terrible social event, and a team happy hour is a terrible place to discuss project blockers. Keep the purposes distinct, and you’ll do both better.

How do we handle performance feedback and sensitive conversations?

One-on-ones, performance reviews, and sensitive feedback conversations are inherently synchronous. They require real-time, private discussion. These meetings should stay. The goal isn’t to eliminate all synchronous communication; it’s to eliminate the low-value, recurring, coordination-overhead meetings that consume the bulk of the team’s time. Protect the high-value synchronous interactions by clearing out the noise around them.

The shift to asynchronous communication isn’t a productivity trend. It’s a recognition that software engineering is a thinking profession, and thinking requires uninterrupted time. Every meeting you eliminate is an investment in your team’s ability to do the work they were hired to do. Start small, measure the results, and let the data make the case. Your team’s code—and their sanity—will thank you.

The Hardest Problem in Computer Science Is Still Naming Things — And Your Postmortem Titles Prove It

Every engineering team has a values poster. Every engineering team also has a service called “data-service-v2.” One of these tells you the truth about the culture.

You know the joke. Two hard problems in computer science: cache invalidation, naming things, and off-by-one errors. It’s funny because it’s three things, and because every engineer has lived it. But the joke trained us to think of naming as a technical annoyance — a friction point between writing code and shipping it, something you solve with a thesaurus and a team vote, then forget about.

I want to argue something different. The names your team chooses — for services, projects, architecture decisions, incident postmortems, refactoring initiatives, Slack channels — are the most honest cultural artifacts you produce. More honest than your values poster. More honest than your engineering handbook. More honest than that paragraph on your careers page about “engineering excellence.” Names encode decisions. They encode who was in the room when the decision was made. They encode what the team knew at the time, what it was afraid of, and what it was trying to avoid admitting. And bad names persist not because teams are lazy — they persist because renaming is politically expensive, because the person who chose the name has usually left, and because the name often encodes a decision that someone else made in a meeting you weren’t invited to.

If you want to diagnose a team’s culture, don’t read its style guide. Read its names.

§ 1 — The Service Called “Platform”

I once joined a team that had a service called “platform.” I asked what it did. Three engineers gave me three different answers. One said it was an API gateway. One said it was a data aggregation layer. One said it was “the thing that talks to the vendors.” The service was four years old, had twelve contributors in its git history — seven of whom had left the company — and had accumulated so many responsibilities that any attempt to describe it required the word “also” at least twice per sentence.

The name “platform” wasn’t a mistake. It was a fossil. At the time it was named, it probably was a platform — a thin layer abstracting away vendor integrations. But the name carried no constraints, and because it carried no constraints, it accumulated every responsibility no other service wanted to own. “Platform” is a name that means “whatever we need it to mean,” and that kind of name is a standing invitation to dump work into a service nobody has to think about until it breaks.

Generic names aren’t a naming problem. They’re a boundary problem. A service called “platform” or “core” or “common” or “utils” is a service with no edges, and a service with no edges grows until it becomes the place where engineering goes to die. The name doesn’t cause the dysfunction. It enables it. The name says: this thing has no specific purpose, so any purpose will do.

I’ve seen this pattern at every company I’ve worked at. The service called “gateway” that became a monolith. The service called “shared” that every team depended on and no team owned. The service called “legacy” that was newer than three services called “new-thing.” The names are diagnostic — they tell you that at some point, the team stopped being willing to draw boundaries, and the name was the first place that reluctance showed up.

§ 2 — Version Numbers That Erase History

Then there’s the version-number name. “data-service-v2.” “auth-rewrite.” “payments-v3.” These names are everywhere, and they share the same pathology: they tell you something came before, but they don’t tell you what changed, why it changed, or what the previous version got wrong.

“data-service-v2” answers the question “is this the new one?” and refuses to answer any other question. What was v1? Why did it need replacing? Is v2 a rewrite, a refactor, or a parallel implementation? Will v1 be decommissioned, or will it run alongside v2 for the next three years while everyone pretends that’s temporary? The name gives you nothing.

The version-number name is a symptom of a team that decided not to commit to a narrative. Naming something “v2” is a way of saying “we’re moving forward” without specifying what forward means. It’s the engineering equivalent of “new and improved” — technically informative, culturally useless. And these names persist because the moment you give something a specific name — “the event-sourced billing service” or “the synchronous payments gateway” — you’ve made a commitment about what it is and what it isn’t. Version numbers let you dodge that commitment.

I’ve watched teams build v3 of a service while v2 was still being built. I’ve watched teams maintain v1, v2, and v3 simultaneously, each with its own on-call rotation, because nobody could agree on which version was canonical. The version-number name doesn’t track progress. It tracks the accumulation of decisions nobody was willing to close out.

§ 3 — Incident Names That Minimize What Happened

This is where naming gets serious. If your service names are cultural artifacts, your incident names are cultural fingerprints.

I’ve seen postmortems titled “Minor API degradation on March 14” that described a four-hour outage affecting the entire checkout flow. I’ve seen incidents codenamed “wobbly Tuesday” that caused six-figure revenue loss. I’ve seen an incident called “the blip” that took down authentication for forty minutes and locked out every internal tool — including the incident management dashboard.

The names we give incidents aren’t neutral labels. They’re organizational signals about how seriously we’re taking what happened. A postmortem called “minor API degradation” tells every engineer who reads it — and every executive who skims it — that this wasn’t a big deal. The four-hour checkout outage is already being softened before the root cause analysis is written. The name is the first draft of the spin.

Google’s SRE book dedicates an entire chapter to postmortem culture, and its table of contents reads like a taxonomy of operational seriousness — “Managing Incidents,” “Postmortem Culture: Learning from Failure,” “Tracking Outages” — each one a named, structured practice with formal expectations. The Google SRE book’s treatment of incident documentation makes clear that postmortems are first-class engineering artifacts, not afterthoughts dashed off between pages. Mature engineering organizations treat the naming and documentation of incidents as a deliberate practice. Immature ones treat it as a creative writing exercise where the goal is making the incident sound smaller than it was.

The minimizing incident name is a trust problem wearing a naming problem’s clothes. Teams name incidents carefully when they’re afraid of consequences. They name incidents casually when they don’t want anyone outside the team to pay attention. They name incidents with cutesy codenames when they want to signal that this is an internal matter, not something the business needs to worry about. Every one of these naming choices tells you what the team is afraid of.

§ 4 — The ADR That Records the Decision But Not the Duress

Architecture Decision Records are supposed to be the antidote to tribal knowledge. They’re supposed to capture not just what was decided but why — what alternatives were considered, what tradeoffs were accepted, what constraints were in play. In practice, most ADRs I’ve read are post-hoc justifications written by the person who won the argument, and their titles reflect it.

“ADR-014: Adopt Kafka for Event Streaming” tells you what was decided. It does not tell you that the team owning the message queue was overruled, that the Kafka migration was driven by a VP who saw a conference talk, or that the team’s preferred option — RabbitMQ, already running in production — was dismissed without a technical evaluation. The ADR title is a clean summary of a dirty process.

The problem isn’t that ADRs are dishonest. The problem is that the naming convention — “ADR-NN: Decision” — encodes only the outcome. The title becomes the canonical reference, and once it’s referenced in three other documents and two Slack threads, it’s locked in. Nobody goes back and amends an ADR title to say “ADR-014: Adopt Kafka Because the VP Saw a Conference Talk and the Team Was Outvoted.” That would be honest. It would also be career-limiting.

So the ADR title becomes a small fiction. Not a lie, but a simplification that erases the political context in which the decision was made. And the next engineer who reads it thinks the decision was made for the reasons stated, because the title gives them no reason to suspect otherwise.

§ 5 — Who Gets to Name Things

Here’s the pattern I’ve seen at every company: the person who creates the thing gets to name it. The person who creates the thing is usually the person with the most context at the time of creation. The person with the most context is usually the person who’s been there longest, or the person with the most political capital, or the person who happened to be in the room when the Jira ticket was created.

This means naming isn’t a democratic process. It’s an exercise in power. The senior engineer who spins up a new service at 11 PM names it. The junior engineer who joins six months later has to live with that name, work with it, explain it to new hires, and pretend it makes sense.

I worked with a team once where every service was named after a Greek myth. Atlas. Prometheus. Icarus. Sisyphus. The engineer who named them was brilliant, had a humanities degree, and left after eighteen months. The remaining team spent the next two years explaining to new hires why the billing service was called Sisyphus. The answer, as far as anyone could reconstruct, was that the engineer thought billing was a repetitive, futile task. This was either a joke or a cry for help, and by the time I got there, nobody could remember which.

Names encode the values and context of the person who chose them. When that person leaves, the name becomes a question nobody can answer. This is why renaming is so hard — not because it’s technically difficult (it’s a find-and-replace), but because renaming is an act of saying “the person who named this was wrong, and I know better.” That’s a political statement, not a technical one. Most engineers don’t want to make it.

§ 6 — The Political Cost of Renaming

So bad names persist. They persist because the cost of renaming is paid by the person who proposes it, and the benefit is distributed across everyone who will ever interact with the name in the future. The proposer takes the political risk of offending the original namer (if they’re still around), the technical risk of updating every reference, and the social risk of being seen as someone who cares about “trivial” things like names instead of “real” things like features.

This is the same dynamic that keeps bad code alive. The cost of refactoring is concentrated; the benefit is distributed. The difference is that with code, we at least have language for talking about technical debt. We have sprints for it. We have metrics that make the cost of inaction visible. With naming, we don’t. There’s no Jira label for “this name is actively misleading every new hire.” There’s no dashboard showing the hours lost to confusion about what “platform” does.

The result is that names ossify. They become part of the team’s vocabulary without ever being validated. Engineers learn them the way you learn the quirks of a codebase — not because they make sense, but because they’re there, and questioning them takes more energy than accepting them. The name becomes load-bearing. You can’t remove it without shaking the structure, and nobody wants to be the person who shakes the structure.

The NIST Cybersecurity Framework demonstrates what happens when an organization treats naming and categorization as a first-class discipline. Its structured taxonomy of risk outcomes — Govern, Identify, Protect, Detect, Respond, Recover — represents deliberate, institutional investment in naming as a foundation for shared understanding. The contrast with engineering teams that name incidents “the blip” and services “platform” is not subtle. When a government standards body takes classification more seriously than your engineering organization does, your engineering organization has a naming problem — and a culture problem.

§ 7 — Practical Experiments: Auditing Your Team’s Names

So what do you do about it? You can’t rename everything. You shouldn’t try. But you can start treating naming as a first-class engineering decision rather than an afterthought dashed off between standup and lunch. Here are three experiments I’ve run on teams I’ve been part of, with varying degrees of success and one outright failure that taught me more than the successes.

Experiment 1: The New-Hire Naming Audit. Ask someone who joined in the last 90 days to list every service, project, and recurring meeting name they’ve encountered, and write down what they think each one means. Don’t correct them. Just collect the answers. The gap between what the name says and what the new hire thinks it means is your naming debt, made visible. I ran this once and discovered that three engineers thought “the bridge” was a data pipeline, a Slack channel, and a deployment process. It was all three. The name “bridge” had been reused for different things by different teams over three years, and nobody noticed because nobody new had ever been asked.

Experiment 2: The Postmortem Title Review. Before your next postmortem is published, have someone who wasn’t involved in the incident read the title and guess the severity. If they guess low, the title is doing work for you — specifically, the work of minimizing what happened. Rewrite the title until a stranger can accurately gauge the impact. This sounds trivial. It is not. The first time I tried this, the original title was “intermittent 5xx errors in the EU region.” The rewritten title was “Checkout unavailable for 47% of EU customers for 2.5 hours due to connection pool exhaustion.” The first title was written by the on-call engineer. The second was written by the engineer who had to explain the incident to the CFO. Both were accurate. Only one was honest.

Experiment 3: The Rename One Thing Challenge. Pick one service, one document, or one recurring meeting with a bad name. Rename it. Track every reference. Update every link. Write a one-paragraph note explaining the old name, the new name, and why the change was made. This is deliberately small. The point isn’t to fix all your names — it’s to prove that renaming is survivable, to establish that names can change, and to create a template for the next person who wants to try. The political cost of the first rename is the highest. Every subsequent rename is cheaper because the precedent exists.

If you want to go deeper, borrow naming discipline from adjacent fields. Editorial teams use structured naming conventions for manuscripts and campaigns — a book title generator that enforces structure can teach you something about why constraints produce better names than open-ended brainstorming sessions. The principle is the same: names that follow a pattern carry information. Names chosen freely carry whatever the namer was thinking about that day, which is usually lunch.

§ 8 — What Your Names Are Telling You

Here’s what I want you to take away. Your team’s names are not a cosmetic concern. They’re a diagnostic surface. They tell you where your team has stopped drawing boundaries (generic names), where it has stopped committing to narratives (version numbers), where it is minimizing failure (cutesy incident names), where it is hiding political decisions behind technical summaries (ADR titles), and where it has let the context of departed engineers calcify into permanent confusion (orphaned codenames).

Every name is a small decision, but the aggregate pattern tells you something your retros never will — because retros are performed for an audience, and names are chosen when nobody’s watching. Names are what your team does when it thinks nobody is keeping score.

So go look at your service catalog. Read your last ten postmortem titles. Open your ADR repository and read the titles without reading the bodies. Ask yourself: do these names tell me what I need to know? Do they carry context, or do they require it? And if they require context — if every name comes with a story that isn’t in the name — then your team has a documentation problem no style guide will fix. Because the problem was never the names. The problem was the meetings where the names were chosen, who was in those meetings, who wasn’t, and the fact that nobody has been willing to revisit those decisions since.

Naming is the hardest problem in computer science because it’s the one that requires the most honesty. You can solve cache invalidation with better infrastructure. You can fix off-by-one errors with tests. But you can only fix naming by being willing to say: this name is wrong, this name is misleading, this name was chosen by someone who is gone, and I’m going to change it. That’s not a technical decision. It’s an act of cultural maintenance. And it’s the act that distinguishes a team that manages its knowledge from a team that just accumulates it.

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.

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.

I’ve sat through enough stand-ups to know the real bottleneck in software development isn’t the code. It’s the calendar. The modern engineering team has mutated into a meeting factory that occasionally ships features. We’ve ritualized interruption and called it collaboration. The fix isn’t a shiny new project management tool or a better retro format. The fix is shutting up and letting people work.

The Meeting Industrial Complex

Somewhere along the way, we decided that synchronous chatter was the gold standard for knowledge work. Got a question? Book a meeting. Need a decision? Book a meeting. Have a meeting coming up? Book a pre-meeting to decide what you’ll decide in the meeting. Then we act surprised when nothing ships on Friday.

Engineering is deep work. It demands long, uninterrupted stretches of concentration. Yank a developer into a 30-minute sync and you haven’t just lost 30 minutes. You’ve vaporized the 45 minutes they spent sinking into flow before the interruption, the meeting itself, and the 20 minutes it takes to rebuild mental context afterward. That’s nearly two hours of productive capacity. Torched. For a status update that could’ve been a three-line Slack message.

The kicker? Most meetings exist to solve problems that meetings created. A team communicates poorly, so leadership layers on a daily sync. The daily sync surfaces too many issues, so they add a weekly planning meeting. The planning meeting reveals misalignment, so they bolt on a cross-team alignment meeting. Before you know it, engineers spend more time talking about work than doing it. It’s a self-licking ice cream cone of inefficiency.

The Async Advantage

Asynchronous communication isn’t just a remote-work buzzword. It’s the default mode for how engineers actually solve problems. You don’t debug a race condition by herding five people into a room and talking about it. You dig into logs, read documentation, write a proof of concept, and then share your findings. The work itself is async. The communication should match.

When a team goes async-first, something almost magical happens: people start writing things down. Design decisions get documented. Trade-offs get explained. Context gets preserved. Six months later, when someone asks why the authentication service uses a custom token format, there’s a written record instead of a vague memory of a whiteboard session that nobody photographed.

Async also flattens the playing field for distributed teams. The engineer in a different time zone stops being a second-class citizen dialing into 9 PM meetings. The introvert who needs time to process before responding gets to contribute at their best. The junior developer can read through the decision history and actually understand why the system works the way it does. Everyone wins except the extroverts who get energy from hearing themselves talk. They’ll survive.

What Async Actually Looks Like

Let’s get specific. Async communication means leaning on RFC documents, design proposals, and threaded discussions in Slack or Discord instead of real-time meetings. It means recording short video walkthroughs with Loom rather than scheduling a live demo that half the team can’t attend. It means writing clear, structured updates in a shared channel instead of going around the room in a stand-up.

Here’s a concrete example. Instead of a one-hour sprint planning meeting, the product manager writes a document outlining the next batch of work—context, acceptance criteria, links to relevant designs. Engineers review it on their own time, leave comments and questions, and the PM iterates on the doc. By the time anyone gets on a call—if they even need to—the major ambiguities are already resolved. The call is 15 minutes, not 60, and it’s optional.

The Meetings Worth Keeping

I’m not a meeting abolitionist. Some conversations genuinely benefit from real-time back-and-forth. Complex technical debates where you need to sketch architecture on a virtual whiteboard. Sensitive feedback that requires tone and empathy. Team bonding that builds the trust necessary for async to work in the first place. The trick is being intentional about which meetings earn their spot on the calendar.

A good rule of thumb: if the meeting is mostly about information transfer, it should be a document. If it’s about decision-making, it should start as a document and only escalate to a meeting if the async discussion deadlocks. If it’s about relationship-building, schedule it sparingly and make it genuinely social. The daily stand-up that’s really just a status report? Kill it. Replace it with a Slack bot that asks three questions and posts the answers to a channel.

I once worked with a team that replaced all internal meetings with async updates for a month as an experiment. Productivity shot up. Bugs got fixed faster. The only complaint came from a manager who felt “out of the loop” because he wasn’t hearing people talk. That’s not a communication problem. That’s a control problem dressed up as a communication problem.

Writing Is Thinking

There’s a deeper reason async works for engineering teams: writing forces clarity. When you have to explain a technical decision in prose, you can’t hide behind hand-waving and jargon. You have to structure your thoughts, anticipate counterarguments, and commit to a position. A spoken discussion can meander for an hour and end with “let’s take this offline.” A written proposal has to land somewhere.

This is why the best engineering cultures are writing cultures. They produce design docs, postmortems, and RFCs that become the team’s collective memory. New hires can onboard by reading through the archive. Decisions get made with the full context visible to everyone, not just the people who happened to be in the room. It’s more democratic, more rigorous, and frankly more respectful of people’s time.

How to Actually Make the Switch

Moving to async-first doesn’t happen by decree. You can’t just fire off a company-wide email announcing “no more meetings” and expect it to stick. The habits are too ingrained. You need to replace the rituals, not just remove them.

Start with the most painful meeting on the calendar. For most teams, that’s the daily stand-up. Replace it with a written check-in. Use a template: what I did yesterday, what I’m doing today, what’s blocking me. Post it in a shared channel. If someone is blocked, they can immediately ping the person who can help. No need to wait 24 hours to say it out loud in a circle.

Next, tackle decision-making. Create a lightweight RFC process. It doesn’t need to be formal. A Google Doc with a problem statement, proposed solution, alternatives considered, and open questions is enough. Give people 24–48 hours to comment. If there’s consensus, you’re done. If there’s disagreement, then—and only then—schedule a focused discussion with the relevant people. Most decisions won’t need the meeting.

Finally, protect deep work time. Block off large chunks of the calendar as “no meeting” zones. Make it culturally unacceptable to schedule over them. If someone tries, the response should be “can this be async?” not “let me shuffle my focus blocks around.” Treat uninterrupted time as the precious resource it is.

The Real Engineering Problem

Here’s the blunt truth: if your team can’t function without constant meetings, you have a trust problem or a clarity problem. Either leadership doesn’t trust engineers to do the right thing without constant oversight, or the team lacks the written context to make decisions independently. Both are fixable. Neither requires more meetings.

Engineering culture is the real technical problem. We obsess over system architecture, code quality, and deployment pipelines, but we tolerate communication patterns that are the equivalent of a single-threaded event loop blocking on I/O. It’s absurd. We’re building distributed systems with high throughput and low latency, and then we run our teams like a batch process from 1972.

Async communication is the horizontal scaling of human collaboration. It lets work happen in parallel. It creates a persistent log of decisions. It decouples services—I mean, team members—so they can operate independently. If you wouldn’t design your system the way you run your meetings, why are you running your meetings that way?

FAQ

Won’t async communication slow down decision-making?

Only if you measure decision speed by how quickly someone speaks in a meeting. Async actually speeds up the overall process because people can contribute when they’re ready, not when the calendar slot happens. A decision that takes two days of async discussion is still faster than waiting a week for the next scheduled meeting. And the decision quality is higher because people had time to think.

What about urgent issues that need immediate attention?

Urgent issues should be rare. If everything is urgent, nothing is. For genuine production incidents, you should have an on-call rotation and a well-defined incident response process. That’s not a meeting—that’s a fire drill. For everything else, “urgent” is usually a euphemism for “poorly planned.” Fix the planning, not the communication channel.

How do you maintain team cohesion without regular face-to-face meetings?

Cohesion comes from shared purpose and trust, not from staring at each other in a conference room. Async communication actually builds stronger cohesion because it creates a written record of collaboration. People see each other’s thinking, not just their talking. For the human connection piece, schedule occasional in-person or video social time that’s explicitly not about work. But don’t confuse socializing with status updates.

What if management insists on keeping the meetings?

Show them the math. Calculate the cost of a one-hour meeting with eight engineers. Then calculate how many hours per week those engineers spend in meetings. Multiply by their loaded cost. That number is usually enough to get attention. If it’s not, propose a one-month experiment: replace all status meetings with async updates and measure velocity, bug resolution time, and team satisfaction. Let the data do the arguing.

The bottom line: your team’s calendar is a legacy system. It’s time to refactor it. Start by deleting the meetings that exist only because they’ve always existed. Replace them with writing. Trust your engineers to manage their own time. You might be surprised how much they ship when you stop interrupting them.