Why Growing Teams Outgrow Rigid Business Frameworks – and What to Do Instead

At one point in my career, I sat in a room with other coaches talking through a large business framework rollout. There were diagrams, reporting structures, team assignments, prescribed meetings, new terminology, and a whole lot of conversation about whether everyone was operating the framework correctly.

Meanwhile, work was still bouncing between too many people. Decisions still took too long. Teams were tangled in dependencies. Customers were waiting.

The framework wasn’t necessarily bad. Some of the practices inside it were even useful. But we were spending an awful lot of energy organizing the problem instead of solving it.

That experience stuck with me because I’ve seen versions of it ever since. A growing company realizes its informal way of working isn’t holding anymore, starts researching an operating system or business framework, and assumes the next step is to find the right system and implement it.

Sometimes that is exactly what the business needs. Sometimes it isn’t.

A framework should help you run your business better. Your business should not have to become better at running the framework.

Not a small distinction in any way, shape, or form.

Key Topics

• Why growing businesses start looking for operating frameworks
• What business frameworks do well
• How good frameworks become rigid inside real companies
• Why context matters more as the team grows
• How Gemba helps you solve the problem that actually exists
• Why Shu Ha Ri gives us a better way to use proven methodologies
• What co-creation actually looks like
• How to tell whether your current operating system still fits

Why Growing Businesses Start Looking for a Framework

Most business owners don’t wake up one morning excited to shop for an operating system. They start looking because something changed.

The team got bigger. There are more managers. More customers. More projects. More moving pieces. Work that used to get handled through a quick conversation now needs coordination across three people who may not even be in the same room. Things start slipping. Meetings multiply. The same issues come up over and over. Managers come to the owner for decisions they probably should be making themselves. Processes live in people’s heads, priorities compete with each other, and suddenly the business feels much harder to run than it did when there were eight or ten people.

So you go looking for structure. That makes sense.

A good business framework can give you shared language, clearer priorities, better meeting rhythms, more visible accountability, and a consistent way to talk about problems. For a team that has almost no operating discipline, that can be incredibly useful. The problem starts when structure quietly becomes the goal.

Frameworks Are Good at Giving You a Starting Point

I want to be clear about this because “custom” gets abused almost as badly as “agile.”

We use proven methodologies all the time. I have spent a ridiculous amount of my career learning frameworks, experimenting with them, teaching them, adapting them, and occasionally realizing I had been using one badly.

When I first learned Scrum, I had never used it before. I watched the videos, read the material, tried to understand the rules, and then started applying it with a team that desperately needed a different way of working. We did not magically become brilliant at it. We practiced it poorly for a while. Then adequately. Then, little by little, we got better.

Some of the practices changed how I thought about work entirely.

Making work visible mattered. Showing people the actual product instead of sending status reports mattered. Getting feedback sooner mattered. Stopping long-term work from constantly losing to whatever happened to be on fire that day mattered.

Those weren’t bad ideas because they came from a framework. They were useful because they helped solve problems we actually had.

That’s the standard.

The Framework Isn’t Usually the Problem

There is a particular kind of relief that comes with choosing a complete system. Someone has already thought through the meetings, the terminology exists, there are templates, roles are defined, the steps are documented, and you don’t have to start with a blank page.

When your business feels messy, certainty is appealing. But certainty and fit aren’t the same thing.

Every methodology and business framework carries assumptions about how organizations work. It has an opinion about meetings, planning, accountability, measurement, decision-making, roles, or how work should move.

Those assumptions may fit your company beautifully. They may fit parts of it. They may fit today and become less useful two years from now.

Where I get concerned is when the first question becomes, “How do we get everyone to follow this?” before anyone has spent enough time asking, “What is actually happening here?”

I’ve lived through that version.

More meetings were introduced to solve communication problems. More roles were added to solve ownership problems. More process showed up to fix delays caused by existing process.

Everything became more organized, but often did not become better.

Growth Makes Context Matter More

When you’re running a ten-person company, variation is easier to absorb. It’s impossible not to know everyone. People overhear conversations and someone notices when a customer has an unusual request. The owner can fill in context because they’re close enough to most of the work to know what is happening. That system, however, does not scale particularly well.

