The Pareto Trap: why 80/20 thinking breaks down in IT delivery

Every delivery leader I know quotes the 80/20 rule. Most of us, me included, apply it more loosely than we admit.

Focus on the 20% that drives 80% of the value, cut the rest, move on. It sounds obvious. In IT delivery it is also one of the ideas most likely to quietly cause damage — not because Pareto is wrong, but because it is often the wrong lens.

This piece is not a refinement of Pareto. It is a case for when it is the wrong lens, and what to use instead. Years of running compliance technology programmes — where getting this wrong shows up as a regulatory finding rather than a missed sprint — have made me more careful about when to reach for 80/20 and when to leave it in the drawer.

Where Pareto genuinely applies

To be fair to the principle, it does show up. Roughly 20% of software modules generate 80% of production incidents. A small set of features drives most user adoption. A handful of stakeholders shape most decisions. As a way to spot patterns, useful. The trouble starts when it stops being a pattern and becomes a decision rule.

Where 80/20 breaks

The naive version goes: if 20% of the effort creates 80% of the value, focus on that 20% and ignore the rest. In IT delivery, the ignored 20% often destroys the valuable 80%.

Edge cases in sanctions screening (unusual spellings, aliases, names in different scripts) look like the low-value 20%. Miss one and you have a regulatory fine no feature list can offset. Disaster recovery looks like the boring 20%; one outage undoes a year of feature credibility. The 5% of dirty records nobody cleans up generate 80% of the exception cost, forever. The operational manuals nobody reads today are exactly what you need on a 2 AM incident call.

In regulated industries, the ignored 20% carries risk that outweighs the entire 80%. Starving it is not efficiency. It is a debt you are hiding, and it collects interest.

But the opposite mistake is real too

For every programme that got burnt by ignoring the tail (the long list of rare cases), there is another that drowned in it. I have seen a compliance rollout where the team spent nine months building for every conceivable edge case: obscure name variants, workflow branches for scenarios the business had never seen, exception paths for regulators who were not ours. The programme went late, and when we launched, most of that engineered tail sat unused while the core workflow was clunky.

So the argument is not “chase the tail.” It is “know which tail you are chasing, and why.” That is harder than either 80/20 or full-coverage thinking, and it is where most of the real judgement in delivery lives.

A better model: three tiers, not one rule

Rather than asking “what is the 20% that matters?” across the whole portfolio, I sort delivery effort into three rough tiers. They overlap in practice, but the sorting is still useful.

Tier 1 — Pareto applies. Product features, user experience, reporting. Prioritise the 20% that drives adoption. Kill the long list of nice-to-haves without guilt.

Tier 2 — Pareto inverts. Compliance controls, security, resilience, the ability to prove what happened after the fact. Full coverage is the minimum bar. You cannot cover 80% of a sanctions rule set. The edge cases are the whole point.

Tier 3 — Pareto is irrelevant. Team capability, knowledge sharing, paying down old shortcuts, recording why decisions were made. These compound over time. Under-investment does not create a crisis today; it creates a slow, invisible tax on every future delivery.

The mistake most of us make when the pressure is on is applying Tier 1 logic to all three tiers. That is what causes operational manuals to get cut and design rationale to live only in someone’s head.

The documentation and governance question

Nowhere does this show up more clearly than in the perennial question every delivery lead has heard:

“Do we really need to spend this much effort on documentation and governance? It doesn’t ship code. Can we skip it?”

The Pareto answer is: cut the 80% that adds no direct value, keep the 20% that does. It sounds disciplined. It is the wrong question. The right one is which parts are Tier 1, which are Tier 2, and which are Tier 3.

Most enterprises get this wrong in both directions at once: status decks nobody reads, wiki pages last updated two years ago, meetings that just restate the agenda — all while the reasoning behind a screening rule change is buried in a chat thread.

A test you can use on Monday

Before producing any document or scheduling any meeting, I try to ask three questions. They are not a decision rule; anyone attached to a document can produce a plausible “yes” to all three. But they are a useful way to force the conversation.

