intermediate 2 min answer

Why does written architectural communication outperform meetings in a distributed engineering organisation, and what makes a document worth reading?

writingasyncdocumentsclaritygithubconceptual
Show the full answer Hide the answer

Why writing outperforms meetings

It scales across time zones, it survives the participants, and it forces the author to think.

A meeting reaches the people present, at one moment, and produces a shared memory that diverges immediately. A document reaches everyone who needs it, whenever they need it, and can be corrected when it is wrong.

The underrated benefit is the second one: writing exposes gaps that speech conceals. An argument that sounds coherent aloud frequently falls apart when written, because prose forces the sequence and the connections to be explicit. Many architectural problems are discovered in the act of writing them up.

For distributed organisations, written-first is not a preference but a requirement — a decision made in a meeting excludes everyone who was asleep.

What makes a document worth reading

1. The conclusion first. What is being proposed or decided, in the first paragraph. Readers should not have to reach page four to learn what the document is for.

2. Written for a specific reader with a specific decision. A document trying to serve executives, engineers and reviewers serves none of them.

3. Ruthlessly shorter than the author wants. The instinct to include everything known is the most common failure. A one-page document that is read beats a ten-page document that is skimmed.

4. Claims with evidence attached. "This will not scale" is an opinion; "at current growth we exceed the primary's write ceiling in seven months, here is the measurement" is an argument.

5. Trade-offs stated. A document presenting only benefits is discounted by experienced readers, and rightly.

6. Open questions marked. Distinguishing what is decided from what is not prevents the reader from assuming a settled position that does not exist.

The practices that make it work

  • Documents in version control alongside the code, reviewed like code, so they are updated when the thing they describe changes.
  • A comment period with a deadline, so asynchronous review does not become indefinite.
  • An owner and a status — draft, accepted, superseded — so readers know what they are looking at.
  • Linked from the components they describe, so the reasoning is encountered where it is needed.

The failure to avoid

Writing after the decision, as a record. The value of writing is largely in the thinking it forces, and a document produced after the fact captures a conclusion without the reasoning that would have improved it.