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 1,500+ leaders like you that read this newsletter!

In case you missed it, last week we talked about what isn’t being talked about in the WFH debate.

Before we get into this week’s post, can we ask a favor?

Do you want similar content on a more frequent cadence? Well turns out, now we’re consistently posting on LinkedIn throughout the week!

A few of the favorites have been:

• Thoughts on ‘learning velocity’

• Thoughts on ‘status quo bias’

• Thoughts on ‘strategic backlogs’

If you enjoy the content in this newsletter, you’ll appreciate some of the bite-sized pieces on LinkedIn. And we’d appreciate it 🙂. Thanks for reading! Follow us in LinkedIn.

Bringing an Economic View to Decision Architectures

Some decisions make a louder noise than others.

Layoffs, perhaps, sound the loudest.

They can also expose the (often) wide gap in understanding between those on the front lines and those in more senior leadership positions in an organization. While the front lines often experience a round of layoffs as a shock or surprise, that’s not true for leaders that have been evaluating those decisions. 

On the ground, the costs of layoffs are clear. Not just for the impacted individuals, but cultural and performance costs, incurred by those that remain. The benefits are not local to the front lines, so they are questioned.

What’s (often) less clear on the ground are the economic models that drove the decision. That’s why it can feel like a surprise, and why it cuts so deep. It can seem arbitrary. It looks like a hard pivot away from a choice made by someone else. And this lack of understanding contributes to the overall feeling of powerlessness.

But everything comes back to the economics of the situation. That can’t be a surprise.

What is surprising, is how rarely (or indirectly) we bring economic models into our day-to-day decision making, on the front lines. If this muscle were stronger, would we be better positioned on the front lines to see those kinds of risks? To see the looming dark clouds that drive dramatic choices like layoffs?

Most of us work in organizations that are driven by some underlying economics (even in non-profits and government settings to some degree). In good times, we can push these underlying factors into the background, and build great culture. But in bad times, we learn that it can’t be ignored. 

Economics eats culture for breakfast, lunch, and dinner.

There are many good reasons to bring a stronger economic mindset to our decision making, and building economic models into our decision architectures up and down the organization. And not just in finance, or the business side of the organization, but in product development, too.

Don Reinertsen has literally written the book on this subject. He introduced a set of powerful principles for product development, built on economic foundations, in “The Principles of Product Development Flow: Second Generation Lean Product Development”. 

This is one of those books that keeps you coming back to re-read over the years, to go deeper, as your experience catches up to his ideas. There is a lot of wisdom in this book.

In this post, I want to cite a handful of his principles, related to decision making. Note that this is just a subset of what he covers. From this subset, we can explore how they might influence our decision architectures.

These are the principles we’ll cover, from Reinersten’s chapter on “The Economic View”:

• E6: The U-Curve Principle: Important trade-offs are likely to have U-curve optimizations

• E7: The Imperfection Principle: Even imperfect answers improve decision making

• E8: The Principle of Small Decisions: Influence the many small decisions

• E9: The Principle of Continuous Economic Trade-offs: Economic choices must be made continuously

• E10: The First Perishability Principle: Many economic choices are more valuable when made quickly

• E13: The First Decision Rule Principle: Use decision rules to decentralize economic control

• E14: The First Market Principle: Ensure decision makers feel both cost and benefit

• E15: The Principle of Optimum Decision Timing: Every decision has its optimum economic timing

• E18: The Principle of Buying Information: The value of information is its expected economic value

When these principles are used to build decision architectures, they can support the decentralization of decision making, and improve decision speed and decision quality.

Before we take a tour, let’s introduce a running example, which we’ll use to help illustrate the concepts. Our hypothetical setting is a product organization, within a Fortune 500 company.

Let’s jump in. And since we’re talking economics, it should be no surprise that we get started with a graph of two intersecting curves.

E6: The U-Curve Principle: Important trade-offs are likely to have U-curve optimizations

An economic model seeks to balance variables like:

• Product Cost

• Cycle Time

• Product Value

• Development Expense

• Risk

This principle points out that these variables are often moving in opposite directions, and finding the balance will be tricky, like an optimization problem. This presents tradeoff decisions to leaders - they will need to set balanced expectations across the different variables.

In our GainFirst example, leaders made a tradeoff decision when they took on some technical debt in the lead-up to the initial launch.

In this tradeoff decision, the leaders recognized that as the overall development expense grows (x-axis), two things follow:

1. The cycle time for the launch grows (more or less linearly)

2. The amount of technical debt can be reduced (in an inversely proportional relationship)

The overall risk in value delivery is the sum of these two drivers of risk: the risk due to delay (i.e. long cycle time) and the risk due to debt (e.g. both in initial customer experience, and long-term debt reduction effort). The U-curve reveals the “sweet spot” where risk can be minimized across the two variables.

