Case Study 2 — The Same Findings, Two Reports: IMRaD vs. Recommendation-First

A composite, fictional-but-realistic scenario. The setting, the people, and the numbers are invented but typical. This is a Deep Dive into the single decision that separates someone who can only write for a professor from someone who can write for a boss: the same evidence, restructured for two completely different readers.

The situation

Maya Okonkwo is a reliability engineer. Her team's checkout service has been timing out under load, and she's spent three weeks finding out why. She built a test harness, replayed production traffic at increasing concurrency, profiled the hot paths, and traced the failures to a database connection pool that exhausts at high load. She tested a fix — raising the pool size and adding a circuit breaker — and the timeout rate dropped from 4.1% to 0.2%.

Now she has to write it up. And she has to write it up twice, because two different readers need it:

• The platform engineering team, who will review her methodology, possibly reproduce her benchmark, and need every parameter — a near-academic audience.
• Her director, Priya, who has a budget meeting in twenty minutes and needs to decide whether to approve the infrastructure change — a workplace decision-maker.

Same three weeks of work. Same findings. Two reports that look almost nothing alike — because, as Chapter 13 puts it, structure serves how the reader uses the document, and these two readers use it in opposite ways.

Report 1 — the engineering report (IMRaD order)

For the platform team, Maya writes a near-textbook IMRaD report. The conclusion comes last, earned by the methods and results that precede it, because this reader evaluates the evidence before accepting the claim.

INTRODUCTION
The checkout service has exhibited intermittent request timeouts
under peak load since the October traffic increase. The cause was
unconfirmed. This report identifies the bottleneck and evaluates a
proposed mitigation.

METHODS
Production traffic from [date range] was replayed against a staging
replica using a custom load harness (k6, v0.47) at concurrency levels
from 100 to 2,000 simulated users in steps of 100, holding each level
for five minutes. Request latency (p50, p95, p99) and timeout rate
were recorded. The application was profiled with [profiler] during the
1,500-user runs. The proposed fix — connection-pool size raised from
20 to 100 and a circuit breaker (5 s timeout, 50% error threshold) —
was applied and the full sweep re-run under identical conditions.

RESULTS
Timeout rate remained below 0.1% up to 1,200 concurrent users, then
rose sharply, reaching 4.1% at 2,000 users (Figure 1). Profiling at
1,500 users showed 78% of request time spent waiting to acquire a
database connection. With the pool increase and circuit breaker
applied, timeout rate at 2,000 users fell to 0.2%, and p99 latency
dropped from 3.8 s to 0.9 s (Figure 2).

DISCUSSION
The connection-pool exhaustion is consistent with the observed
connection-wait time dominating request latency under load. Raising
the pool size addresses the immediate bottleneck; the circuit breaker
bounds the failure when an upstream dependency is slow. These tests
used a single staging replica and replayed traffic; behavior under
genuinely novel traffic patterns, or with the database itself as the
bottleneck at higher pool counts, was not tested and is the next step.

This is right for the platform team. A fellow engineer who doubts the diagnosis can check the methodology, see the connection-wait profiling, and even rerun the sweep. The conclusion is earned. (Note the Results stay clean — "78% of request time spent waiting to acquire a connection" is an observation; the interpretation that this is the bottleneck waits for the Discussion. Same discipline as Case Study 1.)

Report 2 — the report for Priya (recommendation-first)

Now Maya sends "the report" to her director. If she sends Report 1, Priya has to read through a methodology she didn't ask for to reach the one sentence she needs — and she has twenty minutes. So Maya flips the hourglass: recommendation first, methods demoted to an appendix.

❌ Before (Report 1's academic order, forwarded to Priya): "The checkout service has exhibited intermittent timeouts under peak load since October. To diagnose this, we replayed production traffic against a staging replica using a custom load harness at concurrency levels from 100 to 2,000 users, recording latency and timeout rates, and profiled the application during the 1,500-user runs… [400 words of methodology] …we therefore recommend raising the connection-pool size and adding a circuit breaker, at an estimated $0 in new spend but requiring a maintenance window."

The recommendation is buried 400 words deep behind a methodology Priya will never read. For the platform team that build-up was the point. For a director deciding in a budget meeting, it's an obstacle.

✅ After (recommendation-first technical report):

Executive Summary

We recommend raising the checkout service's database connection-pool size (20 → 100) and adding a circuit breaker. In load testing, this cut the peak-load timeout rate from 4.1% to 0.2% and p99 latency from 3.8 s to 0.9 s. The change requires no new spend, only a 30-minute maintenance window. We request approval to deploy in the next release window (Thursday).

Findings (summary) - Root cause: the connection pool exhausts above ~1,200 concurrent users; at peak, 78% of request time is spent waiting for a database connection. - Impact today: 4.1% of checkout requests time out at peak load — roughly [N] failed checkouts per peak hour. - After the fix: timeout rate 0.2%, p99 latency under 1 s, at the same load. - Risk: low; the change is config-level and reversible. One untested case (database as bottleneck at higher pool counts) is flagged for follow-up.

[Full methodology, load-test parameters, and profiling detail in Appendix A — also filed as the engineering report for the platform team.]

Why the second version works

Priya can decide from the first paragraph: the recommendation, the measured benefit, the cost (none), the risk (low), and the action-with-deadline are all in five sentences. The findings she needs to sanity-check the call are a scannable four-line list. The methodology — the k6 sweep, the profiler, the concurrency steps — still exists, in the appendix, for the one engineer on her team who will dig in. Nothing was dumbed down and nothing was hidden; the same rigor sits behind both reports. Only the order changed, because the reader changed.

The deep point: these are not a good report and a bad report. They are the same report, correctly aimed at two readers. Sending Report 1 to Priya would bury the decision; sending Report 2 to the platform team would strip the evidence they need to trust it. Maya wrote both because she knows the four questions are constant (why / what I did / what I found / what it means) but their order and emphasis must serve whoever is reading. That is the workplace-vs-academic distinction of §13.8, and the audience principle of Chapter 2, made concrete.

The takeaways

1. Same evidence, opposite structure — driven by the reader. Academic readers evaluate, so the conclusion is earned and comes last; workplace readers act, so the recommendation leads (§13.8).
2. Lead with the recommendation and the ask. For a decision-maker, sentence one is the recommendation; the opening paragraph must stand alone, and it ends with the action and a deadline.
3. Demote the methods — don't delete them. Credibility still matters and someone will check, so the methodology moves to an appendix, not the trash. (Maya's appendix is the engineering report — write the rigorous version once, attach it.)
4. Recommendation-first is not evidence-free. The recommendation leads, but a scannable findings summary must back it up, or the report is just an opinion (§13.8).
5. Match length to the reader. A one-page report that gets read beats a twenty-page report that gets skimmed. Know which reader you're writing for before you choose the structure.

One sentence to remember: When someone says "send me the report," ask yourself who's reading and what they'll do with it — the peer who must evaluate your evidence and the boss who must make a decision need the same facts in opposite orders.