Every company has a product. Very few companies have an operating system for how the company itself runs. This distinction matters enormously when it comes to strategy execution.
An operating system, properly defined, is a set of repeating mechanisms that process inputs and produce consistent outputs without requiring case-by-case intervention from leadership. Your phone's operating system doesn't ask you to approve every background process. Your company's operating system — if it has one — shouldn't require the CEO to personally track every cross-functional dependency.
Most companies run on intuition and willpower. When something needs to happen, someone makes a call. When something breaks, someone notices and someone else fixes it. This works at small scale. It stops working around the point where the organization is too large for any one person to track everything that's happening.
What an execution operating system contains
An execution operating system is not an org chart, a project management tool, or a strategy deck. It's the layer that connects those artifacts and makes them work together. It has a few core components:
A decision system. Not just decision records — but a set of principles and escalation paths that allow decisions to happen at the right level. This includes operating principles that guide day-to-day choices, decision journals that capture reasoning for future reference, and clear rules about which decisions require cross-functional input and which can be made locally.
An operating rhythm that checks against the plan. Tiago Forte's framing of the weekly review as an "appointment with all your various selves" applies at the organizational level. A weekly or biweekly moment where teams ask: are we still on track against our milestones? What has changed since last week? Are our priorities still the right priorities? This is not a status meeting — it's a synchronization mechanism that lets the organization adjust course without waiting for the quarterly review.
A dependency tracking system. Not just "what is everyone working on" but "what work is blocking what other work." Cross-functional dependencies are where execution most reliably breaks down — and the only way to manage them is to make them visible. This can be a simple tool, a shared spreadsheet, or a project management system that teams actually update. The format matters less than the discipline of keeping it current.
A priority governance mechanism. Not just a list of priorities but a set of rules about how the priority list gets updated. Who can add to the list? What criteria must be met? How are conflicts resolved when two teams have different priorities for the same resource? Without this, the priority list is a suggestion, not a governance tool.
A coordination layer. The operator functions — BizOps, Chief of Staff, Program Management, or whatever the title — that manage cross-functional dependencies, surface decision needs before they become crises, and translate strategy into team-specific context. This is the human infrastructure that makes the system work.
How to know if you have one
The test is simple: can your company make a significant strategic decision without it requiring a crisis-level intervention from the CEO?
If a product pivot is needed based on market data, can it be surfaced, debated, decided, and communicated through the operating system — or does it require the CEO to personally convene everyone, drive the decision, and personally communicate it?
If two teams are competing for the same engineering resource, is there a mechanism to resolve it that produces a documented decision — or does it require an escalation to an executive who then makes a call under pressure?
If a quarterly goal is clearly no longer achievable based on new information, is there a mechanism to update it — or does it quietly get abandoned while everyone pretends it's still on track?
The companies that pass this test have something you can touch: a set of recurring meetings with specific purposes, decision records that actually get used, a prioritized list that teams actually reference, and operators who are explicitly accountable for cross-functional coordination.
Starting from where you are
The good news: you don't need to build an operating system from scratch. The components mostly exist. Most companies have some version of all five components listed above — they're just not named, not connected, and not systematically maintained.
The starting point is audit: map the mechanisms you currently have. What decisions are being made where? What recurring meetings exist and what are they actually for? Is there a priority list and is it current? Who is currently absorbing the coordination cost? Then, identify the biggest gap — usually the one that's causing the most visible execution failures — and build a targeted fix for that gap specifically.
Trying to redesign everything at once is a recipe for change management paralysis. Identifying the one coordination failure that is costing the most and building a mechanism to address it is a recipe for momentum.
The companies that execute strategy consistently are not the ones with better strategies. They're the ones that built the infrastructure to carry strategy into the work — day after day, decision after decision, without requiring the CEO in every room.
That's the operating system. It's not glamorous. It's not a strategy deck. But it's what makes strategy real.