One of Reinertsen’s observations is that the flat bottom of the U-curve is somewhat forgiving to decision makers: it takes the pressure off leaders so that they don’t need to find the exact optimal point on the x-axis. Anything on that x-axis near the U-curve bottom will likely be good enough. Measurement systems can be less precise; it’s the thought process (with charts like this) that needs to be tight.

Bringing this economic model to tradeoffs that have some form of cost on the y-axis is very adaptable. And quick analysis can help build Simple Rules for the desired tradeoff points.

Here’s another example, focused on the classic question of how big a release should be:

We seek to minimize the overall costs of delivering value and getting that precious feedback (new information) back into the organization. 

In this tradeoff decision, the leaders recognize that as the release size grows (x-axis), two things follow:

1. The development costs grow, per unit of value, as dependencies grow (which might be more exponential than the linear plot shown here)

2. The delivery costs, per unit of value, will be greater for small releases and less for big releases (in an inversely proportional relationship)

The overall costs in value delivery is the sum of these two: the per-unit development costs and the per-unit delivery costs. Again, the U-curve finds the “sweet spot” to minimize cost across the two variables.

When the leaders of GainFirst study the U-curves, they arrive at simple rules for development expense (per feature) and for release size, that set a range near the bottom of their U-curve. These rules then drive choice architectures within the decision architecture that can influence how features are planned (i.e. with appropriate levels of expected debt) and how releases are planned (i.e. with an eye towards overall cost and timing of feedback).

E7: The Imperfection Principle: Even imperfect answers improve decision making

Reinertsen believes that rough economic models can make dramatic differences in decision quality (and speed). The models don’t have to be expansive, rigorous spreadsheets of detailed analysis. What’s important is to shine a light on these competing variables, rooted in the economic model. 

And some “good” news: when it comes to decision making, the bar is pretty low right now. We just need to find ways to get a little better.

But without an organization-wide shared understanding of how these economic models should influence decisions, more and more decisions are driven by intuition. This isn’t necessarily bad; these leaders that “rely on their gut” often bring an economic mindset to the challenges. But their interpretations, or how they see the tradeoff, might be unique, and highly contextual. Intuition is not great at these kinds of decisions. It needs to be more System 2 than System 1 (in Daniel Kahneman’s terms).

When personal (not shared) understanding drives the decision, factors like “What do I think would make my stakeholders (especially my boss) happiest?” might tip the scales the most. It gets more political.

At GainFirst, a modest improvement in decision making might take shape as crisper conversations on Product Value. Discovery efforts might yield better (but not perfect) information that better exposes key assumptions, for reconsideration.

E8: The Principle of Small Decisions: Influence the many small decisions

Reinertsen advocates for bringing decision architecture to the front lines, not just the leadership teams:

These small decisions are what determines whether the overall organization is aligned, or not. And as we know, misalignment amplifies dependencies and can grind delivery to a halt.

At GainFirst, the leadership team might set out to improve the visibility of these small decisions by encouraging leaders to structure the agenda of their one-on-ones to walk through recent decisions (on both sides of the table), to improve support, awareness, and skills growth.

E9: The Principle of Continuous Economic Trade-offs: Economic choices must be made continuously

To effectively navigate uncertainty, we must be constantly learning and applying new information. Continuous learning means we are always steering the ship, and punctuating course changes with decisions.

Reinertsen says, “We do not make a few, big, predictable tradeoffs at the start of our development process. We make many small tradeoffs, at random times, throughout our development process.”

This echoes the shift from waterfall planning to adaptive, iterative, and incremental development. As we know, that shift is not easy for those that started their careers with training in traditional planning disciplines. When we are trained in best practices for making a plan (and sticking to the plan), and experience getting rewarded for executing the plans with minimal variance… we tune out to guidance that suggests we should be “continuously making tradeoff decisions.”

And to be honest, it does sound exhausting. That’s why we need the support of a decision architecture, within some kind of framework for planning.

A good decision architecture first establishes whether you work in a repetitive environment (like manufacturing) or a dynamic one (like product development), and the relative magnitude of the cost-of-change in your environment. Dynamic environments that can leverage a lower cost-of-change can and should pursue continuous tradeoff decisions, as new information surfaces.

At GainFirst, they know that software development is a dynamic environment, so they are willing to invest in changes to improve their adaptability. That leads them to spend the time and energy to build a decision architecture.

E10: The First Perishability Principle: Many economic choices are more valuable when made quickly

Economic opportunities, like fresh fruit, can go bad over time. Time can also compound challenges, turning small problems into larger problems. Delays have a cost. This idea, of the importance of understanding the “cost of delay”, is (arguably) what Reinertsen is best known for.

He explains, “Opportunities get smaller with time, and obstacles get larger. This, too, has important implications for our decision making process. It means we must explicitly measure, and shorten, the time it takes to make a decision.”

This is also why we want to push decision making down deeper into the organization, towards the front lines. It is at the front lines where opportunities and obstacles are first noticed. That’s when the clock starts ticking. 

In a centralized environment, how long does it take to socialize those opportunities and obstacles, and turn decisions into actions (and results)? A long time. The fruit is now rotten.

At GainFirst, they saw meaningful examples of this as they supported their community of users. This front-line activity allowed for faster response times and faster communication of new opportunities and obstacles. When visibility improved, communication improved, and fewer opportunities and obstacles were fated to “die on the vine”.

E13: The First Decision Rule Principle: Use decision rules to decentralize economic control

This is the principle that offers the most potential for decision architectures. It advocates for the creation of Simple Rules (like Even-Over Statements) that provide guidance for decision making, while yielding authority for the decision itself. Reinertsen calls economic decision rules, “the most important tool for influencing the many small decisions.”

Simple decision rules offer these advantages: 

1. They can align the economic choices made within or across projects, programs, or products

2. They can ensure that choices are optimal at the system level

3. They can allow us to push control down to lower levels with limited risk

4. They can streamline the process of making decisions

Simple decision rules can be powerful enablers when design or development faces tradeoff challenges. When many people are all faced with a similar tradeoff, what steers them to making suitably-consistent evaluations and choices? When the tradeoffs are between variables that must be optimized at a system level, it is even more critical.

In “Flow”, Reinertsen uses an example of building an airplane at Boeing (oh boy, the comments might get fun here…) to illustrate a decision rule. In this example, the overall weight of the plane is obviously a critical design factor. System designers allocate weight across the subsystems at the start of the development effort, but the allocations are imperfect and need to adapt as new information surfaces. Another design factor is overall cost. 

An economic decision rule was created that allowed a designer - on any part of any subsystem - to “buy” more weight for their design (essentially re-allocating it from some other part of the plane) for a set dollar value from their budget (e.g. $5K per added pound of weight). Spending thresholds were set, like credit authorizations, that allowed this to happen without higher level approvals. 

Of course what made this work was that, at the same time, others were finding ways to design things with less than their allocated weight, and receiving “money back” for that insight. This keeps things optimized at the system level, and sets guardrails for decentralized decision making at the same time.

For GainFirst, a similar system-level design parameter might be the overall performance of the software system, or maybe response times. Or, returning to the technical debt example earlier, imagine that the product teams have created a proxy for technical debt. In the tradeoff between cycle time and technical debt, a simple economic decision rule could state:

Developers (or teams) may add “X points of tech debt” when it can pull in cycle time by “Y days”

The GainFirst leaders might then set X and Y with the help of a U-curve analysis. After initial expectations for cycle time (i.e. project or release delivery dates) and technical debt (i.e. total proxy score) are baselined and allocated to subsystems or teams, then individual decisions can work to optimize the overall system.

In Reinertsen’s words: “The intrinsic elegance of this approach is that the superiors didn’t actually give up control over the decision. Instead, they recognized that they could still control the decision without participating in it. They simply had to control the economic logic of the decision. Control without participation is control without decision making delays.”

E14: The First Market Principle: Ensure decision makers feel both cost and benefit

While it is impractical to turn every exchange within an organization into an economic transaction, the invisible hand of real markets is always lurking in the margins. Development can be outsourced. Legal services can be contracted out. And AI bots don’t require health insurance. Yikes!

When we ignore our internal cost structures, we get complacent on how competitive our cost-for service really is. When we benchmark ourselves within the industry, we learn where our cost structures are keeping up or falling behind. 

Internally, there is one area where it can be more pragmatic to introduce a more transactional set of relationships: in repetitive (i.e. ticket-taking) functions, where demand levels are less clear, or perhaps fluctuate.

This is where Reinertsen suggests creating an internal market, with internal pricing of some kind: “Use pricing to control demand. This is how economic markets work. When prices rise, demand falls. Market work because decision makers experience both the benefits and costs of their decisions. Pricing enables such decentralized control.”

Again, it’s the decentralized control (read: decentralized decision making) that creates the efficiency, when you shape demand like this.

When a shared service organization offers two different classes of service (e.g. one expedited, and one not) at different “prices”, then the organization will learn a lot about demand by watching individual internal customers of the service decide whether to pay for the higher class of service. Individuals are weighing the benefits against the costs, and signaling where the economic value lies. This demand insight can then drive changes in the service offerings, with real data behind the changes.

At GainFirst, the shared service organization that offers design services for mobile apps offers a standard class of service, but it has a reputation for long lead times and delays. It also offers an expedited class of service - that moves you to the front of the queue. If the innovation team decides that it’s worth paying the extra amount (which might be in the form of a budget re-allocation), then everyone wins.

E15: The Principle of Optimum Decision Timing: Every decision has its optimum economic timing

