Exercises — Chapter 21: Workplace Reports

Writing is learned by writing. Most of these ask you to produce or revise a real report. Where a task is open-ended, a self-assessment rubric follows instead of a single answer. Selected solutions: appendices/answers-to-selected.md.

Difficulty: ⭐ foundational · ⭐⭐ intermediate · ⭐⭐⭐ challenging · ⭐⭐⭐⭐ extension.

Part A — Analyze This ⭐

For each, identify what works or what's broken. Name the principle (exception-based reporting, BLUF, outcomes-not-activities, blameless framing, owner+date, minutes-not-transcript).

A1. A weekly update opens: "It was a productive week! I worked on a lot of things and made good progress overall." What's wrong with every word of this opening?

A2. A status dashboard shows five workstreams, all 🟢, every week for two months. In week nine, one of them ships three weeks late with no warning. What failure does this reveal, and what is it called?

A3. An incident-report timeline entry reads: "15:40 — The on-call engineer finally noticed the obvious memory problem that should have been caught much earlier." Identify three distinct problems in this single line.

A4. Meeting minutes record: "The team discussed the budget for 20 minutes and considered several options before deciding to defer the decision to next week." Is this a usable minute? What, if anything, should it capture?

A5. A corrective action reads: "Going forward, we'll be more careful about testing releases before they go to production." Why will this action never happen, and how would you rewrite it?

A6. A trip report's first three paragraphs describe the conference venue, the keynote speaker's background, and the lunch options. The recommendation appears in paragraph seven. What genre mistake is this, and where should the recommendation go?

A7. A progress report's "Done" section reads: "✅ Made significant headway on the authentication system." The "Done" section of a progress report is for finished outcomes. Is "made significant headway" an outcome? Rewrite it two ways: one if the work is done, one if it genuinely isn't.

A8. A feasibility study compares "Option A: our preferred new platform" against "Option B: do nothing, which would be bad." Beyond the loaded labels, why does this fail as a feasibility study?

Part B — Revise This ⭐⭐

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

B1. Rewrite this narrative opening as an exception-first headline (one or two lines):

"This week the team started by reviewing last sprint's work on Monday, then spent Tuesday and Wednesday on the new feature, and on Thursday we discovered that the third-party login service is deprecating the API we use, which we'll need to migrate off of before next quarter."

B2. Convert this progress-report "Done" section from activities to outcomes:

"DONE: Worked on the data pipeline. Looked into the latency issue. Spent time on the new dashboard. Helped with the deploy." (Invent reasonable finished outcomes—the point is the verb discipline.)

B3. This incident-report root cause blames a person and mixes in a fact. Rewrite it as a neutral timeline entry plus a blameless root cause:

"At 9:15 Dev carelessly deleted the production index, which he obviously shouldn't have done, and this took down search for everyone."

B4. Rewrite these transcript-style minutes as decisions + an action-items table (invent owners and dates):

"Marcus said the release was at risk. Aisha thought we could still make it if we cut scope. Dev wasn't sure cutting scope was a good idea but didn't object strongly. The group talked about it and eventually felt that cutting the export feature was probably the way to go. Someone should update the plan and someone should tell the client."

B5. This RAG dashboard hides its one decision in prose. Rewrite it so the decision is a clear, owned, dated line at the bottom:

"Payments is having some issues with the vendor and we might need to build a workaround, which would take a couple of days, so we should probably talk about whether that's worth it given the timeline. Everything else is fine."

B6. Rewrite this travelogue trip-report opening as a value-first one (key takeaway + recommendation):

"I attended the DataCon conference last week. Day one I went to the keynote and two breakout sessions. Day two I attended a workshop on streaming architectures and saw a vendor demo. The food was good and I made some nice connections." (Invent a useful takeaway worth the trip.)

B7. A status note marks a workstream 🟢 but the text says: "Reporting dashboard is on track, though we're still waiting on the final designs and if those don't come this week we'll definitely slip." Is the color honest? Re-color it and rewrite the note accordingly.

B8. Compress this ownerless corrective-actions list into a proper Owner/Due table (invent reasonable owners and dates):

"We need to add monitoring, and we should also extend the load tests, and at some point we should add an approval step to the pipeline, and someone should write a runbook for this kind of outage."

