Too many operations leaders I talk to are stuck in what I lovingly call the tactical firefighting merry-go-round.

The place where strategic thinking, proactive problem solving, and innovation go to die.

Where you can’t see the forest through the trees. Where every day is reacting to what’s on fire instead of building what’s next. Where you’re so busy solving today’s problem that you never get to tomorrow’s opportunity.

Unfortunately, this is where many operations leaders live.

The causes are many:

The company grew too fast, or is currently growing too fast, and operations, systems, and processes couldn’t keep up. Or they weren’t given the attention they needed, because no one had the time.

And here’s the uncomfortable one: too many of the people involved in operations like the tactical firefighting. It makes them feel productive. Important. Needed.

Putting out a fire feels good. It’s visible. It’s immediate. You get a hit of “I solved that” every time.

But that feeling is a trap.

Because here’s what firefighting actually costs you:

You’re always reacting, never building.

You can’t grow, because everything runs through you.

You burn out, because the fires never stop.

And you stay stuck, because you never get the time to fix what’s actually causing the fires in the first place.

The firefighting feels like progress. But you’re running in place. The merry-go-round spins and spins, and you end up exactly where you started.

So how do you get off the ride?

There’s only one way: slow it down long enough to build the structure you need.

That’s it. That’s the whole answer. And it’s harder than it sounds.

Because slowing down feels counterintuitive when everything is on fire. It feels irresponsible. How can I stop to build systems when there are real problems that need me right now?

But that’s exactly the thinking that keeps you on the ride.

You have to be willing to let something smolder while you build the thing that prevents the next ten fires. You have to trust that the short-term discomfort of slowing down is worth the long-term payoff of a business that doesn’t need you to firefight every day.

The firefighting might make you feel productive and important in the moment.

But it’s not where you want to be.

The goal was never to be the best firefighter. It was to build something that stops catching fire.

Most people think standardization is about control.

Lock down the process. Remove the variation. Get everyone doing it the same way.

But that’s not the point. Or at least, it shouldn’t be.

Done right, standardization creates freedom.

Here’s what I mean.

Every decision a person makes takes mental energy. What do I do next? Who approves this? How should I handle this situation?

When the routine stuff is standardized, those questions disappear. People don’t have to burn energy figuring out things that should already be figured out. That frees up their brainpower for the work that actually requires it.

Good standardization reduces cognitive load. It says: don’t waste your thinking on this. Save it for where it matters.

The best processes make the routine automatic so people can be creative, thoughtful, and present where creativity and judgment actually count.

But standardization can go too far.

This is where it flips from helpful to harmful.

Over-standardization looks like making people jump through hoops. Adding steps that don’t add value. Requiring approvals that don’t need to happen. Building process for the sake of process.

It’s when the system starts serving itself instead of the people using it or the customers it’s meant to help.

And here’s the tell: if a step doesn’t make the process work better, either for your employees or your customers, it’s not standardization. It’s bureaucracy.

The difference between the two comes down to one question:

Does this reduce cognitive load, or add to it?

Good standardization removes friction. It clears the path. It takes the mental weight off so people can focus.

Bad standardization adds friction. More hoops. More steps. More boxes to check that don’t move anything forward.

One creates freedom. The other creates drag.

So when you’re building your standards, ask:

Is this making the work easier or just more controlled? Is this helping the person do their job, or am I adding a step because it makes me feel better?

Standardize the things that reduce cognitive load. Cut everything that just adds hoops.

The goal was never control. It was freeing people up to do their best work.

Most companies think the hard part of standardization is writing it all down.

Build the SOPs. Document the processes. Create the playbook. Check the box.

But documentation isn’t the goal. Adoption is.

You can have the most beautiful process documentation in the world. If no one follows it, you don’t have a standard. You have a document.

So how do you get adoption?

One of the most effective ways is also one of the most overlooked: involve the people who do the work in creating the standard.

Instead of imposing standards from the top down, you let the people doing the work help shape them.

The insight: people own what they help build.

When a standard gets handed down from corporate, it’s something being done to you. When you help create it, it’s yours. You understand the why. You have a stake in it working.

The teams that resist standardization the most are often the ones who were never asked. They were just told.

But ownership can go too far.

