Resolving Issues
Resolving Issues

Resolving Issues

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 Through Issues

💡
“If I had an hour to solve a problem I'd spend 55 minutes thinking about the problem and five minutes thinking about solutions." - Albert Einstein

Using Thinking Time

Thinking Time For The Big Issues

"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.

🔨
The Thinking Time Process
  1. Find the Unasked Question - Create a question that will result in clarity and generate better choices. Use the format of "How might we...so that we can..."
  2. Separate the Problem from the Symptom - Write to identify the real obstacle, using the following questions:
    • "What are the possible reasons I am noticing this symptom?"
    • "What isn't happening that, if it did happen, would cause the perceived gap (symptoms) to either narrow or disappear?"
    • "What is happening that, if it stopped happening, would cause the perceived gap (symptoms) to narrow or disappear?"
  3. Check Assumptions - Differentiate the facts from the story you're telling yourself by analyzing your writing. Find where you've substituted an opinion for a fact. At this stage you're forming or re-forming a theory.
  4. Consider 2nd-Order Consequences - Clarify the risks and the possibility of being wrong, along with the costs of being wrong. Ask yourself:
    • "What is the upside?"
    • "What is the downside?"
    • "Can I live with the downside?"
  5. Create the Machine - Create an executable plan and identify the resources required to solve the core problem.

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

Principles for Resolving Issues

Zoom Out

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.

"Think of it as looking at a photo of yourself and the world around from outer space. From that vantage, you can see the relationships between the continents, countries, and seas. Then you can get more granular, by zooming into a closer-up view of your country, your city, your neighborhood, and finally your immediate environment." - Ray Dalio (Source: Principles)

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.

"Our problem is that generally, we do not see the coherence, only the fragments. Our training and experience make it very hard to understand what we might even mean by the word 'whole'. We are much more aware of the parts, of the differences between us. So we focus on finding quantitative measures for our world without always remembering to ask what the underlying meaning of these measures really is." - William Isaacs (Source: Dialogue)

Ask Questions

💡
"While language structures reality, questions help structure language" - Marilee Goldberg

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.

"First, pay attention. Let them get about halfway into something they really think is important and then interrupt. Ask: 'Wait, tell me why you think that is important?' That forces them to back up and describe the assumptions, the facts, and the logic. Second, beware of the declarative statement. When someone makes a point as if it [is] a fact, by saying: 'Everyone knows that.. or ‘We all agree that…’ stop them and say ‘Wait, do you have data to back that up?" - Tom Bell, CEO of Cousins Properties (Source: The CEO Next Door)
🔨
Basic questions to ask about issues:
  • What is the problem? Who does it affect?
  • What is causing it? What about our system is causing it?
  • What results are we getting? What does success look like in that area?
  • What solution is currently on the table?

Simple Variance or Systemic Issue?

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.

Find Root Causes

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.

Only Solve Issues That Help The Business Grow

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?

"Identify a reasonable number of issues that will have the greatest possible impact on the success of your organization, and then spend most of your time thinking about, talking about, and working on those issues." - Patrick Lencioni (Source: The Four Obsessions of an Extraordinary Executive)

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.

"Some people love solving a problem, whether or not anyone else knows about it. Isaac Newton was that way. He invented calculus and then put it on a shelf for decades until friends begged him to publish it. His satisfaction came from the discovery itself. Newton was genius, and there's nothing wrong with being wired like him, but if you are, then maybe you belong in academia or in a large corporate lab. In business, satisfying customers matters more than your favorite research project." - Dave Hitz (Source: How to Castrate a Bull)

More Is Not Always Better

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.

Operational Issues Are Often Relationship Issues

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.

Issue Resolution Frameworks

💡
“A problem well-stated is half-solved.” - Charles Kettering

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

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

"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 and Ishikawa Diagram

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

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

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

  • Comprehend the situation (What? Why? Who? How?)
  • Identify the customer
  • Report customer’s needs
  • Cut, through prioritization
  • List solutions
  • Evaluate tradeoffs
  • Summarize your recommendation

OODA Loop

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

  • Observe
  • Orient
  • Decide
  • Act

Theory of Constraints

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:

  • Identify - find the single part of the process that is limiting performance
  • Exploit - make quick improvements using what you have
  • Subordinate - ensure that other activities are aligned with that constraint
  • Elevate - consider additional actions, if it's still a problem
  • Repeat

DMAIC

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.

Plan-Do-Check-Act (PDCA)

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.

Working With Issues

Tracking Issues

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.

"Sensing changes in the environment, getting the information to the right place, digesting it, and developing appropriate responses are parts of a perpetual learning cycle that will ultimately characterize how a given organization maintains its effectiveness." - Edgar H. Schein (Source: Organizational Culture and Leadership)

The Issues List in V/TO

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.

"These issues are tackled in future quarterly meetings. The issues that are not a big enough priority for this week or this quarter must be stored somewhere so that you don't lose sight of them... This list will include issues as diverse as new product ideas, key employee issues, technology needs, office relocation, capital needs, and the need for HR policies." - Gino Wickman (Source: Traction)

