🔮 Exploring Changes, Together

Good morning!

At the Uncertainty Project, we explore models and techniques for managing uncertainty, decision making, and strategy. Every week we package up our learnings and share them with the 2,000+ leaders like you that read this newsletter!

Over the last couple years, we’ve been sharing our journey with you, as we discover new models and methods. The things we share offer specific ideas for improving the dialog around uncertainty, which in turn supports better decision making.

Some examples: 

• Decision architectures that improve decision quality and speed

• Strategy Development Frameworks like Roger Martin’s “Strategy Cascade” or Richard Rumelt’s “Strategy Foundry”

• Risk exploration using reference narratives and future scenarios 

• Purposeful portfolio management (e.g. Zone-To-Win, KTLO-TechDebt-NewOpportunities, 3 Horizons, CapEx/OpEx)

• Domain modeling and method selection based on complexity analysis (i.e. Cynefin)

• Down-scaling of innovation efforts (with “Thinking in Bets” and Safe-to-Fail experiments)

• Bayesian Belief Networks for “small world” models that support strategic decisions

These are not trivial concepts. What would it take to deploy them? What is needed to experiment with one or more of these new approaches in your organization? Right now?

The main point we present here is that it will take a group effort. The group will need to bring together people that are experts in the work itself (leaders and individual contributors) and experts in how to work (operations teams and tools teams). All need to be motivated and ready to explore new ways of working.

Let’s set the stage: You are on a leadership team, in some part of a larger organization. You contribute to) strategic decisions, in your local context. You have decision authority for both what-you-work-on and how-you-work in your local context, but must work with others to solve challenges in the broader context.

For an organization to get better at working with uncertainty, it must find a way to become more adaptable with respect to both:

• Which work is pursued, and 

• Which ways of working are employed

Let’s think of an example where a leadership team has decided to make change in their strategy development process. They have read about Roger Martin’s Strategy Cascade, and seen the Strategy 5x5 canvas here in the Uncertainty Project, and want to give it a try.

Bringing the Strategy 5x5 into their next 3-day strategic offsite will show adaptability in their ways of working. The agenda of the offsite will be different than the last one.

Using the Strategy 5x5 to more deeply explore the possibility space, and make choices framed as hypotheses, and drive more discovery prior to delivery work - these demonstrate more adaptability in the decision making of what work or value-added changes are pursued.

Thinking differently about uncertainty, drives changes in the way you make decisions and the way you communicate across the organization. 

But making these changes? That’s a tough assignment. It’s not something that one person, acting alone, will likely be able to accomplish.

Why? Because it requires a coherent set of changes that are not independent or isolated. To make effective changes (and get them to stick), it will take a collaborative effort. In this article, we describe the needs in this collaborative effort not in terms of roles, but in terms of “hats”. This is useful because it acknowledges that sometimes one person will take on multiple “hats” while fulfilling a single role.

Four key “hats” that are needed, across the change effort:

• Leaders - accountable for the strategic decisions and for the org design

• Designers - accountable for the organization’s “operating system” (OS)

• Builders - accountable for the crafting of information systems that instrument the OS

• Owners - accountable for executing the work in the organization, per the OS

Let’s pause here and define what we mean by “operating system”:

Operating System:  A coherent set of principles, rituals, cycles, artifacts, guidelines, and working agreements that support the pursuit of outcomes for an organization.

And let’s add some color on who might be wearing these “hats”:

Leaders can be managers, but it’s really about who has decision authority. Designers can be anyone who comes to work each day seeking to improve the flow of operations (e.g. chief of staff, or operations teams) as a system. Builders are people that take more abstract guidance about operations, and make it more concrete in tooling, training, or practice guidance, for specific contexts. Owners own things like projects, goals, products, or specific changes to products, like features. They operate in a specific context (like a team), focus on their work, and are accountable for providing progress updates, as they execute and learn.

So in the context of our effort to drive some change (that helps us with uncertainty), here’s what the different “hats” are saying:

There is a also learning loop within the change effort: 

Leaders ask for better decision support. Designers approach the problem as a system, and make tweaks to the existing “operating system”. These tweaks ripple into the way various “elements” are made visible and managed across the organization, in information systems and tooling. Then the individuals - the people that own and drive those “elements” - do their work, and provide some new or different information along the way. This information is now available, in refined form, to better support the decisions made by the leaders. Leaders decide if the changes helped, and if other changes are desired, around we go again…

Let’s look at the collaboration and handoffs between the “hats”. How would this play out?

1. Leader agrees to try something different, in how they address uncertainty when making strategic decisions

2. Leader sponsors a change initiative in the ways of working around strategy, specific to a ritual

3. Designer explores models that seem like a good fit for the context and its immediate needs (e.g. maybe drawn from the list at the top of the article…)

4. Designer considers new behaviors, frameworks, or models that could help

5. Designer pitches the concepts to the sponsor, with emphasis on new behaviors and alignment to incentive structure

6. Leader chooses team(s) to run a pilot (an experiment)

7. Builders take the new operating model and instrument any new information needs for the pilot team and their leaders

8. Designers roll out the behavioral changes to the pilot team

9. Owners on the pilot team adopt the new behaviors with the new tooling (or info systems)

10. Information flows from the owners - to the tools - to new views driven by the new models - into the dialog conducted by the leaders.

Note that we’ve proposed two more “hats” in this diagram:

• Wranglers - they help the leader collect timely, accurate updates and build the view for the rituals. If you’ve ever worked as a program manager, you understand this.

• Tool Admin - they support the day-to-day use of the tooling instrumented by the builder, which maintains the viability of the operating system created by the designer.

And remember, sometimes people wear more than one hat, and sometimes one of the hats isn’t needed (e.g. responsible, motivated owners might not need to be wrangled…).

Hopefully, by now, you can start to see where these “hats” are worn in your organization. 

But we still need to clarify: 

Why is it important to distinguish the contributions of these distinct “hats”?

We believe it’s important because the jobs (performed by the different hats) are so different, yet so very intertwined:

1. Leaders’ main job is to make decisions. Everything should serve this need.

2. Designers drive change, but must be careful about “change appetite”, and how much sponsorship they have available. Leaders help with this.

3. Builders must recognize that tooling only plays a supporting role to the execution of the operating system. They rely on the designers to deploy non-tool-related change.

4. Owners are in partnership with leaders, seeking the “ground truth” that generates insights. Leaders seek to create environments where learning is rewarded, even when the learning seems like “bad news”.

The other reason it’s important is that these capabilities aren’t always found in our organizations, at the levels of skill needed for successful change.

• Leaders need to be able to make decisions and can recognize what provides good decision support (capability level: generally good)

• Designers are harder to find, and sometimes this capability has not been funded or sponsored sufficiently, i.e. to produce an OS (capability level: often missing)

• Builders can be found where the tools live, but they are often forced to guess at the OS, or just fall back on tool configuration defaults. (capability level: generally good)

• Owners are always present, and usually highly capable, yet the environment they work in (defined implicitly or explicitly through the OS) can make truth-seeking difficult. For example, when learning takes a backseat to productivity, progress is communicated as % done. (capability level: often mixed)

Take a look around your organization. Who is currently wearing these “hats”? How much time and energy are they able to put into these efforts? How visible is their work?

A good way to get started is to identify a ritual where decisions (are expected to) happen. 

• Is the decision support in those meetings strong? Lacking? Somewhere in between? 

• Which parts of the OS are most relevant for that ritual? (remember, the OS can be explicit or implicit)

• Which tools enable information flow for that part of the OS? 

• What do the owners think of that tooling? 

• How are leaders leveraging the updates coming from the owners? 

• What is the quality of the dialog that results? 

• What change could make it slightly better than it is right now?

Now you’re ready to take a trip around the loop, and experiment with better ways to address uncertainty in your strategic decision making.