The Long Letter: Why Rising Complexity Is One of the Biggest Unsolved Leadership Tasks

Published: 17 July 2026

Complexity acts on security, controllability, cost and accountability at the same time. Whoever reduces the self-inflicted share moves all four with the same lever.

In 1657, Blaise Pascal apologised for writing a long letter. His reasoning still holds up today: he hadn’t had time to write a short one.¹ Centuries later, Axel Haitzer put the same idea into a single sentence that every executive team should take to heart: “Whatever hasn’t been fully thought through demands many words.”²

Put these two sentences side by side and you hold the key to a problem most organisations pay for dearly, year after year, without ever putting it on the agenda or naming it in a cost statement. Complexity is rarely a sign of maturity. It is mostly the visible trace, and therefore the proof, of decisions nobody thought through to the end, whether from time pressure, missing skills or missing information. Every postponed prioritisation, every avoided consolidation, every exception left standing makes the letter longer.

I see this pattern regularly in companies: process landscapes that often nobody can fully explain any more, system architectures that grew over years because adding was always easier than tidying up, governance structures that answered every new requirement with another committee and another checklist. In one project, I watched a single operational process accumulate so many special-case detours over the years, running across the whole organisation, that in the end nobody could explain the full flow in one go any more, let alone the reasons behind its many branches. Not out of negligence. Every single addition made sense on its own, but taken as a whole it became, at least in part, pointless. The result, though, burdens the whole organisation day after day with costs that show up explicitly nowhere.

Why Complexity Keeps Growing

Complexity keeps increasing in many organisations for a basic reason: adding something is visible, gets rewarded, and usually solves an acute problem. Leaving something out is invisible work, creates short-term resistance, and calls into question a decision someone once made. “Don’t touch a running system” or “Never change a winning team” are two sentences, or rather one underlying attitude, that illustrate this behaviour.

That is why the comfortable path almost always increases complexity. Without deliberate counter-steering, an organisation does not drift towards simplicity on its own, because holding onto simplicity is a genuine challenge, not least because the parties affected often defend their own complexity with considerable effort.

The Missing Head for the Whole

Behind this sits a deeper cause, one I consider the actual root. We have massively deepened specialist expertise over the decades. For almost every subfield, there are now recognised specialists: in IT, in cybersecurity, in AI, in law, in regulation, in finance and in tax. What has become rarer is the integrative role, the one that still understands the sum of these subfields and pulls them together. The polymath of old cannot realistically be revived at today’s depth of knowledge. Even so, what’s missing is someone, or a team spanning several disciplines, both willing to claim that scope and willing to take the time (call it the extra mile) to understand and judge fields beyond their own. Being accountable for the whole without understanding the parts, at least in broad strokes, is more than just a big challenge. Of course, many aspects and tasks can be delegated, but when it comes to accountability, delegation is no longer enough.

The mechanism behind this is well understood. The finer the specialisation, the more interfaces appear, and every interface carries a cost in coordination and mutual dependency. Past a certain point, these coordination costs eat back up the productivity gain that specialisation created.³

What reduces friction here is not less specialisation. It is more shared basic understanding, the thing specialists need to actually assemble their contributions into a whole. That is exactly the value an integrating role delivers. Understanding the whole means understanding the interactions between the parts, and those interactions do not arise from breaking things down into disciplines. They arise only through synthesis.⁴

On top of that comes a structural effect: organisations build systems that mirror their own communication structure. Conway’s law describes exactly that.⁵ If an organisation consists of siloed departments, that fragmentation migrates one to one into the architecture, interfaces and all. The friction is then not accidental. It is drawn in advance by the org chart.

Here is the crucial distinction: the existence of specialists is not the defect, because specialisation is fundamentally productive and no longer reversible today. The defect is the absence of the integrative function that holds the whole together. Not every interface is redundant either; some reflect real diversity in markets, products or regulation, and belong there. Other interfaces, however, are often just the fossilised imprint of historically grown org-chart boundaries. That is where the real lever sits.

One Cause and One Accountability, Three-Plus Kinds of Cost

These two forces, the tendency to add and the missing integrative function, together produce self-inflicted complexity. It is the shared root cause, and it presents at least three separate bills: a larger attack surface, a loss of controllability, and a permanent financial burden. Above these three sits accountability. It is not a fourth cost category. It is the level at which reduction gets decided. Once you see this structure, you see the lever too. You are not working three separate problems. You are working one cause with a threefold effect.

