Async-first only works if your team shares a memory

Six months ago you committed to async-first. The team reduced standing meetings, switched to written updates, set norms about Slack response times. The first month felt great. By month three, half the team was quietly missing the synchronous rhythm and the other half was buried in unread threads. The honest assessment is that async-first has been a net wash, and you are not sure why.

The reason is the part that most async-first guides leave out. Async tools — better written updates, structured PR descriptions, longer Loom recordings — are necessary but not sufficient. What they assume, silently, is that the team has a shared memory of context that everyone is reading the updates against. If that memory does not exist or is fragmented, async work becomes everyone guessing in parallel at what is going on.

Async is communication, memory is something else

The conventional async playbook is about communication discipline. Write things down. Decide in threads. Avoid meetings that could be a document. Make decisions in places that persist.

This is good advice and it solves one problem: the inefficiency of synchronous time. It does not solve, and was never designed to solve, the more fundamental problem of shared context.

When a colleague in another timezone reads your written update, she is making sense of it against everything else she already knows about the project. If her context is up to date, the update is informative. If her context is six days stale (because she has been heads-down on other work), the update is confusing or, worse, misleading. She makes the wrong inference. By the time you discover the misinference, two days have passed.

In a synchronous meeting, this resyncs automatically. People talk, ask, re-orient, and align in real time. Async loses that. The text alone cannot resync people who are out of sync.

Without shared memory, async creates ghost agreements

A pattern we see frequently at companies that have moved to async without solving the memory problem is what we call ghost agreement. Two people read the same thread, draw two different conclusions, both move forward as if the matter is settled, and only discover the divergence a week later when their work products contradict each other.

Ghost agreement is rare in synchronous communication because the friction of speaking forces the disagreement into the open. In async, friction is low and disagreement can stay invisible. The team feels efficient — look at how few meetings we have — but the work is silently drifting apart.

This is the hidden cost of async-first at SMEs. The visible cost (fewer meetings, faster individual work) is real. The hidden cost (decisions that look agreed but aren't, drift between people that surfaces too late) is also real, and it eats most of the visible gain.

The shared substrate is the missing layer

To work, async needs a substrate underneath it. A common, current, accessible record of what the project actually looks like right now. Not just the most recent thread. The whole picture, kept current as conversations and decisions evolve.

Without this substrate, every async update is forcing every reader to maintain their own private mental model, and those models drift apart over time. With it, the updates are anchored against a shared current state, and "let me re-read the context" is a five-second action rather than an hour of scrolling.

The substrate is not a wiki. Wikis go stale, as we have covered elsewhere on this site. The substrate is a continuously-updated, structured view over the team's actual communication: the threads, the meeting transcripts, the decisions, the current state of each project. Queryable, current, and shared.

What async-first looks like when this works

The shape of work changes in three visible ways.

First, async updates get shorter and more confident. Instead of writing long updates that try to recap every piece of context the reader might be missing, people write tight updates that point at the relevant parts of the shared record. "Project X is now at phase 2. See the discussion in #project-x last Tuesday for the rationale." The reader, lacking context, can pull the rationale themselves rather than waiting for someone to re-explain.

Second, decisions stop drifting. When two people draw different conclusions from the same thread, the disagreement surfaces faster, because either person can point to the same shared record and say "I read this as saying X" — and the other can respond "I read it as Y" — and the actual disagreement becomes visible in hours instead of weeks.

Third, the synchronous time that remains gets more valuable. The meetings that survive are no longer about catching everyone up. They are about the things that genuinely benefit from real-time human interaction: hard trade-offs, sensitive conversations, creative work. The cadence shifts from "lots of meetings to align" to "few meetings to decide".

Why "more documentation" is not the answer

If you proposed solving this problem with more documentation, every person on your team would silently quit. Documentation has been the proposed solution to every coordination problem for thirty years, and it has been failing for thirty years for the same reason: it requires people to do work in addition to their actual work, and they will not do it sustainably.

The substrate that makes async-first work is not a documentation effort. It is a layer that reads the communication that is already happening and presents it back to the team in usable form. The team doesn't write a parallel artifact. They just work, and the substrate is generated from the work.

This is the difference between "you should document your decisions" (which won't happen) and "your decisions are visible because they were made in a thread that is now part of the readable record" (which happens automatically).

A diagnostic question

Here is a question worth asking your team next week. "If you wanted to know the current status of Project X, where would you look, and how long would it take you to feel confident in your answer?"

If the honest answer is "I'd ask Marco" or "I'd scroll through Slack for ten minutes and probably still get it wrong", you do not have a shared memory. You have personal memories, distributed. Async work in that environment is going to keep producing ghost agreements and drift.

If the honest answer is "I'd query the shared record and have a confident answer in thirty seconds", you have what async-first actually needs. The tools and disciplines on top of that substrate work; without it, they don't.

Async is the destination. Memory is the road.

The companies that have made async-first actually work — not as a slogan, as a real operational mode — are the ones that quietly invested in the shared memory layer first. They didn't lead with the meeting reductions and the written-update norms. They led with making the company's working state legible to everyone in the company, and then the rest followed.

The meeting reductions and the written-update norms are downstream consequences of the team having a shared memory. They are not the mechanism. They are the result.

If async-first feels like it isn't working, the diagnosis is almost never "we need to write our updates better". It is "we don't have a shared substrate, so no update is enough". Build the substrate. The rest of async-first will follow.