A Culture of Good Decision-Making (part 1)

Many organizations struggle with decisions-making: both speed and quality are well below where they need to be. Key contributing factors include:

• Ineffective decision processes (e.g, decision-by-HiPPO, decision-by-committee)
• Difficulty handling complex, open-ended questions
• Missing information or too much information
• Organizational problems (siloing, misalignment, and politics)

While these challenges are common, slow, bad decisions are not a universal problem. Some organizations are able to make good decisions fast and at scale.

In this two-part article series I’ll cover the most important principles (part 1) and techniques (part 2) these companies use so you can employ them in your org. 

Differentiate Between Important and Less-Important Decisions

In one of my projects at Gmail we spent months debating what to call a new inbox tab meant to hold transactional mail — confirmations, receipts, calendar updates, etc. After much back-and-forth discussion we finally settled on the somewhat nebulous name “Updates”. 

At the time this decision seemed very important, but in hindsight it wasn’t. The Updates inbox tab is off by default, so most users don’t see it, and the ones that do, quickly learn what it means. Even if we had made a bad choice it would have been an easy one to fix. It’s fair to say that we massively overspent on this one decision.

In my experience this is a common phenomenon. It’s tempting to think of decisions this way:

Polar right and wrong, clear consequences, high stakes. 

But in reality we’re making thousands of decisions every month and most create relatively minor effects if any. These less-consequential decisions disappear in the “noise”; spending time making them can distract us from important decisions that create major forks in the road. 

The expectation to get 100% of decisions right is therefore unrealistic and unnecessary. We should invest energy in decisions based on their importance. 

According to Jeff Bezos, Amazon differentiates between two types of decisions:

• Type 1 decisions — Important decisions that we want to get right almost every time. These decisions should be made through a slow, deliberative process (like Amazon’s Working Backwards process). 
• Type 2 decisions — Less important decisions that should go through a much faster process. We may get some of these decisions wrong, but that’s ok. Amazon strives to empower its teams to make these decisions fast and with low friction. 

Bezos suggests one criterion to differentiate between the two: can this decision be easily reversed, what he calls two-way door vs. one-way door decisions. This is a simple and powerful model, but I suspect it only works in organizations that measure the outcomes of their decisions, and are willing to reverse them. That may be the case for Amazon, but is certainly not the case in most companies I meet. So the doors model may not be right for everyone. 

To decide how important a decision is suggest considering these factors: 

• Potential positive consequences (Impact) — A decision that stands to create a high impact on the business, users, or system is more important. 
• Potential negative consequences (Risk) — A decision that may create strong negative side-effects is more important. 
• Cost — A decision that requires a lot of time and resources to implement and to support in the future is more important.

In the next article I’ll show you techniques to assess all three. 

Decentralize Decisions 

“Any society in the era of the new technology would perish miserably were it to attempt … to run the economy by central planning. And so would any enterprise that attempted to centralize responsibility and decision-making at the top.” — Peter Drucker | The Practice of Management

In many organizations decisions, both important and unimportant, have to go through a manager or a committee. There are two main modes of work:

• Top down: managers tell reports what to do
• Bottom-up: reports come with suggestions for the manager/committee to approve or decide 

This centralized approach to decision-making (which is having a bit of a moment these days) may be better for consistency and alignment, and may feel less risky, but it can, and often does, lead to bottlenecks, slow decisions, high meeting overhead, and disempowered, demoralized employees. Worse, relying on the snap-judgment of busy people that may be optimistic and self-confident, but not well informed, is hardly a recipe for great decision-making.

Already in the 1950s, business management thinker Peter Drucker argued that in modern organizations “knowledge workers” should be allowed to make their own decisions as a lot of the knowledge and information live at the edges of the org. He suggested a different mode of leadership he called Management by Objectives and Self Control (MBO). Managers at all levels decide on the goals — what positive change to create — often with the help of their reports in a top-down or bottom-up approach. Once the goals are in place, leaders at each level, down to the individual employee, should be allowed to decide on a course of action in their area of responsibility — the often forgotten element of self-control. 

Management by Objectives and Self Control may sound novel and risky in the corporate world, but a similar system called Mission-Command has been used in modern armies to decentralize decisions for well over a century. An army general may issue a strategic mission that will then be translated into tactical missions as it cascades down the chain of command. Once the missions are set, some planning and review may take place, but thereafter officers and NCOs at each level have the authority to act based on their judgment and the unfolding situation (which is rarely predictable). The local authority to decide is crucial for success. A senior commander will never step down to call the shots in a local battle, nor expect officers in the field to continuously radio-in asking for approval of their decisions. 

Management by Objectives and Self Control does not equate to managers being completely “hands-off”. Managers can and should stay informed (what Amazon calls “being in the details”) through regular updates and reviews. Important decisions may still be escalated to the manager to approve bottom-up. But by and large, the aim is that the reports will make their own decisions. 

“We strive to develop good decision-making muscles at every level of the company, priding ourselves on how few, not how many, decisions senior leaders make” — Netflix Culture doc

You may be familiar with Management by Objectives and Self-Control through its derived method — Objectives and Key Results (OKR), invented by Intel in the 1970s. However in many organizations OKR is abused to enforce top-down decisions and central planning, both going against the spirit of the system and causing many to dislike OKR. 

Define Clear Ownership, Encourage Loose Coupling

An important first step towards distributed decisions is defining who gets to decide on what matters. In many well-functioning product orgs, work is carried out by semi-autonomous product teams, typically with ownership over functional areas: Search, Security, Transactions, APIs, etc. Team topology makes it clear which decision belongs where, and ensures that the decisions are made by the people with the right expertise. For example when I PM-led the desktop client of Gmail, most relevant product decisions stopped with me and my peer tech-lead and designer (a leadership triad it’s called at Google). We escalated important decisions (like launching the Tabbed inbox) to our managers, and deferred decisions affecting other product areas, such as Search or Security, to their owner teams. 