Security

Bruce Schneier coined the phrase that complexity is the worst enemy of security.⁶ The logic is unassailable. More components mean a larger attack surface. Less overview means less visibility. Many connected parts create nonlinear dependencies, where a small fault at one interface can endanger the whole.

The trajectory of known vulnerabilities backs this up. The number of newly logged entries in the CVE system rose from roughly 18 a day in 2016 to about 133 a day in 2025, with a projection of nearly 50,000 entries for the full year.⁷ One observation from the defensive side itself is particularly uncomfortable: cybersecurity itself has become a driver of complexity, because modern security architectures consist of a large number of specialised systems, each justified on its own. Taken together, they build an armour that itself needs managing, updating and monitoring, and that opens new points of attack in the process. Anyone who pursues security purely by adding more tools buys part of the problem they were trying to solve.

Controllability

Complexity behaves much like entropy: a system in use grows more complex over time, for as long as nobody actively works to reduce it.⁸ That observation originates in software, but it carries over to grown process and organisational landscapes just as well. A useful distinction helps here, between two kinds of complexity.

One kind sits in the problem itself and cannot be removed.
The other kind we add to ourselves.⁹

The larger and more expensive part is usually self-inflicted, and the self-reinforcement is measurable and provable. Over six decades, genuine business complexity rose more than sixfold, while organisational complexity rose roughly 35-fold.¹⁰

Organisations meet more requirements with more structures, processes and metrics, and in doing so create most of their own burden. The effect is insidious, because every single structure was created as a response to a real problem. It’s only in the sum that the result tips over. At some point, nobody has the whole picture any more, and what nobody can see, nobody can steer. In a crisis, this shows up immediately, because there is no time left to have your own system explained to you.

Economics

Complexity is a permanent tax that nobody voted for. Estimates from a vendor-backed survey, best read as an order of magnitude, put the loss at roughly seven per cent of annual revenue and one in every five francs of the software budget. Employees lose nearly seven hours a week on average to complicated processes and fragmented tools.¹¹ Multiply that by headcount, week after week.

In a real incident, particularly in cybersecurity, the bill gets even higher. High system complexity raises the average cost of a data breach by more than USD 1.4 million, compared with low-complexity environments.¹² This tax runs quietly, but without interruption. It burdens normal operations and sharpens costs in a crisis. What makes it uncomfortable is that it shows up as such in no balance sheet line item. It hides in longer project timelines, in duplicated work, in maintenance contracts for systems that hardly anyone uses any more, and in the time good people spend on detours instead of value creation.

Accountability

This is where the circle closes back to Pascal. Whoever doesn’t think things through shifts the cost downward and forward in time, onto operations, onto security, onto the next generation of leadership. The long letter is comfortable for the writer and expensive for every recipient. The short letter costs the writer time and mental effort and spares everyone else both.

Complexity reduction is therefore not just a technical chore for IT or operations. It is, rather, a leadership and governance duty. It starts at management level, because in many cases that is the only place with the authority to leave things out, consolidate, and end exceptions. Leaving something out is a deliberate leadership decision. Adding is usually just the path of least resistance. This accountability cannot be delegated away either. Anyone who simply outsources a complex landscape to external providers hands off tasks, but not the risk, and certainly not the accountability. A board that treats cyber risk, cost pressure and poor controllability as separate agenda items unfortunately overlooks that it is dealing with the same root cause three times over.

A Management Debt That Gets Passed On

You can read this accumulated complexity as a form of debt and credit. In software development, the term technical debt is well established. A quick fix today saves work now but creates a liability that has to be repaid later, with interest. Ben Horowitz coined the same idea for leadership and called it management debt.¹³ Today’s convenient decision, the postponed prioritisation, the exception that never got closed out, is a liability that keeps running through operations, security and the cost structure.

What makes this debt uncomfortable is that it is rarely settled by the people who took it on. It gets passed on, to operations, to the next generation of leadership, to whoever takes over the role next. At that point, it runs into the second problem. Without the integrative function, without a head that still understands the sum of the parts, this debt can hardly be paid down properly. You cannot reliably consolidate what nobody can see in full any more. It is a debt whose books, in the end, nobody can fully read.

