Sharing Knowledge Asynchronously: Code Review, ADRs and Docs-as-Code

Mon, 20 Jul 2026 15:00:00 +0200

In the guide to collaboration modes, we set out a rule: explicit knowledge travels asynchronously. Where synchronous modes pass on intuition through contact, asynchronous modes capture what can be written down — and produce a trace that survives departures. But you still have to avoid the classic trap: documentation that no one reads and no one keeps up to date. This article details the practices that work, and why.

I. The strength and the limit of writing

Writing has an advantage no synchronous mode matches: it depends on no one. It can be read at three in the morning during an incident, six months after its author has left, by someone who wasn’t there when the decision was made. It’s the bedrock of a team’s memory.

ADR (Architecture Decision Record): documenting decisions that matter

Tue, 10 Mar 2026 11:00:00 +0100

Engineering teams spend a lot of time discussing, arbitrating, choosing… and then forgetting why they made certain decisions.
The outcome is familiar:

the same debates come back every three months,
decisions get challenged without the original context,
onboarding depends on “the people who know,”
and unnecessary migrations are born from a simple loss of memory.

An ADR (Architecture Decision Record) exists to avoid that. It’s not a “big architecture doc,” nor a requirements spec: it’s a short note that captures an important decision, with just enough context to keep it understandable and reusable.

ADR on Simple Enough Blog

Sharing Knowledge Asynchronously: Code Review, ADRs and Docs-as-Code

I. The strength and the limit of writing

ADR (Architecture Decision Record): documenting decisions that matter