Overcommunication Is a Feature: Writing More, Meeting Less

"Sorry to repeat myself, but—" is the most misplaced apology in remote work.

On a distributed team, the message you sent once was seen by maybe half its audience, understood by half of those, and remembered a week later by almost no one. The teammate in Warsaw was asleep when you posted it. The designer read it between two other pings and retained nothing. The new hire joined three days after you said it. What feels like repeating yourself is, from the receiving end, often the first time the information actually landed. Distributed teams don't fail from too much communication — they fail from single-shot communication in an environment engineered for message loss.

This post makes the full case for overcommunication as deliberate practice: why redundancy is sound engineering rather than noise, how to narrate work so it's ambiently visible, why public-by-default changes the economics of every message, the five written updates worth systematizing, and the guardrails that keep "overcommunicate" from decaying into "spam."

Redundancy is engineering, not inefficiency

Engineers already know this principle; they just don't apply it to their own messages. Every reliable system built on an unreliable channel uses redundancy: TCP retransmits packets, RAID mirrors disks, error-correcting codes add "wasted" bits precisely so the signal survives corruption. Nobody calls a checksum inefficient.

A distributed team is an unreliable channel with extraordinary loss rates. Consider what stands between your message and its audience:

• Time-zone loss. A third of the team was offline when you posted. Chat tools bury messages by recency, so by their morning, yours is forty messages deep.
• Attention loss. Studies of workplace attention consistently find knowledge workers switching contexts every few minutes. Your message was read in a six-second gap between other demands. Skimmed is not received.
• Membership loss. Teams churn. Every person who joins after an announcement effectively never heard it. On a team growing 30% a year, a third of next year's staff missed everything you said this year.
• Decay loss. Even perfectly received messages fade. A verbal decision has a memory half-life of about a week; the meeting where "everyone aligned" produces four different recollections a month later.

Against loss rates like these, sending each important message once isn't efficient — it's negligent. The redundancy toolkit maps directly from engineering: repetition over time (say it again next week), multi-channel encoding (announce in the feed, record in the wiki, mention in the check-in), durable storage (write it where search can find it), and acknowledgment (require a response for the messages that truly matter, so you detect the drops).

The mindset shift is treating communication as transmission until received, not transmission once sent. "I told them" is not a status. "They demonstrably know" is.

The asymmetry: writing is cheap, silence is expensive

The case for writing more rests on a cost asymmetry most teams never compute.

The cost of an unnecessary written update is small and bounded: two minutes to write, ten seconds per reader to skim-and-dismiss. For a ten-person team, an update nobody needed costs roughly four person-minutes. That's the entire downside.

The cost of a missing update is large and unbounded. Some illustrative math from a scenario every team will recognize: an engineer decides to change an API response format and doesn't write it up, because "it's minor." Downstream, a teammate builds against the old format (a day lost), support fields a confused customer report (an hour), and three weeks later someone re-debates the same change in a meeting because no record exists (six person-hours). One skipped two-minute post; call it two days of aggregate waste. The ratio isn't 2:1 or 5:1 — it's routinely 100:1.

This asymmetry is why "when in doubt, post it" is the correct default even though it guarantees some redundant messages. You're buying insurance where the premium is minutes and the claims are days. The teams that get this wrong optimize for the visible cost (message volume, which everyone can see and grumble about) over the invisible one (silent divergence, which surfaces weeks later disguised as a planning failure).

There's a second asymmetry stacked on the first: writing scales and talking doesn't. A spoken explanation serves the people in the room, once. A written explanation serves every future reader at zero marginal cost — including, frequently, its own author six months later. Every meeting your team runs to re-explain something is interest paid on a writing debt.

Narrating work: the garage door open

The deepest form of overcommunication isn't announcements — it's ambient narration, what some open-source communities call working with the garage door up. In an office, your work is passively visible: colleagues see the whiteboard scribbles, overhear the debugging frustration, notice the prototype on your screen. Remote, all of that visibility drops to zero unless you actively emit it. Narration is the replacement signal.

What narration looks like in practice — three real-shaped examples:

Engineer, mid-morning: "Going down a rabbit hole on the checkout latency. Ruled out the DB — query times are flat. Now suspecting the payment provider's new SDK. If I'm still stuck at lunch I'll timebox it and file a ticket."

Designer, end of day: "Two directions for the onboarding flow attached. Leaning toward B because it cuts a screen, but B makes the skip option less discoverable. Will decide tomorrow unless someone has a strong take."

PM, Friday: "Talked to three churned customers this week. All three mentioned the export limits before mentioning price. Writing it up properly Monday, but flagging now because it contradicts our pricing hypothesis."

Notice what each one does. It's short — under a minute to write. It shares state of mind, not just state of task: current hypothesis, current lean, current doubt. And each creates an interception point: the engineer's post lets a teammate reply "we hit that SDK bug last month, check the retry config" and save half a day; the designer's invites the strong take before the decision hardens; the PM's lets the pricing conversation start three days early. Narration converts your private context into the team's shared context while the information is still actionable.

