It is more like being involved in a complicated love affair. One minute it’s thrilling, passionate, engaging. The next, it’s exhausting and overwhelming, and I feel like I need a break.
— Read on hbr.org/2019/07/when-passion-leads-to-burnout
It is the responsibility of leaders “to keep an eye on the well-being of their staff.” Organizations whose staff feel unmotivated due to stress and burnout cannot aspire to achieve a culture of excellence. Our systems need to be designed to eliminate the root cause for stress and burnout.
Five mechanisms can be leveraged to improve organizational system design: 1) Eliminate organizational issues related to roles, responsibilities and authorities of employees, 2) establish a policy of transparency and effective “bottom-up” internal communication channel to permit employee contribution and recognition, 3) establish criteria for resource distribution, 4) establish a commitment to identify needed training and provide resources for the purpose and 5) establish a systemic feedback loop for analysis and improvement of employee motivation based on periodic measurement of employee motivational levels.
employees know exactly what their tasks are, without sustained overload, with
necessary resources and competence, and recognition for the task well
performed, there will be no major system-induced reason for demotivation.
This gets to the heart of Deming’s use of psychology in his System of Profound Knowledge. Lean calls it Respect-for-People. This is all about ensuring our organizations are healthy places to work and thrive.
We often try to solve problems as if we are outside them. When people describe a problem you will see them pointing away from themselves – you hear the word “them” a lot. “They” are seen as the problem. However, truly hard problems are system problems, and if you are part of the system (hint – you are) then you are part of the problem.
Being inside the problem means we have to understand bias and our blind spots – both as individuals, as teams and as organizations.
Understanding our blind spots
An easy tool to start thinking about this is the Johari window, a technique that helps people better understand their relationship with themselves and others. There are two axis, others and self. This forms four quadrants:
Arena – What is known by both self and others. It is also often referred to as the Public Area.
Blind spot – This region deals with knowledge unknown to self but visible to others, such as shortcomings or annoying habits.
Façade – This includes the features and knowledge of the individual which are not known to others. I prefer when this is called the Hidden. It was originally called facade because it can include stuff that is untrue but for the individual’s claim.
Unknown – The characteristics of the person that are unknown to both self and others.
An example of a basic Johari Window (my own) can be found here.
Users are advised to reduce the area of ‘blind spot’ and ‘unknown’, while expand the ‘arena’. The premise is that the lesser the hidden personality, the better the person becomes in relating with other people.
The use of Johari Window is popular among business coaches as
a cognitive tool to understand intrapersonal and interpersonal relationships. There
isn’t much value of this tool as an empirical framework and it hasn’t held up
to academic rigor. Still, like many such things it can bring to light the
central point that we need to understand our hidden biases.
The Johari Window can also be applied to knowledge transparency, and it fits nicely to the concepts of tacit and explicit knowledge bringing to light knowledge-seeking and knowledge-sharing behavior. For example, the ‘arena’ can simply become the ‘unknown’ if there is no demand or offer pertaining to the knowledge to be occupied by the recipient or to be shared by the owner, respectively.
The Johari Window transforms with the the four quadrants changing to:
Arena – What the organization knows it knows. Contains knowledge available to the team as well as related organizations. Realizing such improvements is usually demanded by network partners and should be priority for implementation.
Façade – What the organization does know it knows. Knowledge that is only available to parts of the focal organization. Derived improvements are unexpected, but beneficial for the organization and its collaborations.
Blind Spot – What the organization knows it does not know. Knowledge only available to other organizations – internal and external. This area should be investigated with highest priority, to benefit from insights and to maintain effectiveness.
Unknown – What the organization does not know it does not know, and what the organization believes it knows but does not actually know. Knowledge about opportunities for improvement that is not available to anyone. Its identification leads to the Façade sector.
One of the key aspects of being an expert is the capacity to apply situational awareness: the perception of relevant information, comprehension of their meaning and the projection to future events.
Developing this situational awareness is a critical part of problem-solving and we can map the 4Cs of trouble-shooting onto these three elements.
The ability to perceive important information is a critical first step to being able to problem-solve, and one that takes time to develop especially in the highly complex and demanding environments most of us operate in. Knowing which information is important and have an understanding of the many subtle cues to evaluate is one of the hallmarks of an expert. But even for experts it can be difficult, which is why building perceptual cues in our checklists, procedures and such is important.
From perception we can draw meaning and significance, allowing the expert to combine, interpret, store and retain information. Integrating multiple pieces of information to arrive at a determination of relevance.
Experts are able to project from current events to anticipate future events and their implications.
The bystander effect occurs when the presence of others discourages an individual from intervening in an emergency situation. When individuals relinquish responsibility for addressing a problem, the potential negative outcomes are wide-ranging. While a great deal of the research focuses on helping victims, the overcoming the bystander effect is very relevant to building a quality culture.
The literature on this often follows after social psychologists John M. Darley and Bibb Latané who identified the concept in the late ’60s. They defined five characteristics bystanders go through:
Notice that something is going on
Interpret the situation as being an emergency
Degree of responsibility felt
Form of assistance
Implement the action choice
This is very similar to the 5 Cs of trouble-shooting: Concern (Notice), Cause (Interpret), Countermeasure (Form of Assistance and Implement), Check results.
What is critical here is that degree of responsibility felt. Without it we see people looking at a problem and shrugging, and then the problem goes on and on. It is also possible for people to just be so busy that the degree of responsibility is felt to the wrong aspect, such as “get the task done” or “do not slow down operations” and it leads to the wrong form of assistance – the wrong troubleshooting.
When building a quality culture, and making sure troubleshooting is an ingrained activity, it is important to work with employees so they understand that their voices are not redundant and that they need to share their opinions even if others have the same information. As the HBR article says: “If you see something, say something (even if others see the same thing).”
Building a quality culture is all about building norms which encourage detection of potential threats or problems and norms which encouraged improvements and innovation.
I recently had a discussion with one of the best root cause investigators and problem solvers I know, Thor McRockhammer. Thor had concerns about a case where the expected conditions were not met and there were indications that individuals engaged in troubleshooting and as a result not only made the problem worse but led to a set of issues that seem rather systematic.
Our conversation (which I do not want to go into too much detail on) was a great example of troubleshooting going wrong.
Troubleshooting is defined as “Reactive problem solving based upon quick responses to immediate symptoms. Provides relief and immediate problem mitigation. But may fail to get at the real cause, which can lead to prolonged cycles of firefighting.” Troubleshooting usually goes wrong one of a few ways:
Not knowing when troubleshooting shouldn’t be executed
Using troubleshooting exclusively
Not knowing when to go to other problem solving tools (usually “Gap from standard”) or to trigger other quality systems, such as change management.
Troubleshooting is a reactive process of fixing problems by rapid response and short-term corrective actions. It covers noticing the problem, stopping the damage and preventing spread of the problem.
So if our departure from expected conditions was a leaky gasket, then troubleshooting is to try to stop the leak. If our departure is a missing cart then troubleshooting usually involves finding the cart.
Troubleshooting puts things back into the expected condition without changing anything. It addresses the symptom and not the fundamental problems and their underlying causes. They are carried out directly by the people who experience the symptoms, relying upon thorough training, expertise and procedures designed explicitly for troubleshooting.
With out leaky gasket example, our operators are trained and have procedural guidance to tighten or even replace a gasket. They also know what not to do (for example don’t weld the pipe, don’t use a different gasket, etc). There is also a process for documenting the troubleshooting happened (work order, comment, etc).
To avoid the problems listed above troubleshooting needs a process that people can be thoroughly trained in. This process needs to cover what to do, how to communicate it, and where the boundaries are.
What we do
Things to be aware of
·What do we known about the exact nature of the problem?
·What do your
standards say about how this concern should be documented?
can be addressed as a comment or does it require a deviation or similar non-conformance
·If the concern stems
from a requirement it must be documented.
·What do you
know about the apparent (or root) cause of the problem?
is really good at dealing with superficial cause-and-effect relationships. As
the cause deepens, fixing it requires deeper problem-solving.
·The cause can
be a deficiency or departure from a standard
or temporary countermeasures can be taken to reduce or eliminate the problem?
or more permanent countermeasures required to prevent recurrence?
oIf so, do you
need to investigate more deeply?
need to be evaluated against change management
cannot ignore, replace or go around standards
·Did the results
of the action have any immediate effect on eliminating the concern or
oIf so, do you
need to investigate more deeply?
should trigger deeper problem-solving and be recorded in the quality system.
countermeasures becoming tribal knowledge and the new way of working
Trouble shooting is in a box
Think of your standards as a box. This box defines what should happen per our qualified/validated state, our procedures, and the like. We can troubleshoot as much as we want within the box. We cannot change the box in any way, nor can we leave the box without triggering our deviation/nonconformance system (reactive) or entering change management (proactive).
Communication is critical for troubleshooting
Troubleshooting processes need a mechanism for letting supervisors happen. Troubleshooting that happens in the dark is going to cause a disaster.
Operators need to be trained how to document troubleshooting. Sometimes this is as simple as a notation or comment, other-times you trigger a corrective action process.
Engaging in troubleshooting, and not documenting it starts to look a like fraud and is a data integrity concern.
The change management process should be triggered as a result of troubleshooting. Operators should be trained to interpret it. This is often were concept of exact replacements and like-for-like come in.
It is trouble shooting to replace a part with an exact part. Anything else (including functional equivalency) is a higher order change management activity. It is important that everyone involved knows the difference.
Is it troubleshooting?
Spare parts that are identical replacements (has the same the same manufacturer, part number, material of construction, version)
Existing contingency procedures (documented, verified, ideally part of qualification/validation)
This should be built into procedures like corrective maintenance, spare parts, operations and even contingency procedures.
Equivalent, for example, performance, specifications, physical characteristics, usability, maintainability, cleanability, safety
Need to understand root cause. Need to undergo appropriate level of change management
Need to understand root cause. Need to undergo appropriate level of change management
This applies to both administrative and technical controls.
ITIL Incident Management
ITIL Incident Management (or similar models) is just troubleshooting and has all the same hallmarks and concerns.