Part C — Write This ⭐⭐–⭐⭐⭐

Produce a complete document for each scenario.

C1. (The compression task.) Compress a 500-word update to a scannable dashboard. Below is a bloated narrative status email. Rewrite it as an exception-based RAG dashboard: an "Overall" roll-up color, one line per green workstream, full detail only on amber/red items, and a "Decisions Needed" line at the bottom. Aim to cut the word count by at least half while increasing the useful information.

Hi everyone, here's the weekly status on the Helios platform migration. It's been a mixed week. Starting with the good news: the user-authentication migration is complete—we finished moving all the auth services to the new infrastructure on Tuesday and everything has been stable since, so that workstream is wrapped up ahead of schedule, which is great. The data-migration workstream is going well too; we've moved about 80% of the historical data and expect to finish the rest by the middle of next week, right on schedule, no issues to report there. Now for the less good news. The reporting-services migration has hit a snag. We discovered that one of the legacy reports depends on a database view that doesn't exist in the new environment, and recreating it is more involved than we expected because the original query logic was undocumented. We're working through it, but it's put us about a week behind on that workstream. We think we can recover the time if we get some help from the original report author, who's now on a different team. The API-gateway migration is the big concern this week. The new gateway is in place, but we've found that response times under load are about 40% slower than the old gateway, which would be a real problem if we cut over to it as-is. We have two options: we can spend roughly a week tuning the new gateway's configuration to try to close the performance gap, or we can delay the cutover and keep running on the old gateway while we investigate, but that would push the whole migration timeline out by at least two weeks. We need to make a decision on this soon because the cutover is currently scheduled for the end of the month. Finally, the infrastructure and networking workstream is fully on track—no issues, everything proceeding as planned. Let me know if you have questions or want to set up a call to discuss the gateway situation. Thanks!

After you write the dashboard, write one sentence naming the single decision a reader must make, and confirm it appears in your "Decisions Needed" line.

C2. (The incident report.) Write the incident report. A fictional scenario: On a Thursday, your company's customer-facing website was unreachable for 22 minutes (10:14–10:36 local time) because a routine certificate renewal failed silently—the TLS certificate for the main domain expired, and there was no alert monitoring certificate expiry. About 1,400 visitors hit security warnings during the window. The on-call engineer noticed via customer tweets, diagnosed the expired cert, and issued a new one to restore service. Write the full incident report using the §21.4 template: Summary, Timeline, Root Cause, Impact, and a Corrective Actions table with at least three actions, each with an owner and a due date. Keep the timeline factual (no blame), and frame the root cause as a system gap (no alert), not a careless person.

C3. (Progress report.) You are three weeks into a fictional project to build an internal analytics tool. This week you committed to finishing the data-ingestion module and starting the dashboard UI. You finished ingestion and got it tested; you started the dashboard but discovered the design team's mockups are missing several screens, so you're partly blocked on UI work. Next week you plan to finish whatever UI you can and begin the export feature. Write the progress report (planned / done / next / blocking), with an honest Overall color and a real ask in the Blocking section.

C4. (Meeting minutes.) From this short meeting description, write proper minutes (decisions, action-items table with owners and dates, and a one-line context note where useful). A 30-minute team meeting: the group reviewed three candidate vendors for a new monitoring tool, agreed to move forward with the mid-priced option (Vendor B) because it met the requirements at lower cost than the premium option, decided to run a two-week trial before committing, and agreed that the security team needs to review Vendor B's data-handling before any contract. The trial setup and the security review both need owners. Invent reasonable owners and dates.

C5. (Feasibility study — short form.) Write a one-page feasibility study answering: Should our team build a custom internal status-dashboard tool, buy an off-the-shelf one, or keep using a shared spreadsheet? Include an executive summary with the recommendation up front, the three options (build / buy / keep the spreadsheet—your "do nothing" baseline), at least three evaluation criteria stated before the comparison, an options-against-criteria comparison table, and a recommendation tied to the criteria. Invent reasonable numbers.

Part D — Synthesis & Critical Thinking ⭐⭐⭐

D1. (Translate for audience.) Take the gateway-performance problem from C1 (the new API gateway is 40% slower under load). Write three one-line versions of that single status item: (a) for a hands-on engineering manager who can reallocate people, (b) for a non-technical executive who only cares about the launch date, (c) for the client who is paying for the migration. Same fact, three readers—change what you lead with and what you omit. (This is the audience principle from Chapter 2 applied to one status line.)

