This page is a work in progress, part of a multi-year effort to capture and share learnings, frameworks, tools, and processes to run organizations. See Running Organizations for more.

"Thinking Time" (credit: Keith Cunningham) changed how I worked as a decision-maker. It focused me on the biggest problems, forced me into challenging my assumptions, and it produced better decisions.

The Thinking Time process, covered in The Road Less Stupid, requires that you spend 30-45 uninterrupted minutes writing an answer to a key question. Instead of focusing on solutions, the process focuses on finding great questions and delegating the solution to writing.

Leaders should carve out standing calendar appointments for Thinking Time. Thinking Time results in powerful memos, more informed discussions, and more considered decisions.

Solving big issues requires the ability to "zoom out" and see the big picture. It's a requirement of any leadership role and one that can't be done by people who are close to the problem and who lack the context of the bigger picture.

Fragmenting the business into parts and categorizing issues too quickly will lead to a constant treadmill of bug-squashing. Zooming out demands that you avoid pursuing local solutions that "shift the burden" from one area of the business to another.

Executives are trained to have the right answers and are expected to give them. In great cultures, executives ask great questions and model that behavior for others. At Bridgwater, management is taught to "probe," by asking questions about the design of processes, about specific problems, or about people's actions or lack of action.

A spirit of curiosity helps the organization avoid blaming, finger-pointing, and creating inadequate surface-level solutions. Curiosity demands open-ended why questioning - questions that don't lead to YES or NO answers.

Is the issue a symptom of a larger problem, or a simple variance? Develop the intuition to know whether an issue is another case representing a systemic issue, or if the issue is simply a one-off problem caused by natural variance.

Sometimes, you need to dig to find a root cause. Sometimes the "root cause" of a problem is simple human error or common variance caused by humans interacting with one another.

Drilling down to find the root causes should be a collaborative approach in which frontline employees team up with management to widen the perspective and deepen the analysis. If "zooming out" is about collecting perspectives, then "zooming in" or drilling down, is about analyzing the situation at a tactical or technical level.

At the root of the drill-down process is the use of the question "why?" Use a Design Thinking process, Correction of Errors process, or a more collaborative Looping approach of sensing tensions to drill down on solutions. See more in the Issue Solving Frameworks section below.

You can't root out all problems, and you can't root out dysfunction in an organization of any significant size. The executive's job is to choose what kinds of terrible, horrible, frustrating problems you're willing to live with. What kinds of problems will you change? What kinds will you accept? What kinds will you avoid solving for now?

It's easy to fall into following your interests or focusing on areas that cause you pain, but if those areas don't help you create leverage and improvement in the business, they're not worth your time. Don't be a mad scientist. Don't follow your interests.

Improvement is not always about adding policies, procedures, work instructions, or people. The more you add, the more that needs managing, the more failure points you create, and the more maintenance you sign up for.

We tend to bias toward adding solutions instead of removing components that cause problems due to Additive Bias. Additive solutions tend to be appreciated more than subtractive solutions. As we get deeper into programs and projects, the Sunk Cost Fallacy causes us to tend to double down. Remember, the goal is to improve the organization as a whole.

We can't solve big problems in the world without people and relationships. In my CEO group, a consistent cliché is "this would be easy if not for the people." Recognizing that many of your issues are issues of human coordination and human relationships, is seeing the organization as more than a simple machine.

There are numerous problem-solving frameworks used in the business world, and I'll share a list of my favorite and most common ones here.

Design Thinking is increasingly being used for problem-solving in business situations. The general framework for design thinking is: Empathize, define the problem, ideate solutions, prototype them, test the solution.

"Looping" is a process from Brave New Work that's used in the context of decentralizing change initiatives and empowering individuals to sense core tensions and resolve them through testing.

The Three stage process is Sensing Tensions, Proposing Practices, and Conducting Experiments. Author Aaron Dignan provides a list of 78 tensions, which team members can use to articulate the problems they're experiencing. From there, Proposing Practices is about identifying tests to run to pursue learning. Experimenting leads to learning, which leads to improvement.

The Five Whys is an "iterative interrogation technique" created by Taiichi Ohno of Toyota. It involves asking "Why" five times to get to the root cause of the problem.

The Ishikawa or Fishbone Diagram is a visual model for executing the root cause analysis and makes the Five Why's more actionable in practice.

Correction of Errors (COE) is based on The Five Whys and is used by Amazon and other organizations. COE is a structured, written format used by teams to document the problem and drill down to get to the root cause.

The process is covered in-depth in Working Backwards. Here is a template.

Circles is a problem-solving framework designed for product management and is used by Google and others. The letters stand for:

The OODA Loop is a real-time decision-making framework that applies to everyday problem-solving in a business environment. The acronym stands for:

The Theory of Constraints is about focusing on the bottlenecks that limit performance. The model was created by Eliyahu Goldratt and is covered in his famous book The Goal. The Five Focusing Steps are:

DMAIC is a Six Sigma practice for continuous improvement. The letters stand for D = Define, M = Measure, A = Analyze, I = Improve = Control.

Define the problem, Measure to quantify the problem, Analyze the cause(s), Improve by solving the root cause, and Control by maintaining the gains made.

PDCA, or the Deming Cycle, is another straightforward continuous improvement model, often used to remove waste. In the Planning stage, you determine the problem, analyze it, and find a solution. In the Do stage, you apply that solution. In Check, you analyze the impact made and measure the performance difference. In Act, you make the change permanent.