If everyone builds their own version of everything, you’re right back where you started: inconsistency, chaos, no real standard at all. Letting people own the process doesn’t mean letting everyone do whatever they want.

The answer is a hybrid.

Standardize the outcome. Involve the people in shaping the how. Keep the deliverable consistent so it looks uniform to the customer, but give the team a voice in how they get there.

You’re not choosing between control and ownership. You’re designing for both.

Here’s what I keep coming back to:

The goal was never documentation. It was consistency. And consistency only happens when people actually adopt what you build.

So if adoption is the whole game, the question isn’t just “what should the standard be?”

It’s “how do we build this so people actually want to follow it?”

Most of the time, the answer starts with bringing them into the room.

Look at this RV.

Kayak strapped to the side. Boxes piled on top. Barbies hanging off every edge. A globe, a telescope, lamps, an inflatable raft. Solar panels. Teddy bears. A guitar.

It’s chaos. And somehow, it’s still moving.

This is what a lot of companies look like on the inside.

They didn’t plan to look like this. It happened gradually. One thing at a time.

They needed to track something new, so they added a spreadsheet. Then another tool. Then a workaround because the tool didn’t quite fit. Then a person to manage the workaround. Then a process to manage the person.

And now? There’s a kayak on the roof and no one remembers why.

This is what I call the Barbie RV Problem.

Companies add things onto their operations instead of taking a systemic look at how things need to be redesigned as they grow.

It makes sense in the moment. Adding is faster than redesigning. It’s less disruptive. It gets you through the quarter.

But every bolt-on adds weight. Adds complexity. Adds drag.

And at some point, the RV can’t turn anymore.

Here’s the thing about growth:

More revenue, more headcount, more customers, more products. All of it leads to more complexity. And complexity doesn’t announce itself. It accumulates.

What worked at $10M doesn’t work at $30M. What worked with 20 people doesn’t work with 80. The systems that got you here won’t get you there.

But instead of redesigning, most companies just keep adding.

Another tool. Another role. Another layer. Another strap holding the kayak in place.

At some point, you have to stop and ask:

What are we actually carrying? Do we still need all of this? Is this RV designed to hold what we’re asking it to hold?

Because the answer might be no. And if it’s no, no amount of straps will fix it.

The companies that scale well don’t just add. They pause at key inflection points and ask: does this still work? They redesign before they have to. They take things off the RV instead of just piling more on.

It’s harder. It’s slower. But it’s the only way to build something that can actually handle the road ahead.

Take a look at your RV. What’s strapped on that doesn’t belong anymore?

Someone said this on a call recently and it stuck with me.

We all know the phrase. And yet, we keep trying to do it anyway.

Here’s the problem:

Once a company gets large enough, you can’t work in silos anymore. Everything is connected. What you do in your corner of the business affects what happens in someone else’s.

But most companies don’t operate that way.

They build piece by piece. Department by department. Each team solving for what’s in front of them without stepping back to see the whole.

Operations makes a change to how orders are processed. Makes sense for their workflow. But no one asked finance how it affects invoicing. Or customer service how it changes what they see. Or the warehouse how it impacts their timing.

Now you’ve installed piece A before piece G. And you’re wondering why the plane won’t turn.

This is how cross-functional inefficiencies are born.

Not from bad intentions. From lack of visibility. Everyone is optimizing for their part of the plane without seeing the blueprint.

The problem is you can’t see the blueprint when you’re in the weeds turning screws. You have to zoom out.

Zooming out means understanding how everything works together. It means asking: if we change this here, what does it do over there? It means making decisions for the whole organization, not just your department.

But most companies don’t build in time to zoom out.

They’re too busy flying. Too busy reacting. Too busy solving what’s right in front of them.

And so each department keeps building their piece of the plane. Independently. Efficiently, even. But not connected.

Then one day someone asks: why is this so hard? Why does everything take so long? Why does every change break something else?

Because the pieces were never designed to work together. They were designed to work alone.

You can’t build the plane while flying it. Not alone. Someone has to be looking at the blueprint while you keep the plane in the air. That’s the only way to build something that actually flies.

In conversations with private equity firms and their portfolio companies lately, I’m hearing a shift.

The question used to be: how fast can you scale?

