At five people in one office, communication is easy. Walk across the room and ask. At twenty-eight people across three timezones, the same approach doesn’t just stop working, it starts actively hurting. The fix isn’t better video calls; it’s learning to write things down first and talk about them second.
The standup problem
The daily standup starts as a five-minute conversation at 9am in the head-office room. Five people standing in a circle, quick updates, done by 9:05. It works beautifully. One room, one timezone, no friction.
Then a second city opens. The standup becomes a video call. 9am head-office is 11am for the satellite: awkward but workable.
Then a third city. Now the standup is a fifteen-minute ordeal. Someone’s microphone echoes. The person joining from a remote farm on speakerphone is inaudible half the time. The head-office team can hear each other fine because they’re in the same room, but the other cities hear a room full of people talking over each other. The remote participants wait for pauses that never come. The meeting runs over because half the updates have to be repeated.
(For Australian teams the timezone arithmetic is its own special chaos. Queensland doesn’t observe daylight saving. The gap between Perth and the eastern cities shifts in October and shifts back in April, and every year someone forgets which direction it goes.)
The standup is the most visible symptom, but the real problem is deeper. The team built all of its communication practices for co-location, and none of them survived the expansion to multiple cities.
The hallway conversation problem
Standups are the scheduled problem. Hallway conversations are the unscheduled one.
In the head-office, decisions happen in the kitchen. The founder mentions something to a developer while making coffee. The developer clarifies an architecture question with a designer at the printer. Operations catches the founder on the way out the door with a supplier issue. Quick, efficient, human, and completely invisible to the other cities.
The remote teams start noticing decisions that seem to appear from nowhere. “When did we decide to change the delivery window?” someone asks in the cross-team sync. “Oh, we talked about it yesterday,” the head-office reply goes. “We forgot to post it.”
This is the single most corrosive pattern in distributed teams: decisions that happen in hallway conversations between co-located people, with remote team members learning about them after the fact. It doesn’t feel like exclusion from the head-office end; it feels like efficiency. A two-minute chat solves the problem. Why schedule a meeting?
But from the satellite, it feels exactly like exclusion. You’re not part of the conversations that shape the product. You find out what was decided, not why. You can’t challenge a decision you weren’t present for without sounding like you’re second-guessing people.
The most useful thing a coach can do for a distributed team is name this in a cross-team retro: “How many decisions were made in a hallway at head-office this week that the other cities don’t know about?” The honest answer is usually “I don’t know; we don’t track them.” That’s the problem.
Written first
The fix isn’t to eliminate hallway conversations. People will talk to each other. That’s good. The fix is to change what happens after the conversation.
The principle: written first. Any decision that affects more than one person gets written down before it’s final. Not after. Before.
The practice: if you have a hallway conversation and reach a decision, post the decision in the relevant Slack channel as a proposal before acting on it. “We discussed moving the Wednesday delivery window to Thursday to avoid the courier bottleneck. Planning to do this from next week. Thoughts?”
The proposal sits for a reasonable period: usually a day for routine decisions, a few days for anything significant. People in other cities read it, ask questions, raise concerns. If nobody objects, it becomes a decision. If someone objects, the conversation continues, in writing, where everyone can follow it.
This sounds like bureaucracy. It isn’t. A three-sentence Slack post takes thirty seconds to write. The alternative, a decision that the satellite city discovers a week later and has to reverse because it breaks their schedule, takes days to untangle.
Writing isn’t overhead; writing is thinking. If you can’t articulate a decision in three sentences in a Slack channel, you probably haven’t thought it through well enough to act on it. The act of writing forces clarity. Or, more bluntly: if you can’t write it down, you don’t understand it well enough to decide.
Async standups
The synchronous standup died a natural death once the written-first principle took hold. In its place: async standups in a dedicated Slack channel.
Each morning, by their local 9:30am, every team member posts three things:
- What I did yesterday
- What I’m doing today
- What’s blocking me
No call. No video. No scheduling. Each person writes when it suits their morning. Perth posts at 9:30 AWST. Brisbane posts at 9:30 AEST. Melbourne posts at 9:30 AEDT. Everyone reads everyone else’s updates when they have a moment.
The blockers section is the critical one. If someone posts a blocker, the relevant person can respond in the thread immediately, or flag it for the daily sync window. Most blockers got resolved in Slack threads faster than they would have in a standup call, because the person who could help didn’t have to wait for the meeting to hear about the problem.
There are adjustment pains. Some people write too much: paragraph-length updates that nobody reads. Some write too little: “Coding. Same as yesterday. No blockers.” The sweet spot: enough detail that someone in another city understands what you’re working on without needing to ask, short enough that people actually read it.
The async standup also surfaces patterns that the synchronous standup hides. When updates are written, anyone can scan a week of history and spot trends: “This squad has posted blockers related to the staging environment four days this week. That’s a systemic problem, not four individual blockers.”
The information asymmetry
The hallway conversation problem is really an information asymmetry problem. And it’s worth being specific about what that asymmetry costs, because it’s not just hurt feelings.
When the head-office makes a decision that a satellite discovers three days later, three things happen.
First, the satellite’s work might be invalidated. If a remote squad has been building a feature based on the old constraint, and the head-office changes the constraint without telling them, the feature needs reworking. That’s wasted effort: not massive, but compounding across dozens of undocumented decisions per week.
Second, the satellite’s trust erodes. Every “oh, we forgot to tell you” reinforces the feeling that the real company is at head-office and everywhere else is a satellite. People start checking out of cross-team initiatives because they don’t believe they’ll be included in the decisions that matter. This is how distributed teams fracture: not through conflict, but through disengagement.
Third, the decision quality suffers. The head-office hallway conversation includes head-office context. The remote city’s context, their suppliers, their relationships, their customer patterns, isn’t in the room. The decision might be wrong for them, but nobody in the hallway knows that because nobody from there was asked.
Written-first doesn’t just solve a communication problem; it solves a decision quality problem. When you write a proposal in a channel that all cities can see, you get input from all cities. The decisions get better because the information is more complete.
The two-hour window
Three Australian cities span Perth (UTC+8), Brisbane (UTC+10, no daylight saving ever), and Melbourne (UTC+11 in summer, UTC+10 in winter). The overlap window (when all three cities are within normal working hours) is roughly 11am-1pm Perth time. Two hours. Some days less, depending on who starts early or leaves at 3pm for school pickup.
That two-hour window has to be sacred. Establish a rule: the overlap window is for synchronous collaboration that needs all cities. Everything else happens async.
The practical effect: meetings that require cross-city participation, sprint planning, cross-team syncs, important decision discussions, happen inside the window. Outside it, each city owns its own schedule. One city can run a local retrospective at 3pm. Another can do an Example Mapping session at 9am. A third can pair-program all morning without interruption.
Protecting the window means defending it from meeting creep. When someone tries to schedule a routine status update during the overlap window, the right pushback is: “Does this meeting need all cities in real-time? If not, write it up and post it. Save the window for things that can’t be done any other way.”
Over time, the team develops a feel for what needs the window and what doesn’t. Status updates: async. Brainstorming: async (write ideas first, discuss the interesting ones in the window). Technical decisions: usually async via ADRs, with the window reserved for contentious ones. Sprint planning: synchronous, in the window. Cross-team retros: synchronous, in the window.
Documentation as communication
Written-first dovetails naturally with practices most teams already have.
ADRs are already async-friendly. A developer in one city proposes an architecture decision, writes the ADR, posts it in Slack, and collects feedback from the other cities over a few days. The decision isn’t made in a meeting; it’s made in a document that everyone can read, comment on, and refer back to.
Decision logs from alignment sessions use a decided/open format that works the same way. Decisions already made are listed with their reasoning. Open questions are listed with the information needed to close them. Anyone in any city can read the log and understand the current state without attending every meeting.
A weekly discovery cadence produces interview summaries shared in Slack channels, not presented in meetings. A product person can run a customer interview on Monday, summarise the key insights, and post them. By Tuesday, the other cities have read the summary and can incorporate the insight into their work.
This is the realisation that makes written-first click: most teams are already doing it in pockets. ADRs are written-first architecture. Example Mapping outputs are written-first specifications. Alignment-session logs are written-first strategy. The principle isn’t new; it’s extending a practice that already works into communication more broadly.
When sync IS needed
Written-first doesn’t mean never-talk. Some activities are worse in async. The team learned which ones through trial and error.
Ensemble programming requires real-time. The whole point is that the team navigates together while the LLM types. You can’t do that in a Slack thread. Schedule ensemble sessions inside the overlap window and protect them fiercely. These are sessions where shared understanding is built in real-time, and there’s no async substitute.
Event Storming also resists async. The energy of the room, the spontaneous challenges, the side conversations that surface hotspots: these depend on real-time interaction. When the team needs to Event Storm new territory, either fly people in or block a long chunk of the overlap window and accept that the remote version will be seventy percent as good.
Retrospectives need sync for the discussion phase, but the brainstorming phase works well async. Adapt the format: before the retro call, everyone writes their observations on virtual stickies (what went well, what didn’t, what to change). The async brainstorming means people have time to think rather than generating ideas on the spot. The sync discussion focuses on the interesting observations, not on generating them.
Conflict resolution needs sync. When two squads disagree about a technical direction, or when a prioritisation decision is contentious, a written thread can escalate into a long, tense exchange where tone is hard to read. A fifteen-minute video call with cameras on usually resolves what fifty Slack messages couldn’t.
The pattern: use async for information sharing, proposal review, and routine decisions. Use sync for creative collaboration, emotional conversations, and anything where misunderstanding would be expensive.
Slack: threads, channels, and DMs
The team developed conventions about how to use Slack that mattered more than anyone expected.
Channels, not DMs, for work decisions. If a decision affects the team, it belongs in a channel. DMs are for personal matters and scheduling. The moment you make a work decision in a DM, you’ve created a hallway conversation: invisible to everyone else.
Threads for depth. A top-level message in a channel is a headline: “Proposing we change the Brisbane delivery window to Wednesday.” The thread is where the discussion happens. This keeps the channel scannable. You can skim top-level messages to see what’s being discussed without drowning in replies.
Shared docs for anything longer than a paragraph. If a decision needs context, background, or analysis, write a doc and link it from Slack. Slack is for pointers and short discussions. Docs are for substance. The doc persists. The Slack thread gets buried.
Video for connection, not for decisions. A weekly social call (no agenda, cameras on, chat about weekends, kids, weather) matters for the human fabric of a distributed team. But it’s not a decision-making forum. Decisions happen in writing.
The coaching transition
The hardest part of moving to written-first is coaching the head-office team through the discomfort of losing their communication advantage.
The head-office has always been the centre. The original team is there. Moving to written-first feels, from there, like slowing down. “I could just walk over and ask” becomes “I have to write a Slack post and wait for a response.” That feels like friction.
The reframe that lands: “The friction isn’t the writing. The friction is the distance. The writing just makes the distance visible. Without written-first, the distance still exists; you just don’t notice it because the pain falls on the satellite, not on you.”
The head-office team often hasn’t realised how much of their communication advantage was someone else’s disadvantage. Once they see the pattern (head-office decides, satellite discovers) the written-first discipline feels less like overhead and more like fairness.
The hardest converts are usually the most verbal communicators: often the same people who write excellent architecture decisions and then communicate everything else by talking. The coaching point is the bridge: “You already write first for architecture. Just extend it to everything else.” Once the habit transfers, those same people often become the most rigorous written-first practitioners on the team. Their Slack proposals end up clear, concise, and well-reasoned: ADRs in miniature.
The remote retro adaptation
The retrospective format evolved through three iterations before the team found what worked.
Version 1: synchronous everything. Everyone joins a call. Facilitator asks “what went well?” People think on the spot, talk over each other, run out of time. The remote cities feel excluded because the head-office room dominates the conversation.
Version 2: async brainstorming, sync discussion. Before the retro, everyone writes observations on a shared Miro board. Three categories: went well, didn’t go well, want to change. People write whenever they have time during the day before the retro. The sync call focuses on discussing the most interesting observations, voting on action items, and agreeing on experiments for the next sprint.
This worked dramatically better. The async brainstorming gave quieter people time to think. It gave people in different timezones equal input. It meant the sync call started with a rich set of observations rather than a cold start.
Version 3: async brainstorming, async voting, sync discussion of the top three. As the team grows to multiple squads, the Miro boards get crowded. The voting step also goes async: everyone dot-votes their top three observations during the morning. The sync call discusses only the observations that got the most votes. Thirty minutes instead of sixty. Focused instead of sprawling.
The evolution is a microcosm of the whole written-first journey. Start with what you know (synchronous). Feel the pain (it doesn’t scale). Shift the generative work to async. Keep the sync time for what sync does best: discussion, connection, decision.
Meeting hygiene
Written-first changes how a team thinks about meetings. Not fewer meetings: better meetings.
Before written-first, most meetings follow a predictable pattern: someone presents information, everyone listens, a discussion happens, a decision is made (or not), and everyone leaves with slightly different recollections of what was decided. The meeting is the entire lifecycle of the idea: presentation, discussion, and decision all in one synchronous block.
After written-first, the lifecycle splits. The presentation happens in writing, before the meeting. The discussion happens partly in writing (comments, questions, async reactions) and partly in the meeting. The decision gets documented in writing, after the meeting.
Meetings get shorter because nobody is hearing the information for the first time. Everyone arrives having read the proposal or the context document. The meeting time is spent on the parts that genuinely benefit from synchronous interaction: resolving disagreements, exploring edge cases, making trade-offs that require reading the room.
A formal protocol helps: every meeting that involves a decision must have a written brief circulated at least 24 hours before. The brief includes the context, the options, and a recommendation. If you can’t write a brief, you’re not ready for the meeting. If people haven’t read the brief, postpone the meeting; there’s no point discussing something that half the room hasn’t thought about.
People sometimes call this “Amazon-style,” a reference to Amazon’s practice of writing memos instead of making slide decks. The framing is slightly different. Amazon does it for rigour. A distributed team does it for inclusion. But the effect is the same: better decisions because people think before they talk.
The onboarding benefit
An unexpected benefit of written-first communication: onboarding gets dramatically easier.
A new hire’s first day becomes reading. Not documentation: Slack channels. Three months of proposals, decisions, questions, and answers, all searchable, all in context. By day two, they understand why the delivery scheduler works the way it does, what the pricing debate has been about, and which architectural decisions are settled versus open.
In a co-located team where the original members have been together since the start, this institutional knowledge lives in memories and hallway conversations. “Why did we choose this courier?” “Oh, someone evaluated three options back in February and this one had the best cold-chain reliability.” That answer exists nowhere in writing. A new hire has to ask, and asking means interrupting someone who has to reconstruct the reasoning from memory.
A written-first team accidentally creates institutional memory. Every decision proposal, every discussion thread, every meeting brief: none of it was intended as documentation. It was intended as communication. But it persists, and that persistence becomes the onboarding resource that no wiki or handbook can match, because it captures not just the decisions but the reasoning and the debate.
What written-first costs
Written-first isn’t free. It has real costs that the team acknowledged honestly.
Speed on routine decisions. A hallway conversation takes two minutes. A Slack proposal with a one-day response window takes a day. For routine decisions, this feels slow. Mitigate it by defining categories: routine decisions (schedule tweaks, minor bug prioritisation) can use a shorter window or even a post-and-proceed approach.
Tone. Writing strips out vocal tone, facial expression, and the thousand subtle cues that prevent misunderstanding. A message that says “I disagree with this approach” reads differently from the same words spoken with a smile and a shrug. Be explicit about tone: “Not a blocker, just a thought” or “I feel strongly about this one” as prefixes that would be unnecessary in person.
Relationship building. You can’t build trust in Slack threads. Weekly social calls, occasional team gatherings, the ensemble sessions where people collaborate in real-time: these are the relationship investments that make the async communication work. Written-first is a communication strategy, not a relationship strategy.
Exclusion of different communication styles. Some people think by talking. They process ideas out loud, riffing and refining in real-time. Written-first disadvantages these people and advantages the careful, structured writers. Make sure the sync sessions (ensemble programming, retros, Event Storms) give the verbal processors space to do their best thinking.
Language barriers. A team that mixes native English speakers with people for whom English is a second or third language has a written-communication asymmetry. Written English is harder for non-native speakers: the nuance, the idiom, the tone. An async standup someone dashes off in thirty seconds takes someone else twice as long. Address it explicitly: “Clear writing isn’t about grammar; it’s about being understood. Short sentences. Simple words. If English isn’t your first language, write simply and nobody will think less of you. If it is, write simply anyway.”
The evolution
Written-first doesn’t get implemented on a Monday morning with a company-wide email. It evolves over months, unevenly, with plenty of backsliding.
Typical phases:
- Month one: the principle gets named. The head-office mostly ignores it. The satellite cities adopt it enthusiastically because it solves their specific pain. The information asymmetry starts narrowing.
- Month two: the meeting protocol kicks in. No decision in a meeting without a written brief first. No meeting outcome without a written summary after. Meeting quality improves because people arrive prepared, and outcomes persist because they’re documented.
- Month three: the holdouts convert. When the team’s most verbal, most head-office-centric communicator becomes a rigorous written-first practitioner, the culture has shifted. It’s not just a rule from the coaches. It’s how the team works.
By the fourth month, people stop calling it “written-first.” They just call it communication. The principle becomes invisible, which is the best sign that a practice has been internalised.
The principle
Written-first means writing is the default mode of communication, not the exception. Decisions, proposals, updates, and context: all written before they’re discussed, so that everyone in every timezone can participate equally.
It’s not about eliminating meetings; it’s about making sure meetings are for the things meetings do well, creative collaboration, emotional conversations, real-time problem solving, and writing handles everything else.
Most teams’ practices are already half-async before anyone names the principle. ADRs document decisions. Example Maps produce written specifications. Alignment sessions generate decision logs. The written-first principle just extends what’s already working in pockets to the whole organisation.
The team that writes things down is the team where everyone knows what’s happening, regardless of which city they sit in. The team that relies on hallway conversations is the team where head-office knows everything and the satellites find out on Monday.
The simplest framing: write it down. Not because writing is better than talking. Because writing includes the people who aren’t in the room.
The teams that make written-first work aren’t the ones with the best tools or the most disciplined processes. They’re the ones where someone, usually a coach, sometimes a team lead, occasionally just a person who’s been the remote one and remembers how it felt, keeps asking: “Who doesn’t know about this yet? How will they find out?”
That question, asked consistently, is the difference between a distributed team that works and one that slowly splits into headquarters and satellites. The writing is just the mechanism. The principle is inclusion.
Related references
- Architecture Decision Records, the original written-first practice
- The Alignment Session, decided/open format as async-friendly documentation
- Retrospectives at Every Scale, retro formats that work async
- Ensemble Programming, the sync practice worth the timezone pain
- Two Squads, One Direction, worked example of cross-city coordination becoming painful
- The Greenbox Story: narrative behind the worked examples