The Hidden Complexity of Success

A growing company can be profitable, popular, and seemingly healthy while quietly outgrowing its processes.

There’s an awkward stage in the life of a successful small business when nothing is obviously wrong. Customers are buying. Revenue is growing. Employees know what they’re doing. Problems come up, but someone usually figures them out. From the outside, the business looks healthy because it is healthy.

What’s much harder to see is how much effort everyone may be putting in behind the scenes to keep it that way.

We’ve been seeing this with a small, Texas-based manufacturer we’re working with right now. The company has roughly 20 employees and makes a distinctive physical product that it sells directly to customers and through wholesale partners. They originally came to us for help with automation, which made sense. As the business grew, so did the work involved in coordinating production, inventory, orders, warehousing, and shipping. People manually moved information between systems and spent time keeping different parts of the operation in sync. Technology could have helped in plenty of places.

But knowing how to automate something is different from knowing what to automate. Before changing the technology, we needed to understand the work underneath it.

For a small business, that kind of investigation has to be realistic. They still had products to make and orders to ship. The founder was already stretched, and the last thing we wanted was to pull her or her employees away from the business for days of workshops. Instead, we conducted about eight hours of mixed-methods research spread across three weeks, fitting it around the work already happening. We weren’t trying to learn everything about the company. We needed a systems map to understand why the work had become difficult and where intervention would actually help.

A pattern emerged quickly. The company had grown the way many small businesses do. Something new needed doing, so someone did it. A problem came up, and someone figured out a workaround. A new system was added because the old one couldn’t handle something. An employee became the person everyone asked about a particular part of the operation because she knew how it worked. None of this was particularly alarming. It was how the company kept moving.

But when something crossed between those different parts of the business, it often found its way back to the founder.

That also made sense. She had developed the product and spent years building the company around it. She knew its customers, suppliers, production quirks, and history. When the company was smaller, having all of that context in one person was incredibly useful.

The company got bigger. Her job got bigger with it. She now had to think about hiring, payroll, marketing, suppliers, new products, protecting the brand, and finding new opportunities for the business. But all of the responsibilities and knowledge she had picked up along the way didn’t magically move somewhere else.

The result was easy to see when she tried to leave. A few days were manageable. Much longer, and questions started piling up. Decisions stalled. Things began to break down. Not because her employees weren’t capable, but because the company still relied on information and decisions that ran through her.

At some point, the founder hadn’t just built the business. She had become part of the way it operated.

It would be easy to call this a delegation problem. Once we talked to the people involved, that explanation didn’t hold up. One experienced employee had already taken on a lot of operational responsibility. She knew the business and could make many decisions herself, but she didn’t always have the information, authority, or clarity she needed. The founder would spot a gap and step in. To the employee, that could feel like micromanagement. To the founder, having to step in was evidence that she couldn’t step away.

Both experiences were real. The problem wasn’t going to be solved by telling one person to let go and the other to take more ownership.

You can’t delegate around a system that still depends on you.

And it’s probably not a great idea to automate it either.

Be careful what you automate.

Automation has a way of making messy business problems look wonderfully straightforward. Someone copies information from one system into another? Automate it. People keep asking the same questions? Give them a system that provides the answer. Is inventory a pain to reconcile? Connect the systems.

Sometimes that’s exactly what you should do. We build those kinds of solutions.

But sometimes the annoying manual step exists for a reason. Someone may be checking two systems because the numbers don’t always agree. A conversation may keep happening because nobody is quite sure who gets to make the decision. Everyone may keep asking the founder because the information they need has never existed anywhere else.

If you automate before understanding those things, you can make the wrong way of working much harder to change. Software needs rules. It needs to know which information to trust, what should happen next, who can do what, and what happens when something unusual comes along. If the humans haven’t worked those things out yet, the software won’t work them out for you.

Our research showed that this company absolutely had opportunities to automate. But it also gave us evidence that some work and organizational design needed to happen first. The answer wasn’t a giant operations transformation program a 20-person company couldn’t afford. In a relatively short time, and without disrupting business as usual, we gave the founder a clearer picture of what was happening and practical places to begin.

The things nobody notices anymore

This is where successful small businesses can get stuck for a surprisingly long time: people are really good at making imperfect systems work.

