Technical Case Study Writing
Quantifying impact, decision framing, before/after comparisons, causation language, and dual audiences
Case study writing essentials
- Impact formula: before → after → multiplier → downstream business metric
- Decision framing: problem that forced the decision + alternatives considered + rationale
- Before/after: same metric, same units, comparable conditions — no cherry-picking
- Causation: attribute specifically + acknowledge confounding factors — honesty builds credibility
- Dual audience: business impact up front, technical depth in labelled sections engineers can drill into
Question 0 of 5
Which sentence most effectively quantifies the impact in a technical case study?
Before → after → multiplier → downstream business metric. Impact quantification formula:
- Before: "45 minutes" — anchors the reader to the starting point
- After: "3 minutes" — the result
- Multiplier: "18×" — makes the improvement intuitive without requiring mental arithmetic
- Downstream metric: "ship 4× more frequently with zero increase in rollback rate" — connects the technical improvement to business value
- Option A ("significantly improved") — "significantly" is vague; it means nothing without numbers
- Option B ("much better") — same problem
- Option D — describes the mechanism (parallelisation, caching) but omits the impact; a reader can't quote this to a manager or stakeholder
A case study paragraph reads: "We decided to migrate to a microservices architecture." What is missing?
Every major decision needs: the problem that forced it + the alternatives considered and rejected. Decision framing formula:
- ❌ "We decided to migrate to microservices" — no context for why
- ✅ "Our monolith was causing 4-hour deploy windows that blocked all teams. We evaluated strangler-fig extraction (too slow for our timeline), a module-based monolith (didn't solve the deployment coupling), and a microservices migration. We chose microservices because we needed independent deploy pipelines within 6 months."
- Problem: "4-hour deploy windows that blocked all teams" — the pain that made the status quo unacceptable
- Alternatives considered: signals the team thought critically, not just followed a trend
- Decision rationale: "needed independent deploy pipelines within 6 months" — gives readers the constraint that drove the choice
Which approach correctly frames a "before/after" comparison in a technical case study?
Before/after both need the same metrics at comparable conditions. Comparative framing rules:
- Same metric: "response time" measured both before and after — not different metrics
- Same units: both in milliseconds — not mixing "seconds" and "ms"
- Comparable conditions: "under 500 concurrent users" (before) vs. "under 2,000 concurrent users" (after) — the "after" actually handles 4× more load
- Both the primary metric AND the quality metric: response time + timeout rate — prevents cherry-picking
- Comparing peak load before with average load after (misleading)
- Showing improvement in isolation without the baseline ("340ms response time" means nothing without knowing the before)
- Using different metrics for before and after (switching from "error rate" to "uptime")
How should you distinguish correlation from causation when attributing improvements in a case study?
Attribute specifically + acknowledge confounding factors — be honest, not defensive. Causation language in case studies:
- Strong attribution: "We rolled back the rate limiter change and the error rate dropped within 60 seconds" — timing makes causation clear
- Qualified attribution: "We attribute the improvement primarily to X — though Y may have contributed" — honest when multiple changes happened simultaneously
- Correlation only: "Error rates fell during the same period we deployed X" — use when you can't isolate the variable
- Engineering audiences are sceptical — overclaiming gets caught
- Acknowledging confounding factors shows methodological rigour
- Future teams reading the case study need accurate attribution to make decisions — false causation leads to the wrong lessons
A technical case study is being read by both senior engineers and engineering managers. How should you structure it to serve both audiences?
Business impact summary up front + labelled technical depth sections below — managers stop reading when satisfied, engineers continue. Dual-audience structure:
- Opening (both audiences): "We reduced our checkout abandonment rate by 22% by cutting page load time from 4s to 340ms" — manager-readable, engineer-interesting
- The narrative (both): problem → what we tried → what worked — accessible language
- "Technical deep dive" section (engineers only): explicitly labelled so managers know it's optional; contains architecture diagrams, code patterns, implementation specifics
- Lessons learned (both): transferable insights in plain language