When and where to regulate

• Define desired results before employing regulation
• Make more rules in stable systems, less when change is frequent
• High regulation is best suited for closed systems
• Use risk management to regulate uncertainty outside the system
• Favor regulation based on events rather than schedules
• Prioritize preventative over reactive or punishing regulation
• Regulate processes as well as inputs and outputs
• Regulate response times and delays
• Use regulation where trust is lacking
• Regulate by controlling rewards and punishments; benefits and costs
• Regulation must serve a purpose other than anxiety reduction for the regulator
• Regulate to establish cadence, synchronization, and cross domain planning requirements
• Minimize undesirable oscillation by matching regulation and response cycles
• Vet increased regulation; it is costly, offers diminishing returns, and limits innovation
• When increasing regulation, plan for increases in planning and monitoring

Increase stability

• Invest in early warning systems
• Increase delays
• Increase separation
• Maintain pressure on resources at an adequate level of discomfort
• Create buffers and margins
• Build in redundant, quick-swap, and multipurpose elements
• Reduce the speed at which the system adapts
• Create barriers and defenses around the system
• Use leaders intent and build shared mental models
• Establish mentoring, coaching, and collaboration systems
• Understand that highly stabilized systems can fail catastrophically

Make rules

• Establish and maintain regulatory power through a mix of legitimate, referent, expert, reward, and coercive means
• Use rules to coordinate processes and hold systems together
• Make rules that support system level optimization over local optimization
• Make rules to minimize the tragedy of the commons
• The optimum number of rules is the number that enables desired action
• Specify rules in only one place and form
• Make rules readily available and well understood
• Specify what cannot be done, rather than what can be done
• Minimize rules that could lead to rule-beating behavior
• Do not make rules that are unenforceable, contradictory, or retroactive
• Do not change rules frequently
• Resist the temptation to implement many across-the-board rules
• Make rules to maximize economies of scale

Manage variation

• Reduce the negative consequences of variation
• Use repetition, dry runs, and tests to identify and eliminate variation
• Improve what works, more than fixing what doesn’t
• Substitute cheap variation for expensive variation
• Move variability to where its cost is lowest
• Increase the gain on negative feedback loops
• Minimize waste, queues, WIP, and batch size
• Allow more upfront variation and exploration when timeframes are long
• Focus efforts on areas of completive advantage