Urgency and Constraints
Core Statement
The system moves only as fast as its binding constraint. Activity everywhere else can look productive while the actual output rate stays unchanged.
Urgency means attacking the constraint directly, not creating generalized busyness.
Constraint Rule
Throughput = rate of the current bottleneck
If 9,999 things work and one required thing fails, the system is blocked by the one.
Operating Moves
| Move | Use When |
|---|---|
| Attack the bottleneck | One part/process gates the whole system |
| Do things in parallel | Workstreams are independent enough to overlap |
| Set aggressive timelines | The team is hiding behind comfortable pacing |
| Daily critical reviews | Delay is expensive and feedback must be tight |
| Move to the problem | Remote abstraction is losing reality signal |
| Prototype fast | Debate has exceeded learning value |
Impossible Breakdown
When something feels impossible:
- Define the exact output needed.
- Identify the physical limit.
- Identify the current blocking variable.
- Ask what would make the bottleneck 10x better.
- Build the smallest test that changes the bottleneck knowledge.
- Repeat until the impossible becomes merely hard.
Parallelization Filter
Do work in parallel when:
- Tasks do not depend on each other.
- The interfaces between tasks are clear.
- A blocker in one task should not idle the whole team.
- More speed is worth coordination cost.
Do not parallelize when:
- The team lacks a shared definition of done.
- Rework risk is larger than speed gain.
- One decision will invalidate most branches.
Failure Handling
Failure is data unless it is catastrophic. The point is not to avoid all failure; it is to make learning fast and survivable.
Good failure:
- Reveals a false assumption
- Improves the design
- Happens early
- Does not destroy the mission
Bad failure:
- Repeats known mistakes
- Comes from ignored feedback
- Breaks trust or safety
- Consumes resources without learning