Complexity Drains Your OPEX

Cables — Credits: Kier in Sight Archives - Unsplash.

A new tool can simplify one task while making the surrounding system harder to operate.

Its license, infrastructure, and support contract appear in Total Cost of Ownership (TCO). The coordination, troubleshooting, duplicated work, and context switching it creates usually do not. They remain distributed across tickets, meetings, pipelines, and people’s time.

Complexity becomes economically relevant when it repeatedly consumes operational capacity.

Complexity is not only difficult to understand. It is expensive to operate.

What Complexity Is↗

Complexity is often used as a synonym for size. A system has many services, many repositories, or many tools, so it must be complex. Size matters, but it is not the whole problem.

Complexity is the amount of knowledge, state, coordination, and interaction required to understand, change, or operate a system safely.

Two systems can contain the same number of components and impose very different costs. One has stable interfaces, explicit ownership, and predictable failure modes. The other depends on hidden state, informal knowledge, manual handoffs, and fragile integrations.

The components are easy to inventory. Complexity hides in their interactions.

components are visible
interactions create the hidden cost

Three forms of complexity are useful in this discussion:

Form	Source	Reducibility
Problem complexity	The real-world domain and its constraints	Rarely reducible
Implementation complexity	Languages, abstractions, tools, and design choices	Often reducible
Operational complexity	Interactions between systems, teams, processes, and time	Partially reducible, always governable

Problem complexity exists because the domain is difficult. Implementation complexity appears in how that problem is represented and solved. Operational complexity emerges when the solution must be deployed, integrated, changed, secured, and kept running over time.

The Kanso Framework focuses on this third form. It asks how complexity is experienced during operation and how much recurring effort that experience consumes.

Five Views of Complexity↗

The following perspectives do not describe the same problem at the same scale. Together, however, they explain how complexity moves from software design into daily operations.

Fred Brooks: Separate Essence from Accident↗

In No Silver Bullet, Fred Brooks separates the essential complexity of software from its accidental complexity.

Essential complexity belongs to the problem being modeled. Business rules, conflicting constraints, and the relationships inside a domain do not disappear because a team changes language or framework.

Accidental complexity comes from representing and implementing that model. Poor tools, awkward languages, unnecessary layers, and weak design can make an already difficult problem harder than it needs to be.

The distinction matters because implementation choices can reduce accidental complexity. Essential complexity cannot be removed, but it can be represented, contained, and managed.

Kanso applies a related distinction to operational work. Its unavoidable and avoidable frictions resemble Brooks’s categories, but they are not exact synonyms. Essential complexity is not the same as unavoidable friction, and accidental complexity is not the same as avoidable friction. Brooks describes the difficulty of constructing software. Kanso classifies operational resistance and the cost it creates across software, people, tools, and processes.

John Ousterhout: Reduce the Burden of Change↗

John Ousterhout defines complexity through its effect on the person changing a system. His Stanford material on the nature of complexity identifies three symptoms:

Change amplification: a small change requires modifications in many places.
Cognitive load: completing a task requires holding too much information in mind.
Unknown unknowns: important dependencies exist, but it is unclear where they are or whether they must be considered.

These symptoms do not stop at source code. Operationally, change amplification means one deployment requires several repositories, approval systems, and teams. Cognitive load means only a few people understand how to recover a service. Unknown unknowns mean a routine change can break an undocumented dependency.

The common cost is attention. The system consumes more knowledge and coordination than the task itself should require.

Linus Torvalds: Remove the Special Case↗

In a 2016 TED interview, Linus Torvalds explains good taste with two ways to remove an element from a linked list. One implementation treats the first element as a special case. The other changes the representation so the same operation handles every position.

The important idea is not the shorter function by itself. It is choosing a model that makes exceptional paths unnecessary.

Operational systems accumulate exceptions easily: one deployment path for a legacy service, another approval for a particular team, and a manual recovery step that only applies on weekends. Each exception appears local. Together they become the normal operating model.

