OCA
OCA
Consulting Group
Threshold.
Month Two · Systems Thinking
1 / 20
Threshold
Where Leadership Becomes Infrastructure
Module Two of Nine
Systems Thinking,
Problem Framing, and Root Cause Diagnosis
Before you solve anything this month, make sure you are solving the right thing.
OCA Consulting Group · Threshold Leadership Cohort · Confidential
△
Getting Started

Before we begin,
tell us where you are.

Your name and level carry forward from Month One, but take a moment to confirm them. How you show up in this module depends on where you are leading from.

Select the level that best reflects your current role.

Coordinator
Scope: Tasks & Logistics
Supervisor
Scope: People & Daily Delivery
Manager
Scope: Operations & Resources
Director
Scope: Strategy & Function
Executive
Scope: Enterprise & Mission
Month Two · Welcome Back
Welcome back.

In Month One you did the internal work. You looked at who you are as a leader, how you show up under pressure, what you value, and where your intent and your impact can part ways. That was necessary groundwork.

Month Two turns that lens outward. The question now is not only who are you as a leader, but what is the system you are leading in, and are you solving the right problems inside it?

This month you will learn to frame problems with precision before you try to solve them. You will distinguish symptoms from root causes. You will learn when a technical solution is appropriate and when the challenge you are facing is adaptive and requires something more fundamental.

The thinking you develop here will shape how you approach every challenge in the months ahead. Take your time with it. Diagnosis is not a delay. It is the work.

△
Leader Self-Assessment

Systems Thinking, Framing,
and Diagnosis Pulse Check

Before we dive into the tools, take a moment to check where you are with systems thinking today. This is not about proving expertise. It is about noticing where you might need to stretch, and naming where you are already strong. Answer honestly. No one sees your results. This is just for you.

Rating Scale
1 — Not on my radar
4 — I do it mostly, but not always
2 — I know it exists, but I don't do it
5 — I do it consistently
3 — I see it sometimes, but act inconsistently
1 — Problem Framing Discipline

When facing a frustrating issue, how often do you pause to write a clear, neutral problem statement before jumping to solutions?

2 — Symptom vs. Root Cause Awareness

How often do you catch yourself treating the visible symptom instead of asking what deeper system condition keeps producing it?

3 — Technical vs. Adaptive Judgment

When a problem persists despite process fixes, how readily do you recognize it might require behavioral or cultural change instead?

4 — Systems Perspective

How often do you consider how structure, culture, relationships, and leadership behavior might all be interacting to create the problem?

5 — Pre-Action Reflection

Before intervening in a recurring issue, how consistently do you ask yourself: am I solving the right problem, or just the loudest one?

Your Private Scoring Guide

Mostly 1s and 2s: This module will feel like a revelation. Lean in. You are about to unlock a new level of leadership judgment.

Mostly 3s: You are seeing patterns but not acting consistently. The tools here will help you bridge that gap.

Mostly 4s: You are strong but rushed. This module will help you make systems thinking automatic even under pressure.

Mostly 5s: You are ahead of the curve. Use this module to sharpen your precision and strengthen your ability to mentor others.

Reflection Prompt

Circle your lowest score. What might happen if you grew just one point stronger there?

“
For every complex problem there is an answer that is clear, simple, and wrong.
H. L. Mencken
The goal this month is not to find a quick answer. It is to find the right question.
02
Module Two Overview

What this module
is asking of you.

Systems Thinking, Problem Framing, and Root Cause Diagnosis teaches you to see problems differently before you try to solve them. Leaders who master this skill stop firefighting and start building systems that do not catch fire as often.

What you will be able to do after this module
Frame a problem with precision rather than emotion or assumption.

Distinguish symptoms from root causes, and causes from consequences.

Classify challenges as technical, adaptive, or both, and select the right kind of response.

Apply at least one root cause analysis tool to a real issue in your work.

Make a reasoned case for which problem deserves your attention most and why.
1 Opening Reflection

Before you go any further, answer these three questions honestly. You do not need to write them down. You just need to sit with them.

Pause and Reflect

What is one problem in your work that keeps repeating? What have you already tried? And what might you be missing?

