Tool: Optimizing for Uncertainty

(also referred to as Optimizing for variability)

Organizational environment, technology, customer and market behavior have very limited degree of predictability. That implies that optimizing the enterprise behavior for predefined outcomes is an unproductive approach to advancing business capabilities. A different approach is needed that would allow the organization to capitalize on change rather than continue to pretend that the change will not take place. Such an approach has to inherently create an ability to comprehend new facts and quickly respond.

What exactly does optimizing for uncertainty entail? Here are the key requirements:

  1. Experimentation
  2. Ability to receive and process signals from the market, specific customers and internal stakeholders, including teams (see Feedback Loop Markers thinking tool; also see Semiconductor Organization anti-pattern for comparison)
  3. Organizational design, business process structure and software architectures that support a combination of:
    • Set-based design: pursuing multiple options at the same time until we know better
    • Simplicity of implementation: aiming at the simplest possible realization to facilitate adaptation in the future and avoid bloated structures that lead to resistance to change
    • Separation of static and dynamic behavior


Optimizing for uncertainty affects different aspects required for the business to be able to adjust behavior to respond to change in the environment, including the structure of the organization, collaboration patterns, process, infrastructure, system under development. The following example illustrate the bullets above applied to various aspects of enterprise operations.

Example 1. Set-based design applied to a process. 

Using two different Lean branching policies (ex: mainline development and short-lived team branches) in different parts of the organization to determine which one works better in the context of the organization.

Example 2. Simplicity of implementation applied to the team structure.

Loose team boundaries allow for smooth swarming around a problem in the environment where business demand is rather volatile.

Example 3. Separation of static and dynamic behavior to a system architecture.

Keeping domain objects pretty basic and thin, while extracting the logic usually subjected to change, into separate “roles” and “scenarios” that can be modified without affecting the more static layers of the solution.