Async-first breaks when decisions live in chat instead of durable, searchable records.
01 THE PROBLEM
Async-first is the failure mode where a company removes meetings but does not replace them with decision-quality documentation.
That distinction matters. A team can be “remote,” “distributed,” or “Slack-heavy” and still not be async-first in any meaningful way. If critical context still travels through DMs, threads, and ad hoc calls, the team has only changed the transport layer. It has not changed how work becomes legible.
The consequence shows up fast. Within one or two quarters, roadmap decisions become hard to reconstruct, incidents take longer to review, onboarding slows, and cross-functional work starts depending on whoever remembers “why we did it that way.” The org feels busy and responsive, but it accumulates hidden coordination debt.
Slack is usually where this debt hides.
Slack is excellent for triage, lightweight coordination, and resolving narrow questions. It is bad at being the system of record. Threads fragment, channel norms differ, search quality decays as message volume grows, and the most important decisions are usually buried inside conversational context that made sense only to the people present that day.
The mistake senior leaders make is subtle: they think async-first means “fewer meetings” or “better chat hygiene.” It does not. Async-first means work can proceed, decisions can be audited, and new people can catch up without requiring synchronous explanation from the original participants.
That requires documentation as infrastructure, not as cleanup.
Stripe’s engineering culture has long emphasized written communication and design docs as a way to scale decisions across teams. Not because writing is aesthetically pleasing, but because written artifacts preserve intent, surface tradeoffs, and reduce coordination load as an org grows. Will Larson makes the same point from the management side in Staff Engineer and his writing on engineering leadership: organizations scale through mechanisms, and documentation is one of the few mechanisms that scales both alignment and autonomy.
If your team says it is async-first, ask one hard question: can an engineer who joins the discussion 10 days later understand the decision, the alternatives considered, the owner, the risk, and the next checkpoint without asking a human?
If the answer is no, you do not have async-first. You have chat-first with delayed replies.
02 WHY IT HAPPENS
This happens because Slack lowers the cost of sending information but raises the risk that information never becomes organizational knowledge.
That is the structural trap.
A message is easier to write than a document. A thread is easier to start than an RFC. A huddle is easier to schedule than writing up a design rationale. In the moment, every local decision is rational. Over time, the system becomes irrational because retrieval, auditability, and context transfer collapse.
This is an incentives problem before it is a tooling problem.
The sender is rewarded for speed. The team is punished later through rework.
A staff engineer answers a deployment question in a thread in 90 seconds. A product decision gets settled in a Slack conversation between engineering, PM, and support in 15 minutes. A security exception gets “temporarily” approved in a private channel. Each action optimizes for immediate throughput. None optimizes for the person who needs to understand the decision three weeks later during an incident, customer escalation, or architectural review.
That gap between transmission and preservation is where async-first cultures fail.
The second root cause is that most companies have no explicit information architecture. They have tools, not rules.
They use Slack, Notion, Google Docs, GitHub, Linear, Jira, and Confluence, but nobody can answer basic questions consistently:
- Where do architectural decisions live?
- What requires a written decision record?
- When does a Slack conversation have to be promoted into a durable artifact?
- Who owns stale docs?
- What is the expected response time for chat vs docs vs tickets?
Without these rules, communication defaults to the path of least resistance. That path is almost always chat.
Linear is a useful counterexample. The company is known for speed, but speed there is not pure conversational chaos. Its product and engineering culture relies heavily on clear issue tracking, tight written specs, and disciplined product development loops. The visible UI polish gets the attention; the less visible operational habit is that important work is captured in structured systems, not left floating in chat. That is one reason teams can move quickly without drowning in status meetings.
The third root cause is leadership modeling.
If executives and senior engineers make decisions in private chats, everyone else learns that the real work happens off-record. Once that norm sets in, documentation becomes ceremonial. Docs are written after the fact, if at all, and they are usually sanitized summaries rather than actual records of tradeoffs and uncertainty.
This is why “we need better documentation” often fails as a directive. The issue is not that people do not believe in writing. The issue is that the org’s real status system rewards immediacy, availability, and verbal fluency more than durable clarity.
DHH has written for years about the cost of real-time interruption and the value of calmer, written communication. Whether or not you agree with Basecamp’s entire philosophy, the core observation is correct: if your culture treats responsiveness as a proxy for contribution, people will optimize for being seen in the stream, not for producing durable artifacts.
The final reason is technical: chat is a poor store of operational memory.
Search in chat tools is optimized for recall of messages, not reconstruction of decisions. You can often find the sentence. You cannot reliably recover the full decision surface: context, options, owner, risk, approval path, and subsequent revision. This matters most in engineering because engineering decisions are not just statements. They are commitments embedded in systems.
GitHub understands this at the code level. Pull requests, issues, and discussions work because they tie conversation to artifacts, ownership, and change history. The broader lesson is portable: communication becomes useful when it is attached to the work object and remains queryable over time.
Async-first companies operationalize that lesson across the entire org. Everyone else drowns in intelligent but unrecoverable conversation.
03 WHAT MOST GET WRONG
Most teams misdiagnose the problem as “too many meetings” or “bad Slack etiquette.”
That is too shallow.
Meetings are not the root problem. Chat is not the root problem. The root problem is that decision-making lacks a durable, enforced path from discussion to record.
This is why the most common fixes fail.
The first failed fix is writing a Slack etiquette guide.
You have seen versions of it:
- Use threads
- Don’t expect immediate responses
- Mark urgent items clearly
- Post in channels, not DMs
- Summarize decisions
None of that is wrong. None of it is sufficient.
Slack norms reduce noise. They do not create institutional memory.
A team can be excellent at threads and still lose context if the final decision never leaves Slack. Better etiquette improves local clarity while preserving the same systemic failure mode.
The second failed fix is adding more tools.
Leaders often respond to async pain by buying Notion, Confluence, Coda, Loom, or project management add-ons. The result is usually tool sprawl without protocol. Information gets sprayed across more surfaces, not consolidated into a clearer operating model.
This is the standard enterprise collaboration mistake: treating discoverability as a feature instead of a governance problem.
A new knowledge base will not help if nobody knows what belongs there, what must be updated, or how it connects to tickets, code, incidents, and roadmap decisions.
The third failed fix is “record everything.”
This sounds sensible and usually produces garbage.
When teams try to document every discussion, they create a graveyard of low-signal notes, duplicate pages, stale decisions, and unlabeled drafts. Search quality gets worse. Trust in docs drops. People go back to pinging the person who “probably knows.”
Good async-first systems do not document everything. They document the right thresholds.
The fourth failed fix is treating docs as one-way communication.
This is where a lot of executive memos and product specs fail. A doc gets published, but there is no clear review window, approval mechanism, dissent path, or update policy. In practice, the doc becomes either a broadcast artifact or a checkbox. Neither supports distributed decision-making.
Stripe and GitHub are instructive here. In both environments, written artifacts are not just storage. They are part of how proposals are challenged, approved, and iterated. The point of the doc is not archival purity. The point is to create a decision surface that others can inspect and respond to asynchronously.
The fifth failed fix is assuming transparency means public channels.
Public channels are useful. They are not a substitute for records.
An org can move more conversation into public Slack and still remain opaque because public does not equal durable, and visible does not equal structured. A thread with 87 messages in `#eng-platform` may be publicly visible. It is still a terrible ADR.
There is also a real failure pattern here that shows up in incidents.
The Google SRE book emphasizes the value of blameless postmortems with clear timelines, contributing factors, and follow-up actions. The reason is not moral; it is operational. If incident learning remains trapped in chat transcripts and fragmented memory, reliability work stalls. Teams repeat avoidable failures because the learning never hardens into a reusable artifact.
You can see the same pattern in public engineering writing from Cloudflare and Shopify after major operational events: the artifact that matters is the postmortem, not the live chat that happened during mitigation. The chat helped resolve the event. The document helps the company avoid repeating it.
That is the distinction most teams miss.
Slack is where work gets unstuck. Documentation is where the company gets smarter.
04 THE FRAMEWORK
What works is a documentation operating system: explicit rules for when information stays conversational and when it must become durable.
Not “encourage docs.”
Not “be more async.”
A real operating system.
Here is the version that works in engineering orgs from roughly 20 to 200 people.
1. Define your systems of record by work type
You need a small, opinionated map for where information lives. If you do not define this, Slack becomes the default record.
A practical version:
- Decisions → ADR/RFC repo, Notion decision log, or Confluence architecture space
- Execution state → Linear, Jira, or GitHub Issues
- Code and implementation discussion → GitHub PRs and issues
- Operational incidents → incident tool plus postmortem archive
- Runbooks → docs repo or internal wiki with owner metadata
- Product specs → one product doc system, linked to tickets and release notes
- Ephemeral coordination → Slack
The rule is simple: Slack can initiate, clarify, or escalate. It cannot be the final resting place for important decisions.
Cloudflare’s engineering teams have written extensively about operational rigor around incidents, runbooks, and post-incident analysis. The broader lesson is durable: reliability depends on separating fast coordination from authoritative records.
If you want one sentence employees can memorize, use this:
Chat is for momentum. Docs are for memory.2. Create promotion rules: when chat must become a document
This is the core mechanism.
A conversation should be “promoted” out of Slack when it crosses any of these thresholds:
- Decision affects more than one team
- Decision changes architecture, security posture, cost profile, or customer behavior
- Work will last longer than one sprint
- The decision will matter during onboarding, incident response, or audit
- Disagreement persists beyond one business day in Slack
- The same question gets asked twice in 30 days
Those thresholds are concrete enough to use and broad enough to catch most high-value cases.
A lot of documentation cultures fail because they require judgment in the abstract. Do not tell people “document important things.” Tell them exactly when a thread graduates into an artifact.
An example:
A Slack thread starts with “Should we route model inference through the API gateway or let background workers call the model provider directly?”
That stays in Slack for initial triage.
The moment it becomes clear the answer affects latency, observability, rate limiting, and provider failover, it is no longer a chat problem. It becomes a design record with:
- decision owner
- options considered
- expected latency impact
- failure modes
- rollback path
- review deadline
That move is what async-first actually looks like in practice.
3. Standardize a minimal decision doc format
Most teams overcomplicate docs. They copy Amazon-style six-pagers or heavyweight RFC templates and create resistance.
Use the smallest structure that preserves decision quality.
A high-functioning template usually includes:
- Context
- Decision
- Alternatives considered
- Tradeoffs
- Impact
- Owner
- Reviewers
- Revisit date
- Links
That is enough.
What matters is not literary quality. It is reconstructability.
Figma’s engineering organization has publicly shared work on scaling product development and technical systems with clear interfaces between teams. The common pattern in companies like Figma, Stripe, and GitHub is that written artifacts reduce ambiguity at those interfaces. The document is less about perfection than about making dependencies visible before they hurt you.
4. Put time bounds on async review
One reason teams fall back to meetings is that “async review” becomes unbounded waiting.
That is not async-first. That is stalled execution.
Set explicit review SLAs by document type:
- Minor technical decision: 24 business hours
- Cross-team architectural change: 3 business days
- Security or compliance-impacting change: 2 business days with named approvers
- Product spec affecting customer workflow: 3–5 business days
If the SLA expires without feedback, the owner can proceed or escalate based on pre-defined rules.
This matters more than most leaders realize. Without response-time norms, written cultures decay into uncertainty and people revert to meetings because meetings at least force closure.
There is a useful parallel in DORA’s work. The Accelerate research by Nicole Forsgren, Jez Humble, and Gene Kim found that high-performing software organizations optimize for fast flow and fast feedback, not just output volume. Async documentation supports that only if feedback loops are time-boxed. Otherwise docs become delay machines.
The metric to watch:
- Median decision review time
- P90 decision review time
- Percent of decisions resolved within SLA
If your P90 is above 5 business days for normal cross-functional decisions, your async system is likely introducing drag.
5. Tie docs to execution artifacts
This is where most internal wikis fail: they become detached from the work.
Every meaningful doc should link outward to execution, and execution should link back to the decision.
Minimum standard:
- RFC links to ticket epic
- Epic links to RFC
- PR links to implementation ticket
- Incident postmortem links to follow-up work
- Runbook links to dashboards and alerts
- Release notes link to spec or design rationale
GitHub’s platform is powerful because the work graph is connected. Code review, issues, discussions, and history are all linked. You do not need to reproduce GitHub internally, but you do need the same property: navigability between intent, implementation, and outcome.
If an engineer cannot start from a production alert and find the relevant runbook, the original implementation decision, and the current owner in under five minutes, your documentation system is underdesigned.
Five minutes is a good internal benchmark. Longer than that, and people stop trusting the system.
6. Assign owners and decay policies
Unowned documentation rots faster than code.
This is not metaphorical. It is a predictable maintenance problem.
Every durable doc needs:
- owner
- last reviewed date
- next review date
- status: draft, active, deprecated, superseded
Without this metadata, teams cannot distinguish “still true” from “historically interesting.”
HashiCorp and GitHub have both cultivated strong docs cultures around product and engineering surfaces, and one consistent pattern in high-signal documentation systems is explicit stewardship. Information without ownership becomes folklore.
A practical decay policy:
- Runbooks: review every 90 days
- Service ownership docs: review every 90 days
- Architecture decisions: revisit at 6 or 12 months depending on volatility
- Onboarding docs: review every quarter
- Incident response procedures: review after every Sev 1 or Sev 2 event
This sounds bureaucratic until you compare it with the cost of stale docs during incidents. Then it looks cheap.
7. Instrument documentation like an operational system
If you cannot measure your documentation system, you will manage it through anecdotes.
Track a small set of metrics:
- Decision-to-doc rate
- Doc retrieval success
- Staleness rate
- Repeat-question rate
- Meeting substitution rate
- Incident learnability
This is where leaders often get squeamish because the metrics feel indirect. Use them anyway.
DORA’s four key metrics—deployment frequency, lead time for changes, change failure rate, and time to restore service—do not mention documentation directly. But documentation quality clearly affects lead time, change failure rate, and time to restore service. The relationship is practical, not theoretical. Poor decision records increase rework. Weak runbooks slow restoration. Missing context drives more coordination overhead per change.
In AI-first startups, add one more metric:
- Prompt/model policy traceability
This becomes crucial once customer escalations, eval regressions, or compliance questions start arriving.
8. Reserve synchronous time for the right failure modes
Async-first does not mean async-only.
This is where mature teams are much more disciplined than dogmatic.
Use synchronous discussion when:
- there is active conflict that text is making worse
- the issue is materially ambiguous and rapid iteration will reduce risk
- incident mitigation requires tight coordination
- a decision has multiple stakeholders and the cost of delay exceeds the cost of a meeting
But even then, the rule stays the same: meet live, decide live if needed, document immediately after. A 30-minute architecture review that ends with no written decision is expensive theater.
Netflix’s engineering culture has long emphasized context over control. That principle only works if the context is available. Sometimes live discussion is the fastest way to generate that context. Documentation is what makes it portable.
The tradeoff here is real:
- More docs increase clarity but can slow local action
- Less documentation increases speed in the moment but raises rework and dependency risk later
At 20 people, you can get away with more conversational memory. At 80 people, memory starts to fragment by team. At 150 people, undocumented decisions become operating risk.
The threshold is not magical, but the pattern is consistent.
9. Make leadership communicate in writing first
This is the highest-leverage move.
If the CTO, VP Engineering, and staff engineers do not write, nobody else will sustain a writing culture.
Leadership should default to written artifacts for:
- strategy changes
- architecture direction
- org interface decisions
- exception approvals
- incident learning
- roadmap tradeoffs
Patrick Collison has spoken publicly about the importance of clear writing at Stripe, and you can see the organizational effect in how Stripe engineers discuss systems, API design, and product constraints in public writing. Clear writing is not decoration there. It is part of how rigor is enforced.
If executives use Slack for “real” decisions and docs for announcement theater, the system fails.
If executives write first, teams learn that the written record is where serious work happens.
10. Design for new joiners, not incumbents
The best test of an async-first documentation system is whether it works for someone who was not there.
Incumbents always underestimate this problem because they silently fill in missing context from memory. New joiners cannot.
A robust system lets a new staff engineer answer these in week three:
- Why does this service exist?
- What are its SLOs?
- What are the known failure modes?
- Which architectural constraints are intentional versus accidental?
- Where do I find the last incident review?
- Which decisions are still under evaluation?
If those answers require three DMs and a call with the tech lead, your system is not async-first.
The Google SRE book treats documentation and operational readiness as first-class because reliability depends on transferability. Knowledge that cannot transfer is not operational knowledge.
That principle applies equally to product architecture, AI systems, platform choices, and go-to-market interfaces.
05 STRATEGIC TAKEAWAY
Documentation is not support work for async-first; it is the control plane. A CTO deciding this quarter whether to scale from 40 to 120 engineers, add a second office, or push more cross-functional product bets should assume undocumented decisions will slow execution before headcount does. The cost does not show up as one catastrophic event. It shows up as rising lead time, duplicated work, noisier incidents, slower onboarding, and more management bandwidth spent translating context between people. If you build the documentation operating system early, you preserve speed as coordination complexity rises. If you do not, Slack becomes the unofficial architecture of your company.
06 IMPLEMENTATION ANGLE
Start with one narrow slice, not a company-wide manifesto.
Pick three high-leverage artifacts: architecture decisions, incident postmortems, and runbooks. Define one template for each, one storage location for each, and one promotion rule from Slack into each. Then make linking mandatory between docs, tickets, and code. In 30 days, you will know whether the issue is tooling or discipline. In most orgs, it is discipline.
The fastest rollout pattern is:
- define systems of record,
- define promotion thresholds,
- set review SLAs,
- assign owners,
- instrument staleness and retrieval.
If you are using Linear, GitHub, Notion, and Slack, that is already enough tooling for most 20–200 person companies. The missing layer is operating rules. related topic
If the company is growing quickly and engineering managers are spending too much time translating context across teams, this is often where org-scaling support becomes useful. Amplify helps engineering teams scale, but the prerequisite is still internal clarity: no external partner can compensate for a company that makes real decisions in Slack and forgets to preserve them.