If a machine breaks, you know you have a problem. If customers stop buying, you know you have a problem. But if an employee knows the inventory number isn’t always right and quietly checks something else before deciding, the problem disappears. If the founder answers a question in 30 seconds, everyone gets on with their day. If someone catches a mistake before an order goes out, the customer never knows.

Do that often enough and the workaround becomes part of the job.

That doesn’t mean anyone did something wrong. In fact, a lot of these habits are probably part of what helped the company succeed. Small businesses can move quickly because people don’t need a process for everything. You can walk across the room and ask someone. Roles can be loose. People pitch in. The founder knows what’s happening because she’s right there in the middle of it.

You don’t want to “fix” all of that by turning a 20-person company into a miniature corporation.

But eventually there are too many customers, orders, employees, and moving pieces for everyone to keep the whole thing connected informally. The founder needs to spend more time leading the business, while the business keeps pulling her back into the day-to-day. People who have grown with the company are ready to carry more of it, but the way responsibility, authority, and information are shared hasn’t necessarily kept up.

The old way of working wasn’t wrong. The business isn’t the same size anymore.

And this is part of why these problems are so difficult to sort out from inside the company. If you’ve been doing something for three years, you stop noticing that it’s a workaround. You know who to ask. You know which spreadsheet is actually current. You know that even though one person technically owns something, somebody else really knows how to get it done.

It all becomes normal.

An outsider doesn’t know those things, which can actually be useful. We don’t know this company better than its founder or employees. They have years of knowledge we will never have. What we bring is deep experience looking at how people, work, and technology fit together, and knowing where to look when they don’t. By listening to people describe the same business from different vantage points, we could connect things that had previously looked like separate problems. What appeared to be an automation problem was connected to how information moved. What looked like a delegation problem was connected to authority and access to information. What looked like micromanagement made more sense once we could see the gaps the founder kept stepping into.

The point of that outside perspective isn’t to tell a founder how to run her company. It’s to help the people inside the business see the company they have actually built clearly enough to decide what needs to change.

Try it before you turn it into policy.

Those findings gave us a starting point, not a new operating model to impose on the company. The work we are doing now is more practical: working with the people involved to test changes where responsibility, information, or decision-making appear to be getting in the way. If a decision currently goes to the founder, moving it is only part of the answer. The person taking it on also needs the information, context, and authority to make it confidently. Trying that change in the real environment helps us see what else needs to change around it.

This is why we treat organizational change as a series of experiments. A process can make perfect sense on paper and fall apart during the busiest week of the year. Sometimes an experiment confirms that a responsibility should move; sometimes it exposes a dependency nobody could see before; sometimes the awkward workaround everyone assumed should disappear turns out to be doing something useful. It’s better to learn that while something is still an experiment than after it has become company policy.

The people doing the work need to be part of that process. Participatory design doesn’t mean everyone gets a vote on how the founder runs her company. It recognizes that no one person can see the whole organization. The founder knows things the production team doesn’t; people working in production and fulfillment see consequences that may never reach the founder. Bringing those perspectives together gives leadership better evidence for deciding what to change and gives employees a chance to shape changes they will ultimately have to make work.

Only after something works does it make sense to codify it. A growing company needs job descriptions, processes, and documentation, particularly as new people join. But writing down a new way of working doesn’t make it real. A handbook can say who owns a decision while everyone continues asking the founder.

Documentation isn’t the mechanism of change. It’s the memory of what the organization has learned.

Circling back to automation. Better work design doesn’t make technology less important; it gives technology something better to support. Once it’s clearer who should make a decision, what information they need, and which parts of the work genuinely don’t require human judgment, we can automate repetitive work without turning today’s workarounds into tomorrow’s software.

For this company, there will eventually be a simple test of whether any of this is working: the founder can leave. She can take a real vacation, spend a month developing a new product or focus on an important customer, and the ordinary problems of running a business won’t wait for her return. Her employees will have the information and authority to handle what shouldn’t require her.

That doesn’t make the founder less important. It makes better use of her skills. The company needs her attention on the things only she can do rather than continually pulling her back into decisions other capable people could make.

And that is ultimately what we found beneath the original request for automation. The company had grown successfully, while the way knowledge, responsibility, and authority were distributed had not grown at the same pace. Nothing was fundamentally broken. Many of the habits now creating friction had helped an earlier version of the company remain nimble and resilient.

The business isn’t the same company it was six years ago. The work ahead involves helping the current business catch up without losing what made it successful in the first place.