Now it’s: how reliably can you execute while scaling?

Growth is still the goal. But sponsors are paying closer attention to what’s underneath the growth. Can you close the books in 15 days or 45? Do you have visibility into working capital? Are your systems integrated or duct-taped together? Is your operational knowledge documented or living in someone’s head?

Why the shift?

Because too many mid-market companies grew fast before building the infrastructure to support it.

Systems were layered on top of systems. Processes evolved organically. Automation was introduced selectively. Governance lagged behind complexity.

That pattern is common in sponsor-backed growth environments. But it catches up to you.

When exit conversations start, operational maturity shows up in the diligence. Reporting consistency. Integration capability. Controls. Working capital discipline. These are no longer back-office concerns. They’re influencing valuation conversations at entry and exit.

So what is operational maturity?

It’s not perfection. It’s predictability.

It means knowing how work actually gets done, not just how it’s supposed to get done. It means your processes are documented so they don’t live in someone’s head. It means having clear accountability so decisions don’t get stuck. It means your systems give you visibility without requiring you to dig for answers.

Operational maturity means your business can execute consistently, even under pressure.

How do you build it?

Start with how work actually flows through your organization. Not the org chart. The actual work.

Where do handoffs get dropped? Where does knowledge live in one person’s head? Where are you reconciling spreadsheets instead of looking at a dashboard?

Then build the infrastructure: documented processes that are actually followed, clear accountability frameworks, systems that surface problems before they become surprises.

This is not glamorous work. But it’s the work that compounds.

The companies creating separation aren’t fixing operational gaps reactively. They’re building institutional capability before they need it.

They’re formalizing close calendars. Strengthening control environments. Documenting processes. Building repeatable models that scale.

The companies that wait until diligence to address these gaps? They’re leaving value on the table.

Growth still matters. But operational maturity is what protects the multiple.

The question is no longer just “can you grow?” It’s “can you prove you can execute while growing?”

If you’re PE-backed or preparing for investment, that’s the question to be ready for.

Anthropic just launched Ode, an AI services firm backed by Blackstone, Hellman & Friedman, Goldman Sachs, and a consortium of major investors.

Why would a company with the most advanced AI in the world need to launch a services firm?

Because technology alone isn’t enough.

Here’s what they said: “As mid-size companies move from experimenting with AI to building it into their operations, they need partners with real implementation depth and a clear understanding of how their businesses actually work.”

Read that last part again: a clear understanding of how their businesses actually work.

This is where most companies get it wrong.

They rush to adopt AI without that understanding. They layer automation on top of processes that are broken, undocumented, or only exist in someone’s head.

And what happens?

The chaos doesn’t go away. It just moves faster.

You can’t automate chaos. You can only accelerate it.

AI is not a fix for broken operations. It’s an amplifier. If your processes are solid, AI makes them better. If your processes are a mess, AI makes them messier, at scale.

So what should mid-market companies actually be doing?

Before you invest in AI, ask yourself:

Do we know how work actually gets done here? Not how it’s supposed to get done. How it actually gets done.

Are our workflows documented? Can someone new step in and understand what happens, when, and why?

Do we have clarity on handoffs, accountabilities, and decision points?

If the answer is no, that’s where you start. Not with AI. With the foundational work of understanding and mapping how your business operates.

Once you have that, AI becomes a tool you can actually use. You can see where it fits. You can measure what it improves. You can implement it without creating new problems.

The companies that will win with AI are not the ones who adopt it first.

They’re the ones who have the operational foundation to actually use it.

Get your house in order. Then layer the technology.

Things go wrong. That’s not the problem.

The problem is when you’re surprised by it. Over and over again.

If you keep getting blindsided, you don’t have an operations problem. You don’t have operations.

If product errors keep catching you off guard, you don’t have operations.

If deadlines keep getting missed and no one sees it coming, you don’t have operations.

If projects keep going over budget and it’s always a surprise, you don’t have operations.

Operations doesn’t mean nothing goes wrong. It means you’re not blindsided when it does.

When you have real operations, you have checks and balances in place. You have warning signs. You see things coming before they arrive.

And when something does go wrong, you know why. You know where the breakdown happened. You’re not scrambling to figure out what went sideways.

Problems are part of running a business. Surprises mean you don’t have the systems to catch them.

Here’s what constant surprises actually cost you.

If you’re always reacting, you never have time to be proactive.

You’re not building something new. You’re not improving. You’re not growing. You’re just responding to the past.

Every fire drill is time you’re not spending on strategy. Every scramble is energy you’re not putting toward what actually moves the business forward.

Reactive companies stay stuck. They’re so busy putting out fires that they never get ahead of them.

And the longer you operate this way, the harder it is to break out of it. Because there’s always another surprise. Always another fire. Always something urgent that pulls you away from the important work.

If your team is constantly reacting instead of anticipating, that’s not bad luck. That’s a sign you need to build the operations that don’t exist yet.

Build the checks. Watch the warning signs. Know where things can break before they do.

That’s real operations.

Operations is all about processes and systems.

We map workflows. We build SOPs. We design controls. We optimize, standardize, and systematize. That’s the work.

But here’s the thing: people are the ones who make those processes run.

And most operations people — if we’re being honest — got into this work because we like managing processes. Not people.

We like getting things done. We like fixing what’s broken. We like the satisfaction of a system that works.

Managing personalities? Navigating resistance? Doing the “dance” to get buy-in? That’s not why most of us signed up.

And yet.

This topic came up towards the end of our last COO Table. A room full of operations leaders, and someone asked: how do you go from managing processes to managing people?

It sparked something. Because so much of operations is actually people. Getting alignment. Building trust. Understanding what motivates different people. Knowing when to push and when to slow down.

You can design the perfect process, but if the people don’t come along, it doesn’t matter.

So how much people skills does operations actually need?

I don’t have a clean answer. But I think it’s more than most of us want to admit.

The tension is real. We want to drive things forward. We have deadlines. We have stuff to fix. And sometimes it feels like we shouldn’t have to “manage around” personalities to get work done.

But we do. Because people are the system.

I’m curious how other operations leaders think about this. Is this something you’ve figured out? Something you’re still wrestling with?

If this is a topic you’d want to dig into with peers, we’re considering it for an upcoming session of The COO Table — a monthly virtual roundtable where mid-market COOs and senior operations leaders meet to discuss one operations question candidly with peers. Small group, one hour, run under Chatham House Rules.

Would you want to be part of this conversation? Let me know.

There’s a famous axiom often attributed to W. Edwards Deming:

“Every system is perfectly designed to get the results it gets.”

Read that again.

Your outcomes aren’t accidental. Whether it’s a business, a workflow, or a daily routine, whatever you’re experiencing is the exact byproduct of the processes, policies, and structures currently in place.

If your support team resolves tickets in 14 days, that’s what your system is designed to produce. If your production line makes 5 widgets an hour, that’s what your system is designed to produce. If you’re missing deadlines or losing customers, that’s also what your system is designed to produce.

Not on purpose. But by design.

Here’s where it gets uncomfortable.

Once you change your goal or set your sights on different results, the system you have is wrong. By definition. Because that system, whether you built it intentionally or it evolved by default, is designed to yield the results you got yesterday. Not the results you want tomorrow.

This is not the fault of anyone who built the current system. It’s just the simple math of systems design.

But many people don’t see it that way.

They get defensive. They’re attached to what they’ve built. They don’t want to admit that the system they created isn’t working for where they’re trying to go.

So instead of reimagining the system, they try to tweak it.

A small adjustment here. A new tool there. A workaround. A patch.

And then they wonder why the results don’t meaningfully change.

Here’s the truth.

If you want to tweak your results, you can tweak the system. Small changes, small impact.

But if you want meaningful change, you cannot get there without reimagining the system. Tweaks won’t do it. You have to be willing to look at what you’ve built and say: this was perfect for what we needed before. It’s not perfect for where we’re going.

That’s hard. As humans, we get attached to what we’ve built. Letting go feels like failure.

But it’s not failure. It’s just math. The system you have is designed for the outcomes you’re getting. If you want something different, you have to build something different.

The companies that actually change their results are the ones willing to accept this.

They stop protecting the old system. They stop making excuses for why it should still work. They reimagine it for the outcomes they actually want.

And then their results change. Because the system changed.

What results are you getting that your current system is perfectly designed to produce?