It is Friday afternoon. The owner of a fifteen-person services firm is sitting at her desk with a printed dashboard, a stack of SOP printouts, and a half-cold coffee. Twelve months ago she did the work. The weekly leadership meeting started on time. The dashboard went up on the wall. The SOPs got documented in Notion over a focused ninety-day sprint. Today the L10 has crept back to forty-five minutes, the dashboard is two weeks out of date, and roughly half the SOPs are stale. She is wondering whether the whole exercise was worth it.
The honest answer is yes, and the second-year version of the system you built is what makes the work worth it. Much of what decays was always going to. What survives is the small set of pieces that genuinely run the business. The job at month twelve is curation, not addition.
What does a year-old operating system actually look like?
A year-old operating system is rarely the clean diagram you built in month two. It is a working version with rough edges, where some elements have become muscle memory and others have quietly died. EOS Worldwide describes the typical implementation arc as 18 to 24 months of facilitated work before a firm runs the system on its own. Year twelve sits inside that arc.
What you usually find on a Friday afternoon is a weekly leadership meeting that still happens but has changed shape, a dashboard that has drifted out of sync with reality, a Notion full of SOPs nobody opens, and a decision-rights document everyone forgot they signed off on. That is normal. It is the shape of an operating system meeting contact with how the business actually runs, not a failure of discipline.
The work in front of you is to read the system honestly. Which pieces are still earning their place, which have aged out, and which were over-engineered from the start. The same retrospective that EOS implementers run with clients at the 12-month mark, Scaling Up coaches build into their quarterly cycle, and McKinsey’s operating-model practice calls a fingerprint review. The question is which elements deserve year two, not whether to keep going.
Which parts of the year-one system hold up?
Three pieces tend to be durable. A weekly leadership meeting in some recognisable form. A handful of hard financial numbers. A small core of mission-critical SOPs tied to onboarding, compliance, and the parts of delivery where mistakes are expensive. The cost of not having them is immediate and visible, which is why they survive.
The meeting cadence holds even when the format shifts. Once a team has spent a year solving its real issues in a fixed slot, it protects that slot. EOS implementers report this as the single most resilient piece of the toolkit, and Patrick Lencioni’s meeting research backs the pattern, teams retain the rhythm long after they drop the formal script.
The financial numbers that survive are usually three to five, sometimes seven if the founder is unusually disciplined. Cash, weekly revenue, gross margin, pipeline, customer complaint volume. The ones tied to existential questions, are we solvent, profitable, retaining customers, delivering on time. Process documentation research shows the same pattern for SOPs, the ones embedded in training and tied to high-stakes operations stay live, while everything else ages out.
Which parts decay, and why?
The sprawling SOP library decays first. The fifteen-KPI dashboard goes next. The RACI matrix is the last to die because it never really lived. Each one fails for a different reason, but the common thread is whether the element was ever wired into the way decisions actually get made. Many are not, which is why they quietly disappear.
The SOP library is the most visible case. The ninety-day sprint produced thirty or forty documented processes. Twelve months on, two-thirds of them have not been touched. Process documentation research is consistent on this point, an SOP without a named owner and a scheduled review date has a useful life of nine to fifteen months before it becomes misleading. Without those two disciplines built in from the start, decay is a near certainty.
The dashboard goes next. The fifteen-KPI version becomes the one updated every other week, then the one updated when someone remembers, then the one with two weeks of stale data. Analysis of CRM and OKR adoption shows the same pattern, when metrics are not tied to a decision they become administrative overhead. Hey DAN’s review of the field puts CRM project failure at roughly 63 per cent for exactly this reason.
The RACI matrix decays differently. Rather than being abandoned visibly, it simply stops being referenced. People drift back to asking the founder for sign-off on anything ambiguous, because the cultural work that would let them act on the matrix was never finished. McChrystal’s Team of Teams research makes the underlying point, distributed authority needs trust and information-sharing as preconditions, not just a chart.
What does the second-year operating system look like?
Leaner, more selective, more personal. The weekly leadership meeting is still there, possibly shorter, with a sharper agenda and a tighter issues list. The dashboard has been pruned to the three to five numbers the leader actually uses on a Monday. The SOP library has been culled to the handful that protect the business. The decision-rights document is now a one-pager with named owners.
The harder shift is psychological. Year two is the point at which founder decision fatigue becomes a material execution risk. Roy Baumeister’s research on decision fatigue, and Vistage’s work with UK founders, converges on the same finding. Twelve months into running a business you are usually cognitively flat by Thursday afternoon. The operating system that survives is the one taking decisions off your plate, not the one adding more reviews to your calendar.
McKinsey’s operating-model work calls this periodically rewriting your operating-model fingerprint. The job is to match the structure to the way the firm actually works and the energy you actually have. Year one was about installing the system. Year two is about adapting it to the people who run it, including you. The dashboard, the SOPs, and the meeting cadence all serve that work, or they get cut.
How do you decide what to keep, rewrite, or drop?
Sort every element of the year-one system into three buckets. Keep the weekly meeting in some form, the three to seven hard numbers, the three to five mission-critical SOPs, and a one-page decision-rights doc. Rewrite the scorecard you have outgrown and the SOPs that have aged out of accuracy. Drop the SOPs nobody references, the dashboard cards that move with the wind, and the recurring meetings that have become ritual rather than work.
A practical test for any element of the system. When did this last change a decision or trigger an action? If the answer is never, or you cannot remember, it is a strong candidate for the drop pile. If the answer is recent but the process around it is heavy, it goes in the rewrite pile. If it consistently earns its place, it stays.
The instinct at month twelve is often to install a new framework. Resist it. The framework that survives into year two is almost always a simpler version of the one already in place, with the same spine and fewer ornaments. That is the work in front of you on a Friday afternoon, and it is enough.
If you would like to talk through your own year-two operating-system review, book a conversation.
