Ask Why Five Times

I was working with a client that had a problem they'd been complaining about for over two years: quote turnaround was too slow. Brokers were furious. The operations team was exhausted. Every quarter, leadership funded another patch: a new dashboard, a new SLA report, a new "underwriter productivity initiative." Nothing moved.

I sat down with the head of one of the teams and asked one question. Then I asked it again. Five times.

Quotes are slow.
  Why? → The underwriter is overloaded.
  Why? → She spends half her day re-keying data from broker emails.
  Why? → Submissions arrive as PDFs and we don't parse them.
  Why? → The Acord ingestion project stalled three years ago.
  Why? → The original sponsor left and nobody owned it after.

Five whys. Roughly five minutes. The "our underwriters are too slow" complaint became a clear, cheap, fundable project: restart Acord ingestion, scope it to a single quarter, name an owner. That was the fix. Not a productivity initiative. Not another dashboard. A scoped engineering project with a name attached to it.

Two years of patches. One conversation. The cheapest tool in my CTO toolkit isn't a framework or a stack — it's the discipline to keep asking why when the room wants to move on.

Where It Comes From

The technique is older than I am. Sakichi Toyoda, the founder of what became Toyota, used "five whys" on the factory floor as part of what would later be codified as the Toyota Production System. The idea was simple: when a machine breaks, don't replace the part. Find out why the part broke. Then find out why that happened. Keep going until you hit something you can actually change.

There's nothing magical about the number five. Toyoda picked it because it tended to land you at a real cause without disappearing into philosophy. Sometimes you get there in three. Sometimes you need seven. The number isn't the discipline — the willingness to keep asking is.

Insurance Runs on Symptoms

If you've worked inside an Insurance organization for any length of time, you already know what I'm about to say. Insurance operations are layered geology. Every year somebody adds another reconciliation report, another reminder email, another bordereau check, another reason an analyst's morning is full before they've answered an email.

Each one of those was, at some point, a reasonable response to a symptom. None of them fixed the underlying cause. The cause is still there. The patches are now technical debt that humans carry around in their workdays.

A few examples I've watched the five-why drill cut clean through:

Notice how often the answer is organizational, not technical. That's not an accident. Most "technology problems" in insurance aren't technology problems. They're ownership problems wearing a technology costume.

Often Less Than Five

The honest version of the rule is "ask why until you hit something you can do something about." Sometimes that's two whys. The deploy failed — why? — because the runbook is wrong — why? — because nobody updated it after the last migration. There's the fix. Don't keep going just because the chain is short.

Sometimes it's seven. Insurance regulatory issues love to bottom out at "because the carrier requires it" or "because state X writes rules differently than state Y." Those aren't dead ends. They're constraints. Once you've named the constraint, you stop fighting it and start designing around it. That's still a root cause — just one you absorb instead of remove.

You stop when the next answer would either be unactionable ("because humans are humans") or off the rails ("because capitalism"). The goal is a sentence that ends in a verb your team can actually do.

Where It Goes Wrong

I'd be lying if I said this technique was universally great. It has real failure modes, and pretending otherwise is how methodologies become cargo cults.

It's a chain, not a tree. Most real problems have multiple converging causes. A linear five-why drill picks one branch and follows it to the floor. You'll get a real cause — but maybe not the dominant one. For genuinely complex incidents, fishbone diagrams or full RCA frameworks beat it. The five-why is the cheap, fast, ninety-percent-of-the-time tool, not the only one.

The asker's bias loads in. Whoever runs the chain decides which "why" to follow. If you walked in convinced the underwriting platform is the problem, you'll find a path that ends at the underwriting platform. Garbage in, confident garbage out. The fix is humility — running the same chain with a different person and seeing if they end up in the same place.

Tone is everything. Asked badly, "why?" five times is an interrogation. People close up, get defensive, point fingers downward. Asked well, it's collaborative archaeology — you and the other person digging together. The form is identical. The result is opposite. If you can't ask without making someone feel accused, the technique fails before it starts.

It needs data. A five-why drill on instinct alone is just a confident chain of guesses. The version that works is anchored in something real — a log, a metric, a recorded customer call, a number on a P&L. Without evidence at each step, you're not finding root causes. You're confirming priors.

It Works Outside the Office Too

I'll be careful here, because the genre of "executives discovering universal life lessons in their methodology" is its own special kind of insufferable. But I do use this in my own life, and I'd be hiding the ball if I pretended otherwise.

"I'm always tired." Why? Because I sleep badly. Why? Because I check my phone in bed. Why? Because the charger is on the nightstand. The fix isn't a sleep tracker. It's a six-foot extension cord and a different spot for the phone.

"I keep losing weekends to the laptop." Why? Because Monday's stack always feels too big to start fresh. Why? Because Friday's open threads stay open. Why? Because there's no Friday ritual to close them. Three whys. The fix is a thirty-minute Friday review — not more discipline, not more hours.

The discipline isn't technical. It's the willingness to stay with a question one beat past comfortable. Most of the time, comfortable is exactly where the symptom lives. The cause is just on the other side of it.

The Drill

If you want to actually run this in a meeting tomorrow, here's the version that fits on a napkin:

The Bottom Line

Most bugs aren't bugs. Most slow processes aren't process problems. Most "people problems" aren't people problems. They're symptoms of something one or two layers down that nobody had the patience to chase.

Patience is the whole game. Five questions. Five minutes. Asked of the right symptom with the right tone, it has rescued more of my engagements than any architecture diagram I've ever drawn.

I work as a fractional CTO with MGAs, TPAs, and insurance broker, usually starting with the symptoms leadership is tired of patching. If quote turnaround, premium leakage, or a stalled platform program sounds familiar, get in touch or book a call.