Further Reading — Chapter 23: Collaborative Writing

Annotated, Tier 1 and Tier 2 sources only. Tier 1 = landmark works you can rely on; Tier 2 = real, widely-attributed ideas and tools without a single pinned citation.

Tier 1 — Foundational and verifiable

William Strunk Jr. and E. B. White, The Elements of Style. The shared baseline every collaborator should write toward. When a team's style guide says "be concise, prefer the active voice, omit needless words," it is usually pointing here. Adopting a common reference is the first step to a consistent house voice.

Joseph M. Williams, Style: Lessons in Clarity and Grace. The deepest treatment of why prose reads as cohesive — the old-to-new flow and the principles of a unified voice. Indispensable for the integration pass in §23.5: it gives you the vocabulary to explain why one author's section jars against another's, not just that it does.

The major institutional style guides — The Chicago Manual of Style, the Microsoft Writing Style Guide, and the Google Developer Documentation Style Guide. These are the bases most teams adopt before adding a short house layer (§23.4). Chicago is the broad editorial standard; the Microsoft and Google guides are written specifically for technical and software documentation and are freely available online. Read the introduction of any one to see how a real style guide is organized — and how short the rules you actually use turn out to be.

Pro Git (Chacon & Straub), the official Git book (free online). The reference for the "git for docs" model in §23.3. The chapters on branching, pull requests, and resolving merge conflicts explain exactly why a semantic conflict must be resolved by a human — the principle behind §23.3's "Why Does This Work?" The docs-as-code movement is built on this workflow.

Tier 2 — Widely-attributed ideas and working tools

The "single-threaded owner" idea, from modern engineering-organization practice. The principle that one named person must be accountable for an outcome — and that a thing owned by everyone is owned by no one — is widely attributed to how large technology organizations structure ownership. The label varies (single-threaded owner, DRI — "directly responsible individual"); the idea is the load-bearing one in §23.2.

RACI, from project-management practice. The Responsible / Accountable / Consulted / Informed matrix is a standard, widely-taught tool for clarifying who does the work, who owns the outcome, who advises, and who is merely told. §23.6 uses only its discipline — separating reviewers (Consulted) from approvers (Accountable) — not its full apparatus.

The Diátaxis documentation framework (diataxis.fr). Not about collaboration directly, but essential downstream: when a team writes documentation together, agreeing what kind of document each piece is (tutorial, how-to, reference, explanation) prevents one of the structural seams from §23.1. Previewed here, treated fully in Chapter 26.

Tool documentation: Google Docs version history, Microsoft Word track changes, and the Confluence/Notion help guides. The most practical "further reading" for §23.3 and §23.8 is the official help page for whichever tool your team uses. Learn your tool's version history, suggesting/track-changes mode, and comment-resolution features deliberately — most collaborative-writing pain comes from people who never learned the safety nets their own tool already provides.