Implementing a Formal Operating System Like EOS or the Rockefeller Habits

Listen to this Blog Post

Throughout recent history, there has been substantial growth in the number of companies who have decided to implement formal “operating systems” to govern certain strategic and operational decisions within their businesses. Though there are many operating systems in existence today, two of the most widely used systems are EOS (the Entrepreneurial Operating System, based on the book Traction, by Gino Wickman) and The Rockefeller Habits (based on the books Mastering the Rockefeller Habits and Scaling Up , both by Verne Harnish).

I implemented EOS in my own company beginning in 2015, and we continued to operate under its various principles and structures until successfully selling the company in late 2020. Though a formal operating system likely isn’t appropriate for all companies and all circumstances, we benefited tremendously from our own implementation.

Based on that first-hand experience, below I share a number of FAQs that I often receive from other CEOs related to the implementation of a formal operating system within a SMB. Though we happened to choose EOS as our system, substantially all of the principles and observations that I share below can be applied to any comparable system.

It’s likely worth noting here that I’m not affiliated in any way with any operating system. I’m simply speaking as a happy customer.

What is an Operating System and Why Did you Choose to Implement one?

Either of the books mentioned above can almost certainly do a better job than I can in defining specifically what an operating system is, but for what it’s worth, I’ve always thought about them as a clear and structured way to incorporate the basic principles of good corporate hygiene into any business. By “good corporate hygiene”, I’m referring to the basic tenets of vision, strategy, operations and execution that substantially all businesses should have in place.

Because EOS is the system with which I’m most familiar, I will use it as my reference point here. In the figure below, I’ve laid out the basic components of EOS (note that other operating systems tend to share many of the same core principles, though often under different names).

As you’ll likely notice, nothing within this framework is profoundly unique or surprising – and that is indeed the point: Can anybody reasonably argue that companies shouldn’t have a clear vision, and a documented plan on how they’re planning to achieve that vision? Can anybody reasonably argue that a company shouldn’t have structured and efficient meetings, clear data and lines of accountability, or systems in place to evaluate their employees? Can anybody reasonably argue that surfacing and solving key issues at the highest level of the organization is a bad thing?

Indeed, in my opinion, the sign of a good operating system is the extent to which it’s basic tools and tenets strike you as intuitive (and perhaps even obvious). In my case, I viewed each aspect of EOS as something that we should have had in place already, with the system itself acting as a sort of structured “forcing function” for me to finally put these things into place.

Should I Use an Implementer/Coach, or Implement the System on my Own?

Alongside the establishment and growth of these operating systems, a cottage industry of sorts has emerged to help CEOs implement the programs described in the corresponding books. “Implementers” or “Coaches” are people specifically trained in each respective operating system who work with CEOs and their management teams to formally implement each tool that the system offers.

I’m often asked by CEOs whether they should use an implementer, or simply implement the tools themselves. Though I can’t say that there is one answer that is best for all companies, I can tell you that we chose to use an Implementer ourselves, and I would happily do so again if faced with the same decision at some point in the future. There are four primary reasons for this:

1. I found that utilizing the services of an implementer created a much higher degree of accountability for me personally. After each meeting, each member of the management team (including and especially me) was given specific “To Do” items that needed to be completed before our next meeting. Without the external accountability mechanism provided by the Implementer, I suspect that I would have been less disciplined in my part of the implementation process, likely because I would have been consumed by the day-to-day “whirlwind” that is an inevitable part of running any small or medium sized business.

2. Our Implementer provided us with tools and exercises that were nowhere to be found in the book. I specifically remember the unique way that our Implementer worked with our management team to help us tease out our company’s core focus, core values, and 10-year target. I won’t give away any of his secrets here, but suffice it to say that I never would have thought of a similar process on my own, and I strongly suspect that the insights that we would have gleaned from the process (had I run it myself) wouldn’t have been nearly as insightful or meaningful.

3. In a way, the financial commitment associated with an implementer forced us to take the implementation extremely seriously (which is the only way to implement, as I’ll discuss further below). Though I viewed the costs as reasonable, it represented an expense nonetheless, and as a result I made both myself and my team accountable for deriving an acceptable return on the dollars that we had spent.

4. Finally, I found that using an Implementer helped me retain bandwidth (that I could deploy in other areas of my company) that otherwise would have been devoted strictly to our EOS implementation: In any implementation, a certain amount of time simply needs to be spent on tasks like scheduling and preparing for meetings, managing deliverables, answering questions, and running various exercises. Without the use of our Implementer, these tasks likely would have fallen squarely on my own shoulders, which in turn would have taken time away from the countless other things requiring my attention at the time. For this reason, I often challenge CEOs who choose not to use an Implementer for reasons purely related to cost, as most of the time these CEOs still pay a large (though theoretically indirect) price through the time that they’re forced to spend away from their day-to-day job.

It’s worth noting here that an engagement with an implementer should be finite. Indeed, in my opinion, the goal of any good implementer should be to essentially work themselves out of a job within an agreed upon timeframe. We chose to work with ours for 12 months (though we could have chosen a shorter time frame), and by the end of those 12 months, it became clear to everybody involved that we no longer needed the Implementor’s guidance, as we had essentially become experts in the tools ourselves. From day 1, this was everybody’s stated goal.

To What Extent Should I Include my Management Team?

Though the tools of an operating system do indeed represent good corporate hygiene that should likely be in place anyways, chances are it will ask a lot of your management team in terms of time, effort, and adopting new ways of doing things. As a result, buy-in from your management team is absolutely critical, as your implementation will likely stall without it.

One way to build that buy-in is by getting the management team involved in the decision of whether or not to adopt the operating system in the first place, as people become inherently more invested in decisions when they play a role in making the decision itself.

It’s worth mentioning that this could put a CEO in an awkward spot where she wants to implement an operating system, but a member of her management team does not. Though this may be uncomfortable, it may not necessarily be a bad thing in and of itself, as situations like these often tend to be instructive: Given the intuitive nature of the tools contained within most operating systems, it’s interesting to probe into specifically why a given manager doesn’t want to implement. Presumably it won’t be because they think that a clear vision, efficient meetings, good data, clear lines of accountability, or good employee systems are bad things (if they do, it’s time to find a new manager!). Most likely, their source of dissent is likely to be time-based (i.e. “We’re busy enough as it is, we don’t have time to layer on something new like this”). However, in my opinion, a level of chaos, firefighting, or relentless busyness that would ostensibly preclude an implementation is actually itself a reason why that company would benefit from an implementation (this isn’t to suggest that implementing a formal operating system is the right decision for all companies in all instances. More on this below).

Another important reason to get your management team deeply involved in an implementation is because they themselves often need to become experts in the system when they diffuse the processes, structures, and tools at a departmental level within each of their respective operating groups (indeed, a full implementation that permeates every level in the organization is where operating systems tend to really shine). It will be much harder for members of your management team to be teachers of the system without having first been students of it.

Can I “Partially” Implement an Operating System?

A “partial” implementation could mean implementing only a small percentage of its tools, involving only certain team members, implementing it only within certain departments, or utilizing the system’s tools only some of the time.

My experience would suggest that doing so would be a waste of both time and money. Like anything in business (and in life), what you get out of something is directly proportional to what you put into it, and if you put in a “C-” effort, you will likely get “C-” results. Said another way, in my opinion, you should be all-in or not in at all. Though there may be examples of companies who have partially implemented an operating system successfully, I’m not aware of any.

In addition to this “Garbage-In-Garbage-Out” principle, there are two other factors that would dissuade me from a partial implementation:

1. A Partial Implementation Where Only a Subset of the Tools are Implemented: This will likely become very challenging very quickly, because many of the individual tools of an operating system tend to be highly interrelated. For example: Good weekly management meetings (tool 1) should explicitly discuss everybody’s main quarterly priorities (tool 2), but you can’t have a quarterly priority if you don’t have a one-year goal (tool 3), you can’t have a 1-year goal unless you know where you want to be in three years (tool 4), and you can’t know where you want to be in 3 years unless you have a clear vision (tool 5) and mission (tool 6) that you’re working towards.

2. A Partial Implementation Where It’s Implemented Only in Certain Departments: Some companies implement operating systems and choose to largely keep the system within the management team. In my opinion, doing something like this would likely only yield partial results and reduce the return that your company will realize from implementing an operating system in the first place. As mentioned above, the true magic of our operating system came when it was diffused down to every department (and, in turn,) every individual within our company. When we did this, we had true organizational alignment around what was truly important, and this wouldn’t have been possible had we kept the tools only at the management team level.

Do I Need to buy the Associated Software Tools?

Due to the growing popularity of these operating systems, another cottage industry has evolved composed of software products (often developed by third-party firms) that companies can use to manage their ongoing implementation and use of a given system. This is a question on which I have a less definitive view: We chose not to purchase any of these software tools, instead managing our implementation through Google’s suite of online tools (Sheets, Docs, etc.). While I suppose it was clunky at times, I never felt as if our implementation was at all hindered by our lack of software tools. Other CEOs I know have purchased the software tools, and speak highly of them. Ultimately, this is a simple cost/benefit decision that each CEO will likely have to make based on their own circumstances.

When is the “Right” Time to Implement an Operating System?

Because I view operating systems as a “forcing function” for management teams to implement the basic best practices of strategy, planning, and execution that should likely be in place anyways, I tend to think that there are only a small handful of instances in which beginning an implementation would represent bad timing. These limited instances are profiled below. If none of them apply to you, it’s likely that your company is ready:

1. The company already has similar structures, processes, and tools in place, negating a need to implement in the first place;
2. The company has not yet found product/market fit and is currently iterating on basic things like their vision, competitive positioning, and so on;
3. The company is not actively pursuing growth;
4. The CEO isn’t fully and genuinely bought into the need to implement;
5. The CEO is brand new to the company

When the CEO is New to the Company

As I mentioned in an earlier blog post, Lessons From my First Month as the CEO of a Newly Acquired Company, I tend to be of the belief that new CEOs are best served taking a measured, humble, “listen-first” approach to their early months on the job. This is so because regardless of how much diligence a new CEO performs in advance of joining the company, it is almost certain that there is still an overwhelming amount of information that she doesn’t yet know about it. For this reason, in my opinion, it’s best for new CEOs to diagnose before they prescribe: That is, take the time to truly understand what the problems and opportunities are in the business before you start making definitive decisions (like those decisions prescribed by an operating system) around them.

It’s also worth noting that, even if a given business is ready for an implementation, it’s possible that a new CEO herself isn’t ready for the implementation to begin. New CEOs often don’t have the experience, context, and information that would otherwise inform fundamental decisions like the company’s long-term targets, mission, and vision, so it’s best to pause on a new implementation until the new CEO feels comfortable that she has that required context.

In Sum

Nowhere in the world’s leading MBA schools will you see mention of implementing a formal operating system to help govern the planning, strategy and day-to-day operations of a SMB. However, in my experience, it is highly practical frameworks like these that are most important and impactful for CEOs and the companies that they run.

Though it’s important for CEOs to know how to calculate their weighted average cost of capital, or know the Four P’s of Marketing, or describe Porter’s Five Forces (among dozens of other tools and concepts typically taught in academic environments), tangible tools like operating systems are at least as important as these concepts, if not more so. If you are looking to add order to the chaos, create organizational clarity and alignment, and better manage your organization’s most important assets, then an operating system is at least worth a thoughtful evaluation.  

---