Consider a specialty coffee roaster that starts with six blends sold wholesale to cafés. Over four years it adds retail bags, a subscription, private-label contracts, two marketplaces, seasonal single origins, and a handful of bespoke grind profiles for larger accounts. Revenue climbs every year. Margin does not. Nobody can point to the moment it went wrong, because operational complexity reduces profitability in a way that never appears as a single line on the income statement. It arrives as fifteen minutes here, a second approval there, a packaging exception that only one person on the floor remembers.
That invisibility is the whole problem. If complexity sent an invoice, it would have been cancelled years ago.
The cost is paid in coordination, not in units
Ask a finance team what it costs to add one more product variant and you will usually get a unit-economics answer: materials, a bit of packaging, some shelf space. That answer is almost always right and almost always irrelevant.
The real cost sits one layer above the unit. It is the extra forecast, the extra supplier conversation, the extra line on a pick list that someone occasionally misreads, the extra SKU that needs a photo and a description and a price review, the extra question in a sales call, the extra reason an order gets held for clarification. None of these is expensive. All of them are recurring, and nearly all of them are absorbed by people who are already on payroll.
This is why growth-through-addition feels free. Salaried time looks like a fixed cost. When your operations manager spends an extra forty minutes a day untangling exceptions, no new expense appears anywhere. What disappears instead is the capacity she would have used to improve something. The bill arrives later, as a hire that feels necessary but cannot be traced to any specific revenue.
A peer-reviewed study of the global service provider industry makes this mechanism explicit. Researchers found that complexity arising from coordinating different services and operations pushed profit margins down through higher coordination costs, while sophistication within particular services could push margins up through informational advantages. Same word, two opposite effects, separated by where the complexity lives.
Stored complexity versus staffed complexity
Here is the distinction I would put at the centre of any decision about adding something new.
Stored complexity is complexity a system holds for you. More rows in a database. More variants in a catalogue. More configurations in a product. Once the system is built, each additional item costs close to nothing to carry.
Staffed complexity is complexity a person has to hold. An exception only one employee understands. A pricing rule that lives in someone’s head. An approval step that requires judgement. A customer who gets different terms for reasons nobody documented.
Staffed complexity compounds brutally because it multiplies at every handoff. Stored complexity mostly does not. The useful question before adding anything is therefore not “how many more things will we have?” but “how many more times will a human have to decide something?” If the answer is zero, you have probably added very little. If the answer is “every order,” you have added a permanent tax.
This test also explains why old blanket advice to cut variety has aged badly in some settings. Shopify raised its product variant limit to 2,048, with the supporting GraphQL Admin API version released in April 2024, and reported that creation time for products at that limit improved tenfold over the project while single-variant products became 33% faster in the admin. More than 6,500 app partners migrated to the new APIs. That is a platform deliberately converting what used to be staffed complexity into stored complexity. A merchant with a deep catalogue in 2026 is not carrying the same operational burden a merchant with a deep catalogue carried a decade ago.
The corollary matters just as much: complexity your systems cannot absorb is far more dangerous than the raw count suggests. Two thousand variants on infrastructure built for them is cheaper than forty variants managed through spreadsheets and memory.
Exceptions have no expiry date
The single most underrated source of staffed complexity is the one-off favour. A customer asks for a different invoicing cycle. A distributor wants a non-standard pallet configuration. A good client needs an extra approval in the sign-off chain. Each is granted as a temporary accommodation and then never reviewed again, because nobody owns the job of reviewing it.
Five years of generous exceptions produce an operation where almost nothing is standard and nobody can say which parts of the process are actually required. This is the quiet reason saying no is a core growth skill. Every yes to an exception is a yes in perpetuity unless you attach a review date to it, and almost nobody does.
How much of this is actually evidenced?
A great deal of writing on this topic recycles dramatic percentages: complexity drains some fixed share of revenue, inefficiency erodes a quarter of the top line, delay costs a predictable premium. I have not found trustworthy primary sources behind the common versions of those figures, and I would not build a decision on them. Treat any round, unattributed percentage about complexity cost as marketing until you can read the study.
What does hold up is narrower and more interesting.
A survey reported by Knowledge at Wharton with George Group found that 64% of respondents said a small portion of products or services accounted for all operating profit at their companies. The same report argued that portfolio and process complexity is often a bigger drag on profit and growth than any other single factor in a business. That is from 2006, and the specific number is a survey of perceptions rather than audited accounts, but the pattern it describes is one almost every operator eventually recognises in their own books.
In the academic literature, a Journal of Operations Management article reported that firms with higher product portfolio architectural complexity had profit margins on average 3% lower than other firms, citing Hoole (2006). A Production and Operations Management study of U.S. airlines using quarterly data from 1988 through 2013 found that carriers with higher operational complexity faced higher future financial distress. Production economics researchers have gone further and studied variety-induced complexity cost factors specifically for their impact on product profitability, which tells you the field now treats variety as a margin question rather than only a factory question.
And the honest counterweight: a 2026 study of Indonesian coal companies found no significant effect of operational complexity on earnings after tax in that sample. Complexity is defined and measured differently across industries and datasets, and the result is not uniform.
So I would state it this way. Complexity is a frequent and well-documented profitability risk with a clear causal mechanism. It is not a law of nature. Anyone who tells you complexity always destroys margin is overselling, and anyone who tells you it never does has not looked at an airline.
Often the problem is not complexity. It is unpriced complexity.
This is the gap I find most consequential, and it is missing from almost every article on the subject.
Suppose a fabrication shop runs standard jobs at a published price and also takes custom work. The custom work requires engineering time, a longer approval chain, non-standard material, and a slower changeover. If it is quoted on the standard rate card plus a modest uplift, that work will destroy margin, and management will conclude that custom work is unprofitable.
The conclusion is wrong. Custom work is unprofitable at that price. The complexity is real, the cost is real, and the customer is simply not paying for it. Before you prune a product line, check whether you have ever actually charged for the coordination it requires. Plenty of “complexity problems” are pricing failures wearing a disguise.
The reverse case is equally common and worth guarding against. Some complexity genuinely cannot be priced because customers do not perceive it. Nobody pays a premium because you run three inventory systems. So the practical filter becomes two questions:
- Would the customer notice if this disappeared? If no, it is pure cost, and the only question is how fast you can remove it.
- Would they pay more to keep it? If yes, it is a product feature you have been giving away. Price it. If no, it is a habit.
Complexity the customer values and pays for is called differentiation. Complexity the customer cannot see is called overhead. Firms get into trouble by confusing the two in both directions, protecting invisible processes out of sentiment while bundling genuinely valuable custom work into a flat fee.
The digital stack is now a major source of complexity
Older discussions of this topic assume complexity is physical: SKUs, factories, warehouses. For a service firm or an online seller, the heaviest complexity now sits in the software and payments layer.
Stripe’s own guidance on running multiple payment providers is unusually candid about the trade-off. Using several providers can improve payments performance or reduce costs on some transactions, but it often creates extra complexity and may demand additional engineering, operational, and partnership resources. Stripe also warns that each added provider is another potential point of failure, with planning required around card-data management, latency, and resource allocation.
Read that as a template, not just payments advice. The older instinct was that adding a provider is an obvious optimisation, because the comparison was a rate card against a rate card. The current framing is conditional: it pays only if you can carry the operational burden. The same logic applies to a second CRM, a third analytics tool, a second fulfilment partner, or a specialist app layered onto an ecommerce stack to solve one narrow problem.
Complexity can also be imposed from outside. Amazon has acknowledged that its 2025 U.S. referral and FBA fee changes, including new fee types, introduced complexity for sellers, while pointing to improved fee calculators, fee-preview tools, and inbounding estimates. If you sell on a marketplace, part of your margin management is absorbing someone else’s design decisions about packaging and shipping thresholds. That is not a failure of internal discipline, but it does need to be budgeted for as real work.
What large companies actually do about it
The public filings are more useful here than the consulting literature, because the actions are specific and the results are reported.
3M stated that its 2023 restructuring to streamline the organisation, remove legacy systems, and simplify supply chains generated over $400 million of savings in 2023 alone, and linked supply-chain simplification to improved service, margin expansion, and increased cash conversion. Note what is bundled together there. Simplification did not only cut cost. It improved service levels and freed cash. That triple effect is the part the cost-cutting framing tends to miss.
Sonoco described simplifying its portfolio around fewer, scaled market-leading businesses as a way to reduce operating complexity and improve agility, and reported an EBITDA margin of 16.9% in its annual report covering 2025. Dover listed product complexity reduction alongside automation, footprint utilisation, strategic pricing, and portfolio management as the levers it uses to improve margin and return on capital.
The pattern worth stealing is not the scale. It is the framing. These companies treat complexity reduction as a standing operating discipline sitting next to pricing and capital allocation, not as a turnaround measure deployed after a bad year. Notice also that Dover puts complexity reduction and strategic pricing in the same list. Those two levers belong together, for the reason described above.
How to tell whether your complexity is earning its keep
Most dashboards cannot see this problem, because the costs are distributed across labour, working capital, rework, software subscriptions, and management attention. You need measures built for the question.
Profit concentration, not revenue concentration
Rank every product, service line, channel, and customer segment by operating profit after allocating the coordination work each one actually consumes. Do it crudely rather than not at all. If a small group carries all the profit while a long tail hovers near zero, you have found your answer, and the long tail is most likely subsidised by the attention of your best people. This is the single highest-value analysis in the whole exercise, and it is close to the method behind finding the most profitable part of your business.
Exception rate
What share of orders, jobs, or contracts deviates from the standard path? Track it monthly. A rising exception rate is the earliest reliable signal that margin will soften, and it usually moves well before the financials do.
Decisions per transaction
Count the human judgements required between order and delivery. Approvals, clarifications, manual lookups, held orders. This is staffed complexity made countable, and it is the number that actually drives cost.
Trend, not snapshot
One period tells you very little. The U.S. Small Business Administration recommends that established businesses include income statements, balance sheets, and cash flow statements covering the last three to five years in a business plan, and that horizon is the right one here too. Complexity creeps. You see it by watching gross margin, inventory turns, and headcount against revenue over several years, not by examining one quarter and declaring a verdict.
Where I would actually start
Given a choice between aggressive simplification and better pricing with better systems, I lean toward selective simplification first, but not for the usual reason. Cutting the tail is rarely where the big money is. Cutting the tail is where the attention is, and attention is the resource you need in order to do the harder work of repricing and re-engineering.
So the sequence I would recommend is roughly this. Kill the exceptions nobody can justify, because they cost the most per unit of revenue and the least to remove. Then review pricing on everything that survives, especially custom and semi-custom work, since some of what looks like a complexity problem will turn out to be profitable at a correct price. Then consolidate tools and providers where the operational burden exceeds the gain. Only then prune the catalogue, and prune it based on allocated profit rather than revenue.
Resist the temptation to simplify everything at once. Complexity that customers value and pay for is a competitive asset, and businesses that strip it out indiscriminately end up cheaper, faster, and interchangeable. The goal is to carry only the complexity you are being paid for, in systems that can hold it without consuming your people. Everything else is a slow leak, and slow leaks are the ones that never get fixed, because nobody can hear them.
If this pattern feels familiar, the related question is structural rather than operational: whether the model itself gets heavier as it grows. That is the test behind deciding whether your business model can scale, and it is worth asking before you add the next thing.
