Self-Implementing EOS: The Tools Teams Get Wrong, and How to Get Them Right

Introduction

As we've seen many teams using MonsterOps to self-implement EOS®, we decided to ask EOS® implementers for their take on self-implementing EOS®, the risks and how to avoid the pitfalls.

Most teams that run EOS® on their own struggle for a reason that has very little to do with how hard the tools are to understand.

They struggle because filling out the tools properly is hard.

Fill out the Accountability Chart honestly, and it will tell you that someone on your leadership team is sitting in the wrong seat. Build the proper Scorecard, and it will put a number in front of you that you have been quietly avoiding for months. Run the weekly meeting with real discipline, and the issue nobody wants to raise ends up on a list, on a screen, with the whole room looking at it.

That is uncomfortable, and so teams do what people generally do when something is uncomfortable. They draw the chart around the people they already employ, and they put revenue on the Scorecard because nobody ever argues with revenue. They get through the agenda each week while pushing the hard issue into the next meeting for the fourth time running. After three months, it's easy to look at it and say it's not working.

We asked a group of EOS® implementers what they see when they walk into companies that have been doing this alone. These are people who sit in other companies' leadership meetings for a living, and their answers were blunt and quite consistent.

What follows is what they told us, tool by tool, along with what to do about it.

EOS® is a system, not a menu

The mistake implementers raise before any other is that teams take the parts of EOS® they like and quietly leave out the rest.

Chris Goldmann has no patience for this at all. Once you drop some of the tools, he says, “it is no longer EOS, it's their rendition, which is always a shit show.” Jake Wells makes the same argument, pointing out that you don't get to do only a few exercises from the workout and eat only the dessert portion of the diet. You are welcome to try, but it simply won't work very well.

The reason half of EOS® performs so badly is that the tools feed one another. The Scorecard tells you which problems are real rather than which ones are loudest, and the Accountability Chart tells you unambiguously who should own each of them. The weekly meeting is where they get solved and decisions have to be made, and the one-page plan tells you which of them actually matter this year. Remove any one of those, and the others become far less powerful.

Justin Winnet adds a warning: you don't have to drop a tool to break the system; you only have to run it shallowly and miss the impact it produces. Most self-implementing teams are far closer to paying lip service than they believe.

This is why almost every implementer we spoke to gave the same first instruction: run EOS® as written before you adapt it. You should learn the recipe before inventing your own, because a team that can't follow someone else's recipe is unlikely to follow its own. As with cooking, use a measuring cup at the beginning, he says.

The tools and what goes wrong with each

The Accountability Chart

The Accountability Chart sets out who owns what in terms of real responsibilities rather than job titles, and it is the tool implementers complain about first. They all describe the same failure: teams build the chart around the people they already have.

The correct order runs the other way. You design the structure the company needs, decide what each seat is responsible for, and only then write names into the boxes. Paul Meadows says most companies do this backwards because arranging the chart around your current people feels natural. He is direct about the consequence. Do it properly, and you may discover that someone no longer has a seat, at which point a hard decision is waiting for you. Avoiding that decision, in his view, is the actual reason teams get the chart backwards.

That is worth sitting with because it means the problem is not really a problem of method. Leaders understand the method perfectly well, but they avoid it because it forces a decision they'd rather not have to make.

Justin Boling describes the same pattern when he says teams keep people in seats instead of defining the right seats, and Jim Lovelady points out that companies routinely turn a clarity tool into an ordinary org chart. Jake Wells mentioned that everyone thinks their baby is cute, and the same is true of their Accountability Chart, but he has seen many ugly babies.

A useful way to test your own chart is to build it again from scratch with no names anywhere on it. If you find that you cannot design the structure without picturing the people currently doing the work, then what you have drawn is an org chart with new labels on it. Add the names at the very end, and accept that some of them will not fit.

The one-page plan and your core values

EOS® calls this document the V/TO, and it holds your core values, the thing your company is genuinely best at, and where you intend to be in ten years.

