When to integrate

• Use integration to increase rewards . . . and risk
• Create a usable system before optimizing
• Prioritize integration at the system level rather than the module level
• Integrate elements that are better understood and predictable
• Integrate elements that most often used
• Use more integration when transaction cost are high
• Use more integration when the cost of failure is low
• Optimize stable elements
• Don’t attempt to optimize areas of uncertainty
• Use more integration in winner takes all environments
• Use integration to increase speed
• Use optimization to surface and identify problems
• Use integration to increase the magnitude of both risk and reward
• Use more integration and optimization when product performance is not good enough
• Use more integration when internal transaction costs are lower than external transaction costs

Optimization & Integration

• Reduce component failure rates and increase precision
• Beware of non-linear activity in optimized systems
• Use decentralization to increase local optimization
• Maintain flexibility with configuration options
• Increase sensing and reaction speed to reduce optimization risk
• Maximize exponential processes by maximizing initial efforts
• Use scarcity to drive optimization
• Scrutinize abundance for waste and optimization opportunities
• Maximize throughput by staying on task as long as possible without decreasing responsiveness below the minimum acceptable limit
• Reject or aggregate most interruptions and requests

Connect

• Increase physical proximity and communication speed
• Strengthen connections and interfaces

Leverage lean principles

• Achieve high quality first
• Minimize waste
• Minimize delays and inactivity
• Create a cadence for actions
• Reduce queues and work in process
• Reduce or eliminate batch processing
• Reduce bottlenecks and constraints
• Produce system outputs to pull rather than push signals
• Make waste, queues, WIP, and batches visible
• Hold reserves rather than redundancy or buffers

Hold reserves

• Hold reserves for known risks
• Hold more reserves in uncertain conditions
• Use reserves to mitigate integration risk
• Use reserves to capitalize on opportunities
• Reduce reserves and increase exploration for unknown risks
• Aggregate reserves above a diverse group of optimizing modules
• Use high reserves to overcome obstacles rapidly
• Build reserves into interfaces
• Store reserves in flexible or general purpose forms
• Reconstitute reserves after use
• Design reserves to be routinely zeroed out
• Aggressively defend the need for reserves
• Hold schedule reserves as well as resource, space, and critical item reserves