A $100 million manufacturer isn't simply a $50 million manufacturer doing twice as much work. Growth doesn't happen that neatly. As a company gets bigger, it adds customers, products, people, suppliers, equipment and locations, but it also adds something much harder to see: combinations. Every new customer brings their own mix of products, pricing, specifications, shipping requirements, contacts and expectations. Every new product has to make its way through sales, estimating, engineering, purchasing, production, inventory, documentation and customer service. Add another location or an acquisition and you may introduce entirely different systems, processes and ways of working.
That's why complexity has a nasty habit of growing faster than revenue. The individual pieces aren't necessarily the problem. It's the number of ways those pieces begin interacting with each other.
You usually don't notice this happening at first because the business keeps working. When a process doesn't quite handle something, somebody figures out how to make it work. The estimator knows which products can actually be modified. Someone in customer service remembers that a particular customer requires a different label on every shipment. The scheduler knows you can't really run that job on Line 3 even though the system says you can. Engineering knows which two products look interchangeable in the ERP but absolutely aren't.
Over time, these workarounds become part of how the company operates. From the outside, it can still look like a well-run business. Orders go out, customers get answers and problems get solved. But listen closely to how the work actually gets done and you'll start hearing things like, "Ask Mike," "I have a spreadsheet for that," "The system says that, but..." or "That's how we do it for this customer."
Those little phrases tell you a lot about how much complexity the organization is carrying around.
There's no "complexity" line on the P&L, but the company is paying for it.
You see it in a quote that takes three days because someone needs an answer from engineering. It's the customer service rep who has to open four systems to answer a fairly basic question. It's the meeting that exists because three departments don't have the same information. It's the employee who takes six months to train because half the job consists of learning things that aren't written down anywhere. Eventually, it's the additional person you hire because a department simply can't keep up anymore.
I've started thinking about this as a complexity tax. You don't get an invoice for it. You pay it a few minutes at a time through another lookup, another email, another phone call, another manual entry, another exception and another workaround. None of those things seems particularly expensive on its own, which is why the cost is so easy to miss. Multiply them across hundreds of employees, thousands of orders and an entire year and they become very real.
More importantly, the complexity tax changes the economics of growth. If every 20% increase in revenue requires 20% more people to handle the additional quoting, customer service, engineering questions and administrative work, the company may be growing, but it isn't really scaling.
This doesn't mean manufacturers should try to eliminate complexity. For many companies, their willingness to handle complexity is exactly why customers buy from them.
Maybe you'll manufacture a configuration your competitor won't. Maybe you handle difficult applications. Maybe you provide customer-specific testing, packaging or documentation. Maybe your sales team can confidently say, "Yeah, we can do that," when everyone else says no. That complexity is creating value, and customers are willing to pay for it directly or indirectly.
The complexity worth attacking is the stuff the customer couldn't care less about. Entering the same information into multiple systems doesn't make the product better. Passing spreadsheets between departments doesn't create a competitive advantage. Calling someone to interpret information that's already buried somewhere in the business doesn't improve the customer experience. Maintaining three versions of the same product data isn't a differentiator.
That's accidental complexity. Most companies didn't intentionally design it into the business. It accumulated over years as customers were added, systems changed, acquisitions happened and employees found practical ways to keep things moving.
Growth just makes the bill bigger.
Manufacturers already understand this concept extremely well on the plant floor. If you're planning to increase production by 30%, you're going to think about capacity. Can the machines handle it? Do we have enough labor? What happens to material flow? Where are the bottlenecks? Do we need another shift or another piece of equipment?
Nobody would intentionally push 30% more volume through a production line without asking those questions.
We don't always apply the same thinking to the rest of the business. What happens when quote volume increases 30%? What happens when you add another 5,000 products? What happens when a large customer suddenly wants detailed compliance documentation for every product they purchase? What happens when an acquisition adds another product catalog, another sales team and another ERP?
Can engineering absorb it? Can customer service? Can your quoting process? Can your product data? Can the systems connecting all of those functions?
Those are capacity questions too. They're just harder to see than a machine that's already running three shifts.
And that's where a lot of growing manufacturers eventually find themselves. The plant may have plenty of capacity to produce more, while the organization around the plant is struggling to absorb the complexity that comes with selling, configuring, scheduling, documenting and supporting more.
Eventually, that pressure tends to trigger a technology conversation. The company needs a new ERP. Or CPQ. Or a new commerce platform. Better reporting. AI. Some of those investments may be exactly right, but new technology doesn't automatically remove complexity. Sometimes it just gives the company a more modern place to put it.
Before choosing the technology, it's worth understanding where the complexity actually comes from. Which parts exist because customers value them? Which parts are remnants of how the company used to operate? Where are employees compensating for gaps in systems or processes? Where does critical knowledge live in someone's head? Where does adding more volume automatically require adding more people?
Those questions tell you a lot about whether the business is actually capable of scaling.
A process that worked extremely well when the company was $30 million may start struggling at $60 million and become a serious constraint at $100 million. That doesn't necessarily mean it was a bad process. It may have been exactly the right process for the company that existed at the time.
The company changed. The way it operates didn't.
That's the part of growth we don't talk about enough. We spend a lot of time thinking about how to generate more revenue, increase production and win more customers. We spend less time thinking about whether the rest of the organization is capable of absorbing everything that comes with that growth.
Because eventually, scaling isn't just about figuring out how to do more.
It's about making sure that "more" doesn't make everything else harder.