An organization already has an operating system, even if it has never named one. Decisions, information, authority, execution, and learning move through recurring mechanisms. When those mechanisms conflict, people compensate manually.
Define the core flows
The operating system should explain how intent becomes work, how context is resolved, how authority is assigned, how changes are validated, how risk escalates, and how learning returns. These flows cut across tools and reporting lines.
A diagram is useful only when it matches the path people actually use.
Account for shared capacity
Those flows rarely say how capacity gets committed, yet allocation is one of the most consequential flows the operating system runs. Several initiatives can each hold a reasonable plan while all of them depend on the same platform team, security reviewers, senior architects, or executive attention. The delays that follow look like execution problems. They began when the same capacity was committed more than once.
Make each commitment visible at the point it is made. A new priority should state its consequence for existing commitments; otherwise reprioritization only lengthens the queue. When a conflict exceeds a team’s authority, escalation should carry a concrete tradeoff to the level that can authorize it, not a general request for attention.
The same flow sets how quickly the organization can change direction. An experiment can invalidate a plan within days while funding, staffing, and objectives still assume the original work. The learning loop is fast and the allocation loop is slow. Define the criteria for reconsidering an investment, an owner who can make that call, and an honest account of transition costs. Then track the time from accepted evidence to a changed commitment.
Faster reallocation is not automatically better. Moving people between projects breaks continuity and carries real learning costs, and a weak signal should not overturn every plan. The Maximum Velocity of a Company develops both arguments.
Use stable interfaces
Teams need common ways to publish decisions, request cross-team action, reference context, present verification, and identify ownership. Stable interfaces reduce translation while preserving local implementation choices.
The interface should define meaning and state, not mandate one vendor.
Make AI a governed participant
Agents need identity, scope, permissions, context, observable actions, and escalation rules. Treating them as invisible tool calls makes responsibility hard to inspect.
The same operating model should show where deterministic systems and accountable humans authorize work.
Operate the operating system
Owners should monitor friction, failures, adoption, and changes in organizational needs. Policies, workflows, and context sources require maintenance and retirement.
The operating system is not a one-time transformation artifact. It is a product under continuous stewardship.
Trace the interfaces
- Define the outcomeA problem worth solving, with evidence and boundaries.
- Resolve the contextOwned sources, accepted decisions, and explicit authority.
- Execute within limitsObservable work, isolated changes, and a way to stop.
- Challenge the resultIndependent evidence and accountable review.
- Deliver and observeBounded release, recovery, and an outcome to inspect.
- Retain what helpsA correction that improves the next decision or check.
The fictional Northstar case connects the dimensions through artifacts and authority. Its operating system can be sketched without naming a vendor:
Customer signal -> accepted intent -> context bundle
| |
decision owner source owners
| |
+----> bounded execution
|
independent evidence
|
release authority
|
observed outcome
|
local correction -> shared learningEvery arrow needs an interface and a failure response. A model call alone does not supply either.
| Interface | Consumer needs | Failure response |
|---|---|---|
| Intent to execution | Accepted scope, evidence, and permissions | Return unresolved decisions before editing. |
| Context to run | Authoritative revisions and access limits | Stop on material conflict or invalidation. |
| Execution to review | Exact patch and observed checks | Preserve failed evidence; revise or reject. |
| Review to release | Authorized action and recovery plan | Wait safely when authority is absent. |
| Outcome to learning | Interpretable signals and owner | Investigate before promoting a general rule. |
Keep control outside the thing being controlled
An agent can propose a better evaluation or policy, but should not unilaterally weaken the rule used to judge its current attempt. Separate the permission to execute work from the permission to change the permission system.
The same principle applies to people. A delivery owner facing a deadline may need an independent risk decision. Independence has a cost, so place it at consequential boundaries rather than making every small action a committee decision.
Operate degraded modes
What happens when context retrieval is unavailable, a reviewer is absent, or the evaluation environment is broken? Define which work can continue and which must pause. An unavailable check is not a passed check.
Northstar can continue preparing a sandbox plan during a release-system outage. It cannot claim release readiness. When the system recovers, the owner rechecks the current revision and any context that changed during the wait.
Keep the state trail sufficient for a new person to resume the work. Protect sensitive traces and remove temporary grants when the run ends. A reliable handoff is part of operation, not administrative cleanup after the interesting work.
Draw the system people actually use
Choose a completed change and trace these interfaces from evidence. Mark every point where someone used an undocumented private channel or invented an owner. Those are candidate design problems, not reasons to blame the person who kept work moving.
Then select one boundary to repair. Applying the Book turns that observation into a company-specific improvement plan. Start there before proposing a platform to automate the entire diagram.