# Chapter 4: Doctrine

## Definition

Doctrine = universal business principles applicable across industries. Unlike climatic patterns (which affect you regardless), doctrine represents deliberate principles you choose to adopt. Key distinction: doctrine *principles* (abstract) vs doctrine *implementation* (context-specific).

## Eight Core Doctrines

### 1. Focus on User Need
Anchor decisions on actual customer needs, not business assumptions. Revenue/profit follow from satisfying users. Common pitfalls: confusing customer needs with business requirements, bias toward legacy systems.

### 2. Use a Common Language
Maps serve as universal language enabling cross-functional collaboration. Without shared frameworks, translation errors and misalignment proliferate between departments.

### 3. Be Transparent
Share maps so assumptions can be challenged constructively. Transparency prevents "walking an Army through a minefield."

### 4. Challenge Assumptions
Every member bears responsibility for questioning decisions. Retribution against challengers is "a deadly sin."

### 5. Remove Duplication and Bias
Organizations unconsciously duplicate components across units. Real examples: 380 isolated ERP systems (chemical company), 740+ duplications (energy company), 1,000+ risk management systems (bank). Profile diagrams aggregate maps to reveal repetition and bias.

### 6. Use Appropriate Methods
Different components need different development approaches. Applying specification-heavy contracts to uncertain components guarantees expensive change-control battles. Maps reveal which to outsource vs build in-house.

### 7. Think Small
Decompose systems into components, structure teams around them. Amazon's "Two Pizza" model, Haier's cell-based structure. Teams need defined interfaces, fitness functions, and decision autonomy.

### 8. Think Aptitude and Attitude
Three attitudes mapped to evolution stages:

- **Pioneers**: explore uncharted territory, accept high failure rates, build future possibilities
- **Settlers**: transform prototypes into products, balance innovation with reliability
- **Town Planners**: industrialize through standardization, efficiency, scale

Misaligning attitude with domain creates dysfunction.

## Design for Constant Evolution

The "mechanism of theft" cycle:
1. Town planners industrialize components into utilities
2. Pioneers build higher-order systems consuming these utilities
3. Settlers productize repeating patterns
4. Town planners industrialize those products

Three success pillars (from Daniel Pink's *Drive*): Purpose, Autonomy, Mastery.

## Key Takeaways

1. Doctrine are tools, not universal laws - implementation is context-specific
2. Transparency and challenge create competitive advantage
3. Duplication destroys capability - solving same problems repeatedly prevents innovation
4. Structure drives culture, not vice versa
5. Appropriate methods by evolution stage prevent cost disasters
6. Pioneer-Settler-Town Planner structures remain extremely rare but highly effective
7. Dual structures (only pioneers + town planners) eliminate the critical middle (settlers)