58 lines
3.1 KiB
Markdown
58 lines
3.1 KiB
Markdown
|
# 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)
|