EOS-ish organizations (and why frameworks need Integrators)

In our final year at ChatterBoss, we implemented EOS.

Looking back, we were what I now call ”EOS-ish”.

We had someone on the team with EOS familiarity, but they weren’t an Integrator. They were in sales.

We didn’t have a true execution owner balancing implementation with business strategy. The system was filtered through my Visionary lens: abstract, future-oriented, sometimes overly optimistic.

EOS was valuable.

It gave our team of ~15 a shared language.

It created alignment faster than we could have without it.

Because we had years of trust and history, we made it work reasonably well.

To be clear: EOS is a well-designed system.

The issue wasn’t the framework. It was how we carried it, and who was responsible for making it work.

And.

We also once spent an entire two-hour meeting with 10 people trying to align on what a “Rock” actually was.

That’s 20 collective hours spent debating terminology instead of executing.

The conversations about EOS began competing with the work itself.

That experience mirrors what we saw repeatedly across our Office of the CEO research.

Turns out, we weren’t alone.

How EOS Shows Up in Practice

Across our Office of the CEO audits, EOS came up in roughly 65–70% of conversations—as a current system, a past attempt, something the founder had self-implemented, or something they were planning to implement.

Most often, founders described a similar path:

“I read Traction and implemented it myself.”

“We use EOS language, but not the full system.”

“We tried to run it internally.”

In some cases, founders also referenced Rocket Fuel, usually after sensing strain between Visionary and Integrator responsibilities.

What stood out wasn’t the intent.

Founders were actively seeking structure, clarity and execution discipline.

What stood out was how EOS was carried inside the organization.

The Pattern We Observed: EOS-ish Organizations

What “EOS-ish” means:

EOS vocabulary embedded in conversations. Rocks defined but revised mid-cycle. Scorecards reviewed but not consistently tied to action. Meetings happening without durable follow-through.

The language adopted, but execution outcomes largely unchanged.

This was the pattern we saw across the majority of organizations using EOS.

Founders often summarized the experience this way:

“We added structure, but execution didn’t really change.”

or

“We’re aligned, but things still don’t finish.”

The framework introduced shared language.

Execution outcomes remained largely unchanged.

Why Self-Implementation Created Drag

In most EOS-ish cases, the Visionary carried implementation personally. Not only does that split attention forcing the visionary to wear multiple hats, it also ignores the fact that most visionaries are simply not wired to do the integrator type work.

As the organization grew, this created compression.

EOS became another layer the Visionary managed, rather than a system that reduced load.

Without a dedicated Integrator, structure existed, but execution ownership stayed diffuse.

Where Outcomes Diverged

The strongest execution outcomes had less to do with which framework was used and more to do with timing and role design.

Here’s what made the difference:

In organizations with better follow-through, we consistently saw:

• An Integrator hired before or alongside EOS rollout
• Clear execution ownership established early
• Reinforcement and closure moving off the Visionary

In those cases:

• Routines held
• Scorecards translated into action
• Completion rates improved

One founder described the shift simply:

“Once someone else owned traction, the system actually worked.”

This Isn’t Just About EOS

The same pattern appeared with other frameworks:

• Scaling Up adopted but meetings inconsistent
• OKRs defined but not reinforced
• Custom operating systems documented but unevenly followed

The common thread:

When the Visionary owns framework implementation and execution oversight, the system becomes another thing to manage, not something that reduces load.

What the Data Shows

Across the dataset:

• EOS language was common
• Self-implementation was frequent
• Execution outcomes improved when EOS was paired with an Integrator early

Where no Integrator was embedded, EOS added vocabulary without the desired results.

What This Means for the Office of the CEO

Frameworks don’t replace role architecture.

When execution ownership is unclear, even well-designed systems struggle to produce durable outcomes.

When execution ownership is explicit, frameworks tend to work as intended.

What’s Next

This is Week 4 of The State of the Office of the CEO: 2025 Findings.

Coming next:

Week 5: Integrator Cognitive Load—the invisible infrastructure collapsing under unowned complexity

Week 6: AI Trust Dynamics—why Integrators deploy AI everywhere except high-stakes decisions

Week 7: Designing Effective Visionary–Integrator Architecture—structural principles from 200+ implementations

Each release documents observed patterns across the dataset.

A Diagnostic Lens

If you’re using EOS (or any framework) but execution still feels uneven, the constraint may not be the system, it may be role design at the Office of the CEO level.

We offer structured diagnostics focused on execution ownership and role design.