Thinking for a Change

It’s always a people problem (Gerald Weinberg)

In “The Secrets of Consulting“, Gerald Weinberg tells us that Whatever the problem is, it’s always a people problem.

All too often, problems are labeled as “Technology problems”, to hide the real problem and avoid blame. This strategy is very effective in a field like IT, where there is lots of technology churn. However, you can always trace even these problems back to people: who selected the technology and why, do people know how to use the technology, were the users of the technology consulted…

It’s always a process problem (The Toyota Way)

The Toyota Way states that Whatever the problem is, it’s always a process problem.

Not surprising, coming from a company which has one of its principles: “The right process will deliver the right results.”

An example situation: Mike the micromanager

Imagine an all too common situation: someone who micro-manages their team. As the number of interventions rises, so does the disruption to team member’s flow. This reduces the team’s productivity. When the lower results become visible, this increases the need the manager feels to intervene, which leads to more interventions. And the vicious circle goes on an on…

Micromanagement as a people problem

What questions would Gerald Weinberg ask?

• Where does this need to intervene come from?
• Is the manager aware of the effects of his actions? Could we clarify this by using a Systems Thinking approach as above?
• Can we improve the way the manager and the team communicate? E.g. the manager could “batch” his requests of the team; the team could provide better visibility into the state of their work, so that the manager need not fear that “things are getting out of control”.
• How do the team members react to the interventions? Are they acting incongruently themselves?

Micromanagement as a process problem

What questions would Toyota ask?

• What is wrong with our hiring or promotion process, that put this manager in a situation he wasn’t able to handle?
• What is wrong with our training and coaching process, that we left this manager in a difficult situation without any help?
• What is wrong with our Genchi Genbutsu (go see on the workfloor) process, that this manager’s manager didn’t go and see how the team was, so that he could see the problem?
• What is wrong with our Hourensou (report, inform, consult) process, that this manager didn’t inform his manager of the problem and consult him for ways to solve the problem?
• What is wrong with our evaluation and “Stop the line to fix mistakes”, that nobody stopped to report the problem and find its cause?

People or Process? Evaporating the cloud

We clearly have a conflict: either every problem is a people problem or it’s a process problem. The “Thinking Processes” provides us with the “Evaporating Cloud” technique to examine and resolve such conflicts.

How do you read this diagram?

• In order to have “An effective organisation” (goal) we need “Effective people” (requirement 1), because the effectiveness of the people determines the qualities of the result (assumption 1)
• In order to have “An effective organisation” (goal) we also need “Effective processes” (requirement 2), because effective processes enable people to work well together (assumption 2).
• In order to have “Effective people” (requirement 1), we need to “Treat every problem as a people problem” (prerequisite 1), because this will help us focus on solving the fundamental people problems and not get sidetracked by superficial symptoms (assumption 3).
• In order to have “Effective processes” (requirement 2), we need to “Treat every problem as a process problem” (prerequisite 2), because this will help us focus on continuously improving our processes and thereby making our solutions available to the whole organisation (assumption 4).
• There is a conflict between D1 and D2: either all problems are people problems OR all problems are process problems.

How can we resolve the conflict?

1. Are the relationships between goal and requirements valid? I think so. I believe we need a combination of effective people and processes to succeed. Take away one of them and you can’t have an effective organisation (if you have effective people, they will probably grow a process anyway).
2. Are the relationships between prerequisites and requirements valid? I believe the only way to be effective is to be continually be solving problems, be they people or process problems.
3. Are the assumptions correct? I believe so, I can’t find any counter-examples for the moment.
4. Why can’t D1 and D2 co-exist? Are they really mutually exclusive? What’s the assumption behind this? Hmmmmmm. Let me think…

Imagine that both statements are true: Every problem is a people problem AND a process problem. Would this assumption lead to a contradiction? Let’s see what we would do in Mike’s case:

• First, we could call in Jerry Weinberg and resolve this manager and team’s issues, so that this team can work effectively.
• Then, we could call in a Toyota sensei to question the processes that led up to this problem and failed to detect and correct it. They would help us to improve the processes, so that this kind of situation could be avoided in the future, so that in the future, all teams can work effectively.

I believe this resolves the conflict: every problem is a people problem that must be solved now AND an underlying process problem that must be solved, so that this problem doesn’t reoccur in the future. That means we have to clarify our goal: “To have an effective organisation, now and in the future“. With these changes, the diagram looks like this:

Reconciling people and process, present and future

Both types of problem solving have their place. We need to deal with the problems that people are having now. We need to continuously improve our processes so that these problems won’t reappear for other teams in the future.

An analogy I like is that improvement needs to be like a ratchet: relentless reflection and continuous improvement (Hansei & Kaizen) drive the gear wheel forward; processes encode our growing and changing knowledge to act as the “click” that prevents the wheel from turning back.