I want to explore this further with my coach
“
The significant problems we face cannot be solved at the same level of thinking we were at when we created them.
Often attributed to Albert Einstein
Diagnosing a system requires stepping back from the urgency of the event. That distance is a leadership discipline, not a luxury.
04
Lesson 1 of 5 · The Iceberg Model

Most of what drives a problem
is below the waterline.

Leaders who only respond to what is visible are always managing consequences. Leaders who understand what is below the surface can intervene at the source. The Iceberg Model gives you a four-level framework for seeing the full structure of any problem.

1 The Four Levels of Every Problem
Waterline
Events — Above the Waterline
What is visible and observable

Specific incidents, data points, and individual occurrences that leadership can see and measure. A missed deadline. A resignation. A client complaint. An error in the report. Events generate the most urgent leadership response, but they are only the surface layer of a much deeper structure.

▼ Below the Waterline
Patterns — Just Below
Recurring behaviors and systemic trends

What repeats? What direction is the trend moving? Patterns reveal that the system is reliably producing a result. Deadlines missed every quarter. Turnover concentrated in one team. Complaints clustered around one function. Patterns are how you know you are dealing with a system, not a one-time event.

Structures — Deeper
Processes, protocols, and design choices producing the patterns

The formal and informal systems that make patterns predictable. Organizational charts, reporting lines, incentive structures, approval processes, meeting cadences, communication norms, and resource allocation decisions. Structures are the architecture. They do not just allow patterns to happen. They generate them.

Mental Models — Root Level
Leader beliefs and what the team has learned to believe

The assumptions, beliefs, and unspoken rules that leaders and teams hold about how things work, what is possible, and what is acceptable. Mental models create structures. They drive which processes get built, which behaviors get rewarded, and which problems get ignored. Changing a structure without changing the mental model underneath it produces a new structure that creates the same pattern.

Peter Senge writes that most leadership failures happen not because leaders lack intelligence or effort, but because they focus on events rather than the underlying structures and mental models that produce them. The leverage is not at the top of the iceberg. It is at the bottom.

Senge, P. (1990). The Fifth Discipline. Doubleday.

2 Apply the Iceberg
Sort Activity

For each statement, tap the level of the Iceberg it represents: Event, Pattern, Structure, or Mental Model.

A manager calls an emergency meeting every time a client escalates a complaint.

Client escalations in this organization have increased every quarter for the past year.

There is no defined process for managers to resolve client issues at the site level without escalating to the Director.

Leadership has always believed that the Director should be the final decision-maker on any client-facing issue.

A team member submitted an incorrect report last Friday.

A note for leaders at your level
Knowledge Check
A leader whose team consistently misses internal reporting deadlines implements a new tracking tool. Two months later, the deadlines are still being missed. Using the Iceberg Model, what does this most likely indicate?
That is right. A solution that does not reach the structural or mental model level will produce temporary improvement at best. The iceberg remains intact below the waterline.
Something to consider. When a technically sound solution fails to hold, the Iceberg Model suggests the cause lives deeper than the event level. Ask: what pattern is the system producing? What structure creates that pattern? What belief makes the structure feel acceptable?
Walk this through with my coach
05
Lesson 2 of 5 · Problem Framing

A well-framed problem
is already half solved.

1 The Discipline of Strong Framing
A poorly framed problem leads to a misplaced solution. Most leaders rush to solutions before they have a clear picture of what they are actually trying to solve.

Weak problem framing is vague, emotional, or already pointing toward a solution. Strong framing is specific, neutral, and evidence-based.

A strong problem statement answers five questions:

What is happening? Name the observable behavior or outcome, not your interpretation of it.
Where? Which team, site, function, or group is affected?
Who is affected? Be specific about who experiences the problem and how.
How often? Is this occasional or consistent? Frequency matters for diagnosis.
What is the impact? What does this cost in time, trust, performance, or relationships?
Weak vs. strong framing
Weak: “My team has a communication problem.”

Strong: “In the past six weeks, three of five project deadlines were missed because team members did not know the status of upstream dependencies. This resulted in two client complaints and an estimated 14 hours of rework.”

