Exercises — Chapter 23: Collaborative Writing

These exercises require you to produce or revise text, not just recognize good practice. Collaborative writing is learned by collaborating — and by doing the integration and reconciliation work that solo writing never demands. Difficulty is marked ⭐ (warm-up) to ⭐⭐⭐⭐ (extension). Where a task is open-ended, a self-assessment rubric follows instead of a single answer.

Part A — Analyze This ⭐

Diagnose what's working or broken. Name the specific failure.

A1. Read this seam between two authors' sections of a project report. Name every Frankenstein failure you can find (voice, terminology, structure, contradiction, redundancy):

…and the rollout will be complete by the end of Q2.

Our valued users have responded positively to the beta. The team is, on balance, reasonably confident that the application will meet the performance targets that have been established, although it would be prudent to conduct additional validation prior to general availability. We are very proud of the work.

TL;DR: GA is set for June 30. Beta users love it (NPS 62) and the app blew past our latency targets in staging. Ship it.

A2. A team lead writes: "Everyone's section is in, so the doc is basically done — I'll paste them together and send it this afternoon." What is wrong with this claim? What work actually remains?

A3. Below are three sentences stating the same fact, written by three authors with no style guide. List every inconsistency:

• "The user can export up to ten reports per day from the platform."
• "Customers may download as many as 10 reports daily using the app."
• "End users are permitted to generate ten (10) report exports each day within the system."

A4. A document goes out for review like this: "Hi all twelve of you — please review the attached 30-page draft and send me your thoughts whenever you get a chance!" Identify three things wrong with this review request, drawing on §23.6.

A5. Two reviewers leave opposite notes on the same paragraph. The owner edits it to read: "We strongly recommend the team tentatively consider possibly migrating, which may or may not be beneficial." What went wrong in the owner's process, and what's the name for this failure?

A6. A team chooses to write a 40-page external proposal — co-authored by a salesperson, an engineer, and a lawyer — in a git repository, using Markdown and pull requests, because the engineer prefers it. Evaluate this tool choice using §23.3 and §23.8.

A7. ⭐⭐ Here is an integrated paragraph that an owner produced from three sources. Does it succeed as "one voice"? If not, where can you still hear a seam?

"The migration is on schedule. The user base has grown a lot and we're stoked about the traction. Pursuant to the foregoing analysis, it is anticipated that the platform shall accommodate projected load, subject to further testing. Anyway, we think we're good for launch."

Part B — Revise This ⭐⭐

Rewrite the weak text. You're given the scenario, not the answer.

B1. Unify the voice. Rewrite the A1 passage as a single integrated paragraph in one consistent voice — confident about what's known, honest about what's pending, no morale filler, one term for the person and one for the product. (This is the §23.5 integration move applied; keep every real fact.)

B2. Enforce the style guide. Using the rule "customer; the platform; spell out numbers under 10; plain verbs," rewrite all three A3 sentences as one consistent sentence.

B3. Fix the review request. Rewrite the A4 review request so it separates reviewers from approvers, sets a deadline and a default, and specifies the version-control mechanism. Invent reasonable details (names, dates).

B4. Reconcile the mush. The A5 paragraph tried to obey two opposite notes (Reviewer 3: "too aggressive"; Reviewer 4: "too weak") and became incoherent. The document is a decision memo for an action-oriented VP who asked for a clear call. Rewrite the recommendation as one clean sentence, and write a two-line decision log explaining your choice and how you honored the losing reviewer's underlying concern.

B5. Vague kickoff → integration-ready kickoff. Rewrite this kickoff message so it names an owner, divides by section with single accountable authors, sequences the shared parts last, pre-decides the key term and a key fact, and schedules integration and sign-off:

"Let's all jump in on the security review doc. I'll make a doc, everyone add your bits by Friday. Whoever knows networking do that part. We'll tidy it up at the end."

B6. Trim the style guide. A teammate proposes a 30-page style guide as the team standard and the documents are still inconsistent. Write the one-page working version: list the section headings it should contain and one example rule under each.

Part C — Write This ⭐⭐–⭐⭐⭐

Produce the document. A scenario, then you write.

