Chapter 21: Workplace Reports: Progress Reports, Status Updates, and Incident Reports

"If I had more time, I would have written a shorter letter." — attributed to Blaise Pascal, Lettres provinciales (1657)

Chapter Overview

On a Monday morning, a project manager named Priya opens her inbox to forty unread messages and a 9:30 leadership review she has not prepared for. Two of those messages are status reports from teams she oversees. The first is 600 words of dense narrative: "This week the team continued working on the integration layer and made significant progress on several fronts, including but not limited to the authentication module, which has been a focus area..." She reads three sentences, learns nothing she can act on, and moves on. The second report is a six-line table. Green, green, amber: payments integration — vendor API sandbox down since Thursday, blocking end-to-end tests, need a decision on the fallback by Wednesday or we slip the demo. Priya reads it in ten seconds, knows exactly what to do, and forwards it to the one person who can unblock it. Same week, same kind of project, same amount of underlying work. One report got acted on. The other got skimmed and forgotten. The difference was not effort or honesty. It was format.

This chapter is about the unglamorous documents that run an organization: the progress report your manager skims on a Friday, the status dashboard leadership reviews on a Monday, the incident report written at 2 a.m. after a production outage, the meeting minutes nobody wants to write but everybody needs, the trip report that justifies the conference budget, and the feasibility study that decides whether a project happens at all. None of these will win a prize. All of them are read by someone busy who must do something with the information—approve, escalate, reassign, decide, or simply stop worrying about a thing that is on track. That is the defining fact of the workplace report, and it drives every choice in this chapter: the reader is not grading your effort; they are making a decision, and your report is the input.

You already have most of the tools. Chapter 4 taught that readers scan rather than read and that the conclusion belongs at the top (BLUF—bottom line up front). Chapter 13 taught the recommendation-first technical report, which inverts the academic order so a busy manager gets the answer before the methodology. Chapter 19 (Emails) taught the action-oriented subject line and the one-clear-ask close. Workplace reports apply all three at once, plus one new discipline that is the threshold concept of this chapter: report the exception, not the routine. A status report that tells you everything is on track when it is, in fact, on track, has wasted your reader's attention. A good one whispers when things are fine and shouts—precisely, with an owner and a deadline—when they are not. By the end of this chapter you will be able to write each of the six report types so that a reader can extract the decision they need in under a minute, and you will be able to take a bloated, narrative update and compress it into something that actually gets read.

In this chapter, you will learn to:

• Select the right report genre for a situation—progress vs. status vs. incident vs. minutes vs. trip vs. feasibility—and structure each to its template.
• Write a progress report on the planned / done / next / blocking pattern that a manager can act on in under a minute.
• Compress a rambling narrative update into a scannable, exception-based RAG dashboard.
• Write an incident report with a factual timeline, a blameless root-cause analysis, and corrective actions that have owners and dates.
• Record meeting minutes as decisions, action items, owners, and deadlines—never a transcript.

📘 Business/Professional track: This is core for you. Progress reports (§21.2), status dashboards (§21.3), meeting minutes (§21.6), and the feasibility study (§21.8) are the documents that will fill your week. If you read one section twice, make it §21.3—exception-based reporting is the single highest-leverage skill in workplace writing.

📗 Software/CS track: Core for you too, with one extra emphasis: the incident report (§21.4 and §21.5) is the direct ancestor of the blameless postmortem you'll write in Chapter 34 (Writing for Computer Science). Raj Patel's outage runs through both. Sprint progress reports (§21.2) and trip reports for a conference (§21.7) round out your week.

21.1 What Every Workplace Report Has in Common

Before the six genres, the shared spine. Strip away the labels and every workplace report is built from the same four moves, in roughly this order of importance:

1. The headline — what the reader most needs to know, stated first. On track? Off track? An incident occurred? A decision is needed? This is BLUF (Chapter 4) applied to reporting. The reader who reads only the first line should still get the one fact that matters.
2. The exceptions — what deviates from the plan or the norm. Slips, blockers, risks, surprises, decisions required. This is where the reader's attention should go, so it goes near the top.
3. The routine — the on-track, as-expected, nothing-to-see-here items, compressed to the minimum. Present so the reader knows you didn't forget, absent in detail because there is nothing to act on.
4. The ask — what you need from the reader, if anything: a decision, an approval, an escalation, an introduction, or simply "no action needed, FYI." One clear ask, with a deadline, exactly as Chapter 19 framed the close of an effective email.

Notice what is not on that list: a chronological narrative of everything you did, in the order you did it. That is the default a writer reaches for, because it matches how the work actually unfolded—and it is almost always wrong for the reader. The writer experienced the week as a sequence of events. The reader needs it as a structure of decisions. Converting the first into the second is the core skill of this chapter, and it is exactly the "top-down, not bottom-up" move from Chapter 4, now applied to the documents you'll write every week of your career.

Here is the move in miniature, on a one-line update:

