No company or organization operates under perfect conditions where nothing ever breaks down or fails. It’s normal and expected that, at some point, you won’t see the results you want to see.
And when that happens, when work repeatedly falls apart or targets keep getting missed, we typically start asking who caused it or what process broke down. Leaders tend to ask if they have a people problem or a process problem.
“Who’s the bottleneck?”
“Why isn’t so-and-so pulling their weight?”
"When will our tech stack work as expected?”
“Why does product team keep missing their deliverables?”
Then they start looking for people to hire, fire, move, or restructure, or for strategies, tools, and processes to introduce, change, or eliminate.
These questions sound diagnostic. But they may be subtly leading the diagnosis.
Asking whether you have a people problem or process problem creates a false dichotomy. It assumes the problem must belong to one of two mutually exclusive categories.
That “either-or” framing locks you into a fixed perspective before you have taken the time to understand what’s actually happening. Instead of seeking answers, you start finding the answers you think you’re looking for.
You’re already inconspicuously leading the diagnosis.
Psychologists Amos Tversky and Daniel Kahneman showed us that how a choice is framed can change how people evaluate it. Once leaders frame an issue as “people or process,” they begin sorting the evidence into these two categories instead of investigating what is actually happening.
Then confirmation bias sneaks in. It’s in our nature to selectively seek and interpret evidence in ways that support what we already suspect or believe, and overlook any evidence that contradicts it.
If a leader thinks Matt is the bottleneck, then every missed deadline becomes another piece of evidence against Matt.
If another leader thinks the tech stack is the problem, then every workaround confirms that belief.
“See? We had to create our own ad hoc agent to produce these reports because we don’t have the right tools in place.”
Before long, you’re no longer observing the system. You’re building a case.
The question itself pigeonholes you into a fake, highly subjective, binary world that contains only two kinds of problems.
So you ain’t solving anything with that question.
Organizational performance is not created by people or processes in isolation. It emerges from the way people, processes, technology, roles, expectations, structures, incentives, authority, and the status quo interact.
People shape processes, and processes shape how people behave.
It’s cyclical and reciprocal.
Whether it’s documented or not. Visible or hidden. Intentional or unintentional.
This relationship has long been recognized in sociotechnical systems theory, which treats people, processes, structures, and technology as interdependent parts of the same system.
People create processes. Processes shape behavior. Behavior creates norms and workarounds. Those norms and workarounds reshape the process.
For example, if a required process becomes too cumbersome, then team members might begin working around it so they can get things done. When leaders resist their feedback, people stop raising concerns. The workarounds become normalized. Leaders eventually notice inconsistent execution and introduce even more policies to correct the problems the original process helped create.
And so on and so forth.
Over time, those interactions become the way work actually gets done. And THAT becomes your operating system.
Part visible, part invisible. Part intentionally designed, part accumulated through habit, pressure, adaptation, and workarounds.
If you want to understand what is producing the results you’re seeing, don’t begin by deciding what kind of problem you have.
Begin by separating the observable result from your interpretation of it. (A practice I call content vs context.)
"The team doesn’t care” is an interpretation.
"No one raised a question, concern, or idea during the last four team meetings” is an observable result.
“The marketing team is unreliable” is an interpretation.
“The marketing team missed five agreed-upon deliverables for sales, product, and customer success over the last two months” is an observable result.
One points the finger and blames. The other gives you something observable that you can investigate.
So start by objectively examining what’s happening:
Name the observable result. Describe what happened without blame, judgment, or an explanation disguised as fact.
Establish the pattern. How often does it happen? When did it begin? Where does it happen? Where does it not happen?
Map the conditions surrounding it. Identify the people, roles, processes, tools, information, decisions, incentives, dependencies, and pressures involved.
Compare the exceptions. When does the actual desired result occur? What is different about those situations?
Form and test multiple explanations. Identify several plausible causes before committing to one. Then look for evidence that could disprove each explanation, not just evidence that confirms it. Think like a scientist.
As you investigate, ask:
Does the result follow one person across otherwise functional conditions?
Does it follow the role regardless of who occupies it?
Does it occur at the same handoff between teams?
Does it appear only under certain conditions, such as time pressure or shifting priorities?
Does the documented process depend on unofficial workarounds?
What continues to happen even after the person, tool, or process has changed?
A poorly defined problem makes almost any solution seem reasonable. Replace the employee. Add a new tool. Rewrite the process. Schedule another meeting (ugh.) Restructure the team.
But if you haven’t clearly defined the result you’re seeing, or what is producing it, then you have no reason to believe any of those interventions will change it.
Let’s say the recurring, observable result is that no one contributes during your team meetings.
You’re the leader. You work through the agenda, ask questions, and receive short answers. No one raises concerns, shares ideas, challenges an assumption, or brings up something you haven’t explicitly asked about.
The easy "people" explanation might be that the team is passive, disengaged, introverted, or “all Gen Z anyway.”
The easy "process" explanation might be that the meeting is too long, the agenda needs to change, or everyone should be required to contribute one talking point.
Either explanation might contain part of the truth. But neither explains the system yet.
So you follow the result.
You notice that the same people participate actively in meetings you don’t attend. The conversations are lively. They surface problems, challenge ideas, and volunteer solutions. Weird.
You also notice that your one-on-ones with those employees are shallow. They answer the questions you ask but rarely introduce anything new. Ok.
Then you look more closely at your behavior (or work with a coach who helps you see more clearly.)
You remember the times you immediately explained why someone’s idea wouldn’t work. The projects you micromanaged after delegating them. The questions you asked people without warning and expected them to answer on the spot. The occasions when someone challenged your thinking and you became defensive. Uh-oh.
The team learned something from all those interactions.
They learned to withhold ideas. The meetings reinforced passivity. The one-on-ones stayed shallow. Their silence left more room for you to speak, direct, and control the conversation. And you may have interpreted that same silence as evidence that the team had nothing to contribute, or needed even more direction from you. Dang.
Your behavior shaped how the team operated. The team’s response then reinforced your behavior. It became a feedback loop. Eureka.
At that point, is it a people problem or a process problem?
See how that question is too small? Too limiting? Potentially harmful, even?
If a result keeps recurring, something in the system is continuing to produce it. That doesn’t mean anyone intentionally designed the organization to miss deadlines, create bottlenecks, silence employees, or frustrate customers.
It means the conditions producing those outcomes still exist. We just might not see all of them yet.
The current configuration of people, behaviors, processes, tools, incentives, and authority is producing the result it is set up to produce.
The leader, their behavior, the team’s response, what people have learned, the norms they’ve formed, and the workarounds they’ve adopted, all of it interacts to reproduce the same result. Until something in that system changes, the result is likely to keep repeating.
You see, the system is working. That’s the real problem.
The pattern tells you where to begin.
If the result repeatedly concentrates around one person’s behavior, address that behavior and examine what it has taught the surrounding team to do in response.
If the result follows a role, regardless of who’s in it, examine the expectations, authority, resources, incentives, and constraints built around that role.
If it repeatedly appears between people and functions, examine the handoffs, decision rights, information flow, and dependencies connecting them.
The point is not to absolve people of responsibility or blame every failure on a broken process. People are part of the system. So are their choices, behaviors, capabilities, and willingness to change.
The point is to understand what’s really happening, and what’s producing that result before deciding where and how to intervene and course correct.
Because replacing a person won’t repair the conditions that taught everyone else to operate the same way. And adding another process won’t correct behavior that no one is willing to confront.
Follow the pattern. Find the conditions reinforcing it. Then intervene where the system can actually change.