How long will it stay useful? A design decision might be referenced for years. A weekly status slide is stale in seven days.

What is the cost if it is missing? A missing operational manual turns a 30-minute recovery into a six-hour outage. A missing meeting minute is an inconvenience.

Will many people use it, many times? Onboarding material compounds with every new joiner. A one-off report doesn’t.

Long shelf-life, high cost if missing, repeated use across many people: invest heavily. Low on all three: stop producing it. The test is only as honest as the person applying it. It is a prompt for a judgement, not a replacement for one.

Governance: control or theatre

Governance has the same problem as documentation, but sharper. Good governance decides, manages risks, controls scope, escalates early. Bad governance looks busy and produces nothing: meetings reviewing the same issues, approval chains that slow decisions without adding rigour, steering committees that end without a decision recorded.

A real example, from some years ago. On a compliance platform programme, we inherited four separate meetings covering the same delivery: a weekly working group, a fortnightly design review, a monthly steering committee, and a risk review. In practice, the same open risks were walked through in three of them, the same slides reformatted for each audience, the same items “noted” week after week without an owner. The programme office was spending two days a week just preparing packs.

Plenty of people had noticed. Nothing had changed because the problem was political: each forum had a sponsor, and challenging the meeting felt like challenging the sponsor. When we finally forced the question — what decision has this meeting actually made in the last three sessions? — two of the four could not point to one. Collapsing them was still a fight; one sponsor pushed back and I had to escalate, another agreed publicly, then quietly kept an informal version going for weeks before it faded.

What stuck was a single weekly delivery meeting with the decision log at the top of the deck. The design review and steering committee stayed. Roughly 30% of governance overhead disappeared, once you honestly counted the unofficial shadow meetings too, and decision quality went up, because the right people were finally in the room.

The lesson was not that governance is waste. It was that we had confused activity with control, and unpicking that is a political exercise as much as an analytical one.

The rough rule I now apply: if a meeting has not produced a decision or a mitigated risk in three consecutive sessions, it deserves a hard look. Not automatic death — some forums exist to prevent bad decisions, and “no” is a legitimate output — but a serious question about whether it still earns a place in the calendar.

The regulated industry angle

In banking, compliance, healthcare, the argument tilts further, with an honest caveat.

Regulators do not accept “we delivered fast” as a defence. They accept evidence. A minor audit finding, left unaddressed, becomes a formal instruction to fix it — what some regulators call a Matter Requiring Attention (MRA). That escalates to formal action, and formal action is a problem for the CEO and the board. A screening rule change without recorded reasoning is an automatic finding.

The caveat: in a regulated environment, you do not decide unilaterally what documentation is wasteful. The regulator and internal audit both have a view, and either can override yours. “Cut aggressively” needs qualifying: cut what you can defend cutting, build the case for the rest. The reframe still holds: documentation and governance are part of what you deliver, not the cost of delivering it.

So — cut documentation and governance?

No. But cut the wrong documentation and the wrong governance where you have the standing, and build the case for the rest. Next time someone argues it is consuming too much effort, don’t defend it and don’t cut it. Ask a better question.

“Which 30% of what we produce is generating 90% of the assurance value, and can we stop producing the other 70% — or at least stop pretending the rest is equally important?”

That question is defensible with sponsors, credible with auditors, honest with engineers, and — unlike the usual debate — actually solvable, one artefact and one forum at a time.

Closing thought

Pareto is not wrong. It is just not the only tool in the box, and reaching for it as a reflex is where most of us — me included — get into trouble.

The 80/20 rule works when the value is concentrated and the rest is safe to ignore. It fails when the rest carries the real risk, and it fails again in the opposite direction when we chase edge cases nobody will ever hit and call it rigour. The judgement to tell them apart is the actual job.

Sort the portfolio honestly. Apply Pareto where it works. Guarantee coverage where it inverts. Invest continuously where it is irrelevant.

---

If this resonated, I’d be curious to hear where you’ve seen Pareto genuinely help — and where you’ve seen it quietly break, in either direction. The comments are open below.