C1. Harmonize three mismatched sections into one voice. ⭐⭐⭐ (The chapter's anchor task — do this one carefully.) Three authors contributed sections to a one-page recommendation memo on whether to adopt a new analytics tool. Their raw sections are below. Your job: produce a single, integrated, one-voice memo (roughly 200–300 words) that runs all five integration moves from §23.5 — unify voice, unify terminology, smooth seams, hunt contradictions, cut redundancy. Then, beneath your memo, write a short note (4–6 bullets) listing exactly which Frankenstein failures you fixed and where.

Author 1 (engineer): "We did a technical eval of Metrica over three weeks. It connects to our warehouse fine. Query performance is good — sub-second on our standard dashboards. One concern: the API rate limits are tight, 100 calls/min, which could bite us at scale. Otherwise solid."

Author 2 (analyst, over-hedged): "The platform appears to offer a reasonably comprehensive suite of capabilities that may potentially address a number of the analytical requirements that our stakeholders have articulated, although it should perhaps be noted that a more thorough evaluation might be advisable before any firm conclusions are reached. The user experience seems generally acceptable. Our team did considerable work assessing it."

Author 3 (manager, breezy + a contradiction): "Bottom line: let's buy Metrica. It's fast, the team likes it, and it does everything we need. No real downsides. We can roll it out next month. Price is $40K/yr which is totally worth it."

⚠️ Note the planted issues: three names for the tool/product, a swing from fog to breezy, a contradiction (Author 1 flags a real concern — rate limits; Author 3 says "no real downsides"), redundant filler ("did considerable work"), and an uncalibrated certainty gap. A good integration keeps the rate-limit concern, reconciles it with the recommendation, and lands on one calibrated voice.

C2. Reconcile conflicting reviewer feedback. ⭐⭐⭐ (The second required task.) You own a 2-page recommendation memo. Five reviewers return the comments below — and several conflict. Write a decision log (a short table or list) that, for each conflict, (a) classifies it as a conflict of fact, judgment, or authority; (b) states your decision; (c) gives the one-line reason (by evidence, by audience/purpose, or by role); and (d) where you decline a note, says how you honored its underlying concern another way. The document's audience: a decision-oriented director who explicitly asked for a clear recommendation, not options.

• Reviewer 1 (Marketing): "The intro is too long — cut it in half."
• Reviewer 2 (Product): "The intro needs more background; I didn't have enough context."
• Reviewer 3 (Sales): "Make the recommendation softer — it feels too aggressive."
• Reviewer 4 (the Director, your approver): "Make the recommendation clearer and stronger — I want a decision."
• Reviewer 5 (Legal, your approver for risk wording): "The phrase 'guaranteed savings' on page 2 must be removed — we can't make that claim."
• Reviewer 1 again: "Page 2 says we save \$200K; page 1 says \$250K. Which is it?"
• Reviewer 3: "I love the word 'transformative' in paragraph 2."
• Reviewer 5: "Delete 'transformative' — it overstates and creates expectations."

C3. Write a one-page style guide. ⭐⭐ Your team is starting a set of internal runbooks maintained by six engineers. Write a one-page house style guide for the project: include terminology (3–4 canonical terms with rejected alternatives), voice/register (1–2 sentences), person and tense, three mechanics rules (Oxford comma, numbers, dates), and three key facts an author would need to keep consistent.

C4. Draft a division-of-labor kickoff. ⭐⭐ You're kicking off a 20-page incident postmortem with four contributors (on-call engineer, SRE, product owner, support lead). Write the kickoff message: name the owner, assign sections, sequence the shared parts, pre-decide the canonical terms and the incident timeline format, and schedule integration, review, and sign-off.

Part D — Synthesis & Critical Thinking ⭐⭐⭐

Cross-chapter integration; find the flaw; translate.

D1. Map the integration pass onto the editing hierarchy (Ch 12). The §23.5 integration pass has five moves; Chapter 12's editing hierarchy has six levels. Write a short paragraph mapping each integration move to the hierarchy level(s) it corresponds to, and explain why the integration pass — like the hierarchy — must work top-down (voice/structure before sentence polish).

D2. Find the flaw. A team proudly reports: "We have a great process — every one of our eight stakeholders has full edit access and veto power, so nothing ships unless everyone agrees, guaranteeing quality." Critique this process using §23.2, §23.6, and §23.7. What will actually happen?

D3. Translate the conflict for three deciders. Two reviewers irreconcilably disagree: one wants a recommendation softened (it reads as too aggressive to a skeptical board), one wants it strengthened (it reads as too wishy-washy to an action-oriented exec). Write the one-sentence trade-off statement you'd bring to the decider — the kind that names the choice so they can decide by audience. Then write two versions of the resolved recommendation: one if the audience turns out to be the skeptical board, one if it's the action-oriented exec.

D4. Why can't a tool resolve a merge conflict? ⭐⭐⭐ Section 23.3's "Why Does This Work?" argued that git's refusal to auto-merge a semantic conflict is a feature, not a bug, and tied it to §23.7's conflicting-feedback problem. Write a paragraph (150–200 words) explaining the shared principle: why some conflicts in collaborative writing are inherently human decisions that no tool can make. Use one example each from version control and from reviewer feedback.

Part M — Mixed Practice (Interleaved) ⭐⭐–⭐⭐⭐

These mix Chapter 23 with earlier chapters. Choose the right approach for each — the chapter isn't always named.

M1. A reviewer returns your section with the comment: "This is bad, rewrite it." Two problems are tangled here. Diagnose what's wrong with the feedback itself (Chapter 12), then describe how you, as the receiver, should respond without getting defensive (Chapter 12) — and how, as the document owner, you'd weight this note against four other reviewers' more specific comments (Chapter 23).

M2. You're integrating three sections and notice the QA section hedges every sentence ("may possibly suggest," "could potentially indicate") while the eng section overstates ("this proves the system is bulletproof"). Neither is calibrated. Rewrite one sentence from each toward a calibrated middle, and name which chapter's principle you're applying (Chapter 7) and which integration move it is (Chapter 23).

M3. Your team's co-written proposal needs an executive summary. One author wrote it first, before the sections were done, and it now summarizes a plan that changed. Explain why this happened (Chapter 23, §23.2), then describe the correct sequence — and write the opening sentence of an executive summary that leads with the recommendation (Chapter 20).

M4. A collaborator sends you the "final" document as an email attachment named proposal_FINAL_v4_Maya_USE-THIS_really-final.docx, with their edits applied directly (no track changes). Name the two distinct collaborative-writing failures here (§23.3), and write the two-sentence message you'd send back to fix the process going forward.

M5. You're the document owner reconciling feedback. Reviewer A (a security engineer) flags a real factual error in the security section; Reviewer B (a marketer, louder, left 30 comments) wants the security section "punchier." How do you weight these two notes, and on what basis (§23.7)? Connect your reasoning to Chapter 2's central question.

M6. A two-person team co-writes a one-page internal note. One of them insists on a full RACI, a style guide, an approval gate, and a decision log. Is this right? Apply the §23.9 "it depends" and Chapter 12's stakes-scaling logic to decide what process this document actually needs.

Part E — Extension ⭐⭐⭐⭐

For motivated readers and the Deep Dive track.

E1. Run a real one. Find a partner and co-write a genuine 2–4 page document end to end using the chapter's lifecycle (this is the Project Checkpoint). Keep all four artifacts: the one-page style guide, the raw "before" (sections stapled together), the integrated "after," and a decision log of one conflict you resolved. Then write a 200-word reflection: which step was hardest, and what did integrating someone else's prose teach you that solo writing never did?

E2. Design a review workflow for a real team. Pick a real or realistic organization and document type (e.g., an open-source project's contributing docs, a company's external press release, a research lab's grant proposal). Design the full review-and-approval workflow: who drafts, who owns, who reviews (advisory), who approves (by role), in what order, with what deadlines and defaults, in what tool, and how conflicts are escalated. Defend each choice in one line.

E3. Audit a real collaborative document's history. Open the version history of a real multi-author Google Doc or the git log of a real docs repository you have access to. Write a short analysis: How many authors? Can you see the integration pass in the history (a single author touching every section near the end), or does it look like sections were stapled together? What would you change about the team's process based on what the history reveals?

Selected solutions and rubrics: see appendices/answers-to-selected.md for worked answers to A1–A6, B1–B4, and M1–M4. The open-ended tasks (C1–C4, D1–D4, E1–E3) use the self-assessment rubrics below.

Self-Assessment Rubric — Integration tasks (C1, B1, A7)

Rate each, 0–2 (0 = absent, 1 = partial, 2 = fully achieved):

• One voice. Could a reader tell where one author stopped and the next began? (Target: no.)
• One terminology. Is each concept named exactly one way throughout?
• Seams smoothed. Do the sections connect with real transitions, not cliffs?
• Contradictions resolved. Are dates, numbers, and recommendations consistent — and was a planted concern (e.g., the rate limit) preserved, not erased, but reconciled?
• Redundancy cut. Is each fact, caveat, and definition stated exactly once?
• Certainty calibrated. Confident about what's known, honest about what's pending — neither fog nor breeziness (ties Chapter 7)?

10–12: publishable integration. 6–9: the seams are mostly gone but a voice or a contradiction leaked through — re-run the move that failed. Below 6: you edited the prose but didn't integrate it; reread §23.5 and redo, treating the sections as raw material, not a draft.

Self-Assessment Rubric — Reconciliation tasks (C2, B4, D3)

• Classified correctly. Is each conflict labeled fact / judgment / authority?
• Decided by the right basis. Fact → evidence; judgment → audience/purpose; authority → role. Did you match each?
• No averaging. Did you decide each conflict, or did you split differences into mush?
• Concern honored. Where you declined a note, did you address its underlying concern by another route?
• Logged. Is each decision recorded with a one-line reason, so it won't be relitigated?

Strong: every conflict classified, decided by the correct basis, no mush, declined notes' concerns honored elsewhere, all logged. Weak: you tried to satisfy everyone, or you decided by who was loudest rather than whose domain it was and who the document is for.