Not every instance of complexity is a failure, and not every legacy burden can be pinned on a single leadership team. Some of it is inherent to the business itself, some grows with the market and with regulation. But the self-inflicted part is a leadership decision, whether actively made or passively allowed. Not paying it down is also a decision, just one whose costs someone else carries.

Why These Levels Belong Together

The good news lies in the structure of the problem itself: precisely because the three costs share the same origin, self-inflicted complexity, reducing that root cause can act on multiple levels at once. Secure systems, controllable processes and affordable costs are not three separate projects. They are three effects of the same lever, with two handles. One is removing the interfaces that only mirror an org-chart boundary. The other is a named role accountable for the coherence of the whole.

One caveat belongs here too: reduction only works on the self-inflicted share, not on the complexity that is inherent to the problem itself. A regulated financial institution cannot remove its regulatory reality. But it can reduce the sheer number of tools, exceptions and special-case workarounds it uses to cope with that reality. That is exactly where the gain sits, one that shows up on several levels at once.

It would equally be a mistake to confuse simplicity with mere reduction. Radically stripping down a system without understanding its purpose creates a new kind of risk. Simplification is therefore not a cost-cutting exercise. It is intellectual work. It requires knowing the purpose of a system or process precisely enough to know what can genuinely be dropped and what cannot. Simplicity is not less thinking. It is more of it, done upfront. It is the short letter someone actually took the time to write.

What This Means for Leadership

For boards and executive teams, this leads to an uncomfortable question for the next meeting. The question is not: “What more can we add to get better?” It is: “What can we leave out without getting worse, or even while getting better?” And right after it, a second question: “Which of our interfaces reflect genuine diversity, and which just reflect our org chart?” In my experience, that second question tends to spark good, sometimes heated discussions that take real time, and that is exactly as it should be.

Whoever asks these questions regularly, and actually answers them, writes shorter letters. Shorter letters are safer, more controllable and cheaper all at once, because they come from the same piece of thinking. Reducing complexity is not a tidy-up job on the side. It is a permanent, recurring leadership task that lowers all three cost categories at the same time.

References

Blaise Pascal, “Lettres provinciales” (“Provincial Letters”), Letter 16 (1657).
Axel Haitzer, quoted as provided by the author.
Gary Becker and Kevin Murphy, “The Division of Labor, Coordination Costs, and Knowledge,” Quarterly Journal of Economics (1992). Core idea: the division of labour is limited by coordination costs, not by market size alone. nber.org/system/files/chapters/c11238/c11238.pdf
Russell Ackoff on systems thinking: the essential properties of a system lie in the interactions of its parts, not in the parts themselves; understanding the whole comes through synthesis, not through decomposition (W. Edwards Deming Institute). See also Fred Brooks on conceptual integrity, footnote 9. deming.org/ackoff-on-systems-thinking-and-management
Conway’s law (Melvin Conway, 1968): systems mirror the communication structure of the organisation that designs them. Wikipedia: Conway’s law
Bruce Schneier and Anthony Vance, “Complexity Is the Worst Enemy of Security,” MIS Quarterly (2025); the phrase originates in Schneier’s Crypto-Gram (2000). schneier.com/academic/archives/2025/03/complexity-is-the-worst-enemy-of-security.html
CVE growth based on NVD data; NIST, “NIST Updates NVD Operations to Address Record CVE Growth” (2026). nist.gov/news-events/news/2026/04/nist-updates-nvd-operations-address-record-cve-growth
Lehman’s laws of software evolution: a system in use increases in complexity unless work is actively done to reduce it. Wikipedia: Lehman’s laws of software evolution
Fred Brooks, “No Silver Bullet” (1986), on the distinction between essential and accidental complexity, and “The Mythical Man-Month” on conceptual integrity, which only a few minds or a single chief architect can safeguard. warwick.ac.uk/…/conceptual_integrity.pdf
Yves Morieux, Boston Consulting Group, Complicatedness Index; see also his “Smart Simplicity” approach to strengthening integrating roles. bcghendersoninstitute.com/in-conversation-with-yves-morieux-about-complexity
Freshworks, “Cost of Complexity” (2025). Note: a vendor-backed survey, to be read as an order of magnitude. freshworks.com/pressrelease/…
IBM and the Ponemon Institute, “Cost of a Data Breach,” figure from the 2023 edition. ibm.com/reports/data-breach
Ben Horowitz, “Management Debt,” Andreessen Horowitz (2012). a16z.com/author/ben-horowitz/management_debt