Chris Goldmann rates it alongside the Accountability Chart as one of the two most important documents in any business, and he is specific about which part gets faked. Core values describe how a company already chooses to behave, and, in his words, they should be “DISCOVERED, never demanded.” This means you find the values your company lives by rather than inventing the ones you wish it lived by. Mia Juan sees the same thing from a different angle and says core values are the first thing self-implementing teams get wrong, which is why her opening advice is to slow down and take the time to get them right.

The failure here is a quiet one, and that is what makes it dangerous. A leadership team spends an afternoon at an off-site writing five agreeable words; the words go up on the wall and onto the careers page; and from then on, nobody uses them to decide anything at all. No hiring decision turns on them, nobody is let go because of them, and no client relationship ends because of them (remember integrity at Enron?). You end up with a glorified document rather than a working tool for improving your company.

The ten-year target carries its own version of this problem. Goldmann's rule is that every decision should move you closer to the target and that anything that doesn't should not be done. That only works if the target is concrete enough to measure a real decision against. That isn't easy to do, but that's exactly why it's such a valuable exercise.

The test worth running is to name the last decision your core values actually changed when it was inconvenient (e.g., letting go of a good salesperson because they didn't fit the culture). If nothing comes to mind, how do we know they aren't just wishes?

The Scorecard

The Scorecard is the short list of numbers a leadership team looks at every week, and two separate things tend to go wrong with it.

The first is straightforward. Boling and Lovelady both describe the same pile-up of too many numbers, owned by nobody in particular, updated inconsistently, and therefore trusted by no one.

The second is less obvious. Paul Meadows explains that most leaders load their Scorecards with lagging indicators. A lag measure is an outcome and reports what has already happened, while a lead measure is an activity that changes behaviour now and predicts what happens next. While lagging indicators matter, he argues that they pale in comparison to the value of good lead measures.

For example, revenue is a lag measure, as are closed deals, churn, and margin. This means that by the time any of them turns red, the quarter that produced the result is already finished, and all you can do is explain it. It's like trying to drive by looking in the rear-view mirror. Proposals sent, on the other hand, is a lead measure, along with first-response time, demos booked, and onboarding calls completed. Each of these is entirely under our control and can be changed this week.

It can take several quarters of getting it wrong before a team lands on the handful of numbers that genuinely predict their business.

To test your own, take each number in turn and ask what somebody would do differently on Monday morning if it came in red. Where the honest answer is that nobody would do anything and you would simply know, you are looking at a lag measure. Keep a few of those, make the rest predictive, and put a name against every line.

In MonsterOps, we paid particular attention to those metrics and how we present them to increase visibility and accountability.

The weekly leadership meeting

EOS® calls it the Level 10 (L10 for short), and it follows the same agenda at the same time every week.

When implementers are asked where a team should begin, this comes up more often than anything else, largely because it is the tool that forces the others into existence. Jim Lovelady describes what it produces when it is run properly structure, accountability, and a weekly pulse, and then names the underlying issue by saying that most companies don't have a meeting problem so much as a meeting discipline problem.

The forcing function is what makes it a sensible starting point. The meeting arrives every week whether the team is ready or not, and it drags the rest of the system along behind it because you need numbers to review, priorities to check, and an issues list to work from. Teams that start here tend to find the other tools pulled into use without much argument, provided the meeting actually reaches them. Our guide to running better leadership meetings covers the practical cadence in more detail.

That is why MonsterOps treats the meeting as the heart of your operating system, using live metrics, Rocks, and an issues list rather than relying on separate documents assembled by hand each week.

One warning is worth adding because a calm meeting is easily mistaken for a healthy one. Jake Wells settles the question by asking why you are all in the room if you are not arguing about the options. A leadership team that never disagrees is a sign that its members are reviewing status rather than making decisions.

IDS: actually solving the issue

IDS stands for Identify, Discuss, and Solve, and it is the part of the weekly meeting where problems are meant to get resolved. It is also the part that gets faked most often.

Lovelady says teams discuss and debate at length and then leave with the same issues still sitting on the list. Boling frames it as a straightforward discipline problem: people talk about issues without ever solving them.

Most of the time, the breakdown happens at the beginning rather than the end. Teams discuss the issue exactly as it was written down, and the written version is almost always the polite version, with the real issue sitting one level below it and requiring somebody to say something awkward. A team that never reaches that level can run an orderly, well-facilitated discussion every week and still fix nothing.

The check here takes about a minute. Open your issues list from three months ago, and if the same items are still on it, what you have been running is a discussion group with a timer. If you are using MonsterOps, a simple question to MonsterAI will give you the answer and keep you honest about where your team stands.

Rocks

Rocks are the goals for the coming ninety days. There should be a small number of them, and each should be owned by one person. Winnet lists them among the tools most often run without depth, and Juan puts it more plainly by saying that teams frequently don't know what the goal behind a Rock is supposed to be.

The usual failure is that the quarterly list is really a to-do list. There are too many items on it; several either have no single owner or have multiple owners; and most of them describe ongoing work rather than something that will visibly be finished or unfinished by the end of the quarter. When the quarter closes, nobody can say cleanly whether a Rock was hit or not, so the review turns into a negotiation, and the next quarter is set with the same fuzziness baked in.

A Rock that works passes a simple test: on the last day of the quarter, you should be able to say “done” or “not done” without any discussion at all. Anything that needs a conversation is not yet a Rock. MonsterOps requires a single owner and a status on every Rock for exactly this reason, though no software can stop a team from writing a vague goal.

The people tools nobody gets to

Two tools frequently never make it into a self-implementation at all, and Mia Juan names both of them: the People Analyzer and quarterly conversations. Each requires a structured discussion about whether a particular person is right for a particular seat, and each is the kind of thing a leadership team sincerely intends to get to next quarter, every quarter.

It is worth seeing that this is the same avoidance that bends the Accountability Chart, simply appearing somewhere else. Once the chart has been drawn around the people already in the building, any tool that measures those people against it becomes uncomfortable by design, and so it keeps getting postponed.

What the teams that make it work do differently

When we asked what successful self-implementers have in common, almost nobody answered in terms of process, and nearly everybody answered in terms of character.

The first thing is that they commit all the way. Justin Boling describes teams that choose consistency over perfection, that want a healthy leadership team rather than a busy one, and that spend enough time using the tools that they become part of how the company works. They don't dabble; in his words, they commit.

The second is honesty about the current state. Lovelady says the teams that succeed don't pretend things are working when they aren't. Just as importantly, they resist the temptation to reshape the process into something more comfortable. Alongside that, he argues, you need at least one strong internal champion who protects the discipline, because without a named person whose job that is, the process is the first casualty of a busy quarter.

The third is a genuine appetite for change. Justin Winnet's entire answer was four words: “a desire to change.” This sounds obvious until you count how many leadership teams adopt an operating system in the hope that it will fix everybody else in the building.

The fourth is the most practical thing anyone said, and it came from Paul Meadows. Some self-implementers book a single day with an implementer once a year or bring one in to run their two-day annual planning session. They use it as a check that they are doing things correctly and as a chance to get expert answers to the questions they have stored up. Teams that do this, he says, outperform teams that go it entirely alone. Self-implementing and hiring an implementer don't have to be a black-and-white choice. One paid day a year can be the thing that helps make self-implementation a success.

The blind spot you can't design around

Self-implementers face a structural difficulty: the person running the weekly meeting is also sitting in it, usually as the most senior person present and sometimes as the subject of the issue nobody wants to raise.

Paul Meadows calls this the leader's dilemma. It is hard to step outside a system you are part of for long enough to work on it, and harder still to see the whole company rather than the parts you touch every day. Justin Winnet says the same thing from the inside and rather more bluntly, pointing out that when you are working on the business, there are times when you are the problem.

There is a second version of this that is harder to notice, and Jake Wells names it when he describes teams rating themselves as absolutely crushing it on dimensions where they are merely average, then asking how they would ever know. He has a point. A self-implementing team scores its own checkup, decides for itself whether the chart is strong, and judges for itself whether the meeting was disciplined. Every one of those assessments is made by the person with the most reason to award a pass.

You are unlikely to be fully objective about a system you are inside, although you can still be consistent, and consistency compounds in a way that objectivity does not. That is Boling's answer: stop trying to make it perfect and simply get better every week, in much the same way you would approach a new training regime. Meadows' one day a year could be a way to get an outside perspective.

What's different in 2026

The change implementers keep returning to is AI, but none of them raised it as a solution.

Paul Meadows spent twenty-five years in IT and describes himself as a fan of the technology before drawing a careful line. Plenty of teams will try to use AI to run EOS® for them, and it will handle the routine parts perfectly well. Some of this work depends on human judgement, though on reading tone, reading a room, and sensing what somebody is carefully not saying. That part is not ready to be handed over. Chris Goldmann describes the leader who asks ChatGPT, receives an answer, but never understands the thinking behind it, ending up with output that lacks true understanding.

Jim Lovelady points out that staying focused has become considerably harder. In his view, that makes EOS® more useful now rather than less because it supplies clarity and discipline to teams being pulled in every direction at once, especially with AI disrupting everything. Justin Boling maintains that nothing important has changed at all, since something always changes. The companies winning at any given moment, he says, are clearer than their competitors, better aligned, and better at execution.

The reasonable conclusion was that AI can carry the administration of an operating system including the notes, summaries, chasing, reporting, and first drafts while the conversations remain entirely human. Where it reduces the friction of running the system, it earns its place, and where it becomes a way of avoiding the difficult conversation, it is the cherry-picking problem again in more modern clothes. That is the approach we've been embracing at MonsterOps from day one. MonsterAI will tell you which Rocks are drifting and what your team decided about a question last quarter because it can read your own goals, numbers, issues, and meeting notes, but it won't be able to help with the conversation you have been avoiding since March.

Where software actually matters

Selfishly, as the owner of MonsterOps, I asked them in what ways they thought software mattered.

Very little of the above is a software problem, and nobody would describe a team as having failed because the Scorecard lived in the wrong application.

Two of these findings do have a software consequence, though.

The first is consistency, which is largely a question of friction. If updating the Scorecard means chasing five people for numbers, if it is slow to update, or if it is super clunky, then it stops happening during a busy week and a busy week is precisely when it matters.

The same applies to access: when half the team has no login because seats are charged individually, the data goes stale, and the weekly meeting slowly turns into a status report (which is why we decided to provide unlimited seats with MonsterOps by default).

The most repeated point across every conversation was that doing half of EOS® doesn't work because the tools depend on one another. That argues for keeping the whole system in one place, where the Scorecard, Rocks, issues list, and meeting genuinely connect. Spread them across a spreadsheet, a shared document, and a task app, and cherry-picking makes things harder (or breaks the whole system).

These insights shaped how we built MonsterOps. Our flat price ensures nobody is left out of the system for licensing reasons. Everything runs in one place, and everything is reachable through a full API and an MCP server, which means your own data stays usable outside the tool.

If you are working out where to put it all, we ranked the options in Self-Implementing EOS®: Top 7 Software Tools, and if you would rather start with the reading, these five books are where most self-implementers begin.

Final words

Not everyone we spoke to thought self-implementing was a good idea.

Chris Goldmann rejected the premise entirely, telling us there are no successful self-implementing companies. EOS® is a complete system; teams running it alone never develop a deep enough understanding of what it can do for them, and they will never match a team that has been properly coached. There is no game and no profession, he says, in which anybody learns from a book alone.

Paul Meadows makes the financial argument instead, observing that, spread across a year, an implementer costs slightly more than a minimum-wage employee and asking whether that is a worthwhile investment to get everything you want out of the company. He then asks the harder question: whether a leader is self-implementing because it suits the business or because they need to remain in control, and whether they could handle discovering that the problem is them and hearing somebody say so.

The teams that make it work commit fully to the system, and they run it as designed before changing anything. They stay consistent long after it stops feeling new, and they give one person the job of holding the line.