3.1 KiB
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:
- Town planners industrialize components into utilities
- Pioneers build higher-order systems consuming these utilities
- Settlers productize repeating patterns
- Town planners industrialize those products
Three success pillars (from Daniel Pink's Drive): Purpose, Autonomy, Mastery.
Key Takeaways
- Doctrine are tools, not universal laws - implementation is context-specific
- Transparency and challenge create competitive advantage
- Duplication destroys capability - solving same problems repeatedly prevents innovation
- Structure drives culture, not vice versa
- Appropriate methods by evolution stage prevent cost disasters
- Pioneer-Settler-Town Planner structures remain extremely rare but highly effective
- Dual structures (only pioneers + town planners) eliminate the critical middle (settlers)