Chapter 5 — Objects of Control¶
Outcomes are what you want. Objects of control are what you can actually manipulate.
Most bad systems fail because they are designed to control outcomes directly (“increase innovation,” “improve alignment,” “move faster”) without specifying what is being controlled to produce those outcomes.
This chapter makes a hard distinction:
- Outcomes are goals and results.
- Objects of control are the levers a system touches every time it runs.
If you don’t name the object of control, your system will default to controlling something accidental—often meetings, documents, or reporting.
The Failure This Chapter Prevents¶
Observable failure: systems are installed that create activity, but the underlying levers never change.
Symptoms:
- Lots of planning, no improvement in delivery predictability
- More dashboards, same surprises
- New “alignment” cadences, same cross-team conflicts
- Repeated strategy resets with no changes in investment behavior
- Artifacts proliferate but decision-making does not improve
Root cause:
- The system has goals, but no controllable mechanism.
The Core Idea: Systems Don’t Control Outcomes¶
You can’t directly control:
- customer satisfaction
- innovation
- reliability
- speed
- “alignment”
- quality
You can influence them by controlling proximate objects like:
- constraints (WIP limits, SLAs, timeboxes)
- interfaces (APIs, contracts, ownership boundaries)
- work items (definition, size, sequence, acceptance)
- incentives (what is rewarded, punished, tolerated)
- information flow (what is visible, when, to whom)
- domains (bounded contexts, responsibility maps)
A system that tries to control outcomes directly will drift into moralizing (“we need to care more”) or reporting (“let’s measure it harder”).
What “Object of Control” Means¶
An object of control is:
- touched repeatedly by the system
- changeable by the actors running the system
- causally close enough to influence the failure
- representable as an artifact or rule
A good object of control is something you can point to and edit.
If you can’t edit it, you can’t control it.
The Common Objects of Control¶
This book uses a deliberately short list to force precision. Most systems manipulate one or two of these.
Goals¶
What gets controlled:
- goal definition
- goal hierarchy
- goal review cadence
- goal acceptance criteria
Typical systems:
- OKRs, KPI trees, strategy deployment
Misuse risk:
- goals become wishes or slogans
- goals multiply without tradeoffs
Work items¶
What gets controlled:
- what counts as “work”
- work item size and slicing rules
- entry/exit criteria (DoR/DoD)
- prioritization and sequencing rules
Typical systems:
- agile variants, kanban policies, intake processes
Misuse risk:
- backlog as junk drawer
- prioritization without capacity reality
Interfaces¶
What gets controlled:
- team boundaries and integration points
- API contracts, SLAs, change protocols
- cross-team dependency handling
Typical systems:
- platform operating models, integration governance, contract testing norms
Misuse risk:
- “coordination” replaces interface clarity
- escalations become the interface
Domains¶
What gets controlled:
- responsibility boundaries
- language boundaries (what terms mean where)
- ownership of concepts and data
Typical systems:
- domain-driven design, team topologies, operating model definitions
Misuse risk:
- domains become political territories
- boundaries drawn without enforcement
Constraints¶
What gets controlled:
- WIP limits, timeboxes, approval thresholds
- quality gates
- queueing policies
- default rules when decisions are not made
Typical systems:
- flow-based delivery, incident response, change management
Misuse risk:
- constraints applied without authority
- constraints become bureaucracy rather than throughput protection
Incentives¶
What gets controlled:
- what is rewarded, punished, ignored
- performance metrics and evaluation criteria
- promotion narratives
Typical systems:
- performance systems, goal systems, compensation-linked measurement
Misuse risk:
- metric gaming
- local optimization
Information flow¶
What gets controlled:
- what is visible
- when it becomes visible
- to whom
- in what form (artifact)
Typical systems:
- dashboards, reporting cadences, decision logs, review rituals
Misuse risk:
- legibility replaces truth
- reporting replaces decisions
Selecting the Right Object of Control¶
Use this sequence to avoid choosing an object that is merely convenient.
Step 1: Start from the failure¶
Ask:
- “What must change repeatedly for this failure to reduce?”
If the answer is “people need to communicate better,” you don’t have an object. Keep going.
Step 2: Identify the decision you need to optimize¶
Common mappings:
- Priority decisions often control: work items, investment, goals
- Ownership decisions often control: interfaces, domains
- Sequencing decisions often control: work items, constraints
- Diagnosis decisions often control: information flow, work item definitions
- Repair decisions often control: constraints, interfaces, ownership boundaries
Step 3: Run the “edit test”¶
For each candidate object:
- Can the team change it within their authority?
- Is it updated often enough to matter?
- Can it be represented as an artifact or rule?
- Does changing it plausibly affect the failure within a reasonable time horizon?
If the answer is “not really,” it’s not your object of control.
The Most Common Trap: Controlling Meetings¶
When people don’t know what to control, they control the calendar.
Symptoms:
- new cadences
- more “syncs”
- longer planning sessions
- more reviews
This creates the illusion of governance but usually does not change:
- ownership boundaries
- sequencing rules
- constraints
- interface contracts
Meetings can be part of a system, but they are not an object of control unless the meeting produces enforceable artifacts and constraints.
Object of Control and Artifact Must Match¶
You can’t control an object you can’t represent.
Examples:
- If you control interfaces, you need interface artifacts (contracts, SLAs, ownership maps).
- If you control constraints, you need constraint artifacts (WIP policies, gates, default rules).
- If you control domains, you need domain artifacts (maps, glossaries, context boundaries).
If your artifact is a slide deck but your object of control is interfaces, you will get theater.
Misuse Model: How “Objects of Control” Gets Misapplied¶
Misuse 1: Choosing too many objects¶
If you control everything, you control nothing.
Failure mode:
- the system becomes complex
- enforcement collapses
- adoption becomes political
Correction:
- choose 1–2 objects of control max for a system. Treat others as secondary effects.
Misuse 2: Choosing an object outside authority¶
You design a system that requires changing incentives or org boundaries when you can’t.
Correction:
- redesign the system to use objects you can actually control, or define an adoption path that includes the authority holder.
Misuse 3: Picking an object that is too far from causality¶
Example: controlling dashboards to improve reliability.
Dashboards can improve awareness but rarely change the mechanisms that produce incidents (interfaces, constraints, quality gates).
Correction:
- prefer objects closer to causal mechanisms even if they are less comfortable.
The Non-Negotiable Rule Introduced Here¶
You may not design or adopt a system until you can state:
- The object of control is ______
- The actors who can change it are ______
- The artifact that represents it is ______
- The constraint that enforces it is ______
If you can’t complete this, you are trying to control an outcome with vibes.
Exit Condition for This Chapter¶
Write:
- Your system’s 1–2 objects of control
- Who has authority to change each object
- The artifact that will make each object inspectable
- One constraint that prevents drift or avoidance
If you can do that, you are now operating like a system designer, not a framework consumer.