A business can have excellent people, a real product and money in the bank, and still have no agreed way of deciding what matters, who owns it, how it is measured, and what happens when it slips. That agreed way is the operating system. This is the one I install.
Each one is useless without the other two. Objectives nobody owns do not get done; ownership with nothing measured cannot be reviewed; measures with no objective above them get published and ignored.
Agree the company goals and write them down. Then cascade them: to each team, and to each person in it. Everyone should be able to say what the company is trying to do, and what their own part of it is.
Cascading is the half that gets skipped. A goal that stops at the management team is known to five people and guessed at by the other fifty. The test is not whether the objectives exist but whether somebody three levels down can name the one their work serves — and whether their answer matches their manager’s.
Written down, in one place, in that order, so a disagreement about a milestone can be traced up to the objective it is supposed to serve. Most disagreements that look like personality turn out to be two people serving different objectives, neither of them wrong.
In a company of fifteen everybody covers everything, and that is the right way to start. The cost of never writing it down turns up later: a purchase order raised twice, a supplier briefed by two people with different priorities, a customer commitment that operations hears about after it was made.
So: who owns what, who decides what, and what everyone else is entitled to expect. Agreed in the room, written down, and redrawn when the company grows past the structure that was holding it.
The useful distinction is between the person who decides, the people who must be consulted first, and the people who only need to be told. Most companies have the first and the third and skip the second, which is where the resentment comes from. This is also the part that has to be revisited on a schedule: boundaries drawn at 20 people are wrong at 40, and nobody notices until something has been dropped twice.
Agree the handful of measures that genuinely say whether this is working, and who owns each one. Publish them on a fixed rhythm whether they look good or not, and use them to decide. A measure nobody publishes when it is bad is not a measure.
Each measure has a name against it — not a department, a person — and that person reports it. Reporting a bad number yourself is uncomfortable, and that is exactly what makes it work. People fix the number before the next cycle rather than explain it afterwards.
Then the meetings that consume them. One rhythm reviews the measures and clears whatever is in the way of the milestones. A longer one looks back honestly and re-cuts the period ahead. A dashboard everyone can see does the rest, because most cross-team friction is two teams working from different numbers rather than different intentions.
Where a company has no operating system at all, EOS gives it a complete one in a single piece: vision, people, data, issues and process together, with a rhythm that runs them. Nothing is left to be invented later: the meeting agendas, the scorecard, the issues list and the accountability chart are all defined, and they already fit each other.
Best where the management team is forming, and nobody has yet agreed how decisions get made.
Where the structure is already there and the real problem is that nobody is aiming at the same thing, OKRs are the smaller change. They add objectives, key results and a review cycle, and leave the existing meetings, reporting lines and job titles where they are.
Best where functions already work, and the failure is alignment rather than absence.
A board should not be surprised. Almost everything that would surprise one lands in one of three places.
A risk is scored where it happens, and reported in what it costs: the milestone that slips, the margin that goes, the extra burn and the runway it takes with it. A board cannot act on “the line is late”. It can act on “the line is late, and that is 3 months of runway”.
How likely is it to happen, and how bad would it be if it did. Score each 1, 2 or 3, and multiply.
That is quantitative, on a scale a management team can hold in its head. Not the systems-engineering version, where severity, occurrence and detection are each scored out of 10 and multiplied into a number you need a spreadsheet to read.
The scores sit with the team as part of the measures reviewed on the rhythm, so escalation is mechanical: when a score moves up, the band moves with it, and nobody has to decide whether something now feels like a high. What the board sees is which way each risk has travelled since the last meeting, not only where it stands.
Goes to the board every time, with the mitigation, the owner and the date it closes.
Goes to the board too, on the same three commitments, with the response worked out before it is needed.
Tracked by the team, not in the pack. Forty open risks tell a board nothing. The few that moved tell it where to look.
The others are the commercial judgement that sets a company’s direction, and the operations that deliver the product.