The second version names what is happening, where, how often, and what it costs. That specificity changes the quality of every conversation and decision that follows.
2 Reframe a Weak Statement
Knowledge Check
Which of these is the strongest problem statement?
That is right. This statement names what happened, how often, and what it cost. It is specific, neutral, and evidence-based, which makes it actionable.
Something to consider. Strong framing is specific and evidence-based. Options A, B, and D name general impressions rather than observable outcomes. Option C is the only one grounded in observable data.
Your Problem Statement

Think of a recurring challenge in your organization. Apply the framework above. Be specific and evidence-based.

Walk this through with my coach
“
You want to get out of the hole? First you're going to have to put down the shovel.
Rick Dicker — The Incredibles (Pixar, 2004)
Diagnosing a system requires stepping back from the urgency of the event. That distance is a leadership discipline, not a luxury.
06
Lesson 3 of 5 · Symptoms, Causes, Consequences

Symptoms are visible.
Causes are what matter.

1 Three Things Leaders Must Separate
Symptoms are the visible signs that something is wrong. High turnover, low morale, missed targets, frequent conflict. These are what get leadership attention first. They are important signals. They are not the problem.

Causes are the conditions that produce the symptoms. A lack of clarity about expectations. A culture that discourages candor. A workflow that creates overload. A leader whose behavior erodes trust over time. Causes are often invisible until you look deliberately.

Consequences are what happens if the issue continues unaddressed. Loss of key people. Declining client confidence. Budget impact. Reputational damage. Consequences are what make diagnosis urgent. They are the cost of inaction, not the cause of it.

Treating a symptom without addressing the cause is the most expensive kind of leadership. It costs time, credibility, and resources, and it leaves the system intact to produce the same symptom again.

2 Label Each Statement
Label Activity

For each statement, tap whether it describes a Symptom, a Cause, or a Consequence.

Quarterly engagement scores declined for the third consecutive quarter.

Managers have never received training on how to give effective feedback.

If this pattern continues, two experienced team members have indicated they are considering leaving.

Team members frequently say they do not know what is expected of them.

No clear role descriptions exist for three positions added during the expansion.

Knowledge Check
A manager notices their team is frequently missing internal deadlines. They implement a new tracking tool. Two months later, deadlines are still being missed. What does this most likely indicate?
That is right. A recurring problem that persists after a solution is applied almost always means the solution addressed a symptom, not a root cause. The cause is still intact and still producing the outcome.
Something to consider. If a problem keeps recurring after a solution has been applied, the solution addressed a symptom, not a cause. The cause remains active and is continuing to produce the same outcome.
Walk this through with my coach
07
Lesson 4 of 5 · Technical vs. Adaptive

Know what kind of
problem you are facing.

1 The Distinction That Changes Everything
Technical problems have known solutions. They can be resolved with expertise, process, training, or a better tool. A broken intake system. A gap in technical skills. An unclear policy. The solution exists and can be implemented by someone with the right knowledge.

Adaptive challenges require people to change how they think, believe, or behave. No tool fixes them. No policy resolves them. They require a shift in values, norms, or culture, and those shifts can only happen when the people who have the challenge are genuinely part of working through it. A team that has stopped trusting each other. A culture of silence around performance. A leader whose style is creating fear.

Mixed problems have both dimensions. A new technology rollout is technically solvable, but if the team does not trust that leadership will support them through the transition, the technical solution will fail for adaptive reasons.

Ronald Heifetz and Marty Linsky write that the single most common leadership mistake is applying a technical fix to an adaptive challenge. The fix provides temporary relief while the underlying condition continues to grow.

Heifetz, R. & Linsky, M. (2002). Leadership on the Line. Harvard Business Review Press.

A note for leaders at your level
2 Classify the Scenarios
Classification Activity

For each scenario, tap Technical, Adaptive, or Mixed based on what kind of challenge is primarily present.

Staff are not completing required training because the learning management system is difficult to navigate.

A high-performing team member consistently undermines peers in cross-functional meetings.

A new reporting system is being implemented but managers distrust the data it produces.

A team has no standardized intake process for client requests, creating inconsistent service.

Knowledge Check
A senior leader wants to implement a new performance management system. The software is ready. The training plan is designed. But when they survey the team, they find that most managers do not believe performance conversations have any real impact and avoid them even now. What kind of challenge is this?
That is right. This is a clear mixed problem. The technical layer is ready, but the adaptive layer, changing the belief that performance conversations matter, is the real barrier to success.
Something to consider. When a technically sound solution sits in an environment where people do not believe in it, resist it, or do not trust it, you have an adaptive challenge embedded in a technical one. Both must be addressed.
Walk this through with my coach
08
Lesson 5 of 5 · Root Cause Tools

Tools for finding
the real cause.

Each tool below serves a different diagnostic purpose. Learn what each one does, when to use it, and what it looks like in practice. Every tool except the Five Whys includes an activity so you can try it before you need it.

1 The Five Whys
What it is
A simple iterative technique that drills from the surface problem to its root cause by asking "why" repeatedly, typically five times. Each answer becomes the subject of the next why. You stop when you reach a cause that is structural, systemic, or not within one person's control to fix alone.
When to use it
Best for problems that are clearly defined, are recurring, and where you need a fast, structured path to the root cause. It works best when one person or a small team applies it to a problem they know well. It becomes less reliable when the problem has multiple independent causes.
What it looks like
A team is missing its weekly reporting deadline every week.
Why? The data is not ready in time.
Why? The data team receives the request too late to pull it.
Why? There is no standard timeline for when requests are submitted.
Why? No one has ever defined the workflow between the two departments.
Why? The departments have never been asked to coordinate on this process.

Root cause: a missing cross-functional workflow design conversation. The fix is structural, not a performance correction.
Apply It to Your Work

Choose the problem you framed earlier, or any recurring challenge in your organization.

2 The Fishbone Diagram
What it is
Also called the Ishikawa or Cause-and-Effect Diagram. It maps contributing causes across multiple categories radiating from a central problem statement, like the bones of a fish. The problem sits at the head. The categories, typically People, Process, Environment, Technology, and Communication, form the spine and bones. Each category holds a set of possible causes.
When to use it
Best when a problem has multiple possible causes across different domains and you need to see the full landscape before deciding where to intervene. It prevents tunnel vision by forcing you to consider categories you might otherwise overlook. Especially useful in team-based diagnostic sessions where different roles bring different perspectives.
What it looks like: Fishbone for “Client escalations increased 40% in six months”
PROBLEM Client escalations +40% in 6 mo. PEOPLE New mgrs. lack conflict skills Staff turnover disrupts knowledge PROCESS No escalation threshold defined Intake docs inconsistent ENVIRONMENT 3 sites understaffed Delayed response from overload TECHNOLOGY Platform bugs delay responses COMMUNICATION Clients get different answers No response standard defined Solid lines = main category branches    Dashed lines = sub-causes

The problem sits at the head (right). Each colored branch is a category. Dashed lines show specific contributing causes within each category. The goal is to map all possible causes before deciding which to investigate further.

Activity: Identify the Category

A team is experiencing consistently low scores on internal quality reviews. Using the Fishbone categories above, tap the correct category bone for each contributing cause.

The quality review checklist has not been updated in three years and no longer reflects current standards.

Two of the four reviewers were recently promoted and have not received formal review training.

The review scoring software crashes mid-session, causing reviewers to re-enter data from memory.

Reviewers are notified only 24 hours before a review is due, leaving no time to prepare properly.

3 Current State Mapping
What it is
A visual representation of how work actually flows from start to finish today, not how it is supposed to flow. It captures every step, decision point, handoff, and delay in a process. The goal is to make the invisible visible: who does what, in what order, and where the friction lives.
When to use it
Best when the problem involves a process that is not producing consistent results and you suspect the issue is in the design, not the people. It is also powerful before implementing a new process, because it reveals the gap between the intended flow and the actual experience. Teams often discover that what leadership believes the process is, and what staff actually do, are two entirely different things.
What it looks like
For a client intake process, the current state map might show:

Client contacts site → Front desk logs the request → Request sits in shared email until someone checks it → Manager receives notification (average 2 days later) → Manager assigns it → Staff member contacts client (often without full context from the original log)

The map reveals two structural problems: no ownership of the shared inbox, and no context transfer between the log and the assignment. Neither shows up in the policy document.
Activity: Identify the Breakdown

Review this simplified current state map for a staff onboarding process. Tap the step where the most significant structural breakdown occurs.

New hire accepts offer → HR sends welcome email with start date → Hiring manager is not notified until day before start → Manager scrambles to set up access and workspace → New hire arrives to no computer, no login, no desk → IT ticket submitted on day 1 → Access granted average 4 days later
4 Pareto Analysis
What it is
A quantitative prioritization tool built on the Pareto Principle: roughly 80% of outcomes are produced by 20% of causes. Pareto Analysis ranks causes by their frequency or impact to identify which few are responsible for the majority of the problem. It prevents the common mistake of treating all causes as equally important.
When to use it
Best when you have data on how frequently different causes contribute to a problem and you need to decide where to focus limited time and resources. It is most powerful after a Fishbone or Five Whys analysis has generated a list of possible causes. Pareto helps you determine which of those causes, if resolved, would produce the greatest reduction in the problem.
What it looks like: 120 client complaints analyzed by cause
0 20 30 40 54 54 Delayed Response 45% 30 Incorrect Information 25% 22 No Follow- Through 18% 10 Rude Interaction 8% 4 Other 4% Number of Complaints First 2 causes = 70% of all complaints

Pareto finding: Addressing delayed response and incorrect information alone would resolve 70% of complaints. That is the starting point for intervention.

Activity: Read the Histogram

A manager tracked causes of team overtime hours over one quarter. The histogram below shows the data. Based on what you see, tap the answer that correctly applies the Pareto Principle.

0% 10% 20% 30% 38% Rework/ Unclear instruct. 31% Waiting for approvals 16% Covering colleagues 10% Non-essential meetings 5% Other
5 The Pre-Mortem
What it is
A Pre-Mortem is a prospective diagnostic tool developed by psychologist Gary Klein. Before a plan, process, or intervention launches, you ask your team to imagine it is one year in the future and the initiative has failed. Working backward, you identify what went wrong and why. Unlike failure mode analysis, which categorizes technical risks, the Pre-Mortem surfaces the human, cultural, and political risks that technical planning tends to miss. It turns hindsight into foresight.
When to use it
Best when designing a new process, launching a change initiative, or implementing an intervention where failure would be costly, hard to reverse, or trust-damaging. Also valuable before a difficult conversation, a restructuring, or any decision where the stakes are high. Leaders who run Pre-Mortems consistently are less likely to be surprised by adaptive resistance, unintended consequences, or implementation gaps.
What it looks like
A Director is about to implement a new peer feedback process. Before launch, the team runs a Pre-Mortem: "Imagine it is one year from now and the peer feedback process has failed. What happened?"

Scenario named: Managers gave feedback that was too vague to change anything.
Likelihood: High — no training exists on behavioral specificity.
Impact: Medium — the process runs but produces no real development.
Prevention: Add a 30-minute calibration session before launch and a sample template with before/after examples.

Scenario named: Staff saw the process as punishment rather than development.
Likelihood: High — no communication addressed how results would be used or protected.
Impact: High — participation collapses and trust in leadership declines.
Prevention: Send a transparent communication about purpose, confidentiality, and what will and will not be shared before the first cycle launches.

Scenario named: Managers competed for scores rather than using feedback to grow.
Likelihood: Moderate — the incentive structure rewards ranking, not development.
Impact: High — the tool becomes political rather than developmental.
Prevention: Explicitly decouple peer feedback scores from any performance rating system.
Activity: Run the Pre-Mortem

A manager is about to launch a new shift scheduling system without consulting the team. Imagine it is six months later and the rollout has failed. Which scenario most likely describes what happened?

Walk this through with my coach
“
It is not enough to do your best; you must know what to do, and then do your best.
W. Edwards Deming
Knowing what to do starts with knowing what is actually happening. Diagnosis before prescription, always.
09
Applied Practice · Stakeholder Analysis