The best way I've found to "smoke out" issues consistently is to track them at all levels and make them as transparent as possible to everyone in the organization. This creates collective intelligence, ensures that people feel heard, and creates the opportunity for generative discussion.

In EOS, there are three levels of Issues Lists to keep.

The Issues List in the Vision/Traction Organizer (V/TO™) is a list of strategic concerns. This list includes a broad spectrum of issues that becomes a backlog to be worked on by the Leadership Team.

By storing strategic Issues in a common, visible place, you can keep strategic conversations to a monthly and quarterly rhythm while addressing the tactical and operationally urgent concerns weekly.

This list is made up of actionable and urgent operational concerns that the Leadership Team must act on or delegate. If issues from this list can be pushed down to departments, they are moved to a Departmental Issues List.

These are Lists that anyone within a given department can add to and that are processed during Weekly Department Meetings. These items can be tactical or strategic in nature.

Kickstarting these lists can be as simple as requiring meeting attendees to add items to the List before each meeting.

The Issue/Proposal Process is my favorite structured method for addressing Issues thoughtfully, collectively, and inclusively, appealing to thinkers of all types. Issue/Proposal is Matt Mochary's method, covered in The Great CEO Within.

Issue/Proposals can be used at all levels. The process can be used on a one-off basis or can be built into an operating rhythm by carving out standing meeting times.

If you don't have an established writing culture, this is a tough change, especially for those who like to process ideas verbally. It's easy to plow through this process and leave some people feeling they weren't heard or weren't given enough time. After a few rounds of execution and practice, this seems to be less of a concern.

In The Great CEO Within, Matt Mochary breaks down two ways to ease into the process, leaning on meeting time instead of pre-work, and then gradually adding pre-work after 3-4 rounds:

Writing isn't a perfect medium for solving root cause issues and is particularly difficult for solving process issues. Sometimes, visually workshopping an issue is the fastest, most effective approach for working through an issue.

Workshops are important for handling areas of white space in your business - particularly, for addressing handoffs between teams. For that reason, workshops are often cross-functional exercises.

Holding a workshop event can help you firefight a nagging issue in the organization or when delivery KPIs are off-target. They can also be used as part of a regular (i.e. annual) process for improving processes in an area of the business.

Workshops should be framed as collaborative learning experiences, not sessions for managers to fix the organization's problems.

Focusing on small, continual improvements using adaptive and flexible approaches is usually superior to multi-day events that result in big changes. A 90-minute workshop might be plenty to address a big process issue is plenty.

The typical Kaizen Event, a Six Sigma process, is a 3-5 day workshop. These events are costly and require big positive changes to be uncovered. I'm dubious of the risk-reward equation. The amount of necessary changes and follow-through after this kind of workshop likely requires a top-down change management process and some command-and-control management to ensure accountability.

Workshops can help team-building, but they are not FOR team-building. Workshops should focus on issue resolution and improvement. The cost of the workshop is the combined hours of all individuals attending, the follow-up, and the process and procedure changes that follow. There's no guarantee that you'll come out better, so scheduling Workshops carries some risk, too.

Be clear about the issue. Don't convene a group exercise without verifying that the people involved understands what they're solving for. There are countless ways to improve things, but fewer ways to solve a specific, well-defined issue.

Be careful with assumptions that lack both consensus and data. Exposing variation in processes and committing to a plan of updating KPIs and tracking performance is often enough. If Management forces process change without consensus or facts, workshops will be viewed as a management process and a distraction from the "real work."

You need frontline staff to take responsibility for the outcome of the event. If management jams a new how down people's throats, you're unlikely to get commitment or buy-in to whatever decision is made.

If groups are large, break them up into multiple groups and use multiple facilitators. Each group should create its own map or visual before reconvening. Have them compare visuals. This will expose variations in the process and can produce unique perspectives that may not otherwise come to light in a large group setting.

Once you've identified where the issues are, you can use tools like Root Cause Analysis, The 5 Whys, or an Ishikawa Diagram to analyze the problem as a group.

Often, just flowcharting the process will make issues clear, as the group will expose clear issues at handoffs, or with especially complicated steps in the process, without the need for additional tools.

Be careful not to jump too quickly to problem-solving, or let the group begin negotiating what the "best way" is at this step.

Move from critical analysis to generative thinking on possible solutions to the bottlenecks you've uncovered. Help the group converge on a plan to address the bottleneck(s) and work through how they might implement that plan.

Any time you change a process, you have to consider what new tools, systems, or resources are required to make the change as well as how to change existing SOPs, checklists, tasks, and work instructions.

A plan should also include how you'll monitor the performance of the updated process over time, which includes a change in the KPIs you'll track and monitor.

Issues must be assigned to an accountable person (i.e. Direct Responsible Individual) who is empowered to solve them. Once an issue is assigned, it can be converted into a new Goal (i.e. an OKR) which can result in improved procedures (i.e. new SOP), or better measurement (i.e. new KPI), for example.

The following are three examples of operational issues and the corresponding KPIs you could use to track performance in response, from the book Making Work Visible.

If KPIs indicate that there is an issue, with, say Flow Time - things not getting delivered in a timely manner - a Directly Responsible Individual (DRI) can create an OKR to develop new SOPs for some part of the process to speed up delivery. That could look something like this: