Strip away the slide decks and consulting problem-solving is a small set of habits for attacking ambiguous problems under time pressure with incomplete information — which is a fair description of most incidents, most architecture decisions, and most of the work that gets called "senior". The methods are worth borrowing regardless of what you think of the industry that produced them.
1. Define the problem before solving anything
Consultants spend a disproportionate amount of time writing a single problem statement, because a well-framed problem is specific, measurable, actionable, and time-bound. "The app is slow" is not a problem statement. "Checkout p95 latency rose from 400ms to 2.1s after the 12 March release, costing an estimated 4% conversion; we need it back under 600ms within two weeks" is — and notice that it already tells you where to look and when you are done.
2. Lead with a hypothesis
The instinct to gather all the data first is expensive and usually never terminates. Instead, state your best guess at the answer up front — the day-one answer — and then design the cheapest analysis that could disprove it. This is the scientific method with a deadline, and it is exactly how good debugging already works: you do not read the entire codebase, you form a theory about which layer is lying and test it.
3. Decompose MECE
Mutually Exclusive, Collectively Exhaustive: break the problem into buckets that do not overlap and that together cover everything. It is the same discipline as a well-designed switch statement — no gaps, no duplicates.
Checkout p95 latency regression
├── Client (bundle size, render blocking, network waterfall)
├── Edge / network (TLS, CDN misses, region routing)
├── Application (new code path, N+1, serialization, GC)
├── Data layer (query plan change, lock contention, cache hit rate)
└── Dependencies (payment gateway, fraud service, auth)
Each branch: what would make it true? what is the cheapest test?The tree matters less than what it forces: enumerating the branch you were about to skip. Most long incidents are long because everyone searched the same branch for three hours.
4. Do the 80/20 pass first
Before deep analysis, find the biggest number. Which endpoint carries most of the traffic? Which query is most of the database time? Which customer segment is most of the revenue? A quick, rough answer on the dominant factor beats a precise answer on a marginal one, and it usually reframes the problem. Consultants call this the 80/20; engineers call it "profile before optimizing". Same instinct, same reason it works.
5. Communicate with the pyramid principle
Answer first, then the three-or-so supporting arguments, then the evidence beneath each. Barbara Minto's structure exists because busy readers decide whether to keep reading in the first two sentences, and because a recommendation buried at the end of a chronological narrative is a recommendation nobody acts on. Practically: your incident summary starts with "we should roll back release 481; here is why", not with what you tried at 02:14.
- The elevator test — if you cannot explain the problem, your answer, and the reason in ninety seconds, you do not have it yet.
- So what? — after every finding, ask it. A fact with no implication does not belong in the summary.
- No surprises — pre-brief the people who will be affected before the meeting where the decision lands.
- Force the insight — a chart everyone nods at has told you nothing. Look for what contradicts your expectation.
Where the method fails
Hypothesis-driven work invites confirmation bias — you must actively look for the evidence that kills your theory, not the evidence that flatters it. MECE trees can become a decomposition ritual that substitutes for actually reading the code. And a confident, well-structured presentation of a wrong answer is more dangerous than an unstructured right one. The discipline is a way to move fast under uncertainty, not a way to be right without evidence.