How to take on a team that's been self-implementing EOS®

Teams that have been running EOS® on their own arrive in wildly different shape. Some come to you with real humility, aware of exactly where the cracks are. Others read a different book, built something adjacent, and believe they are running EOS® when they are running a version of it that only half works.

If you treat both the same way, you lose either way. Come in hot on a strong team and you insult the work they did. Rubber-stamp a weak one and you leave them exactly as broken as you found them. So before I decide anything, I figure out which team I am actually sitting across from.

Here is how I run it.

Ask for their tools before you do anything

The first thing I say is simple: send me your tools. Their V/TO™, their Accountability Chart™, their Rocks™, their Scorecard™, all of it. Then I take an honest, judgmental look at what is there.

Good cooking is mise en place. Everything chopped, everything ready, before you turn on the heat. You cannot decide how to engage a self-implementing team until you have seen what they built, because the whole plan depends on it. A ten minute look at their real tools tells you more than an hour of them describing how they think they are doing.

Sort them into one of three modes

Once I have seen the tools, every self-implementing team falls into one of three modes.

Mode one: they read a different book.

The tools look EOS®-ish but the foundation is off. These teams need to start with a Focus Day and build it properly, because you cannot optimize a structure that was never sound. Do not let the fact that they have been at it for a year talk you out of starting at the start.

Mode two: decent tools that need sharpening.

This is where most teams land. The bones are good, the execution is uneven. Here I run a self-implementer session: we stop, we fix, and we optimize wherever it is needed. The rule I hold myself to is that I am not there to throw everything out. I am there to layer stuff on top. Every time you rip out something that was working, you spend trust you did not need to spend.

Mode three: genuinely strong.

Every so often you open the tools and they are just good. These teams do not need a foundation or a tune-up. Ask when the next quarterly is and go run it with them.

The spread is close to a bell curve. Most teams sit in the middle in mode two. Roughly one in six are strong enough to jump straight in, and roughly one in six read the different book and need to start over. Figure out which sixth or which middle you are in, and the engagement plan writes itself.

Name the thing they're almost always missing

Whatever mode they are in, self-implementing teams are almost always missing the same thing, and it is not a tool. It is third party accountability.

I was in a room once where a team was projecting the following quarter, and they landed on 3.71% EBITDA, and nobody blinked. I tilted my head at them like a confused Labrador and asked why nobody was mad. I told them I was mad. That number was nonsense, and everyone at the table could see it, and not one of them would say it.

That is what happens without an outside voice. The CFO put the number up. The sales manager said he could sell it. The CEO nodded along while privately deciding who he was going to have to let go. Everybody had a reason not to be the one to call it, so the bad number sailed through. The value I add in that moment is that I have no reason to protect anyone. I am not telling you how to run your business. I am telling you how to run a business, and this leaves you no flexibility.

A team can build every EOS® tool correctly and still not have this, because you cannot be impartial about your own numbers. That is the gap you are really there to fill.

Give them the data, then hand back the decision

The other thing I bring that a self-implementing team does not have is a data set. They have run their company. I have run this problem across dozens of companies. When something surfaces in the room, I can tell them they are somewhere around client sixty eight to hit this exact wall, here is how other teams went after it, here are the outcomes those teams saw, and here is why I think they got them.

Then I stop, because the decision is not mine. I hand it back through IDS™. Are you going to live with it, end it, or change it? Live with it is rarely a real answer. End it is rarely a real answer. So we are changing it, and if we are changing it, then articulate the Rock™ for me. I give them the fullest, most honest picture I have, and they make the call. That is what keeps it their business instead of mine.

What goes wrong

The predictable ways this falls apart all come from skipping a step or leading with ego.

You pick a mode blind. You skip the tool audit, guess at where the team is, and run a Focus Day for a mode three team or drop a mode one team straight into a quarterly. Look first.

You come in as the expert who trashes their work. It feels good and it costs you the room. Whatever they built, they built with real effort, and the fastest way to lose a self-implementing team is to tell them it was all wrong. Layer, do not level.

You name the problem and then solve it for them. If you diagnose the bad number and then tell them what to do about it, you are now running their company. Give them the data and make them decide.

You let sloppy language slide. If a team is calling the tools by the wrong names, fix it early. Getting the terminology right is part of getting the system right, and it signals that precision matters here.

The payoff

Run it this way and you meet the team where they actually are instead of where your process assumes they should be. You keep everything they got right, which is often more than they get credit for, and you install the one thing they could never install for themselves: a voice with no reason to protect anyone, that will say the number is nonsense when the number is nonsense.

That voice is what they were missing the whole time they were self-implementing. It is why they finally called you.