As the team grows, sales develops its own needs. Operations has different constraints. Finance works on a different rhythm. Customer-facing teams may need to respond in hours while another function can plan work weeks ahead.

That does not mean the company is fragmented. It means the work is different. And one of the mistakes I see in growing businesses is confusing alignment with uniformity.

Every team does not need the exact same meeting because consistency feels neat. Every function does not need the same scorecard. Every problem does not need the same workflow.

Sometimes consistency helps. Sometimes it adds work.

In another note I’d mentioned maximizing the amount of work not done. I take that seriously, and you should too. If a process, meeting, report, approval, or layer isn’t helping the business make better decisions or deliver something of value, I’m going to ask why we’re doing it.

“Because it’s part of the framework” is not enough.

Go See Before You Solve

One of the practices we use at Unrestricted Humans comes from Lean thinking: Gemba.

The basic idea is beautifully simple. If you want to understand the work, go to where the work actually happens. Not literally in every case, since we work with virtual companies too, but you get as close to reality as possible.

Watch the handoff. Talk to the person doing the work. Follow the customer request. Look at what happens when something goes wrong. Ask the manager what they are supposed to decide, then ask what they actually feel comfortable deciding. Compare the process document with what happens on Tuesday afternoon when three things hit at once.

This is one reason we believe the people closest to the work usually have more answers than leadership realizes.

They know where the friction is. They know which part of the process nobody follows. They know why the spreadsheet has six extra columns. They know that everyone technically has permission to make a decision, but no one does because the last person who made one got overruled.

A methodology cannot tell you that before it sees your business, but your people can.

We intentionally look at some of the usual gaps: whether processes are actually well-defined, whether employees are consulted when rules change, whether leadership instructions are clear and reasonable, whether people feel confident and capable, and whether improvement is genuinely encouraged.

Those answers tell us much more than whether you’ve adopted the “right” framework.

Custom Doesn’t Mean We Make It Up

This is worth saying plainly: We are not sitting in a conference room inventing brand-new management theory for every client. That would be absurd.

We use tried-and-true methodologies because people have spent decades learning useful things about leadership, systems, flow, communication, decision-making, and how work gets done.

The customization happens in how those principles are applied.

If a team needs clearer decision rights, there are proven ways to create them. If work is invisible, we know practices that can make it visible. If priorities constantly get displaced by whatever feels urgent, there are well-established ways to create focus and feedback. If leaders are answering every question instead of building capability, we have leadership practices for that too.

We’re not trying to prove how clever we are. We’re trying to figure out what works, so it works better.

Shu Ha Ri: A Better Relationship With Frameworks

Another concept that has shaped how I think about this is Shu Ha Ri. It’s commonly used to describe stages of learning.

At the beginning, you follow the practice. You learn the rules, understand the form, and resist the temptation to customize everything before you’ve actually learned anything.

Sometimes an owner says, “That won’t work here,” when what they really mean is, “That will require us to change something uncomfortable.” Those are different problems.

As your understanding grows, though, you begin to see why the practices work. You can tell which parts are essential and which parts are simply one way to apply the principle.

Eventually, you have enough experience and judgment that you’re not dependent on the original form.

That’s a much healthier way to use a business framework.

Learn it. Practice it. Understand the principles beneath it. Adapt when the evidence tells you to.

That is very different from installing a system and treating deviation as failure.

Co-Creation Is Not Consultant-Speak for “We’ll Ask Your Opinion”

There’s another difference that matters to me (and Mary, too): I don’t want to be the smartest person in the room. I do want to bring expertise into it.

Those sound contradictory until you think about what each person actually knows.

We bring experience across leadership, organizational design, agility, facilitation, systems, and business operations. We’ve worked inside complicated organizations. We’ve led through change. We’ve seen what happens when systems support people and what happens when they absolutely do not.

Your team brings the context we cannot possibly have on day one.

They know the customers. They know the personalities. They know the history behind the weird workaround. They know why an apparently simple process became complicated three years ago and no one ever cleaned it back up.

If we come in assuming one side has all the answers, we’re leaving half the intelligence in the room unused. That is why one of our core beliefs is that we fix it together, not for you.