It’s helpful to define team identity by setting a clear mission for each team (for example “users find what they’re after fast and accurately” for the Search team) and a set of consistent metrics that team is aiming to improve (for example the average clickthrough rate on the top 10 search results). It’s best if these metrics are part of a broader metrics hierarchy that ties team metrics to company metrics and align teams, disciplines, and departments around a small set of top-level goals. 

In many organizations functional teams exist but are not able to make their own decisions because of a high level of technical dependencies, which require other teams’ approval for any change (tight coupling). In other cases, decisions have to go through a series of committees — privacy, design, launch cal — each with its own review process and decision schedule. Most pernicious of all is the challenge of big-room-planning where all teams have to convene every 8-12 weeks to agree on the scope of the next big cross-team launch (for example PI planning in SAFe). 

Good product companies work hard to liberate product teams from such constraints (loose coupling). There’s no silver bullet to create a dependency-free environment, but here are some helpful methods: 

• Periodically adjusting team topology to minimize dependencies (there’s never an ideal topology though). 
• Being careful about breaking out common code to platform and services teams (which tend to become a dependency and a bottleneck) as a means of optimization 
• Defining clear interfaces between system areas
• Creating temporary ad-hoc teams to tackle a cross-team goals
• Aligning teams using shared goals, but then letting them choose how to collaborate or work independently on achieving these goals 
• Making heavy use of automated testing so breakages are detected early and fast
• Instituting a culture where it’s OK for teams to move fast and potentially break things, rather than try to seek approval and mitigate risks in advance. 

Share Context in All Directions

“We expect managers to practice context not control — giving their teams the context and clarity needed to make good decisions instead of trying to control everything themselves.” Netflix Culture

In the book “No Rules Rules” Netflix co-CEO Reed Hastings talks about a discussion he had with a certain facilities executive (not a direct report) who asked various company offices to provide a 5-year headcount plan so he can rent office space in advance and ensure everyone gets what they need. 

Hastings was not happy: 

I felt like saying, “You bozo! Don’t prioritize error prevention over flexibility! That is a total waste of time. There is no way we can have any accuracy with a plan like that. Call off this project right away.” But that would be leading with control.

Instead I reminded myself of what I often tell leaders throughout Netflix:

WHEN ONE OF YOUR PEOPLE DOES SOMETHING DUMB DON’T BLAME THEM. INSTEAD ASK YOURSELF WHAT CONTEXT YOU FAILED TO SET. ARE YOU ARTICULATE AND INSPIRING ENOUGH IN EXPRESSING YOUR GOALS AND STRATEGY? HAVE YOU CLEARLY EXPLAINED ALL THE ASSUMPTIONS AND RISKS THAT WILL HELP YOUR TEAM TO MAKE GOOD DECISIONS? ARE YOU AND YOUR EMPLOYEES HIGHLY ALIGNED ON VISION AND OBJECTIVES?

Hastings said little to the facilities executive in this discussion, but immediately made long-term planning vs. flexibility a topic of discussion with his direct reports, sharing the context that Netlifx should strongly prefer for the latter. This context then trickled down, and hopefully reached the hapless facilities manager helping him choose a better course of action. 

Netflix may be an extreme case in point, but the principle is valid in any company. Context helps the people doing the work make better decisions and improves the odds of achieving the goal. Conversely, without context people have to escalate decisions because the knowledge only exists at the top. Uninformed employees are also less likely to be trusted by their managers.

Context-sharing is an important feature of mission-command as well. When an army officer gives a mission to reports he/she strives to share all relevant information: Why was this mission chosen? What is the bigger campaign? What enemy and friendly forces are deployed in the area? 

In modern companies, leaders have many powerful tools to share context: 

• Vision and mission statements
• Strategy, including strategic principles (for example focus on the buyer first) and current opportunities/threats the company is focused on
• Company-level metrics and metric trees
• Multi-level goals 
• Research findings
• Internal docs – meeting summaries etc. 

Not all context comes from the top, tough. Teams should be encouraged to do their own research and analysis. Good product companies invest much into user research, data analytics, and experimentation platforms, striving to make these services available to every team. Product teams are given access to customers to interview, and research and validation techniques such as surveys, fake door tests, and early-adopter programs are encouraged. 

It’s important to note that context needs to flow in both directions. Strategic context flows down, but tactical context should flow up. In the army the units in the field may radio in updates like “the bridge was destroyed by enemy forces” helping senior officers adjust the campaign and the strategy. Similarly product teams should update middle and top managers with what they’ve learned about the market, the technology, and the users, as well as what challenges they’re facing. Transparency is key for good decisions, while hoarding information is not. As kindergarten children are taught — sharing is caring. 

Takeaways

Making better decisions faster does not mean more planning and review processes. On the contrary it means understanding that most decisions aren’t that important, and therefore should be made in a quick and efficient way. It’s best to decentralize decisions and push them to the right level where people have the necessary knowledge and expertise. To do that you should a) define clear areas of responsibility with loose coupling, b) create well-aligned goals and metrics at each level c) share as much context as possible. 

In part 2 of the series I’ll share specific decision tactics for: dealing with stakeholder opinions, publicly supporting deciders, avoiding the trap of “resulting”, using templates and algorithms, and, of course, guiding your decisions by evidence. 

---

In my courses we practice implementing evidence-guided development and empowered teams hands-on.

Secure your ticket for the next public workshop or contact me to organize an in-house workshop for your team.