What do self-implementers typically get wrong about EOS Process?

Self-implementers often swing between two extremes — either over-documenting every detail or avoiding documentation entirely because it feels bureaucratic. The result is that important processes end up living only in founders' heads rather than being clearly mapped at the right level of detail.

How detailed should EOS process documentation be?

Process documentation should focus on high-level core processes with clearly defined sub-processes and steps underneath them. The goal is clarity you can point to, not walls of text. Overly detailed documents tend to go stale quickly and rarely get opened.

What should EOS training focus on for new employees?

Training should focus on sub-processes and their steps, not on memorizing edge cases or reading lengthy documents. Link out to detailed training only where genuinely helpful. The right person in the right seat will know how to execute without excessive hand-holding.

How does good process documentation help with delegation?

When processes are clearly mapped, you delegate a defined way of doing something rather than vague expectations. This makes delegation safer for the team, less stressful for founders, and eliminates the paralysis of feeling like you need to document every tiny step before letting go.

Why is working with an EOS Implementer helpful for Process?

An implementer helps slow you down and forces explicit clarity on things you might not realize are blind spots. They can untrain self-implementing habits and provide a new perspective on how to think about scale, delegation, and ownership.

Blog Dogfood What I Missed About Process as a Self-Implementer

Dogfood

What I Missed About Process as a Self-Implementer

When we self-implemented EOS®, I genuinely thought we had Process handled well enough. We had documentation in key areas, we kept working on things as they bubbled up. Our teams were on the same page and onboarding wasn’t too challenging (in fact, we were good at it!). Process sat comfortably in the “important but not urgent” bucket, probably like many of you.

But I’ve seen the light now after a few sessions (and follow up calls) with the Process Queen and our implementer, Lisa González. She untrained us from our self-implementing mentality on process. Nothing she said was complicated. It was just a new way to see the same thing… that pesky thing called Process! Here’s what’s changed for me after diving into Process with an expert.

Process Starts with Simple Visibility
Train on Sub-Processes, Not Everything
Mapped Processes Actually Create Leverage
Why This Was Easy to Miss

Process Starts with Simple Visibility

The shift for me was realizing that Process isn’t about documentation for documentation’s sake. It’s not a wall of words or a folder full of SOPs that look impressive but rarely get opened. It’s creating clarity you can actually point to and read cleanly.

High level core processes, clearly defined sub-processes underneath them, and the right steps under those are all you need. The goal is to lay out the steps clearly and then delegate to the people you hire, and make them capable of doing the steps after proper training. It’s less about preparing for a hypothetical “who gets hit by a bus” scenario and more about removing ambiguity from the work that happens every day.

As a self-implementer, I tended to swing between two extremes. Either I wrote down every little detail, or I avoided writing anything because it felt heavy and bureaucratic. I realize now the result was predictable…. not much actually got written down, and a lot of important processes lived only in my head or Larry’s head. I can’t unsee it now.

Here’s another big one I learned…

Train on Sub-Processes, Not Everything

What actually matters for training and onboarding is documenting the high-level sub-processes for each core process, putting clear steps underneath them, and then linking out to training only where it’s genuinely helpful. Training should then really focus on those sub-processes and steps, not on memorizing edge cases or reading long documents that feel thorough but don’t age well.

You can still write detailed documentation if you love doing that, but in my experience those docs go stale fast. A Sales Process is a good example. Sub-processes like (1) reaching out to a trial or (2) requesting payment can each have a short checklist underneath them, and that’s usually enough to get someone moving in the right direction without the process ever collapsing under its own weight. And likely those sub processes will rarely change or won’t ever feel very stale.

Thinking about Process and onboarding in this way also drives home the importance of right person, right seat. The right person is going to know how to execute without a ton of hand-holding, which makes those impossibly detailed and heavy process documents obsolete.

Mapped Processes Actually Create Leverage

Once I saw how processes could actually create leverage for how we operate, things really started clicking. When your processes are laid out cleanly and at a higher level, you start to see extremely practical ways to operate better:

Delegation becomes dramatically easier. With good Process muscles, you’re delegating a clearly defined way of doing something, which is safer for the team and a lot less stressful for the founder. You also don’t need to be paralyzed about writing down every single tiny step and ultimately deciding “it’s easier to just do it myself.” This is a game-changer for people who have trouble “letting go of the vine.”
It becomes obvious what should be automated and what shouldn’t. When you can see the steps laid out, the automation candidates almost highlight themselves. In an increasingly AI-driven world, this feels huge. You can start replacing effort instead of just adding headcount, without guessing where the leverage actually is.
Accountability tightens naturally. When the “how” is explicit, accountability stops being personal or emotional. You’re not debating effort or intent anymore; you’re just comparing reality to a documented process.

That reframed our process for Process (see what I did there) from “should probably clean all this up someday” into a real growth multiplier as we continue to scale Strety with a small team.

Why This Was Easy to Miss

This all goes back to trying to implement EOS on my own. I had good intentions, but there were blind spots I didn’t even realize were blind spots. Having an implementer helps slow you down and forces explicit clarity. It changes how you think about scale, delegation, and ownership.

We’re still working through our own processes, but this already feels like one of those things I can’t unsee now that I’ve seen it. And once that happens, it’s hard to go back to relying on what’s just floating around in your head to build and scale a business.