Why Your EOS Process Rock Keeps Failing (and What to Change This Quarter)

You set the Rock. The quarter ended. The Rock failed. Again. Here's why this Rock dies when your others land, and how to structure it so it finally gets done.

Key Takeaway

"Document our core processes" fails as a Rock because it's a craft job assigned to people who already have full seats. The fix is structural: scope the Process Rock to one process, name a pen-holder who is not the process owner, and run working sessions where the owner talks and the pen-holder writes. If that math doesn't work in-house, bring in outside hands.

Why the Process Rock Fails When Your Other Rocks Land

The Process Rock fails because it's a craft job disguised as a task. Most Rocks are decisions and projects your leaders already know how to execute. Documenting core processes requires a separate skill set, extraction, interviewing, distilling, and it gets assigned as a side project to leaders who are already at capacity.

You know the loop. Quarterly planning, someone brings up the Process score, and "document our core processes" goes on the Rock sheet. Week 3, nothing. Week 7, "on track," and everyone politely pretends that's true. Week 11, off track, IDS'd into a plan to really push at the end. Quarter over. Rock failed. Back on the sheet with a new owner.

If that reads like your last three quarters, nothing is wrong with your team. In Traction, Gino Wickman calls Process the most neglected of the Six Key Components, and the Process Rock is where the neglect shows up. Teams stuck in this loop usually have a solid V/TO™, L10s that start on time, other Rocks that land, and a Process score sitting at the bottom of every Organizational Checkup. The problem isn't Rock discipline. It's this Rock. (For why the Process Component™ lags the other five and how to reach the 80 percent strength target, start with our pillar guide.)

Look at your other Rocks. Hire a controller. Launch the new pricing. Open the second location. Decisions plus project management, two things your leadership team is already good at. Now look at what the Process Rock requires: getting a process out of somebody's head, choosing the right altitude, and structuring it so a new hire can follow it. That's interviewing, distilling, and writing. It's a craft, the same way payroll and legal are crafts, and you would never put "do our own legal work" on the Rock sheet.

And the craft got assigned to the people with the least room to learn it. Your ops leader didn't stop running ops. Your sales leader didn't stop selling. Documentation became the eleventh priority in a ten-priority week, thirteen weeks in a row. The Process Rock didn't fail in week 12. It failed the day it was scoped.

The Three Reasons Your Process Rock Died This Quarter

A failed Process Rock traces back to one of three causes: nobody held the pen (documentation was everyone's job, so it was no one's), wrong altitude (your team tried to write full SOPs when EOS asks for 20/80 core processes), or no extraction method (people froze at a blank template).

Figure out which one killed yours before you set it again. The fix is different for each.

1. Nobody Held the Pen

The Process Rock gets structured one of two ways, and both fail. Version one: the Rock owner is "accountable for making it happen," which means sending reminder messages to department heads. Version two: each department head documents their own processes, which spreads the work so evenly that nobody owns any of it.

Either way, there's no pen-holder: no single person whose actual deliverable is the finished document. Run GWC on the documentation job itself and the failure is predictable: your department heads may Get it and even Want it, but Capacity is the C that fails, thirteen weeks in a row. So the knowledge stays in their heads and the shared drive stays empty. We've written about this dynamic in what to do when your expert won't document what they know. It's rarely resistance. It's a full seat plus a task from a different skill set.

2. Wrong Altitude: You Asked for 20/80 and Got 40 Pages

EOS is specific here: 6 to 10 core processes, each documented at 20/80. Capture the 20 percent of steps that produce 80 percent of the outcome, in one to three pages. Not a manual. Not a screenshot-by-screenshot SOP.

Almost nobody lands at that altitude on the first try. The detail-oriented ops manager turns process one into a 40-page manual, burns nine weeks, and processes two through eight never start. Or someone knocks out ten pages of thin bullets in a weekend that nobody could train from. Both are altitude failures, and both burn the quarter. The fastest calibration is seeing a finished one, which is why we published real examples of what 20/80 documentation actually looks like.

