EOS Fixed the Business- It Didn't Fix This

A founder found me a while back through something I'd written, and on our first call she said the thing I've now heard from a dozen people in some version or another.

"I tried processes and systems. Now I have them. And I'm still unhappy."

Sit with the shape of that sentence, because it isn't a complaint about EOS. It's more interesting than that. She wasn't telling me her implementer was bad or her Level 10s were a waste of time. She told me the system did what it said it would, but what she was actually hoping for didn't show up.

I'm Todd Palmer, an executive coach for CEOs and founders, and I'm often not the first coach a founder hires. There's a reason for that, and it isn't that I'm better than the people who came before me. People usually find me after they've exhausted the tactical answers. By then they've already fixed a great deal, and what's left doesn't respond to the same tools.

Almost everything written about EOS right now assumes the system broke. Why EOS fails. When EOS implementation fails. EOS alternatives for next year. A lot of it is written by people who sell a different system. Very little of it takes seriously the possibility that your implementation worked fine and you're still not okay.

I Trained In Both Systems And Chose Not To Certify

I'm not the guy who thinks frameworks are stupid. I've recommended EOS. I've recommended Scaling Up. I've watched scorecards, accountability charts, and documented processes bring real clarity to companies that badly needed it, and I've seen leadership teams get sharper because somebody finally wrote down who owns what. As I've written before, the failure I see most often isn't the framework; it's a certified implementer who's never sat in the CEO seat telling a drowning team to trust the process.

I did go do the training. Both of them. And then I chose not to certify in either, and the reason matters more than the story.

When you certify, you sign a contract to represent that product. With EOS, you use the EOS tools. That's the deal, and it's a reasonable deal for the people who take it. What bothered me wasn't the quality of the tools. It was the idea that I would know the toolbox before I knew the problem. If every entrepreneur walked into the room and I had already agreed which tools I was going to use, I worried I'd eventually start fitting people to the framework instead of fitting the work to the person.

A framework should give you a frame. It was never supposed to be the whole house.

I'll implicate myself here, because I've done the thing I'm about to describe. When I was running Diversified Industrial Staffing, and things were going badly, I reached for systems too. New process, new dashboard, new consultant, new book. Some of it genuinely helped. And some of it was me doing something visible and structured so I didn't have to sit with the thing I actually didn't want to look at, which is the pattern I've since called the Avoid-Dance. Reaching for a system feels like leadership. Sometimes it is. Sometimes it's the most productive-looking way to avoid yourself.

So when a founder tells me the system worked and they're still unhappy, my first thought isn't which system next. It's a question. What were you hoping would change that a process was never going to touch?

Here's what I've watched enough times to call it a pattern. Frameworks are excellent at problems of clarity, consistency, and coordination. Who owns what. What we measure. How we meet. When a company is chaotic, that's where most of the pain is, and installing a system feels like a miracle. Revenue steadies. Meetings stop being a mess. People know their numbers.

And then the founder arrives somewhere they didn't expect. The company runs. The scorecard is green. And they're sitting in a well-organized business they're not sure they want to be in, still circling the same conversation with the same partner, still unable to say out loud that they don't know if they want to own this thing anymore. None of that is on the accountability chart. There's no seat for it.

Now here's the part underneath, and it's why the next framework is so tempting.

If the system is the problem, you get to keep the problem outside yourself. If EOS is the problem, I don't have to ask whether I'm afraid to fire my VP. If Scaling Up is the problem, I don't have to ask whether I actually want to own this company anymore. If the implementer is the problem, I don't have to examine why I keep overriding the leadership team I claim I want to empower. The framework gives me somewhere external to put the discomfort, and there's an entire industry ready to sell me the next place to put it.

Another reason entrepreneurs reach for systems under pressure, and I think it's the more honest one. Systems don't reject us. A dashboard doesn't argue with you. An SOP doesn't get angry. A process doesn't force you to admit you were wrong. Difficult conversations do. Letting someone go does. Telling your partner the truth does. Admitting you don't want the business you spent twenty years building certainly does. Systems feel objective. Leadership gets personal very quickly.

That's not a character flaw. That's a smart person choosing the work that hurts less, which is what most of us do most of the time.

Chris Argyris spent a career at Harvard on this mechanism, and his language for it is the most useful I've found. He and Donald Schön separated two kinds of learning. Single-loop learning is error correction inside your existing assumptions, like a thermostat that notices the room is cold and turns the heat on. Double-loop learning is when you question the assumptions themselves, the governing values underneath the strategy rather than the strategy.

Operating systems are exceptionally good at helping leaders identify variance, create accountability, and improve execution. Sometimes they also surface deeper questions. A well-run leadership team argues about strategy, roles, and people, and real reckonings happen in those rooms. But they weren't designed to help a founder understand why he keeps avoiding the same conversation, why she can't let go of control, or why a business that looks successful on paper no longer feels like success.

Argyris's sharper finding is the one that stings. Studying why smart, successful professionals struggle to learn, he found that the most capable people are often the worst at double-loop learning, because they're skilled enough to build airtight, defensible explanations that protect them from examining their own contribution. The better you are at reasoning, the better your defense. Which is why "we need to tighten up our Level 10s" can be completely true and still be a way of not answering the question.

Before we go further, though, I want to slow down, because there's a trap in writing like this and I don't want to walk you into it.

