Case Study 2: One Piece, From Charter Draft to Revised Final

A composite "Deep Dive," fictional but realistic. It traces a single portfolio piece across the whole arc of the book—from a writer who hadn't yet learned any of this to one who has—so you can see the growth narrative as evidence rather than claim.

The most persuasive artifact in a portfolio is the one that shows the writer changing. This case study is that artifact, slowed down. It follows one paragraph—the opening of a data-analysis memo—from the rough version a writer produced early, before the book's lessons landed, to the version in the finished portfolio. Both describe the same finding from the same analysis. The difference is everything the book teaches, applied.

The writer and the subject

Mateo Salgado chose, in his Chapter-1 charter, to write about his team's deployment pipeline. His charter's honest line was: "I'd like to be able to make leadership care about reliability work, which they currently see as a cost." Hold onto that line; the whole case study is about closing the gap it names. Early in the book, as a Chapter-13/Chapter-27 exercise, he drafted a memo to his VP of Engineering about deployment failures. Here is the opening he wrote then—competent, sincere, and wrong in a way he couldn't yet see.

Before: the charter-era draft

In order to assess the reliability of our deployment process, we undertook an analysis of all production incidents occurring over the previous two quarters. Incidents were categorized by root-cause type (configuration, code defect, infrastructure, and external dependency) and the mean time to recovery was calculated for each category. The data was then segmented by whether the incident occurred before or after the migration to the new CI/CD pipeline in March. A total of 47 incidents were analyzed. After controlling for severity, several patterns emerged in the data, which are discussed in detail below. The configuration category showed the highest frequency, followed by code defects…

Read it as the VP would. She wants to know one thing—is our reliability getting better or worse, and do I need to spend money on it?—and this opening makes her excavate for it. Diagnose the failures by the book:

• Method-first order (Chapter 27's "methodology wall"). The first four sentences are apparatus—how the analysis was done. The reader climbs over root-cause taxonomies and recovery-time calculations before reaching anything she can act on. The finding is somewhere "below."
• Nominalizations and expletives (Chapter 3, Chapter 6). "In order to assess," "we undertook an analysis," "patterns emerged in the data which are discussed"—the prose is padded with the throat-clearing the book spent two chapters cutting. "We undertook an analysis of incidents" is just "we analyzed incidents."
• No "so what?" (Chapter 27's ladder). It stops at observation ("configuration showed the highest frequency"). It never reaches interpretation, let alone a recommendation. It hands the VP a number and leaves the hardest step—deciding what to do—to the reader least equipped to take it.
• Wrong audience entirely (Chapter 2). The register, the detail, the order are all built for a peer auditing the analysis, not for an executive deciding a budget. It's not a bad analysis. It's a memo written for the wrong reader.

Mateo, at the time, was proud of it. It was thorough and accurate. That pride is the curse of knowledge (Chapter 2): he was reading his intention—"I'm showing my work"—not his sentence, which buried the only thing the reader needed.

The diagnosis (the self-assessment that drove the fix)

When Mateo assembled his portfolio in Chapter 40, he ran the §40.4 rubric-walk on this memo. The scored dimensions: leads with the recommendation — Fail. Every finding answers "so what?" — Fail. Method demoted and sized to the reader — Fail (it's at the front and dominant). One page — Fail (the method crowded it to two). One sentence of diagnosis: "The single weakest dimension is order—the method is first and there's no recommendation; the revision is to lead with what leadership should do and demote the method to a footnote." That sentence is the revision, already designed. The prose work just executes it.

After: the revised final

We should fund a configuration-management fix this quarter, and here's the number that makes the case: since the March pipeline migration, configuration errors have caused 60% of our production incidents and the longest outages—averaging 95 minutes to recover, versus 22 for everything else. That's roughly 40 hours of customer-facing downtime in two quarters traceable to one fixable cause. The migration itself worked—overall incident frequency is down—but it shifted our failures from code to config, and config is where we're now bleeding time. A one-engineer, one-quarter investment in automated config validation would target the category responsible for most of our downtime. (Full analysis—47 incidents, categorized and segmented pre/post-migration, with the one caveat that our observation window is short—in the appendix.)

Now read it as the VP. The first sentence is a recommendation in her currency (fund a fix, this quarter). The evidence that justifies it follows immediately, quantified in the unit she cares about (60% of incidents, 95-minute outages, 40 hours of downtime, one fixable cause). The method—the whole apparatus that opened the draft—is demoted to a single parenthetical with its honest caveat (Chapter 13's calibrated honesty). It fits on a third of a page.

What changed, level by level

The transformation walked down Chapter 12's editing hierarchy, and the order matters:

• Structure (first): recommendation-first, not method-first. This one change fixed three rubric dimensions at once and is the §40.5 / Chapter 27 move. Everything else followed from it.
• Content: he pushed every finding down the "so what?" ladder—observation ("config causes most incidents") → interpretation ("the migration shifted failures from code to config") → recommendation ("fund config validation"). Only the recommendation is actionable, and now it leads.
• Sentences and words (last): he cut the nominalizations ("undertook an analysis" → "analyzed," then cut entirely), killed the expletives, and put the numbers in the reader's terms. He did this after the structure was settled, so he never polished a sentence he was about to move (Chapter 12's discipline).

Why this is the portfolio's best evidence

Mateo put both versions in his portfolio, in an expandable "How this memo changed" panel, and referenced it as the centerpiece of his growth narrative. It closes the loop on his charter's honest line: he can now make leadership care about reliability work—not by asserting it matters, but by leading with the recommendation and quantifying the stakes in their currency. The before/after proves the meta-skill (§40.5): he can see and fix his own writing. A reader who sees this doesn't just believe Mateo improved—they watch the improvement happen, sentence by sentence, and conclude that the next memo he writes on the job will get the same treatment. That conclusion, not any single polished document, is what the portfolio is for.

Back to: Chapter 40 · Case Study 1 · Exercises