Kanso asks whether the flow can be reordered before another condition is added. Sometimes the simplest improvement is not a new abstraction. It is a better representation of the problem.

Alan Kay: Contain Complexity↗

Alan Kay’s The Early History of Smalltalk describes systems built from autonomous objects that retain and protect their own state, communicate through messages, and bind behavior late.

The relevant idea is containment. A component should expose a narrow way to interact while keeping its internal decisions local. Consumers should not need to understand every detail behind that boundary.

Encapsulation does not make complexity disappear. It decides where that complexity must be understood. A boundary is useful only when its contract is clear and its interactions remain predictable. Splitting one opaque system into many opaque services merely distributes the confusion.

Rob Pike: Count the Combinations↗

In Simplicity is Complicated, Rob Pike argues that languages often grow by borrowing features from one another. They become larger and more similar without necessarily becoming better.

The cost of a feature is not limited to learning it in isolation. It can combine with every existing feature, convention, tool, and exception. The visible addition may be small while the number of possible interactions grows.

The same is true of operational platforms. A new tool brings its own identity, permissions, telemetry, lifecycle, failure modes, and ownership. Its local value may be real. Its system-wide cost depends on how all those properties interact with what already exists.

The Kanso View↗

Kanso moves the conversation from complexity as a design quality to complexity as an operating cost.

Friction is the natural resistance of an ecosystem to the introduction of a new element.

That resistance continues to appear as the element is integrated, changed, and operated. Friction is how complexity becomes visible in work.

Friction	Meaning	Treatment
Unavoidable	Required by the domain, regulation, physical limits, or a mitigation whose cost exceeds its benefit	Accept, contain, document, or partially automate
Avoidable	Created by redundancy, manual work, fragile integration, recurring errors, or unnecessary approval	Eliminate, standardize, automate, or redesign

Unavoidable friction is the natural cost of operating a solution in its actual context. Security patches must be applied. Regulatory evidence must be produced. Geographic latency cannot be designed away.

Avoidable friction exists because the system runs less cleanly than it could. The same report is produced twice. Credentials are rotated manually. Three teams coordinate a change that could be expressed as policy. A failed integration is repaired every week but never redesigned.

Brooks: essential / accidental complexity
Kanso:  unavoidable / avoidable operational friction

The first distinction explains why some difficulty remains. The second asks how that difficulty consumes operational capacity and whether the recurring cost is necessary.

How Complexity Drains OPEX↗

Complexity does not appear in OPEX as a line named “complexity.” It appears as time.

new component
      |
      v
more interactions
      |
      v
coordination + waiting + rework + troubleshooting
      |
      v
recurring operational hours
      |
      v
OPEX overhead

The Kanso model separates the minimum cost of operation from the overhead created by avoidable friction:

Cost of Complexity = Natural OPEX + OPEX Overhead

Kanso Index (KI) =
    OPEX Overhead / Scoped Operational OPEX x 100

Scoped Operational OPEX = Natural OPEX + OPEX Overhead

Natural OPEX is the minimum human operational cost required to run the measured system. OPEX Overhead is the human operational cost consumed by avoidable friction. The Cost of Complexity is their sum within that scope. In this model, it is the same total represented by Scoped Operational OPEX.

The numerator and denominator must use the same team, system, period, and cost basis. If the numerator measures one platform for a month while the denominator covers an entire organization for a year, the result says nothing useful.

KI measures scoped human operational effort. It does not represent every accounting category inside corporate OPEX. It is a directional instrument for comparing the same scope over time, not an accounting standard.

TCO answers what it costs to own a solution throughout its lifecycle. The Cost of Complexity asks how much human effort is required to keep that solution working inside a particular ecosystem. They overlap, but they are not interchangeable.

A Practical Example↗

Consider a hypothetical twelve-person infrastructure team that introduces a second observability platform. The purchase appears justified: it solves a real gap and its license fits the budget.

After adoption, three recurring frictions emerge:

