great-operators — Cook, Grove, scaling

Operators are the craft of making things work at scale. Not building the thing — that is engineering. Not designing the thing — that is design. Making the thing run, reliably, at volume, with a team.

The operator's register is different from the engineer's register in a specific way: the engineer asks "does this work?" The operator asks "does this work when the person running it is not the person who built it, under time pressure, at 2 AM."

Why great-operators is a distinct plugin

The failure mode of mixing operations with strategy is that the strategist makes plans that cannot be executed, and the operator makes processes that optimize the wrong things. Keeping them separate forces each to produce its own artifact: the strategist produces a direction, the operator produces a system for executing in that direction.

great-operators does not set direction. That is great-minds. It does not make the product. That is great-engineers and great-designers. It makes the machinery that produces the product reliably.

The personas

Tim Cook: supply chain and execution discipline. The Cook register is about dependencies, lead times, and what happens when one node in the chain fails. A Cook review of a launch plan asks: what are the critical path dependencies, and what is the fallback when each one fails.

Andy Grove: management clarity and OKRs. The Grove register is about output versus activity — measuring what ships, not what was attempted. A Grove review of a team structure asks: where is the output measure, and what happens when it is not met.

Charlie Munger: mental models for decision-making under uncertainty. The Munger register is checklist-adjacent — what are the known failure modes of this class of decision, and which ones apply here. Not what should we do, but what would a rational actor with these constraints do.

Patty McCord: people operations and team design. The McCord register is about who you need on a team to produce a specific kind of output — not who is available, but who is required. A McCord review of a hiring decision asks: what does this person need to be able to do on day ninety, and does this candidate show evidence of that capability.

What it unlocks

Operations reviews before a launch. Hiring decisions filtered through someone who has staffed high-output teams. Process design that asks "does this scale" before the process is built.

The most valuable use is the pre-mortem: run the plan through each operations persona before it ships and ask what breaks. Cook identifies the dependency failures. Grove identifies the measurement gaps. Munger identifies the decision errors. McCord identifies the team gaps.

If you get stuck

If you are not sure whether a problem belongs in great-operators or great-minds, ask whether it is a direction problem or an execution problem. Direction: great-minds. Execution at scale: great-operators.

If you are not sure which operations persona to route to, describe what would go wrong. Supply chain failure: Cook. Measurement failure: Grove. Decision failure under uncertainty: Munger. Team capability failure: McCord.

Cross-reference

Lesson 10 (great-engineers) and this lesson both describe expansion plugins that shipped after the foundational five. Compare them: engineering is sub-divided by craft register; operations is sub-divided by the failure mode each persona is designed to catch.

Plugin source

The shipped plugin lives at github.com/sethshoultes/great-minds-constellation/plugins/great-operators. Nine operations personas (Cook, Grove, Munger, McCord, Deming, Ohno, Horowitz, Walton, Kelleher).

Deliverable

Take one process you own that runs on a regular cadence. Run it through the Cook review: what are the dependencies, and what fails when each dependency is late or unavailable. Write three sentences of Cook's critique.