3. No Extraction Method: The Blank Template Problem

The 3-Step Process Documenter™ gives you a clean frame: identify your core processes, document them at 20/80, get everyone following them. The trouble lives in step two, which quietly assumes the process will move from head to page by an act of will. So the process owner opens a blank template, stares at it, types "Step 1," and goes back to their real job.

Here's what we see constantly: the same person who can't write page one can talk about the process fluently for an hour, every step, every exception, every judgment call. The knowledge isn't missing. A method for extracting it is. Documentation is an interviewing problem before it's a writing problem, and that's the real reason so many teams are stuck on step two of the Documenter.

How to Structure the Process Rock Differently This Quarter

Rebuild the Process Rock around four changes: scope it to one core process instead of all of them, name a single pen-holder whose deliverable is the document, put recurring working sessions on the calendar, and separate talking from writing. The process owner talks while the pen-holder captures, drafts, and brings it back for review.

The Plural Is the Trap

The words "document our core processes" predict the failure. A Process Rock scoped to all your processes at once loses to whichever fire is loudest that week, and the result is none of them. If the Rock can't name the process, the pen-holder, and the session cadence, it's not ready for the Rock sheet.

1. Shrink it to one process. "Document our core processes" is a whole component wearing a Rock costume. Pick one process with two questions: where's the most pain when it's done wrong, and how much lives in one person's head? Highest on both wins.

2. Name a pen-holder who is not the process owner. The owner has the knowledge and a full seat. Handing them the pen is how the Process Rock died last time. The pen-holder needs writing chops and real hours: an ops coordinator, an EA who writes well, a marketer between projects. Their name goes on the Rock. It's a Rock assignment, not a new seat on the Accountability Chart.

3. Book the working sessions before the quarter starts. Forty-five to sixty minutes, weekly, same slot, protected like the L10. On the calendar, the Rock has a heartbeat. Scheduled "when things calm down," it's already dead.

4. The process owner talks. The pen-holder writes. Record every session. The pen-holder asks what kicks the process off, what happens next, where it breaks, and what gets checked before it's done. Within 48 hours the recording becomes a 20/80 draft. The owner marks it up in fifteen minutes. The next session closes the gaps.

5. Give the L10 something to check every week. Milestones on the Process Rock: sessions booked by week 1, draft by week 5, leadership review by week 8, team trained by week 11. A Rock that can only be judged in week 12 will die in week 12.

The Integrator's Role in This Rock

The Integrator's job is not to write anything. It's to protect the structure: keep the Process Rock scoped to one process, refuse to let working sessions get bumped, and stop the Visionary from adding three more processes in week 6. Scope creep kills this Rock faster than laziness ever will.

Run it this way and the Process Rock stops being a writing project and becomes a meeting rhythm, the one skill every EOS company already has.

When to Bring In Outside Help to Document Your Processes

Bring in outside help when the quarter's math doesn't work: nobody inside can hold the pen without dropping their seat, the same Process Rock has failed twice or more, or the knowledge sits with someone who will never write it down. Extraction and packaging are execution work, not facilitation, so this is not your implementer's job.

There's no prize for doing this in-house. You already pay outsiders for payroll, bookkeeping, and legal, not because your team couldn't learn them, but because the learning curve costs more than the service. Process extraction is the same category. It only feels different because everyone can technically type.

The math test is simple: the pen-holder needs three to five focused hours a week for a quarter. If every seat at your leadership table is full, that's your answer. Pulling your ops manager off ops to play technical writer for thirteen weeks produces a worse document than someone who extracts processes for a living, at a higher real cost.

The second signal is history. If this Rock has failed two or more quarters, you've run the experiment. More resolve is not a strategy; a year of the same failed Rock is data. Across the EOS-run companies we work with, in trades, staffing, and real estate, the pattern repeats: the Process Rock lands the quarter someone outside the org chart holds the pen.

