The Complexity-Matching Fallacy

Definition

The instinctive response to a complex problem is to build a correspondingly complex solution — a regulation, procedure, or menu of options detailed enough to anticipate every case. Sull and Eisenhardt argue this instinct is wrong: because a complex system's parts interact in combinatorially many ways, no set of rules can be exhaustive enough to cover them, and the resulting complicated solution overwhelms the very people it's meant to guide — driving down both compliance and effective decision-making.

In the Book

The book's clearest evidence is regulatory bloat: the Basel I banking accord ran 30 pages in 1988, Basel II ballooned to 347 pages sixteen years later, and Basel III doubled that again; the Glass-Steagall Act that governed U.S. banking for seven decades was 37 pages, while its successor Dodd-Frank was projected to reach 30,000 pages with supporting legislation; the U.S. tax code alone runs to 3.8 million words. The book uses a Lego-block combinatorics puzzle to make the underlying mechanism vivid — mathematicians spent decades believing six Lego blocks could combine 103 million ways before massive computing power revealed the true figure was 915 million — to argue that if professional mathematicians can't map the combinations of six blocks, no legislature can envision every contingency in banking or tax law. The chapter then shows complexity backfiring on its own goals: a forty-five-country study found tax-code complexity was the single best predictor of whether citizens evade taxes, beating the top marginal rate, education, income, and perceived fairness combined; forty-five tax professionals given identical data produced forty-five different tax bills for the same fictional family, ranging from $36,322 to $94,438; and 401(k) enrollment fell from 75% to 61% as employers added more investment options, even when employers matched contributions dollar for dollar.

Why It Matters

This reframes "add more detail" as a default failure mode rather than a safe default. Whenever a system designer faces rising complexity — in law, in organizational policy, in a product's configuration options — the instinct to cover every edge case with an additional clause or setting is exactly the move that erodes both the designer's ability to reason about the system and the user's ability to comply with or use it. The corrective isn't necessarily fewer requirements but a different shape of solution: a small number of rules that leave room for judgment on the specifics, rather than an exhaustive specification that tries to leave nothing to chance.