❌ Before (narrative, writer's order): I spent Monday and Tuesday setting up the test environment, then on Wednesday I started running the integration suite, and by Thursday I'd found that the payment vendor's sandbox was returning 500 errors, so I've been blocked since then waiting to hear back from them.

✅ After (exception-first, reader's order): 🔴 Blocked: payment vendor's sandbox has been down (500 errors) since Thursday, halting integration tests. Need someone to escalate with the vendor by Wed or the demo slips.

Why it's better: The "before" makes the reader walk through four days to reach the one fact that matters; the blocker arrives last, buried under setup work that needs no attention. The "after" leads with the problem, names what it blocks, and states the ask with a deadline. Same information, but the second version respects theme 6—every sentence earns its place—and theme 5—structure serves the reader, not the chronology of the writer. The reader can act on the second in five seconds.

🔍 Why Does This Work? Why does leading with the exception beat a complete chronological account, even though the chronology contains more information? Think about it before reading on.

Because the reader's scarcest resource is attention, not information, and the two trade off. A complete chronology forces the reader to process everything in order to find the one thing they need to act on—it spends a lot of their attention to deliver a little of their need. Exception-first reporting spends almost none: the reader sees "🔴 Blocked" and "need a decision by Wed," routes it, and moves on. The routine items are still available (you list them), but they don't cost attention because they're compressed and clearly labeled "fine." You're not hiding information; you're sorting it by what the reader has to do with it. That sort is the entire job.

🔄 Check Your Understanding A teammate's weekly update opens: "This week I attended the sprint planning meeting on Monday, paired with Sam on the caching bug Tuesday morning, and reviewed three pull requests." Nothing in those three sentences is a slip, a blocker, or a decision needed. What's wrong, and what should open the update instead?

Answer

The update opens with routine activities in chronological order—exactly the writer's-order narrative this section warns against. None of it requires the reader to act. The update should open with the headline (on track or not?) and any exception (a slip, blocker, or risk). If everything genuinely is on track, the first line should say so—"On track for the sprint goal; no blockers"—so the reader can stop reading immediately. The activity list, if kept at all, belongs lower and compressed.

21.2 The Progress Report: Planned, Done, Next, Blocking

A progress report answers a single question for whoever is tracking your work: are we on track, and if not, what do you need from me? It is the most common report you will write—weekly to a manager, per sprint to a team, monthly to a client, or at project milestones to a steering committee. The cadence and audience vary; the skeleton does not.

The skeleton has four parts, and naming them is half the battle:

• Planned — what you committed to for this period (last week, last sprint). This is the baseline the reader measures against. Without it, "done" is meaningless—done relative to what?
• Done — what you actually completed. Completed, not "worked on." "Worked on the API" is not progress; "shipped the three new API endpoints" is.
• Next — what you're committing to for the next period. This becomes next report's "Planned," which is how the reader tracks whether you hit your own targets.
• Blocking — what's in your way that you can't clear yourself. This is the part the reader most needs, because it's the only part that requires them to do something. If nothing is blocking, say "Nothing blocking" explicitly—its absence is information.

Here is the template, suitable for a weekly update to a manager or a sprint review:

PROGRESS REPORT — [Project / Sprint] — [Date or sprint number]
Author: [name]    Overall: 🟢 On track / 🟡 At risk / 🔴 Off track

PLANNED (this period)
- [Commitment 1]
- [Commitment 2]

DONE
- ✅ [Completed item — phrased as a finished outcome]
- ✅ [Completed item]
- ⏳ [Partially done — name what's left and the new target]

NEXT (next period)
- [Commitment for next period]
- [Commitment for next period]

BLOCKING / NEEDS DECISION
- 🔴 [Blocker] — [what it blocks] — [what you need, from whom, by when]
- (or: "Nothing blocking.")

Watch the verbs. "Done" is for outcomes, not activities. The most common progress-report failure is reporting effort as if it were achievement. Compare a single line:

❌ Before: Spent this week working on improving the checkout flow and looking into the reported performance issues.

✅ After: Shipped the redesigned checkout flow (live to 100% of users Thursday). Identified the cause of the slow checkout—an unindexed database query—and the index fix is queued for next sprint.

Why it's better: "Working on" and "looking into" describe motion, not arrival; a reader cannot tell whether anything finished. The revision names two finished outcomes ("shipped," "identified the cause") and one concrete next step with a timeframe. The reader now knows the state of the work, not just that you were busy. This is the same discipline Chapter 13 applied to a Results section—report what happened, in verifiable terms, not how hard you tried.

Now a full before/after at the report level. Here is a real-feeling weekly update written the way most people write them—and then rebuilt.

❌ Before (a narrative weekly update): Hi team, here's my update for the week. It was a busy one! On Monday I caught up on email after being out Friday, then jumped into the data-migration work. I spent most of Tuesday and Wednesday writing the migration scripts and testing them against a copy of the staging database, which took longer than expected because the staging data was out of date and I had to refresh it first. Thursday I ran the migration on staging and it mostly worked, though there were some issues with the timestamps that I'm still debugging. I also helped onboard the new contractor and sat in on the architecture review. Friday I started documenting the migration process. Next week I'll keep going on the timestamp bug and hopefully start planning the production migration. Let me know if you have questions!

What does the reader have to do to use this? Read 130 words, mentally sort the achievements from the side-quests, hunt for anything off track, and guess at what's needed. Now the rebuild:

✅ After (the same week, structured): ```text PROGRESS — Data migration — Week of Mar 10 Overall: 🟡 At risk

PLANNED: Write + test migration scripts; run on staging.

DONE: - ✅ Migration scripts written and tested against staging. - ✅ Migration run on staging — succeeded except for timestamp conversion (see blocker). - ✅ (Side tasks: onboarded the new contractor; attended architecture review.)

NEXT: Fix the timestamp bug; draft the production-migration plan.

BLOCKING / RISK: - 🟡 Timestamps shift by the server's timezone offset on migration — root cause not yet found. This blocks the production migration. If unresolved by Wed, the production date slips a week. Need: 1 hr of @Maria's time (she wrote the original timestamp logic). ```

Why it's better: The "Overall: 🟡 At risk" headline tells a scanning manager the one thing that matters before they read a word of detail. Achievements are separated from side tasks (which are demoted to a parenthetical, present but not competing for attention). The blocker is specific (what's broken, what it blocks, the schedule consequence) and ends with a concrete, named ask. The reader can now make a decision—get Maria an hour free—in the time it took to read the "before" version's first sentence. The word count dropped by roughly a third, and the useful information went up.

🧩 Productive Struggle Before reading the next section, try this. Take the last status update you sent—an email, a Slack message, a stand-up note—and find its single most important sentence (the one the reader most needed). Where is it? If it's not in the first two lines, ask yourself why. Most writers discover their key sentence is in the middle or the end, arrived at the way they arrived at it in real life. Moving it to the top, before you read on, is the whole lesson of §21.1–21.2 in one edit.

[📍 Good stopping point — you have the shared spine and the workhorse genre. The rest of the chapter covers the five remaining report types, each with a template.]

21.3 The Status Update: Exception-Based and Scannable (RAG)

A status update differs from a progress report in audience and altitude. A progress report goes to someone tracking your work in detail. A status update—often called a status report or a dashboard—rolls up many workstreams for someone who is tracking the whole at a glance: a program manager watching ten teams, an executive watching a portfolio, a client watching the project they paid for. The reader of a status update does not want to read; they want to scan a board and find the red. This is where two techniques become non-negotiable: RAG status and exception-based reporting.

RAG stands for Red, Amber, Green—a traffic-light system that lets a reader assess health in one visual pass:

• 🟢 Green — on track. On schedule, on budget, no help needed. The reader can skip it.
• 🟡 Amber — at risk. A problem exists or is emerging; it may be recoverable without intervention, but the reader should be aware. Watch this one.
• 🔴 Red — off track. A real problem that needs attention now, usually a decision or resources from someone above you. The reader must act on this.

The power of RAG is that it turns "how are things?"—a question that otherwise demands paragraphs—into a color the eye catches instantly. But RAG only works if you obey one rule: the color must mean something, and the rule for assigning it must be consistent. The classic failure is "watermelon" reporting—green on the outside, red on the inside—where everything is reported green until the week it explodes, because no one wanted to be the bearer of amber. A status update where everything is always green is not a status update; it's decoration. Amber and red are not admissions of failure. They are the entire reason the report exists.

⚠️ Warning: the watermelon report. If your status is green every single week and then a project suddenly fails, your reporting was broken long before the project was. Green should mean "genuinely fine," not "I don't want to explain a problem." Calibrate honestly: if you'd be surprised to still be on track in two weeks, you're amber now.

Exception-based reporting is the companion discipline. It means: spend detail only where there's an exception. Green items get a single line—a name and a color, nothing more. Amber and red items get the explanation, because that's where the reader's attention and your words should go. You are inverting the usual instinct to write the most about the things you spent the most time on. Instead, you write the most about the things the reader must act on, which are usually the things that went wrong.

Here is a status-dashboard template for a multi-workstream project:

STATUS — [Project] — [Date]                        Overall: 🟡
Owner: [name]   Next milestone: [milestone] — [date]

┌─────────────────────────┬────────┬──────────────────────────────────────────┐
│ Workstream              │ Status │ Note (only if amber/red)                   │
├─────────────────────────┼────────┼──────────────────────────────────────────┤
│ Authentication          │  🟢    │ —                                          │
│ Payments integration    │  🔴    │ Vendor sandbox down since Thu; blocks E2E  │
│                         │        │ tests. DECISION NEEDED by Wed: build the   │
│                         │        │ mock fallback (2 days) or slip the demo.   │
│ Reporting dashboard     │  🟡    │ 3 days behind; recoverable if design signs │
│                         │        │ off by Fri. No help needed yet.            │
│ Infrastructure          │  🟢    │ —                                          │
└─────────────────────────┴────────┴──────────────────────────────────────────┘

DECISIONS NEEDED: 1 (Payments fallback — by Wed)

A few things make this template work. The Overall roll-up at the top is the BLUF: one color for the whole project, so a reader who reads nothing else still knows the headline. Green rows carry a dash, not a paragraph—their job is to exist, confirming the workstream wasn't forgotten, not to be read. The red row carries the full story and the decision, phrased as a choice with a deadline. And the Decisions Needed line at the bottom is a gift to the executive reader: it pulls every required action into one place, so they don't have to hunt the table for the things that need them.

Now the headline before/after for this chapter—the 500-word narrative update compressed to a scannable dashboard. Here is the bloated original:

❌ Before (a ~250-word narrative status email): Hi all, weekly status on the Atlas project. The authentication workstream continues to go well; we finished the OAuth integration last week and the team has moved on to session management, which is progressing nicely and we expect to wrap it up by the end of next week as planned. On the payments side, things have been more challenging. We've been integrating with the vendor's API, but their sandbox environment went down on Thursday and has been returning errors since, which means we can't run our end-to-end tests. We've opened a support ticket with them but haven't heard back. This is becoming a concern because we have the demo to leadership coming up and if we can't test the payment flow we may not be able to demo it. One option would be to build a mock version of the vendor's API so we can test against that, but that would take a couple of days of engineering time that isn't currently planned. The reporting dashboard is a few days behind schedule because we're waiting on final designs from the design team, but we think it's recoverable if we get the designs by Friday. Infrastructure is all on track—no issues there. Let me know if you have any questions or want to discuss the payments situation.

That is honest, complete, and almost useless to a scanning executive. The one decision buried in it—mock the vendor API or risk the demo—is in sentence eight, framed as "one option would be," with no deadline and no clear ask. Here is the same content as a dashboard:

✅ After (the same status, as an exception-based RAG dashboard): ```text STATUS — Atlas — Mar 14 Overall: 🟡 Next milestone: Leadership demo — Mar 28

Authentication ......... 🟢 OAuth done; session mgmt on track for next Fri. Payments ............... 🔴 Vendor sandbox down since Thu → can't run E2E tests → demo at risk. DECISION by Wed: build mock API (2 eng-days, unplanned) OR drop payments from the demo. Reporting dashboard .... 🟡 3 days behind, waiting on designs. Recoverable if design delivers by Fri. No action needed yet. Infrastructure ......... 🟢 On track.

DECISION NEEDED: Payments fallback — owner: Priya — by Wed Mar 19. ```

Why it's better: Word count fell from ~250 to ~90, and the time-to-decision fell from "read the whole email and infer the ask" to "scan for red, read one row." The amber/red items carry the explanation; the green items carry a dash. Most importantly, the buried "one option would be" became a sharp, owned, dated decision at the bottom. The "before" is a writer telling you about their week; the "after" is a report engineered for a reader who has thirty seconds and a decision to make. This is theme 5 (structure serves the reader) and theme 6 (every sentence earns its place) operating together—and it's the exact compression you'll practice in this chapter's exercises.

🔄 Check Your Understanding In an exception-based RAG dashboard, why do the green items get only a single word or a dash while the red items get three lines of explanation? Isn't that backward—shouldn't you write more about your successes?

Answer

It's backward only if the report's purpose is to celebrate effort. Its actual purpose is to route the reader's attention to what needs action. Green items need no action, so they need no words—their single line exists only to confirm the workstream is tracked and fine. Red items need a decision, so they get the space to explain the problem and state the ask. You allocate words by the reader's need to act, not by how much work you did. Writing more about your green successes would bury the red item the reader actually came for.

21.4 The Incident Report: Timeline, Root Cause, Corrective Actions

When something goes wrong—a production system goes down, a shipment is lost, a safety event occurs, a security breach is detected—someone has to write the incident report. Its purpose is twofold and worth stating plainly, because the two purposes pull in different directions and confusing them is how incident reports go wrong: (1) to create an accurate, durable record of what happened, and (2) to drive the changes that keep it from happening again. It is not to assign blame, and it is not to make anyone look good. An incident report that protects reputations at the expense of accuracy is worse than no report, because it teaches the organization the wrong lessons.

A complete incident report has five parts:

• Summary — what happened, the impact, and the current status, in three or four sentences at the very top. Impact in concrete terms: who or what was affected, for how long, how badly. This is the BLUF; a VP reading only this paragraph should understand the event.
• Timeline — a minute-by-minute (or as granular as needed) factual sequence: detection, diagnosis, key actions, resolution. Timestamps and facts only—no interpretation. The timeline is the Results section of an incident report (Chapter 13): what happened, neutrally, before anyone argues about why.
• Root cause — why it happened. Not the surface trigger ("a server crashed") but the underlying cause ("a memory leak in the new release exhausted the host's RAM, and there was no alert on memory usage to catch it before it crashed"). This is the Discussion: interpretation, clearly separated from the timeline's facts.
• Impact — the full accounting: users affected, duration, revenue or data loss, SLA breaches, downstream effects. Sometimes folded into the summary; broken out when the stakes warrant it.
• Corrective actions — what will change so this doesn't recur, each as a concrete action with an owner and a due date. A corrective action without an owner and a date is a wish, not a plan. This is the part that justifies the whole exercise.

The single most important cultural principle here is the blameless stance, which you'll meet again as the blameless postmortem in Chapter 34. Blameless does not mean no accountability; it means the report attacks the system that allowed a human error to cause harm, not the human who made it. "Raj deployed the bad config" is blame, and it's also a dead end—it suggests the fix is "Raj should be more careful," which fixes nothing. "A config change reached production without review because the deploy pipeline had no required approval step" is blameless, and it points straight at a real fix: add the approval gate. The blameless framing isn't softness; it's the only framing that produces durable corrective actions, because the next person at that keyboard will make the same mistake unless the system changes.

Here is the incident-report template:

INCIDENT REPORT — [short descriptive title]
Incident ID: [id]    Severity: [SEV-1 / SEV-2 / ...]    Status: [Resolved / Monitoring]
Author: [name]    Date of incident: [date]    Report date: [date]

SUMMARY
[3–4 sentences: what happened, impact (who/what/how long/how bad), current status.]

TIMELINE (all times [timezone])
HH:MM  [Event — fact only, no interpretation]
HH:MM  [Detection: how/when the problem was noticed]
HH:MM  [Diagnosis / key action taken]
HH:MM  [Resolution]

ROOT CAUSE
[Why it happened — the underlying cause, not just the trigger. Separate from the timeline.]

IMPACT
- Users affected: [number / segment]
- Duration: [start–end]
- [Revenue / data / SLA / downstream effects]

CORRECTIVE ACTIONS
| # | Action | Owner | Due | Status |
|---|--------|-------|-----|--------|
| 1 | [Concrete change] | [name] | [date] | Open |
| 2 | [Concrete change] | [name] | [date] | Open |

The most common timeline mistake is smuggling interpretation into the facts. Watch:

❌ Before (timeline with interpretation mixed in): 14:32 — The careless deploy of the broken config caused the API to start failing, which obviously should have been caught in review.

✅ After (fact in the timeline; judgment in root cause): Timeline — 14:32 — A configuration change (commit a3f9c2) was deployed to production. API error rate began rising at 14:33. Root cause — The configuration change contained an invalid database connection string. It reached production without review because the deploy pipeline did not require an approval step for config-only changes.

Why it's better: The "before" packs three things into one timeline entry—a fact (a deploy happened), a judgment ("careless," "broken"), and a conclusion ("should have been caught"). That makes the timeline arguable, which defeats its purpose: the timeline is supposed to be the part everyone agrees on. The "after" puts the neutral fact in the timeline (a specific commit deployed at a specific time) and moves the why to the root-cause section, framed blamelessly (a missing approval step, not a careless person). Now the timeline is unarguable and the root cause points at a fixable system. We work through Raj Patel's full incident report in §21.5 and in Case Study 2.

🔍 Why Does This Work? Why insist on separating the timeline (facts) from the root cause (interpretation), when an experienced reader could infer the cause from the facts anyway? Think before reading on.

Because the two serve different readers and survive on different timescales. The timeline is the shared, verifiable record—it's what a regulator, a future engineer, or a disagreeing colleague can all accept, because it asserts only what happened and when. The root cause is an argument about why, and arguments can be wrong, revised, or contested. If you blend them, a reader who disputes your interpretation may start doubting your facts too, and the whole report loses authority. Keeping them separate means your facts stay trustworthy even when your analysis is debated—the same Results-vs-Discussion discipline from Chapter 13, now load-bearing for an outage that might end up in front of a lawyer.

🪞 Learning Check-In Pause and notice your own instinct. When you describe something that went wrong—a bug, a missed deadline, a mistake—do you reach first for what happened or for whose fault it was? Most of us reach for fault, because it feels like an explanation. But "whose fault" rarely changes the system, and the system is what produces the next incident. Catch yourself the next time you write "X failed to..."—and ask whether the sentence would be more useful as "the process allowed..." This shift, from blame to system, is a habit you can build, and it will make every incident report, postmortem, and retrospective you ever write more honest and more useful.

21.5 Raj Patel's Incident Report: A Worked Example

Let's make the incident report concrete. Raj Patel is a backend engineer; you'll meet him again documenting an open-source project in Chapters 24–26 and writing a blameless postmortem in Chapter 34. (Raj and this incident are composite and fictional, built to be realistic, per the book's citation honesty in the style bible.) Last Tuesday, the payments service Raj's team owns went down for 47 minutes during business hours. Raj has to write the incident report. Here is his first draft, written tired and a little defensive, the way real first drafts get written:

❌ Before (Raj's defensive first draft): The payments service went down for a while on Tuesday afternoon. It looks like the new release had a bug in it that caused a memory leak, and eventually the service ran out of memory and crashed. We didn't catch it because the memory alert wasn't set up. Once we figured out what was happening we rolled back the release and things recovered. We should be more careful about testing releases and we'll try to set up better monitoring going forward.

This is not a terrible start—it's honest, and the underlying analysis is roughly right. But as a report it fails several tests at once. The impact is vague ("for a while," "things recovered")—a VP can't tell if this cost the company $50 or $50,000. There's no timeline, so no one can reconstruct the sequence or learn from the response. The root cause is half-stated and tangled with the timeline. And the corrective actions are wishes: "be more careful" and "we'll try to set up better monitoring" have no owner, no date, and no teeth. Here is the rebuild.

✅ After (Raj's report, structured): ```text INCIDENT REPORT — Payments service outage (out-of-memory crash) Incident ID: INC-2041 Severity: SEV-1 Status: Resolved Author: Raj Patel Date of incident: Mar 11 Report date: Mar 12

SUMMARY On Mar 11, the payments service was fully unavailable for 47 minutes (14:18–15:05 UTC) during business hours. ~3,200 checkout attempts failed; customers saw payment errors. Cause: a memory leak in release v2.8.0 exhausted host memory; no memory alert existed to warn before the crash. Resolved by rolling back to v2.7.4. Service is stable; corrective actions below.

TIMELINE (UTC) 13:50 Release v2.8.0 deployed to production. 14:18 Host memory reached 100%; payments service killed by the OOM killer. 14:21 First customer reports of failed payments; on-call paged. 14:35 On-call identifies rising memory in v2.8.0 from host metrics. 14:52 Decision to roll back to v2.7.4. 15:05 Rollback complete; payments recovered; error rate normal.

ROOT CAUSE Release v2.8.0 introduced a memory leak: payment-session objects were retained after completion (a missing cleanup call). Under production load, host memory was exhausted in ~28 minutes, triggering the OOM killer. Two contributing factors: (1) no alert on host/process memory, so the leak was invisible until the crash; (2) load tests run only for 5 minutes, too short to surface a slow leak.

IMPACT - Users affected: ~3,200 failed checkout attempts. - Duration: 47 minutes (14:18–15:05 UTC). - Est. lost transactions: ~$18,000 (recoverable — customers can retry). - SLA: breached the 99.9% monthly availability target for payments.

CORRECTIVE ACTIONS | # | Action | Owner | Due | Status | |---|-------------------------------------------------------|---------|--------|--------| | 1 | Add the missing session-cleanup call; patch + release | Raj | Mar 13 | Open | | 2 | Add memory alerts (warn 80%, page 90%) on payments | Priya | Mar 15 | Open | | 3 | Extend load tests to 1 hour to surface slow leaks | Sam | Mar 20 | Open | | 4 | Require approval for config + release to production | Raj | Mar 22 | Open | ```

Why it's better: Every failure of the draft is now fixed. The summary gives a VP the whole event—duration, customer impact, dollar estimate, current status—in four sentences. The timeline is factual and reconstructable, with no judgment words. The root cause names the underlying mechanism (retained session objects) and the two systemic gaps (no memory alert, too-short load tests), all framed blamelessly—nowhere does it say anyone was careless. And the corrective actions are real: each is a concrete change with a named owner and a due date, so this report can actually be tracked to completion. Notice too that the report never names a culprit. The leak was a missing cleanup call; the system let it through. That framing is what makes the corrective actions point at the right fixes—and it's the seed of the blameless postmortem you'll write in Chapter 34.

💡 Tip: write corrective actions as a tracked table, not prose. The moment a corrective action lives in a sentence ("we should improve monitoring"), it has no owner and dies. The moment it lives in a row of a table with an Owner and Due column, someone is accountable and it can be followed up in the next review. The table format is the accountability. This is the same lesson as meeting minutes in §21.6: an action item without an owner and a date is not an action item.

21.6 Meeting Minutes: Decisions, Actions, Owners, Deadlines

Almost everyone who takes meeting minutes does it wrong the same way: they try to transcribe the meeting. They capture who said what, in what order, in long paragraphs nobody will ever read. Minutes are not a transcript. A transcript records the conversation; minutes record the outcomes. Six months later, no one cares that Marcus raised a concern about timeline and Aisha responded that the vendor could accommodate it. They care about three things, and only three: What was decided? What are we doing about it? Who owns each thing, and by when?

So good minutes capture exactly four kinds of information and discard the rest:

• Decisions — what the group agreed to. Stated as a settled fact: "Decided: ship the v2 redesign on April 15." Not the debate that led there—the conclusion.
• Action items — the concrete next steps that came out of the meeting.
• Owners — exactly one named person per action item. Not "the team," not "we"—a single accountable human. An action owned by everyone is owned by no one.
• Deadlines — a date for each action item. "Soon" is not a deadline.

Everything else—the discussion, the back-and-forth, the considered-and-rejected options—is either discarded or compressed to a one-line "context" note where it's genuinely needed to explain why a decision was made. Here is the template:

MEETING MINUTES — [Meeting name] — [Date]
Attendees: [names]    Absent: [names]    Note-taker: [name]

DECISIONS
- [Decision, stated as a settled outcome]
- [Decision]

ACTION ITEMS
| # | Action | Owner | Due |
|---|--------|-------|-----|
| 1 | [Concrete next step] | [one name] | [date] |
| 2 | [Concrete next step] | [one name] | [date] |

DISCUSSION NOTES (only where context matters)
- [One line: why a decision went the way it did, if non-obvious]

NEXT MEETING: [date / agenda preview]

The before/after here is dramatic because the transcript habit produces so much waste. Here is a fragment of transcript-style minutes:

❌ Before (transcript-style minutes): The meeting began at 2:00. Marcus opened by reviewing the project timeline and noted that he was concerned the April deadline might be too aggressive given the remaining work on the payments integration. Aisha responded that she had spoken with the vendor and they had agreed to provide additional support, which she felt would help. There was some discussion about whether to bring in a contractor. Dev said he thought a contractor might not have enough context to be useful quickly. Priya suggested that instead the team could descope the reporting feature to make the deadline more achievable. After some back and forth, the group seemed to agree that descoping reporting was the better option. Marcus said he would update the project plan. The team also discussed the upcoming demo...

That's 130 words and still climbing, and to find out what was actually decided, you have to read the whole thing and infer it ("the group seemed to agree"). Here is the same meeting as minutes:

✅ After (decision-and-action minutes): ```text MINUTES — Atlas project sync — Mar 14 Attendees: Marcus, Aisha, Dev, Priya Note-taker: Priya

DECISIONS - Descope the reporting feature from the April 15 release to protect the date. (Context: payments integration is at risk; descoping reporting buys the time.) - Do NOT bring in a contractor (insufficient ramp-up time to be useful).

ACTION ITEMS | # | Action | Owner | Due | |---|--------|-------|-----| | 1 | Update the project plan to reflect descoped reporting | Marcus | Mar 16 | | 2 | Confirm extra support window with the payments vendor | Aisha | Mar 17 |

NEXT MEETING: Mar 21 — review revised plan. ```

Why it's better: The decision that took the "before" version a hundred words and a vague "seemed to agree" to convey is now stated as a settled fact in one line, with a one-line context note explaining why (so a future reader understands the reasoning without re-litigating it). Two action items each have exactly one owner and a date. The reader who missed the meeting knows, in fifteen seconds, what changed and what they owe. And crucially, the minutes are now actionable: Marcus and Aisha can be held to their items at the next sync, because the record says who owns what, by when.

✏️ Try This Here is a snippet of a meeting: "The group talked for a while about the slow API. Some people thought caching would help; others thought the real problem was the database. Eventually it was felt that we should probably look into adding caching, and someone should also check the database indexes at some point." Rewrite it as one DECISION line and a 2-row ACTION ITEMS table. You'll have to invent owners and dates—that's the point: vague minutes force the writer to demand specifics that vague discussion glossed over.

One good version

DECISION: Add a caching layer to the API as the first performance fix; investigate database indexes in parallel. ACTIONS: (1) Prototype the caching layer — Owner: [name] — Due: [date]. (2) Audit the slow queries' database indexes — Owner: [name] — Due: [date]. Notice that "someone should also check... at some point" had to become a named owner and a real date. Writing the minutes exposed that the meeting never actually assigned the work—which is exactly the gap good minutes catch.

21.7 The Trip Report and the Feasibility Study

Two more genres round out the workplace-report family. They look different from the weekly cadence reports, but they obey the same spine: lead with what the reader needs, demote the detail.

The trip report

A trip report documents a business trip—a conference, a client visit, a site inspection, a training—for the people who didn't go but paid for it or need its findings. Its real audience is your manager (who approved the expense and wants to know it paid off) and your colleagues (who want the useful bits without attending). The cardinal sin is the travelogue: a day-by-day diary of sessions attended and meals eaten. Nobody needs your itinerary. They need the takeaways and the recommendations—what you learned that changes what the team should do.

So a trip report leads with value, not chronology:

TRIP REPORT — [Event/Visit] — [Location] — [Dates]
Author: [name]    Purpose: [one line: why you went]

KEY TAKEAWAYS (the 3–5 things worth knowing)
- [Insight, finding, or contact that matters to the team]
- [Insight]

RECOMMENDATIONS / ACTIONS
- [What we should do differently as a result] — [owner, if any]

WORTH FOLLOWING UP
- [Contacts made, tools to evaluate, sessions whose recordings to watch]

(Details / full notes: [link or appendix])

❌ Before (travelogue): Day 1: I arrived and registered, then attended the keynote, which was about AI in industry. After lunch I went to a session on data pipelines and another on observability. Day 2: I attended sessions on...

✅ After (value-first): Key takeaway: two competitors presented that they've moved to event-driven architectures and cut their data-pipeline latency by ~60%. Recommendation: we should pilot the same approach for our reporting pipeline next quarter—I have a contact at [Company] who offered to share their migration playbook. (Full session notes attached.)

Why it's better: The travelogue makes the reader sit through your schedule to find the one insight worth the trip; most readers quit first. The value-first version delivers the insight, the recommendation, and the follow-up contact in three sentences—and then offers the full notes for anyone who wants them. The trip's cost is justified by the recommendation, not by the list of sessions you sat through.

The feasibility study

A feasibility study is the heaviest report in this chapter and the one closest to the proposals and business cases of Chapter 20. It answers one question—should we do this thing, and can we?—by examining options against defined criteria and recommending one. It precedes a decision to commit real money or time, so its reader is a decision-maker who needs a defensible recommendation, not a data dump.

A feasibility study typically covers:

• Executive summary — the recommendation, up front, standing alone. (Chapter 20's lesson, and Chapter 13's recommendation-first technical report: the busy reader gets the answer first.)
• Background / problem — what question prompted the study and why it matters now.
• Options considered — the alternatives, including the "do nothing" baseline. A study with only one option isn't a study; it's an advocacy piece.
• Evaluation criteria — the dimensions you judged options on: technical feasibility, cost, time, risk, organizational fit. Stated before the comparison, so the reader trusts the criteria weren't reverse-engineered to favor a foregone conclusion.
• Analysis — each option scored against each criterion, ideally in a comparison table the reader can scan.
• Recommendation — which option, and why, tied explicitly to the criteria.

The structural key is the options-against-criteria comparison table, which lets a decision-maker see the whole trade-off space at a glance:

                  | Option A: Build | Option B: Buy | Option C: Do nothing
Technical fit     | High            | Medium        | —
Cost (1 yr)       | $120k           | $80k          | $0
Time to deliver   | 6 months        | 6 weeks       | —
Risk              | Medium (staffing)| Low          | High (problem persists)
RECOMMENDATION: Option B (Buy) — lowest risk, fastest delivery, acceptable cost.

That single table does what ten paragraphs of prose cannot: it lets the reader compare options on every dimension at once, see the trade-offs, and check the recommendation against the evidence. The recommendation sits below the table and above the detailed analysis—visible to a scanner, supported for a reader who digs in. This is the inverted pyramid (Chapter 4) and the recommendation-first technical report (Chapter 13) applied to a decision document: answer first, evidence below, full detail in an appendix.

🔄 Check Your Understanding A colleague's feasibility study presents only one option—the one they want to build—and spends ten pages arguing for it, with no comparison table and no "do nothing" baseline. Beyond being one-sided, why does this fail as a feasibility study specifically?

Answer

A feasibility study's entire job is to compare alternatives against stated criteria so a decision-maker can choose with confidence. With one option and no baseline, there's nothing to compare—the reader can't see what's being given up, can't judge whether the recommendation is actually best, and can't tell whether the criteria were chosen to favor the conclusion. It's structurally an advocacy document (Chapter 20's proposal), not a feasibility study. The "do nothing" baseline matters most: without it, the reader can't even tell whether acting beats not acting. A study that can't be used to choose has failed its genre.

📐 Project Checkpoint

Your Communication Portfolio's first piece is the technical report (begun in Chapter 13 with IMRaD and the recommendation-first workplace variant). This chapter adds a closely related, higher-frequency artifact and sharpens the report into something a real workplace consumes.

This chapter's increment: produce a one-page project status report for your portfolio's technical-report project, in two formats.

1. The exception-based RAG dashboard. Take whatever project anchors your portfolio (the data analysis, the small software project, the research effort—whatever you've been carrying since Chapter 13). Break it into 3–5 workstreams. Assign each an honest RAG color—and be ruthless about not defaulting everything to green. For each amber or red item, write the one-line explanation and, where relevant, the decision needed with an owner and a date. Add an "Overall" roll-up color at the top and a "Decisions Needed" line at the bottom. Keep the whole thing to one screen.

2. The progress-report version. Write the same status as a planned / done / next / blocking progress report—the format you'd send your manager. Use the verb discipline from §21.2: "Done" gets finished outcomes ("shipped," "completed," "identified the cause"), never activities ("worked on," "looked into"). Make the "Blocking" section name a real obstacle, what it blocks, and a concrete ask—or say "Nothing blocking" if that's the truth.

Then do the diagnostic that proves the format earned its keep: hand both to someone who knows nothing about your project and ask them, "What's the one thing that needs attention, and what would you do about it?" If they can answer in under a minute from the dashboard, your exception-based reporting works. If they can't, your reds are buried or your greens are too loud—revise until the answer is obvious.

This connects to your earlier increments: the recommendation-first discipline comes from Chapter 13, the BLUF headline from Chapter 4, and the one-clear-ask close from Chapter 19's emails. It previews the next: in Chapter 22 (Instructions and Procedures) you'll write documentation that tells people how to do things, where the reader is acting, not deciding—a different relationship to the reader that demands a different structure. Keep both status formats; the dashboard becomes a model you'll reuse in Chapter 27 when you write about data.

21.8 Common Mistakes and Practical Considerations

The genres differ, but the failures rhyme. Here are the ones practitioners actually make, and the judgment calls the templates can't decide for you.

Mistake 1: Reporting activity instead of outcomes. "Worked on the migration" tells the reader nothing about state. Report what finished ("migration scripts complete and tested") or what changed ("found the root cause"). If you genuinely made no completable progress, that itself is the report—and probably an amber.

Mistake 2: Everything is green (the watermelon). A status that's green every week until it isn't has failed as an early-warning system, which is most of its value. Amber is not weakness; amber is the report doing its job. If you're never amber, you're either not reporting honestly or not thinking ahead about what could slip.

Mistake 3: Blame in the incident report. "Raj pushed the bad config" is a dead end; "the pipeline allowed an unreviewed config to reach production" points at a fix. The blameless framing isn't politeness—it's the only framing that produces corrective actions that actually prevent recurrence. (Full treatment of blameless postmortems: Chapter 34.)

Mistake 4: Corrective actions and action items with no owner or date. "We should improve monitoring" is a wish. "Add memory alerts — Owner: Priya — Due: Mar 15" is a plan. The owner is one named person, never "the team." Put actions in a table with Owner and Due columns; the table format is what makes them trackable.

Mistake 5: Minutes as a transcript. Capturing the conversation instead of the outcomes produces a long document nobody reads and from which no one can extract what they owe. Record decisions, actions, owners, deadlines. Discard the debate—or compress its conclusion to a one-line context note.

Mistake 6: The travelogue trip report and the one-option feasibility study. Both bury (or omit) the thing the reader needs—the takeaway, the comparison—under a chronology or an advocacy case. Lead with value; for a feasibility study, always include the alternatives and the "do nothing" baseline.

Now the judgment calls, the "it depends":

How much detail? It depends on the reader's distance from the work and their power to act. A status update to a VP who oversees twenty projects gets one line per workstream; a progress report to a hands-on manager gets more. The further up and the busier the reader, the more you compress and the more you lead with the exception. Read your specific reader, exactly as Chapter 13 said of the academic-to-workplace report spectrum.

How often? Match the cadence to the project's volatility and the reader's need, not to a ritual. Weekly is the default for active projects, but a stable project might warrant biweekly, and a crisis might warrant daily. The worst cadence is "whenever something goes wrong," because then the very arrival of a report is bad news—and people start dreading and avoiding them.

RAG thresholds. Decide in advance what makes something amber vs. red, and apply it consistently, or RAG becomes mood lighting. A workable rule: green = on track with no help needed; amber = at risk but recoverable without escalation; red = needs a decision or resources from above you now. Write the rule down where your team can see it.

When the report is the bad news. Incident reports and red status items deliver news people don't want. Resist two temptations: softening the facts (which corrupts the record) and editorializing the blame (which corrupts the fix). State the impact plainly, keep the timeline neutral, frame the cause as a system, and make the corrective actions concrete. Chapter 19's "email that delivers bad news" applies—lead with the fact, be straight, then give the path forward.

Templates vs. judgment. The templates in this chapter are scaffolds, not straitjackets. A two-line Slack update doesn't need a five-section structure; a SEV-1 outage that ends up in front of regulators needs more than the template's bones. Use the template to make sure you didn't forget the function of each part—the headline, the exceptions, the owner, the date—then size the form to the stakes.

Frequently Asked Questions

What's the difference between a progress report and a status update?

A progress report goes to someone tracking your work in detail (a manager, a sprint team) and is built on planned / done / next / blocking. A status update rolls up many workstreams for someone tracking the whole at a glance (a program manager, an executive, a client) and is built on RAG colors plus exception-based detail. Progress reports answer "what did you get done and what's in your way?"; status updates answer "across everything, what's healthy and what needs attention?" The status update is more compressed and more scannable because its reader is further from the work.

What does RAG status mean, and when should something be amber vs. red?

RAG is Red, Amber, Green—a traffic-light health indicator. Green = on track, no help needed (the reader can skip it). Amber = at risk but recoverable without escalation (the reader should be aware). Red = off track, needs a decision or resources from above you now (the reader must act). Decide the thresholds in advance and apply them consistently; the most common failure is "watermelon" reporting, where everything stays green until it suddenly fails, which destroys the report's value as an early warning.

How do you write an incident report without blaming anyone?

Separate facts from interpretation and attack the system, not the person. Put neutral, timestamped facts in the timeline ("a config change deployed at 14:32"), and put the why in a root cause section framed as a systemic gap ("the pipeline had no required approval step"), never as a human failing ("X was careless"). Then make every corrective action a concrete change with an owner and a due date. Blameless doesn't mean no accountability—it means the report fixes the conditions that let a human error cause harm, which is the only thing that prevents recurrence.

What should meeting minutes actually contain?

Four things: decisions (what the group agreed, stated as settled outcomes), action items (concrete next steps), owners (exactly one named person per action), and deadlines (a date per action). Not a transcript of who said what. If a decision's reasoning matters for the future, add a one-line context note—but discard the back-and-forth. The test of good minutes: someone who missed the meeting can tell, in under a minute, what was decided and what they personally owe.

How long should a workplace report be?

As short as the reader's decision allows. A weekly status to a busy executive is often under 100 words—a few RAG rows and a "decisions needed" line. A progress report to a hands-on manager runs longer because the reader is closer to the work. An incident report for a serious outage is longer still, because it's a durable record. Length should scale with the reader's distance from the work and the stakes of the decision, never with how much effort you want to display. When in doubt, cut the routine and keep the exceptions.

Chapter Summary

Key Takeaways

• A workplace report is an input to a decision, not a display of effort. The reader is busy and must do something; structure everything around what they need to act.
• Report the exception, not the routine. Compress what's fine; spend your words and the reader's attention on what deviates—slips, blockers, risks, decisions needed.
• Lead with the headline (BLUF). On track or off? Incident occurred? Decision needed? The reader who reads only the first line should still get the one fact that matters.
• Outcomes, not activities. "Shipped the checkout redesign," not "worked on checkout." A reader can't act on motion.
• Owners and dates make actions real. A corrective action or action item without one named owner and a date is a wish. Put them in a table.
• Incident reports are blameless and fact-separated. Neutral timeline (what happened) apart from root cause (why, framed as a system gap). Attack the process, not the person.
• Minutes record outcomes, not the conversation. Decisions, actions, owners, deadlines—never a transcript.

Action Items

1. Adopt planned / done / next / blocking for your next progress report; demote side tasks to a parenthetical.
2. Convert your next status update to a RAG dashboard with an "Overall" roll-up and a "Decisions Needed" line; refuse to default everything to green.
3. For any incident, write a factual timeline first, then a blameless root cause, then corrective actions in an Owner/Due table.
4. Take your next meeting's minutes as a decisions-and-actions table; throw away the transcript impulse.
5. Run the one-minute test on every report: can a stranger find the one thing needing attention and say what they'd do?

Common Mistakes

Reporting activity instead of outcomes · the all-green watermelon · blame in incident reports · ownerless, undated actions · minutes as transcript · the travelogue trip report · the one-option feasibility study.

Decision Framework: Which Report, and How to Shape It

Spaced Review

A few questions reaching back, to strengthen retention.

1. (From Chapter 19) An email's subject line should be specific and action-oriented. How does that principle apply to the headline of a status update or the summary of an incident report?
2. (From Chapter 13) A workplace technical report inverts the academic IMRaD order to put recommendations first. Which two report types in this chapter most directly inherit that recommendation-first inversion, and why?
3. (From Chapter 4, bridging) Chapter 4's diagnostic was the "reverse outline"—write down each paragraph's single point and read the list. How would you adapt that diagnostic to test whether a status update is properly exception-based?

What's Next

Workplace reports are written for a reader who is deciding—approve, escalate, fix, choose. Chapter 22 (Instructions and Procedures) turns to a reader who is doing: someone with your document open in one hand and a task in the other, following your numbered steps to install software, run a procedure, or complete an SOP. That changes everything about how you write—the reader won't read sequentially, they'll skip to step 7; a missing warning isn't a style flaw but a safety hazard; and the only real test of your instructions is whether someone who has never done the task can succeed with them alone. The shift from "reader as decision-maker" to "reader as actor" is the next move in your professional-writing toolkit.

Practice: Exercises · Quiz Go deeper: Case Study · Case Study 2 Review: Key Takeaways · Further Reading