Friction	Monthly effort	Classification
Maintaining a brittle alert adapter	20 hours	Avoidable
Triaging duplicate alerts	24 hours	Avoidable
Reconciling dashboards manually	16 hours	Avoidable

At a blended cost of $60/hour:

60 hours/month x $60 = $3,600/month
                     = $43,200/year

The license is visible in TCO. The recurring sixty hours are OPEX overhead distributed across engineering work.

Not every cost belongs in that overhead. Initial onboarding, secure configuration, required data retention, and necessary platform maintenance may be unavoidable. The duplicated alerts, manual reconciliation, and brittle adapter are not inherent to observability. They come from how this tool was integrated into this system.

Kanso does not begin by removing the platform. It begins with evidence:

Record the three frictions in the Friction Ledger.
Confirm their scope, frequency, and time cost.
Separate necessary operation from avoidable overhead.
Run a Friction RCA on the avoidable work.
Apply the countermeasures it produces.
Measure the same scope again after one month.

Here the countermeasures were consolidating alert routing, removing the duplicated dashboards, and automating credential renewal for the adapter. Another system with the same three frictions could need different ones.

The example ends with measurement because an intervention is still a hypothesis. A change that consumes more effort than it recovers has not reduced operational cost. It may only have moved the friction.

From Friction to Action↗

Kanso uses a small operating loop:

detect -> classify -> quantify -> analyze -> act -> measure again

Detect finds the friction through evidence. Useful sources include ticket wait times, pipeline retries, incident records, logs, and short interviews with the people doing the work.

Classify separates unavoidable operation from avoidable overhead. The goal is not to label every inconvenience as waste.

Quantify turns hours into cost. The Friction Ledger records the affected scope, time, cost, evidence, and proposed action. Complexity stops being a general complaint and becomes a specific operating condition.

Analyze asks why that condition exists. The Friction RCA examines the technical, organizational, and process dimensions behind a single friction.

Act applies a proportional response: eliminate, standardize, automate, redesign, or contain.

Measure again confirms whether the change recovered capacity. The Harmony Board tracks that trend over time.

The complete process and its artifacts are described in the Kanso Framework.

Design Principles↗

The five perspectives lead to a practical set of decisions:

Preserve essential complexity; remove accidental complexity.
Make changes local when possible.
Reduce the context required to operate safely.
Change the representation before adding special cases.
Encapsulate unavoidable complexity behind explicit boundaries.
Treat every new feature, tool, and process as a recurring interaction cost.
Use automation to remove friction, not preserve a bad process.
Standardize only variation that does not create meaningful value.

Local simplicity can export complexity to the rest of the system.

A team can make its own workflow easier by adding a tool, approval, or adapter that creates work elsewhere. Optimization is meaningful only when the measured boundary includes the people and systems receiving that work.

Limits↗

Complexity is not automatically waste. Some domains are difficult because the stakes, rules, or physical constraints are real.

Not every friction should be eliminated. A control that prevents a critical failure may be worth its cost. Reducing one team’s burden may only transfer it to another team. Automation can make a flawed process faster and more permanent. Standardization can erase differences that the domain actually requires.

KI should measure systems and flows, never rank individual workers. Operational friction is evidence about design, ownership, and interaction. It is not a proxy for personal productivity.

Every intervention also carries its own maintenance. Automation, standards, and new boundaries need upkeep, and that cost belongs in the same ledger as the friction they replaced.

Conclusion↗

Complexity is a property of the system. Friction is how that complexity is experienced. OPEX overhead is how repeated friction becomes economic cost.

Brooks helps separate what belongs to the problem from what was added to it. Ousterhout shows how complexity burdens understanding and change. Torvalds demonstrates the value of removing special cases. Kay shows how boundaries can contain complexity. Pike warns that additions create combinations, not isolated costs.

Kanso connects those ideas to operation. It makes friction visible, separates the necessary from the avoidable, and measures whether intervention recovers capacity.

Complexity is inevitable. Simplicity is intentional.

Explore the Kanso Framework.