Here’s another curve for you:

This suggests that, for any decision, the risk varies with when the decision is made. It’s possible to make a decision too early - when other options go unexplored, or haven’t even emerged yet. It’s also possible to make a decision too late, when the economics have changed. You missed your window. Understanding the shape of this curve, on a per decision basis, can be supported by a good decision architecture.

Reinertsen says, “If the cost, payoff, and risk of our decisions are time-dependent, then each decision will have an optimum economic timing. The general principle is that we should make each decision at the point where further delay no longer increases the expected economic outcome. By avoiding ‘front-loading’, we can take advantage of the fact that market and technical uncertainty decrease with time.”

So at some point, new information just isn’t changing the expected economic value of the situation as much as it had been. That’s the optimal time to make the decision.

In a decision architecture, this might involve adding a risk-over-time plot to a decision template. The decision maker could use this to explore the unique risk factors for the decision, with respect to:

1. How long it might take to collect new information and reduce uncertainty

2. How long they are able to wait, before the economics might change (i.e. “last responsible moment”)

With this conceptual framework, decision makers could have a conversation about optimal timing.

At GainFirst, the leadership team might build a risk-over-time view for a decision about the design of the new mobile app. It would factor in risks related to the deadlines for submission to the app store, lead times for the design shared service, and relative uncertainty about the needs. This would help them balance exploration against execution, with a risk perspective.

E18: The Principle of Buying Information: The value of information is its expected economic value

The value of new information is highly contextual. When you know very little, basic facts have great value. When you have a good handle on a situation, new information offers less relative value.

The value of information is derived not from what you need to know, but from why you need to know it. Knowledge for knowledge’s sake (continuously reducing uncertainty) hits a point of diminishing returns. Understanding where that point is… that is the challenge when you consider “buying information.”

When uncertainty is high and the economic stakes are high, then we should be willing to pay a premium (in time, effort, or dollars) to buy information. Framing this as a learning need, with a willingness-to-pay assessment, can get it started. In fact, when we frame our work (to navigate uncertainty) as learning loops, then the learning loop has an economic value (i.e. value of the information) and an economic cost (i.e. cost to obtain the information). This cost-benefit analysis drives whether the discovery, experiment, hypothesis, research, or investigation is worth doing right now.

With a backlog of learning loops for consideration, we can evaluate which ones make the most (economic) sense to do first.

This approach helps leadership teams set priorities that reduce uncertainty (where economically sound) with early experimentation and small bets. At GainFirst, they use views like this to sequence the exploratory work on their new adjacent product, learning about mobile app development with experiments focused on learning.

Overall, these principles can help shape our decision architectures, and are especially useful in product development contexts. 

Here are some actionable takeaways to help get started “deciding how to decide”:

1. Focus on improving conversations around tradeoff decisions, by introducing an economic model and mindset.

2. Pursue a small, relative improvement in your decision making. It won’t require perfect information or fully optimized choices.

3. Recognize that the aggregate impact of small, decentralized decisions is bigger than the impact of large decisions (especially when the large ones are poorly communicated and executed)

4. Monitor the balance on tradeoff decisions. Some might seem to shift every day, as new information surfaces and insights emerge. For this reason, some choices should be re-visited over time.

5. Time your decisions to catch them while they are ripe. Opportunities decay; they have a half-life.

6. Create and share simple decision rules to retain influence over decision making while delegating authority. This is the way.

7. Use economic models to view internal operations in terms of markets. But be careful: don’t try to turn everyone into a freelancer. It’s the new mindset that matters.

8. Understand the risk around a decision-to-make, to clarify the optimal timing (to make the decision).

9. Buy your information in the bargain bin, and know when to stop shopping. We will always make decisions in the presence of some uncertainty, so don’t overspend for extra knowledge.

And to close, here’s a bonus principle that gets to the practicality of this post.

E21: The Show Me The Money Principle: To influence financial decisions, speak the language of money.

And almost all decisions are financial decisions, in the end. The path from a proposed change to a financial impact or effect is complex, winding, and often unprovable, but when you use the “language of money” in the exploration, it can improve decision making effectiveness.

Reinertsen says, “Whenever I am told that management makes decisions too slowly, I ask to see the specific proposal that went to management… In my experience, most managers make amazingly fast decisions when they are presented with compelling economic arguments.”

If we hope to decentralize decision making to the front lines, and want to close the gap in understanding between leadership and the front-lines on economic reasoning, let’s start by bringing richer language to the job.

It will need the language of money and the language of uncertainty.

Join us for the upcoming Decision Architecture discussion series!

We’ve set up a series of 5 live sessions to cover topics around Decision Architecture. It’s free and exclusive to Uncertainty Project subscribers, but we will have a limited number of spots (just to make sure we can facilitate/manage actual discussion). Sign up for the waitlist if you’re interested!