Weekly Leadership Team Issues List

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.

"Leadership issues include things as diverse as company Rocks being off track, a bad number in the Scorecard, key employee issues, major client difficulties, and process -and system-related problems." - Gino Wickman (Source: Traction)

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 sales team might have hitting call numbers, presentations, closing business, marketing, and presentation materials on their list, while the operations team might have fulfilling orders, purchasing, customer complaints, and low production numbers on theirs." - Gino Wickman (Source: Traction)

Proposing Solutions

Writing + Discussion -> Decisions

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.

🔨
The Issue/Proposal Process

1. Draft a write-up of an issue identified in an Issues List and propose a solution to that idea.

2. Send the draft to all relevant people. Ask for comments and questions within the doc by a specific date and time (send a reminder before that date/time!).

3. Draft writer responds to comments in the doc

4. Draft writer schedules a meeting time to discuss the proposal after the date/time has elapsed. Invites are only sent to those who have commented in the doc.

5. In the meeting, discuss the proposal and work to develop a consensus. If no consensus is reached, stop the discussion and turn to a decision-making framework, like RAPID.

How to Ease Into Issue/Proposal

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:

"Reserve the first 15 minutes of the meeting for all participants to write out their updates and issues. Then use another 10 minutes of the meeting for all participants to read each other’s updates and issues. Then discuss and decide."
"Require that all participants write their updates and issues prior to the meeting. Do not allow people to bring up an issue that they have not already written up. Use the first 10 minutes of the meeting for all participants to read each other’s updates and issues."

Workshopping Issues

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 For Key Process Issues

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.

"The greatest opportunities for performance improvement often lie in the functional interfaces - those points at which the baton (for example, 'production specs') is being passed from one department to another." (Source: Improving Performance)

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.

90 Minute Events

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.

Purpose = Improvement

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.

Issue Clarity

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.

Use Facts or Consensus

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."

Running Workshops

Use a Facilitator(s)

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.

🔨
Use a Leader or Manager to facilitate, coach, and help the team work through process improvement, but don't let a facilitator dictate a solution.

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.

Bring Existing Documentation

🔨
Have the team collect relevant documents including process documentation, formal and de-facto SOPs, outdated docs, and anything else relevant to the issue. This can be done during the Workshop or can be prepared prior.

Flowchart the Process

🔨
Have the team produce a realistic flowchart of the current process, including edge cases/exceptions. You might add swimlanes to denote where the actions of one team or individuals' steps differ from another.
🔨
Start by defining the beginning and end of the process. This creates clear boundaries to work within and is the easiest place to start. As you add detail, show the inputs and outputs of the process and place them in sequential order. Ask "And then what happens?" to prompt the group to continue filling in the detail.

Analyze the Flowchart

🔨
Collaboratively diagnose where the problems are. Ask the group:
  • Which of these steps is a problem?
  • Which step is the most costly or most prone to error and mistakes?
  • Which step is unnecessary?
  • Where do delays occur?
  • Where is waste occurring?

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.

"The activity by itself is liable to bring improvement. Making a flowchart will help people become aware of what was previously done unconsciously. It will bring out undiscovered variations in methods, provoke discussions, and possibly encourage studies to determine which method works best." - Peter R. Scholtes (Source: The Leader's Handbook)

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

Ideate Solutions

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.

🔨
Ask:
  • What problem are we solving?
  • How will we know it's working?
  • How will we measure it?
  • Why is this the best route instead of another solution?
  • What could go wrong when we roll this out?
  • Is this just a test, or a pilot?
  • How widely will we roll this out?
  • Who is accountable for monitoring and reporting on progress?

Prepare for Change

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.

🔨
Assign individual accountability to each component of the plan. Don't walk away with a new management project that frontline staff has no accountability for. The facilitator should summarize the findings. DRIs should be assigned to updating documentation and communicating with relevant stakeholders.

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, Goals & KPIs

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.

Measuring Issues

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.

Issue: “Things take too long”
  • KPI: Flow time - measures speed. The clock starts when work begins and ends when the customer can consume the value
    • Response: “Here's how long things actually take to do"
Issue: “Not enough features get delivered”
  • KPI: Flow velocity - measures throughput - the number of items completed over a period of time; useful for gauging capacity
    • Response: “The capacity of the teams is often less than the demand. Teams are constrained by conflicting priorities.”
Issue: “We are at risk of not completing all the initiatives on this year's roadmap”
  • KPI: Flow load - the amount of work started but not yet finished. Lots of work in progress is expensive
    • Response: “Attempting to do too many things at once results in lower quality and slower delivery.”

Converting Issues Into SOPs

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:

🧰
Objective: Speed Up Flow Time By Reducing Rework
  • Key Result: Develop SOP for X Process
  • Key Result: Develop SOP for Y Process
  • Key Result: Train Team On X Process SOP
  • Key Result: Train Team On Y Process SOP
  • Key Result: Measure New Flow Time And Report Back to the Team