Not every recurring business problem is psychological. Sometimes you have a market problem. Sometimes you don't have enough capital. Sometimes your strategy is wrong, or your execution genuinely is sloppy, or you don't have the talent you need and no amount of self-reflection will conjure it. I've watched coaches turn "the problem is you" into a hammer, and it's lazy.

So run four questions before you conclude anything about yourself.

Is this an execution problem? We know what to do, and we aren't consistently doing it. Is this a capability problem? We don't have the people, skills, capital, or resources. Is this a leadership problem? Somebody isn't making or enforcing a decision. Or is this a founder problem? I know what probably needs to happen, and something inside me keeps resisting it.

The first three have operational answers; go get them. My work usually lives in the fourth, and I get most curious about it when the first three no longer adequately explain a pattern that keeps repeating across different people, processes, and circumstances.

What The Next Framework Actually Costs You

I'll be specific about the bill, because founders underestimate it.

There's the direct spend, which is the smallest part. Implementer fees, training days, software, the leadership offsite. Annoying, but survivable.

The real cost is time and attention. A serious framework rollout consumes months of your leadership team's bandwidth. If you're on your second or third one and the first two worked, you've spent years of executive attention refining how the company operates while the actual constraint sat untouched.

Then there's what it does to your team. The first system was exciting. The second was fine. By the third rollout, your leadership team may have learned something about you: when things feel uncertain, the boss goes shopping for another answer. They stop investing emotionally in it, because they've seen this movie. You get compliance instead of commitment, which looks close enough on a scorecard and is worth almost nothing.

And there's the decision you didn't make. The conversation with the partner didn't happen. The wrong executive stayed another quarter. The pricing problem went untouched. The restructuring got delayed. The decision to sell got avoided. Every one of those has a number attached to it, and not one of them will ever appear as a line item on your financial statements. Avoidance is one of the most expensive items on an entrepreneur's P&L, and it's invisible on the P&L.

The good news buried in this is that you're not at the mercy of a market here. If the constraint were demand or capital or regulation, you'd be stuck with it. The fact that it has followed you through two functioning operating systems suggests it's something you have real ability to change. That's leverage, not a verdict.

Now, there's another possibility I don't want to miss, and it may be the most important thing in this piece.

Maybe the operating system didn't fail you at all. Maybe it succeeded so well that it finally created enough stability for you to hear something the chaos had been drowning out.

When you're fighting fires every day, there isn't much room to ask whether this is still the life you want. Payroll. Sales. People. Cash. Customers. The noise is total, and it's genuinely useful noise, because it's urgent and it's solvable and it keeps you from having to sit still. Then the system works. The leadership team functions. The scorecard turns green. The business becomes less dependent on you.

And suddenly there's quiet.

That quiet can be uncomfortable as hell, because now you can hear the question the chaos was drowning out. Sometimes the framework didn't create the problem. It created enough space for you to finally see it.

If that's where you are, the arrival of a deeper question isn't evidence that anything went wrong. It might be evidence that you're ready for a different kind of work.

The Leftover List

Here's a small thing you can do this week. Takes about twenty minutes.

Two columns on one page. On the left, write down honestly everything your operating system fixed. Be generous. Meeting discipline, role clarity, the numbers you finally track, the accountability that didn't exist before. Most founders under-credit this, and you should see it plainly.

On the right, write down what's still on the list. What was bothering you before the rollout that's still bothering you now.

Then take each item on the right and run it through the four questions. Execution, capability, leadership, or founder. If it's one of the first three, go solve it, and your system may well be the right tool. If it's the fourth, no operating system is going to reach it, and buying a new one is expensive avoidance.

In my experience, the right column is short, and most of what's on it is a person, a conversation, or a decision.

One caution, because I don't want this read as permission to be impulsive. If you're well into an implementation and it's genuinely half-installed, finish it. Abandoning a system you never fully ran and calling that a revelation is its own kind of avoidance, and it's the more common error in the other direction. Sometimes buying the next framework is avoidance. Sometimes refusing to finish the current one is avoidance. The question underneath both is discernment versus avoidance. Gathering information that could actually change your decision is discernment. Moving because sitting still is uncomfortable is not.

So here's where I want to leave you, and it's a bigger question than the one you came in with.

If nobody on your leadership team could hear your answer, what would you admit isn't working anymore?

Be careful before you answer that, because I'm not only asking what isn't working inside the business. I'm asking whether the business you worked this hard to build is still creating the life you want to live.

Maybe you already know exactly what it is and simply haven't been willing to say it out loud. Other times you're too close to the problem to see it clearly, and that's not a failure of nerve, it's what a blind spot is. Both are reasons to stop automatically reaching for another framework.

Before you buy another system, hire another consultant, or redesign another process, get curious about the question.

And if you want someone to help you separate the business problem from the leadership problem, and the leadership problem from the stuff happening between your ears, that's a conversation I'm always willing to have.

Here when you need me,

Todd

From Suck to Success

In From Suck to Success, Todd uses his own experience in professional purgatory to propel your business upward by embracing Massive Curiosity coupled with Massive Accountability.

We care about your data. Read our privacy policy.

Screenshot of From Suck to Success Book Cover

Latest From the Blog

Read Todd's latest tips on building connection through psychological safety.