The Crank The Code Structural Operating Model
This is the structural model I use to design and operate technical organisations.
It is not a philosophy of optimisation.
It is a model for reducing systemic fragility.
The goal is simple:
Engineering effort should compound rather than fragment.
1. Authority Before Accountability
No one should be accountable for outcomes they cannot steer.
Decision rights must be explicit.
Escalation paths must be defined.
Cross-domain trade-offs must have a clear owner.
Most organisational failure is misattributed execution failure.
It is usually decision ownership failure.
Authority precedes performance.
2. Escalation Over Heroics
Heroics hide structural weakness.
If incidents require individual intervention to resolve, the system is brittle.
Escalation surfaces should be explicit.
Decision thresholds should be clear.
Ownership during failure should not be ambiguous.
Resilience is structural, not cultural.
3. Stability at the Core, Experimentation at the Edge
Revenue-critical systems must be predictable.
Innovation belongs where failure is contained.
Core systems: - Observable - Recoverable - Boring by design
Edge systems: - Experimental - Reversible - Isolated from systemic risk
Novelty moves inward only after proof.
4. Decision Latency Is the First Scaling Bottleneck
Scaling does not first fail at code complexity.
It fails at coordination cost.
When decision ownership is unclear: - Dependencies multiply - Escalations increase - Delivery slows despite headcount growth
Scaling requires governance evolution.
Headcount without boundary clarity increases entropy.
5. Metrics as Diagnostic Instrumentation
Profit is validation.
Operational metrics are instrumentation.
Metrics exist to reveal behaviour, not to drive it.
When metrics become targets, behaviour distorts.
Healthy measurement: - Explains variance - Surfaces risk - Identifies friction - Informs trade-offs
Metrics diagnose systems, not people.
6. Architecture Follows Decision Boundaries
System boundaries should mirror authority boundaries.
Cross-team coupling is often governance failure expressed in code.
Clear ownership produces clean interfaces.
If architecture feels tangled, examine decision structure first.
Organisations design systems that mirror their communication structure. This is not optional.
7. The Role of the Technical Leader
The CTO is not the smartest engineer in the room.
The CTO:
- Decides where authority sits
- Locks direction deliberately
- Protects structural integrity
- Absorbs ambiguity at organisational boundaries
- Ensures escalation beats heroics
The objective is not velocity.
It is sustainable velocity.
Outcome
When this model works:
- Incidents are contained, not dramatic.
- Delivery feels calmer, not rushed.
- Trade-offs are explicit.
- Teams know where decisions live.
- Profit becomes predictable rather than volatile.
Effort compounds.
Structure holds.
Change becomes deliberate rather than reactive.