How to make narration a habit

• Anchor it to existing rhythm. The easiest home is a daily async check-in — the "what I'm doing" answer becomes narration with a deadline. Teams running check-ins in Openbook get this almost free: the scheduled prompt asks, the status flags (Blocked, Help, Milestone) structure the signal, and the digest makes it readable.
• Teach the three-sentence form: what I'm on, what I've learned or decided, where I could use eyes. Anyone can produce that in ninety seconds.
• Leaders narrate first. If the manager's work is opaque, everyone else's stays opaque too. A lead posting "spent today wrestling with the budget, here's where it stands" does more to normalize narration than any policy.
• React to it. Narration into a void dies in two weeks. A reaction emoji is the minimum viable proof someone's listening; a "this saved me an hour, thanks" keeps the whole practice alive for a month.

One boundary worth stating: narration is pull-visibility offered by the worker, not surveillance demanded by the manager. The moment narrated details get used to nitpick hours or second-guess sequencing, people revert to opaque status-speak ("working on tickets") and the channel is dead. Narration survives only where it's demonstrably safe to say "today was mostly dead ends."

Public by default: killing the DM tax

Every workplace question answered in a DM is answered for an audience of one, then lost. The same answer in a public channel is answered for the team, indexed by search, and available to every future asker. Yet on most teams, the DM share of substantive communication keeps creeping up, because DMs feel safer and less noisy. This is the DM tax: the compounding knowledge loss of private-by-default habits.

The public-by-default rule: work communication goes to the most public channel that's appropriate, and privacy is the justified exception rather than the comfortable default. Legitimate exceptions are real and worth listing so the rule doesn't overreach — personal and HR matters, performance feedback, anything about a named individual, half-formed venting that needs a safe first audience, and genuine secrets (deals, security, personnel). Everything else — questions, decisions, status, plans, lessons — belongs in the open.

What changes when teams actually flip this default:

• Questions stop being repeated. The fourth person with the same staging-environment question finds the thread instead of re-interrupting the same expert. The expert's interruption load drops measurably.
• Passive learning starts. Juniors absorb how seniors think by watching public problem-solving. In DM cultures this apprenticeship never happens.
• Decisions become auditable. "Why did we choose Postgres?" has a linkable answer with the reasoning attached, not an archaeology project through three people's memories.
• Information asymmetry stops being a status game. When updates are public, "being in the loop" stops depending on being in the right private threads — which particularly benefits new hires, remote-est members, and anyone outside the informal in-group. The broader trust case is laid out in the case for transparent internal communication.

Migration is behavioral, not technical. The three moves that work: leaders redirect gently and relentlessly ("great question — ask it in #eng so the answer's findable?"), answerers answer in public even when asked in private ("posting the answer in the channel so others can find it"), and the team celebrates public asking explicitly, because the whole default collapses if public questions ever attract mockery. Expect the transition to take about six weeks of consistent redirection before it self-sustains.

The five updates worth systematizing

Ad-hoc overcommunication works; systematized overcommunication compounds. These five written updates cover most of what distributed teams need, each with a minimal template so writing one takes minutes.

Update	Cadence	Length	Template skeleton
Daily narration	Daily	3 sentences	Doing / learned / need eyes on
Weekly team status	Weekly	Half page	Shipped / in progress / blocked / next week / risks
Decision record	Per decision	5–10 lines	Decision / context / options rejected / owner / date
Shipped announcement	Per release	4 lines	What / who it affects / what to do / where to ask
TIL (today I learned)	Ad hoc	2–5 lines	Gotcha found / cost of finding it / how to avoid

Two of these deserve emphasis. Decision records are the highest-value writing a team does per word — ten lines that prevent entire re-litigation meetings. The discipline is writing them at decision time, in a durable home (wiki or docs, not chat), and linking them whenever the topic resurfaces. Weekly statuses work best as structured standing questions rather than freeform prose, so readers can scan the same shape every week; teams that run these in a dedicated status room with goal RAG states get an audit trail of the project's whole history for free. We've detailed that format in project status reports people actually read.

The durable-home point generalizes: overcommunication without durable storage is just louder ephemerality. Chat is where information flows; docs and wikis are where it lives. Every important message should end up — or at least be linked from — somewhere that search will find in six months. That storage layer is the documentation culture covered in why documentation is the backbone of remote work.

Leaders: say it seven times, then twice more

Everything above applies double to anyone communicating strategy, priorities, or change. The communication-industry folk rule that a message must be repeated seven times before it sticks is directionally right even if the number is folklore: leaders reliably overestimate how thoroughly they've communicated, because they've heard the message in every draft and every meeting. The team heard it once, partially, while doing something else.

The practical discipline for leaders:

1. Repeat across formats, not just occasions. The quarterly priority shows up in the all-hands, the written follow-up, the next three weekly updates, and the criteria used to answer roadmap questions. Different encodings reach different people.
2. Vary the words, keep the message. Verbatim repetition reads as nagging; re-derivation ("here's this week's decision, and notice it follows from the priority") reads as coherence.
3. Watch for the boredom threshold. The reliable heuristic: when you are thoroughly sick of saying it, the organization is roughly beginning to hear it. Stopping at your own boredom point is the most common leader communication failure.
4. Close the loop. Redundancy without acknowledgment can't detect drops. Ask people to play the priority back in their own words — in 1:1s, in planning docs — and treat mangled playback as your transmission failure, not their listening failure.

Guardrails: overcommunication is not noise

The obvious objection: doesn't all this writing drown people? Only if you confuse more signal with more interruption. The two are separable, and the guardrails below are the separation.

Volume goes up, urgency goes down. The overcommunicating team sends more messages and pings people less, because almost everything is posted FYI-style with no response expected. Narration, statuses, TILs, decision records — none of them should trigger a notification that demands attention now. Urgency stays reserved for the genuinely urgent, which is what makes it credible. Routing rules for this are the subject of our async vs sync decision framework.

Structure is what makes volume skimmable. Fifty freeform paragraphs a day is noise; fifty updates in known shapes and known places is a newspaper. Templates, consistent channels, clear titles ("DECISION: retiring the v1 API on May 1" beats "some API thoughts") let readers process high volume in minutes. Findability does the rest — a workspace with real global search turns every past update into an asset instead of scroll-past debris; this is where having feeds, check-ins, docs, and decisions in one searchable place, as in Openbook, quietly pays for the whole practice.

Overcommunicate conclusions, not everything. The rule is "write more of what others need," not "stream your consciousness." A message that makes the reader do the summarizing has outsourced the sender's job. Narrate state and decisions; spare the team the play-by-play of every tab you opened.

Watch the read side. If people report they can't keep up, the fix is almost never "write less" — it's tighter templates, better titles, fewer channels, digests for the low-priority streams. Prune the structure before you prune the signal.

The four objections you will hear, answered

Rolling this out means arguing with reasonable skeptics. These are the four objections that come up on nearly every team, and the answers that actually hold.

"I don't have time to write all this"

Run the person's own numbers with them. Daily narration: three sentences, ninety seconds. Weekly status from a template: ten minutes. A decision record: five. Total: under twenty-five minutes a week. Then count the other side of their ledger: one status meeting skipped (45 minutes), one "wait, what did we decide?" conversation avoided (15), one interruption prevented because the answer was findable (10, plus the refocus cost). The writing pays for itself inside the first week, and the person making this objection is usually the one whose knowledge is most bottlenecked behind their calendar — meaning they capture the most interruption-relief of anyone.

"Nobody reads my updates"

Half the time this is a formatting problem, not an audience problem: no consistent title, no consistent home, key point buried in paragraph three. Fix the shape before concluding nobody cares. The other half of the time it's true and still fine — updates are partly insurance, and insurance you didn't claim isn't waste. The status nobody read this week is the record that settles a dispute in month three and onboards a hire in month six. That said, zero engagement forever is data: check whether you're writing what the team needs or what's easy to emit.

"This feels performative"

It becomes performative exactly when narration gets read as self-promotion or, worse, gets scored. Two protections: normalize narrating failures and dead ends with the same weight as wins (a lead posting "today was three hours down a wrong path" inoculates the whole channel), and keep narration out of performance evaluation entirely. The content being useful to teammates — interceptable, learnable-from — is what separates narration from broadcasting; hold updates to that standard and the performance anxiety fades.

"Our senior people won't do it"

Then it will fail, so solve this first, not last. Seniors hold the most context, so their silence is the most expensive on the team — and their participation is the permission structure for everyone else's. The effective pitch to a reluctant senior is selfish, not civic: every question your narration pre-answers is an interruption you don't get, and every decision you record is a meeting you're not dragged back into. One senior engineer's TIL habit typically does more for the rollout than any manager announcement.

A four-week rollout

• Week 1 — Model it. Leads start daily narration and a written weekly status. No mandate yet; just visible practice and visible reactions to anyone who joins in.
• Week 2 — Systematize two updates. Launch the weekly status template and decision records. Put both in durable homes, not chat. Write the first three decision records yourself to set the bar.
• Week 3 — Flip the public default. Announce the norm, list the legitimate privacy exceptions, and start the gentle-redirect habit on DM'd questions.
• Week 4 — Cut a meeting. Pick one recurring status or FYI meeting and replace it with the written version that now demonstrably works. This is the payoff that makes the writing feel like a trade rather than a tax — and it's the argument you'll need for the skeptics.

Then hold the line for a quarter. The practices are simple; the compounding is where the value is — a searchable record of decisions, a team that intercepts each other's mistakes early, new hires who onboard from the archive, and a calendar with visibly fewer meetings on it.

If you're assembling the infrastructure for this — feeds for announcements, check-in rooms for narration, status rooms with standing questions, wikis for the durable layer, all under one search — Openbook's free plan includes every room type mentioned in this post. Start writing more; the meetings will thin out on their own.