The same problem looks different
from different positions.

1 Why Perspective Matters in Diagnosis
A process problem looks like a communication problem to the person receiving unclear outputs. A trust problem looks like a performance problem to the leader who has not yet seen the environment they created. A workload problem looks like a prioritization problem to the person who does not see how many requests are flowing in from above.

Stakeholder analysis is not just a political exercise. It is a diagnostic tool. When you understand how different people experience the same situation, you get a more complete and accurate picture of what is actually happening and why.

Map at least three stakeholders: someone above you, a peer, and someone on your team or below you in the organization. For each, describe how they experience the problem, what they would say the cause is, and what they need.
Stakeholder Perspective Map

Include at least one person at a different level than you. Their perspective on the same problem will almost always reveal something you cannot see from where you sit.

Pause and Reflect

If the people who experience this problem most directly were in the room with you right now, what would they say that you have not yet fully considered? And what would that mean for how you have been thinking about the solution?

Walk this through with my coach
10
Applied Practice · Prioritizing Problems

Not every problem
deserves your attention first.

1 What Makes a Problem Worth Solving Now
Good leaders do not just solve problems. They choose which problems to solve and when. Prioritization is a leadership discipline because attention is a finite resource. Every problem you pursue is a problem you cannot pursue simultaneously.

When assessing priority, consider five dimensions:

Impact: How significant is the effect on people, performance, or mission?
Frequency: Is this happening once or repeatedly?
Risk: What is the consequence of leaving it unaddressed for 30, 60, or 90 more days?
Cost: What is this costing in time, money, talent, or trust right now?
Strategic relevance: Is addressing this aligned with what the organization most needs to accomplish?

High-leverage problems score high on at least three of these dimensions. They are the ones worth your focused diagnostic attention.

Urgency and importance are not the same thing. A leader who only responds to what is urgent rarely gets to what is important. Systems thinking helps you see the important before it becomes urgent.

Problem Priority Assessment
Pause and Reflect

What problem have you been tolerating because it is not yet urgent enough to demand action? What would change if you addressed it now, before it becomes a crisis?

Walk this through with my coach
11
Month Two · Capstone Artifact

What you are building
for your portfolio.

Your Month Two group deliverable is built from the Northstar Case Study you were introduced to in Month One. You are analyzing Alex Morgan's region using the diagnostic tools from this module. This is not a reflection exercise. It is a structured group analysis grounded in the case evidence you have been given.

Month 2 Group Deliverable: Root Cause Analysis and Consequence Map
1. Iceberg Model. Map what is visible in Alex's region (events) and what is driving those events below the surface: patterns, structures, and mental models. Be specific at each level using evidence from the case. The mental model level should include at least two entries naming what Alex believes to be true and what the team has learned to believe as a result.

2. Technical versus adaptive diagnosis. For each problem you identify in Alex's region, determine whether it is primarily a technical problem, an adaptive challenge, or both. Explain your rationale using case evidence. If your group disagrees, the Challenger holds the disagreement open until evidence resolves it.

3. Five-Why root cause analysis. Choose one target: either why managers have stopped raising problems, or why Alex does not yet see that this is happening. Run the Five Whys until you reach a cause that cannot be solved by Alex alone. Name the organizational root cause clearly. This will anchor your systemic recommendations in later months.

4. Consequence map. If the current pattern continues uninterrupted, map the downstream consequences at three levels over eight weeks: the team level, the regional performance level, and the organizational level. Use the logic of the system, not speculation. Base your map on what the candor collapse produces if nothing interrupts it.

5. Risk Statement review. Return to the Leadership Risk Statement your group wrote in Month One. Read it aloud. Note what holds, and what you would add to make it more precise in light of what you now know. The statement is a living document and the evidence is accumulating.
Walk this through with my coach
Module Reflection
Leadership is not just about solving problems fast. It is about solving the right problem. Good diagnosis protects time, energy, trust, and effectiveness.
Pause & Reflect

“What did I learn about the way I typically approach problems?”

“What will I do differently before I try to solve the next issue?”

Navigate
0