One honest note on software, since it's usually the first reach: platforms like PlaybookBuilder, which describes itself as the Process software used by EOS Corporate, are built for storage, delivery, and training. What no platform does is get the process out of your operations manager's head. Extract first, then load the platform, or you're paying monthly for an empty shelf. We've written a full breakdown of documenting your core processes yourself versus hiring it done, including the honest cases where DIY wins.

A Failed Process Rock Also Poisons Followed By All™

Followed By All fails before it starts when the Process Rock keeps dying. Every failed quarter teaches your team that process documentation is optional, so by the time documents finally exist, the culture has already learned to ignore them. The FBA checklist (train, measure, manage, update) assumes documents your company takes seriously.

Spelled out: train everyone on the core processes, measure whether they're followed, manage to them through LMA, and update them on a real cadence: a review date on every document, checked at the same Quarterly where you set Rocks. Every item assumes documents that exist and a team that believes they matter.

A failed documentation Rock destroys that second assumption. Your team watched the Process Rock get set, die, and get set again with a speech about how important it is this time. Three cycles in, the lesson is unmistakable: leadership says process matters but behaves like it doesn't. When documents finally arrive, they land in a culture the Rock sheet itself trained to ignore them. It's the same graveyard dynamic we broke down in why your SOPs collect dust; EOS companies just have a more visible paper trail.

The reverse is also true, and it's the best argument for the one-process Rock. When a single process gets documented, trained against, and wired to a Scorecard number, your team sees process documentation work for the first time. The second process is easier to Rock because nobody's debating whether it's worth it. Followed By All isn't a policing project bolted on at the end. It's the compound interest on a documentation Rock that landed.

Frequently Asked Questions

I'm an Integrator and I can't get department heads to finish documenting their core processes. How do other EOS companies actually get this done?

The companies that finish stop asking department heads to write. They separate the knowledge from the pen: the department head talks through the process in a working session, and a pen-holder, an internal writer, an ops coordinator, or an outside partner, drafts the document. The head reviews and corrects. Reviewing takes an hour; writing competes with running a department, and the department always wins.

Our Process Rock failed again. Should we set the same Rock next quarter or change the owner?

Change the structure, not just the owner. Swapping owners fails again because the constraint was never the person. It was scope (all processes at once), altitude (SOP-level detail), or method (no extraction sessions). Next quarter, scope the Rock to one core process, name a pen-holder who is not the process owner, and put weekly working sessions on the calendar before the quarter starts.

The 3-Step Process Documenter says document at 20/80, but my ops manager keeps writing 40-page SOPs. How detailed should core processes actually be?

A core process should be one to three pages: the major steps covering the 20 percent of the work that produces 80 percent of the outcome. Your company needs 6 to 10 of them total. Full SOPs are a different layer that hangs off individual steps later. If a document takes a quarter to write, it is an SOP wearing a core process name tag.

Is there a service that will document our core processes for us? We run on EOS and keep failing this Rock.

Yes. Done-for-you process documentation exists, and it works differently than software: your leaders talk through the work in structured sessions, and the service extracts, writes, and packages the documents for review. The Systems Effect does exactly this. Software alone will not close the gap, because the problem is extraction, not storage. Evaluate any partner on one question: do they hold the pen or hand you a template?

How many core processes should we document, and which one comes first?

EOS points to 6 to 10 core processes. Don't start with all of them. Score each on two axes: how much pain when it is done wrong, and how much lives in one person's head. The process highest on both is your first Rock. One process documented, trained, and followed beats ten drafts nobody opens.

What should the Rock say instead of "document our core processes"?

Something like: "Sales process documented at 20/80, reviewed by the leadership team, and trained to the sales team by week 12. Pen-holder: named. Weekly working sessions booked." One process, one named pen-holder, milestones the L10 can check every week. If the Rock cannot fail visibly by week 4, it is written too vaguely to succeed by week 12.