D2. (Find the flaw.) A team proudly adopts RAG status and ships a beautiful weekly dashboard. Six months later, leadership complains the dashboards are "useless—everything's always green and then projects fail anyway." The dashboard format is fine. Diagnose the real problem and propose two concrete process fixes (not formatting fixes) that would make the colors mean something.

D3. (Genre selection.) For each situation, name the right report genre and justify in one sentence: (a) you visited a key supplier's factory and learned their lead times are doubling; (b) a database migration corrupted 200 customer records before it was caught; (c) your manager asks how the quarterly project is tracking; (d) the team must choose between three cloud providers; (e) a planning meeting ended with several commitments but no one is sure who owns what.

D4. (The boundary case.) When does a "red" status item stop being a status update and become an incident report? Consider a payments outage that's ongoing during your weekly status cycle. Argue where the line is and how the two documents should reference each other.

D5. (Cross-genre integration.) An incident report's corrective-actions table and a set of meeting minutes' action-items table look almost identical (Action / Owner / Due). What's the same about them, and what's different about the contexts that produce them? Why does both genres independently converge on the same table format? (Hint: think about what makes an action actually happen.)

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

These mix this chapter with earlier ones. Choose the right approach—don't assume it's always a Chapter 21 technique.

M1. You need to tell your team about a complex, multi-step process change. Is the right move a status update, a set of instructions (Chapter 22 preview), or an email (Chapter 19)? Justify, then write the first three lines of whichever you chose.

M2. A status update's red item reads: "Payments integration is blocked due to the fact that there are issues with the vendor's API that are causing problems for our testing." Apply Chapter 3's conciseness lens and this chapter's exception-based discipline. Rewrite it tight and actionable.

M3. You're writing the executive summary of a feasibility study. Whose advice governs the summary—Chapter 4's BLUF, Chapter 13's recommendation-first technical report, Chapter 20's executive summary, or all three? Explain how they align, then write a three-sentence executive summary for a "buy the off-the-shelf tool" recommendation.

M4. A teammate sends a 400-word status email. Before you tell them to use a RAG dashboard, run Chapter 4's reverse-outline diagnostic on it (in your head): what would the reverse outline reveal that justifies the dashboard recommendation?

M5. An incident report's root-cause section says the outage "proves our deploy process is fundamentally broken." Apply Chapter 13's lesson on overclaiming in a Discussion section. Is "proves... fundamentally broken" calibrated to one incident? Rewrite it.

M6. You must deliver genuinely bad news in a status report: the project will slip a month. Combine Chapter 19's "email that delivers bad news" (lead with the fact, be straight, give a path forward) with this chapter's exception-based reporting. Write the red status item and the accompanying one-line note.

Part E — Extension ⭐⭐⭐⭐ (optional)

E1. (Design a reporting standard.) Imagine you lead a team of eight. Design a one-page status-reporting standard: the cadence, the format (give the template), the explicit RAG thresholds (what makes something amber vs. red), and one rule that fights watermelon reporting. Then write the two-sentence pitch you'd use to get the team to actually adopt it.

E2. (The blameless rewrite, hard mode.) Take a real (or realistic) incident where a human action was clearly the proximate trigger—someone ran the wrong command, deployed at the wrong time, skipped a step. Write the root-cause section twice: once the easy blameful way, once blameless. Then write a paragraph arguing why the blameless version produces better corrective actions—and honestly address the objection "but doesn't this let people off the hook?"

E3. (Compression to the limit.) Take your answer to C1 (the Helios dashboard) and compress it to a Slack message a manager reads on their phone—no table, under 60 words—without losing the one decision. Then reflect: what did you keep, what did you cut, and what does that tell you about the irreducible core of a status update?

Self-Assessment Rubric (for the open-ended Write/Synthesis tasks)

Score each produced document against these. Aim for "strong" on every row before moving on.

Selected solutions and rubrics: appendices/answers-to-selected.md. For the open-ended tasks (C1–C5, D1–D5, E1–E3), use the rubric above; there is no single correct answer, only stronger and weaker reports.