Co-creation doesn’t mean consensus on every decision. It doesn’t mean everybody gets their favorite solution. And it definitely doesn’t mean avoiding hard conversations.

It means the people who need to live with the system help build something they understand and can actually operate.

Because eventually, we leave. That’s the point.

The Goal Is Capability, Not Dependency

I get suspicious of any business improvement approach that only works while the expert is there enforcing it.

If your leadership team can run the meeting but doesn’t know why the meeting exists, I’m not sure we’ve accomplished much. If your managers can complete a scorecard but cannot tell when the measures have stopped being useful, that’s compliance, not capability. If every adaptation requires someone outside the business to tell you whether you’re “allowed” to make it, the system is still dependent on somebody – just a different somebody.

The primary measure of success is being able to leave your team better at seeing what is happening, understanding what matters, making decisions, and adjusting when conditions change.

That doesn’t happen through a 500-slide deck. It happens through work.

Real conversations. Decisions. Experiments. Reflection. The occasional uncomfortable realization that the problem we thought we had was not actually the problem.

Change is not easy because the methodology looks elegant.

Sometimes the Framework Is Fine and Leadership Is the Problem

This is another part nobody particularly enjoys hearing. Sometimes the operating system is not too rigid. Sometimes the owner keeps overriding it.

You can’t:

• give managers authority and then reverse their decisions every time you would have chosen differently.
• establish quarterly priorities and introduce six new urgent ones every other week.
• say you want accountability and then rescue people from every consequence.
• tell employees to raise problems and become defensive when they do.

No framework can do that leadership work for you.

A system can expose the behavior. It can create conversations around it and make inconsistency much harder to ignore. But you still have to decide what to do with what you learn.

That’s true whether the framework came out of a bestselling business book, an Agile methodology, your operations team, or the whiteboard in your conference room.

How to Tell Whether Your Operating System Still Fits

I wouldn’t throw out a framework because someone hates one meeting. Instead, look for patterns.

The team is spending more time servicing the system than learning from it. Reports are completed because they are required, meetings happen because they’re scheduled, and nobody can explain what decisions are actually improving as a result.

Workarounds are becoming normal. People technically follow the process, except for the five exceptions everybody knows about and the three unofficial steps that make it function in real life.

Different parts of the company need different operating rhythms. Uniformity is creating friction instead of alignment.

Managers know the framework but still can’t make decisions. If everything important routes to the owner, the problem is not a missing template.

People are afraid to adapt. The team knows something isn’t working, but changing the process feels like breaking the rules.

Leadership talks more about whether the methodology is being followed than whether the business is improving.

That last point is one of the best leadership gut-checks you can reflect on.

You Don’t Have to Choose Between Proven and Custom

This is probably the false choice I want owners to stop making. You do not have to choose between a rigid off-the-shelf system and making everything up from scratch. There is a lot of space in between.

You can totally use proven practices, learn from frameworks, borrow the good stuff, understand why it works, then apply it to the business in front of you.

That’s what Gemba and Shu Ha Ri have taught me over and over again. Start with reality. Learn the principles. Build enough understanding to adapt intelligently. And when the business changes, look again.

That isn’t a failure to stick with the system; that’s the whole point of having one.

The Better Question to Ask Before Choosing a Framework

If you’re comparing business operating systems right now, I understand what you’re looking for.

You want confidence that you’re not about to spend a lot of time and money introducing something your team will abandon six months from now. You want structure without bureaucracy and your managers to actually manage. You want priorities to stay priorities, and ideally, you’d like fewer things to require your personal involvement.

So before asking, “Which framework should we use?” I’d ask something else: What does this business need to become capable of doing that it cannot do reliably today?

Maybe your team needs clearer decisions. Maybe your leadership team needs a real operating rhythm. Maybe you need better visibility into work. Maybe managers need to stop acting as messengers between employees and the owner. Maybe you need a framework. Maybe you need to simplify the one you already have.

The answer should come from the problem, not the product someone happens to sell.

If you’re trying to figure out what kind of operating system actually fits the business you’re running now, start with our Framework Fit Scorecard. And if the answer still isn’t obvious, book a Fit Call.

We won’t start by figuring out how to fit you into our methodology. We’ll start by looking at what’s actually happening.

-L