Over the past few years I’ve taken a fair amount of friendly grief from EOS Implementers about Strety and the topic of EOS purity. Usually it comes with a smile, sometimes with a little head shake, and occasionally with the very polite version of, “Brian… that’s not exactly EOS pure.”
And honestly, they weren’t wrong.
When I first started building Strety, I was coming at EOS the way a lot of founders do when they’re self-implementing. I loved the philosophy, loved the language, and believed deeply in the idea that a simple set of tools could bring clarity and accountability to a growing company. We were running Level 10 meetings (my favorite EOS tool to this day), we had a Scorecard (which I’ve always loved because I’m a data guy at heart), and we were trying to create the kind of culture where everyone knew what mattered each week.
But at the same time, I was building software for founders like me who were figuring this out on their own. And if you spend time with enough self-implementers, you start hearing the same requests over and over again. People say things like, “It would be great if we had a place to park issues we can’t get to yet,” or “I wish we could keep a backlog of Rocks,” or “It’d be helpful if the team could vote on issues before the meeting.”
Those didn’t feel like crazy ideas. They felt practical. So we built an Issues Parking Lot, a Rock Backlog, and the ability to sort Issues by votes in L10 meetings. Not only were we building these extras for our customers, we used the heck out of them ourselves.
Once we got our EOS license, those kinds of “extras” were exactly where the occasional friendly pushback from Implementers would come in. They’d remind me that EOS works best when the tools are used the way they’re designed, and that once you start modifying the mechanics too much, you can unintentionally break the rhythm that makes the system work.
At the time, my thinking was pretty simple. There are far more companies self-implementing EOS than working with Implementers, and my original philosophy was to build the product I would want if I were running EOS on my own. My assumption was that if I found something useful, there were probably thousands of other companies out there who would, too.
That assumption has mostly held up.
But something interesting has shifted for me as I’ve spent more time inside the system and worked more closely with the EOS discipline itself — and seen it through the eyes of our own Implementer. I’ve started to see more clearly why the concept of EOS purity exists in the first place. It’s not really rigid or dogmatic. It’s just designed really intentionally so that the core tools reinforce each other.
Some of our most controversial “extras” for implementers are the backlogs and “parking lots” I mentioned above, for one simple reason. Pretty much anything that we were subcategorizing in those ways should just sit in one (long) long-term Issues list, for the leadership team to KKC (Keep Kill Combine) every quarter. There really should be no “backlog” Rock, because a Rock is something that you’ve decided to make a priority. Same with “parking lot” Issues – they should live where the rest of your long-term Issues live. One of the huge benefits of using the EOS tools “purely” is they help you stay focused — and these modifications make it easier for things to get muddy.
Going through the exercise with Lisa about those “extras” and having her run our first implementer-led Annual with us made me realize that as self-implementers, we sometimes overcomplicate things. Like people say, EOS is simple, but not easy. The modifications and extras might seem to make sense, but they actually introduce more confusion than clarity at the end of the day.
It made one thing clear to me — we needed a KKC feature in the software. Once we introduced that and actually ran through an implementer-guided Annual, keeping everything in the long-term Issues list made a lot more sense. So while we took a couple “extras” out of our Strety experience, we added something powerful in — a tool that helps teams dig in and prioritize like they should.
So yes, in many ways I’ve become a believer in EOS purity. Lisa (and most Implementers) are really not the “purity police” telling us what to do. But through teaching, facilitating, and guiding us, I’ve now seen how much cleaner things run when the core tools stay intact and are used the way they were designed.
Where I still believe there’s room to expand, though, is outside of those core tools. EOS intentionally doesn’t try to solve every operational habit inside a company. One-on-one meetings are a good example. EOS gives guidance, but it’s flexible by design, because different leaders and teams operate differently. The same thing happens with a lot of the smaller workflows that show up once a company is actually running.
That’s the space where I think additional tools can live.
So the shift for me hasn’t been about changing EOS. If anything, it’s been the opposite. The core tools should stay pure. Don’t modify Rocks. Don’t reinvent the Level 10. Don’t turn the Scorecard into something else.
But if teams want additional tools around the system to help them run the business more smoothly, that can exist too, in what we call our EOS+ features — tools that live outside the core tools but are still deeply situated in an EOS implementation, like 1:1 meetings, projects, surveys, etc.
This is why inside Strety we’ve started thinking about those features a little differently. The EOS tools stay exactly the way they’re supposed to be. And if people want things like Issue voting or a Rock backlog that customers have asked for over the years, we can simply put them behind a small toggle labeled “Non-EOS-Pure Features.” We still want to support people running EOS the way they want — I’m a huge believer that some EOS implementation is better than none.
But we created an entirely EOS Pure version of Strety for those who want to stick to the discipline and have guardrails protecting the clarity of their implementation.
It turns out that’s a pretty healthy compromise.
The Implementers can rest easy knowing the core system is respected, and the self-implementers, who will always experiment a little because that’s just what founders do, still have room to solve the problems that show up while running a real company.
And somewhere in that middle ground is probably where most businesses actually operate anyway.