Blog

Leading with Respect: The Right to Be Successful

Comments off 23 Views0

I recently had the pleasure of presenting a webinar on a topic I am passionate about: Leading with Respect.

The event drew over 350 attendees, the majority of whom stayed tuned in for the entire time and were highly engaged in the chat. The fact that so many people attended shows how important and pertinent this topic is today.

Considering the high levels of stress, fear, uncertainty, and change we all are going through, it is no surprise that the topic of how to effectively create a workplace of inclusion, engagement, accountability, teamwork, and amazing results is so popular.

Lead with Respect provides 7 core areas of behavior-based patterns that change how leaders, managers, and teams show up and interact. Leading with respect involves awareness of our focus and intention, and how well we are connecting with people to create an environment of mutual trust and sustained high levels of performance. This is accomplished through the application of 7 core practices:

  1. Go and See for Yourself
  2. Create a Meaningful Challenge
  3. Listen to Understand
  4. Teach and Coach
  5. Support Others
  6. Foster Teamwork
  7. Learn as a Leader

After nine years of applying and refining these practices, I am still humbled and deeply moved when I see the impact they have on people, teams, and leaders to create mutual trust, psychological safety, and camaraderie. As human beings, we all want to be included and respected while at the same time know we are making a meaningful difference.

Lead with Respect is built on a foundation of key principles about what people need to flourish. One of the attendees asked, “Under the assumption ‘People have a right to be successful,’ how do you define successful?” This is an excellent question! As applied to these practices, success is defined by each individual person. Working with hundreds of people, I have noticed a pattern emerge: practically everyone shares the same human needs and sees success in similar ways:

  • Contributing towards a meaningful purpose or challenge (purpose)
  • Feeling comfortable sharing ideas, asking for help, and reporting problems (safety)
  • Being part of a team that you care about (belonging)
  • Helping others and being helped (teamwork)
  • Taking control of how you “show up” (autonomy)
  • Learning something new each day (development)
  • Getting better at something with persistence and practice (mastery)
  • Setting and achieving challenging goals (results)

Leading with Respect provides the framework, principles, and tools to build a working environment where people come together to create amazing results because they really care about each other, their customers, and their organization!

For more information and to connect with Mike Orzen, click here.

The Mythical Value Stream Manager

Comments off 552 Views0

For decades, the lean community has been talking about the importance of creating and managing customer value across the value stream. A value stream is comprised of all the activities performed to create, manage and deliver value to customers. It includes all the wasteful and broken processes we have come to accept as inherent in the way the work gets done. A key player who focuses on coordinating and aligning the efforts of all pieces of the value stream is the value stream manager. Their goal is to get everyone working together and aligned toward the common goal of optimizing their entire value stream. I like to call this character the “mythical value stream manager” because they are described in books, but seldom seen in the wild – much like a unicorn.

This person is the master coordinator among silos, conflicting priorities, constrained resources and localized performance. No small task as most people focus on improving that small piece of work they have been assigned to and seemingly have control over. Can you really fault anyone for trying to make things better? Lean teaches us waste reduction, minimizing variation and addressing overburden as ways to improve flow. It’s no surprise that we attempt to apply these methods and tools to our own work first!

But herein lies the problem as well as the opportunity: local improvements do almost nothing to improve value stream performance and often negatively impact overall flow of the same value stream the team intended to improve!

Good intentions gone awry

I worked with a company whose Document Control Department decided to make improvements to their work processes with the noble intent of improving the flow of customer value. The company had been experiencing many delays in updating controlled documents (work instructions, drawing and technical specifications). The focus was on the time it was taking to process change requests and deliver updated and accurate documents to the appropriate work groups. The current process was taking days and sometimes weeks and crippling production and service levels in departments across the company. The team had received lean training and requested the help of a lean facilitator to guide them through an improvement effort.

After a focused 3-day effort, the team generated a series of countermeasures intended to address the blockers in their workflow which slowed or stopped their work. They rolled out the changes and measured the impact. Success! The total time it took from start to completion of their section of the value stream went for days to hours to minutes. The team held a party to celebrate the amazing results. They invited the departments whom they delivered they worked for. Surprisingly, no one attended!

A few people from the team were curious why no one came to the celebration. They paid a few people a visit and quickly found that the improvements they made had shifted work and problems to the very people they were trying to serve! Instead of impacting the flow of value across the value stream, they had optimized their flow by shifting the non-value added work to others. One team member shared, “What we discovered was that we had taken out the trash from our work flow  and dumped on our neighbors’ front yard! To make matters worse, we then threw a party and invited them to share in the fun. Our efforts were well intended, but we completed screwed things up!”

Without a person focusing of the flow of the value stream, how can we expect leaders and front line contributors to coordinate their efforts to create improvements that ultimately impact the customer? When so many of our performance measures are focused on local results, how can we understand and support value-stream level outcomes?

Why we don’t have value stream managers

If we accept the importance of creating flow and the impact of a designated value stream overseer, then why are they so rare? There are many reasons (excuses) that come up including: 

  • It’s not my job to focus beyond my area of responsibility
  • I’m busy just keeping my head above water
  • My numbers are good, go pick on someone else
  • I agree it’s important, but don’t step on my turf and try to influence my program
  • My incentives determine my focus and my behavior
  • Who needs more responsibility without authority? This is a fool’s errand!

Whether you agree with these points or not, they’re real in the minds of many.

What can we do about it?

When leaders understand and appreciate the potential impact of a designated role focused on managing the value stream to improve the flow, quality and value at the speed of customer need, they may be willing to run an experiment. Create the role, provide clear goals and boundaries, socialize the change and gain support, gather baseline performance measures, run a trial for 90 days, re-assess performance by comparing to baseline, reflect on the results, share the learning, take your next step based on the learning. Sounds easy! It’s not.

  • Identify a pilot area where you can test the effectiveness of value-stream focus
  • Socialize the idea with every part of the stream (all the silos, vendors, departments, customers, managers and leaders (start with the leaders)
  • Recruit a person who is willing to take on a temporary role of value stream manager – they’ll need a mandate to make things happen – this might be in the vocal support of the CEO or GM
  • Plan on getting it wrong, learning from mistakes and making adjustments based on the data

Measures help people align

What works best to align people across the value stream is the use of value-stream level metrics that everyone is measured by. When everyone is playing off a common scoreboard, they shift their efforts from localized to global results. Here’s a few examples:

  • Value stream percent complete and accurate
  • Value stream cycle time
  • Order fulfillment rate
  • Returns

Give it a try

If you  want to make a serious impact in your improvements, consider shifting your focus outward to a value-stream level perspective and find someone who is willing to take on the role of value stream leader. They’ll have to work with others based on what makes the most successful sense to the value stream rather than a single department or functional area. Approach this work as a learning experiment and expect many check/adjusts along the way. Good luck!

Until you shift to a focus on value-stream level performance, most improvement efforts are destined to miss the mark as they will shift waste and inefficiencies to another part of the business. Customers won’t feel the difference, even if you are celebrating the results! But what if your competition is focusing on value-stream improvements? From your customers’  perspective working with you, if things aren’t getting better, they’re actually getting worse.

I wrote this back in 2019 for the Lean Enterprise Insitute and a friend contacted me to share it again – Thanks Lisa!

Effective Structured Problem Solving through Self-awareness

Comments off 398 Views0

Seeing the Real Gap

PDCA, the unassuming four-step cycle of plan-do-check-adjust, is the secret sauce of learning and improvement. This scientific method of structured problem-solving brought us the industrial revolution, chemistry, modern medicine, physics, computers, space travel, the internet and the world as it exists today. It seems quite natural that we would apply this potent tool to our work processes to address issues around flow, variability, overburden, and non-value added work.

Indeed, the PDCA mindset captures the essence of lean problem solving. By leveraging the scientific method to address problems, we pursue the goals of lean. Habitual use of this approach builds our ability to understand what our customers value, create and flow that value, and relentlessly strive to improve – all while fostering a learning culture built on respect for people and continuous improvement.

Easier said than done. A scientific mindset searches for facts by testing hypotheses, runs experiments to validate what we think we know, relentlessly uncovers new truths, and revises our thinking based on fact-based learning. It sounds easy but it is deviously tricky, because our mind assumes our current perception and understanding is accurate and we know what we are talking about!

Here’s the amazing thing: very few people actually embrace the scientific method when applying PDCA. I certainly don’t mean to offend anyone here, so how can I make such a bold claim? My findings are based on over 200 A3s created by people I have coached, and on the numerous A3s I have personally developed in my formative years of lean practice. All of these examples used an A3 form to structure the PDCA thinking process, but failed to coach the A3 owner to go deep enough to perceive actual conditions and generate anything that might be called a discovery. These attempts at problem-solving often implemented solutions that were known before the A3 was even started. They simply captured preconceived ideas on paper and declared them as lean improvements.

In Atomic Habits, author James Clear writes, “The challenge for anyone interested in making progress is to simultaneously have (1) the confidence to go after what you want, (2) the humility to accept who you are right now, and (3) the willingness to build skills that bridge the gap between 1 and 2.” Before you can “accept who you are right now,” you must have the ability to make that determination accurately. Not only do we need to understand and accept who we are, but also where we are. This is grasping the situation in lean problem solving.

In order to grow, a person needs to clearly see the gap between where they are and where they need to be. Gaps exist in every aspect of life: our performance, capability, trust, understanding, comfort level, alignment, teamwork, leadership – the list is endless. To see these types of gaps clearly, the level of perception we’re talking about requires a new degree of self-awareness, non-judgment and neutrality. If we want to really “go and see” to understand and grasp the current situation deeply, we must develop greater self-awareness in ourselves and coach others to do so, as well.

To develop an ability to see what is really happening and accept things as they are is more difficult than it sounds. In fact, very few of us experience this degree of mindful awareness more than a few times in our lives. Think back to a moment when time seemed to stop, and you were totally absorbed in the present moment. You were all there with no distracting thoughts or mental commentary. Things appeared to be more vivid; sounds and smells felt more acute. This often happens in times of great wonder like the birth of a child and at times of great peril like a near-death experience.

The key element which enables us to know what is really happening versus what we think is happening is mindful self-awareness. The difference between these two states of mind is enormous – it is the chasm between our prejudgments and unconscious bias, and the actual facts of the situation. In PDCA problem-solving, we are taught to continually grasp the situation and reflect on where we are in the process. Each step of the way we ask questions such as: “What is happening?” “What should be happening?” “How do actual outcomes compare to my expectations?” “How do my actual behaviors compare to my intended actions?” “What surprised me?” “What can I learn from all this?”

The answers to these questions require curiosity, insight and honest unvarnished perception of what truly exists—and not what we assume or hope is there or needs to be there. I once had a coach who called this “brutal honesty.” It was brutal because we had to face the unembellished reality however painful it might be.

The key to mindful problem-solving is pausing long enough to ask questions such as:

  1. How do we know what we know?
  2. How much of our thinking is based on evidence?
  3. How can we validate our understanding?
  4. How can we be curious about what we don’t know?

An Example 

I was recently coaching a group of highly-skilled project managers who were concerned that their performance measurement system was no longer aligned with the business. They felt disconnected with the rest of the organization and believed the measures were driving wrong behaviors.

Here is an early version of their problem statement:

The current metrics system doesn’t drive the right behavior resulting in the lack of problem-solving and inconsistent team behavior and focus.

The team was quick to suggest “solutions” ranging from developing new metrics to adopting whatever metrics were in use by the business. I asked them how they knew this was a problem. They responded by saying, “we are not supporting the business,” “there is no alignment,” and “we are not driving the right behaviors.” I felt the team was caught in a loop that looked like this:

I asked the team what the impact of no support, alignment, and wrong behaviors was. They struggled for a while to answer, so I followed up with, “how do you know the impact is negative and to what degree?”

That question seems to trigger a moment of clarity as someone responded, “our project delivery metrics have been dismal for over a year!”

Another team member asked, “so are we saying that our current metrics system is causing our poor performance? If so, what can we do to prove it?”

At that moment, I could feel the collective awareness of the team shift. It was like they were all waking from a dream. They let go of the original problem statement loop they had been stuck in and moved on to the freedom of a new way of looking at the situation.

Their next problem statement was based on curiosity:

Current project delivery performance is significantly underperforming. Over the past year, our blended performance has been at a 62 while our target is 90. The business impact has shown up as late project launches, cost overruns, and lack of promised functionality. Estimated business value of this performance gap represents hundreds of manhours and as much as four million dollars annually.

Note how the team’s second problem statement does not assume a cause (the metrics system) nor suggest a solution (fix the metrics system). It also focuses on a gap (blended performance metric) and not symptoms (lack of alignment and bad behavior). At this point the team is attempting to see the reality of the situation and identify what they need to learn to understand cause and effect.

The current state section of the A3 is waiting for them to dive deep into the symptoms and detailed characteristics of the problem. After performing this work, the team may discover the need to modify their problem statement again. That is a good sign. Changing your belief based on new evidence and learning is a wonderful thing (and the essence of PDCA)!

If we fail to develop our self-awareness, we are sentencing ourselves to life in a prison of our own making. It may be comfortable to see the world in a way that confirms our limited and current  beliefs, but this safe perspective prevents us from gaining access to the underlying truth of what is really happening. This path of comfort comes at a cost—we miss the insight, the breakthrough and the joy that comes from seeing deeply what is real and responding to the facts.

As lean practitioners, we owe it to ourselves and to the world to honor the process, practice PDCA and engage the scientific method with deep respect and mindfulness. All we need to do is pause, become aware, practice, and persist!

Mike Orzen is a lean practitioner and coach who has been experimenting with lean, respect for people, mindfulness and coaching for almost 30 years. He can be reached at mike@mikeorzen.com.

 

 

 

 

Honor the Work of Others by Honoring their Work Experience

Comments off 541 Views2

Respect is less about how we feel about our people and more about what we do for our people!

So many work processes are performed “unconsciously” in the sense that they are done without a clear understanding of the key steps, degree of expected quality, how much time they should take, and how difficult the work should be. Beyond treating people well, respecting people is about being thoughtful and intentional about the work experience of the people you lead. When organizations leave work totally undefined, they leave it to each person to try to figure out the best way to do the work based on their own singular, personal opinion. This usually creates a chaotic mess.

Recently, I was working with a large tech company whose new customer onboarding process was a combination of tribal knowledge and make-it-up-as we-go work processes. After doing a thorough virtual “go and see,” it was clear to me that everyone was suffering, including the people doing the work and new customers who were shocked by the delays, uncoordinated communications, and the overall disappointing experience.

I asked the leader who I was working with, “What kind of a message do you think this sends to your people and your customers?” “We don’t really care about you!” was his reply. I think he nailed it… When work processes are left undefined and open to personal opinion, we send a strong message to people: “We accept the status quo, so do your best with our broken processes.”

When I am coaching leaders and team members, I often ask, “How long has this process been broken?” Invariably I hear, “As long as I can remember,” and “It’s always been that way,,. so we’ve learned to make it work.” But trying to make a broken process work means wasteful extra steps, mistakes, rework, interruptions, and highly variable flow of the work. It also means there is little stability around the time it takes to deliver and the quality that the customer receives. No one is happy; frontline workers live in fire-fighting mode while customers encounter a broad range of unpleasant purchasing and customer support experiences.

In response to the problem, we gathered a team to work on a rapid improvement effort around the new customer onboarding process, employing lean methods and tools. The team came together and worked so well that they completed eleven PDCA learning cycles across four A3s in a period of seven months. The results were amazing in terms of customer feedback and satisfaction, work performance metrics and teamwork!

The team celebrated briefly only to discover that improvement work was not a one-time effort. It became painfully obvious that the process for this and every other type of work needed to be adjusted and improved on an on-going basis in perpetuity! When I asked the leader and team members for key insight and takeaways from this experience, the common recognition was that:

  • Work processes need to be defined, shared, and honored by everyone doing the work
  • It was not enough to improve the work once; ongoing improvement was essential
  • Teams needed to be deeply involved in the improvement effort, but also needed support from their leaders and someone who knew lean thinking and practice
  • None of the other points really matter if the people who are doing the actual work do not feel respected by their leaders
  • The best way to show respect is to enable team members to improve their own work processes as a central element of their daily work

So what concrete actions can leaders take?

  • Go and See – spend time with your people doing the daily work on the front lines to understand what it is to stand in their shoes and do the work
  • Identify the core work processes that the team performs (just ask folks!)
  • After watching, asking, and observing, ask yourself, “Is this work process stable, commonly applied, predictable, and effective?”
  • If not, ask the team to answer the question, “What is the problem we need to solve?”
  • Create an opportunity for the team to hold an improvement event (aka Kaizen event) with adequate support and coaching for them to be successful. 

In short, honor the work of others by honoring their work experience. As a leader, when you take the time to deeply understand the challenges your team members face and the impact this has on teams and customers, you will demonstrate more respect for people while driving improved performance. This is a win-win for the customer, the team, and the entire organization.

Ultimately, it is not what you personally think or feel about the idea of respect that counts; it is about what you actually do to support your people. Demonstrate your respect for others by

Principles Systems & Tools – What Shingo Can Teach Us About DevOps

Comments off 2102 Views0

 In my last post, The Power of a Game: What I Learned from Facilitating the Phoenix Project Simulation, we explored how DevOps and Agile practices are built on underlying Lean principles that go back decades to a time before the Toyota Production System. When you look into the history of Lean, it is almost impossible not to encounter the great thinker Shigeo Shingo. Shingo worked closely with Taiichi Ohno(the father of the Toyota Production System) to advance Lean thinking while building the lean production system at Toyota.

As someone who attempted to apply Lean to IT long before DevOps came into existence, I have always said that DevOps is about creating an environment where it is safe to look deeply, question what is happening, think crazy things, experiment, and learn based on outcomes. Ten years ago, I was invited by The Shingo Instituteto serve as a teacher, coach and assessor. I had recently been awarded the Shingo prize for my book, Lean IT – Enabling and Sustaining Your Lean Transformation. What I learned from Shigeo Shingo’s writings heavily deepened my understanding of the role of Lean and flowin IT. These ideas are reflected in the Lean Enterprise Pyramid below and it’s amazing how effective they are with Agile and DevOps.

Principles & IT Excellence

A principle is a timeless universal truth that controls outcomes whether you believe in it or now. Think of it as a fundamental truth or proposition that serves as the foundation for a system of beliefs and behaviors. Principles govern consequences and outcomes – both positive and negative. “Create customer value” is a core principle in business success. If you don’t believe in customer value, or don’t deliver it, your prognosis is pretty bleak.

In Lean IT, I introduced some key principles that drive IT success (see the Principle Pyramid image).

Let’s begin with a working definition of DevOps – a mindset, tool set, and set of practices that combine software development and IT operations to shorten the development/operations life cycle to deliver small iterative features, fixes, and updates often and in close alignment with business objectives and value creation.

Consider the lean principles pyramid from a DevOps perspective :

  • Foundation principles build an intentional culture of trust, respect, focus and learning
  • Behavior ishow we show up and engage
  • Perspective is a fresh new way of looking at IT work
  • Flow is the outcome of effective DevOps in action
  • Capstone of the pyramid fosters a regenerative culture of trust, safety, experimentation, collaboration and innovation
  • Outcomes are higher quality IT solutions and services, in less time, with less cost with healthier teams!

For DevOps, Agile and High-Velocity IT of any flavor to be successful, each of these principles must be addressed. You can’t address them all at once, so I suggest beginning at the base while taking steps to enhance flow. If you focus on these two elements, respect for people and flow, you will always be progressing in the right direction!

Systems & IT Excellence 

Shingo defined a system as a collection of tools and tasks that are highly integrated to accomplish a specific outcome. The Shingo Model captures the important relationship between principles, systems, tools and results. It also supports three key insights which clarify how to achieve excellence in IT (or any organization). IT needs to get good and then continuously get better with its systems, tools and results (no kidding!). Understanding how these elements are informed and reinforced by principles is essential to making this happen.

The insights:

  1. Ideal Results Require Ideal Behavior
  1. Beliefs and Systems Drive Behavior
  1. Principles Inform Ideal Behavior

For DevOps & Agile, the Shingo Model provides a logical sequence for change. Put another way, what are the key questions we need to answer?

  1. What do the ideal behaviors of DevOps look like?
  2. A) What beliefs do our people have today and what beliefs do they need to embrace DevOps? B) What systems (think: work systems, procedures, policies and technology) do we have in place today, what behaviors do they drive and what needs to change?
  3. How can our understanding of lean principles clarify our understanding of question #1?

Take a moment and reflect on the role of principles and systems in your transformation. The more you ground your approach in the stability of principles, the greater your chances of success. If you or your organization does not truly believe in these principles, a conversation around which principles you do believe in would be a good place to start.

Please let me know if this is helpful and what obstacles you encounter.

Michael Orzen has been serving as a Lean coach and guide in the IT space for over 25 years. His passion for hi-velocity IT, respect for people, mindfulness and continuous learning have made him a highly sought adviser and coach to many IT leaders. He lives in Portland, Oregon and can be reached at mike@mikeorzen.com.

Show Respect, Psychological Safety and Social Neuroscience

Comments off 3170 Views0

The focus of our work and teaching in recent years (Mindful Coaching, Helpful Coaching, Leading with Respect, Humble Inquiry Questioning, Coaching for Development) has led us to three questions we believe are critical for the Lean/ Continuous Improvement community to consider:

  1. Why would a practical business leader like Fujio Cho make “Show Respect” the third part of his advice to leaders?
  2. What is “Psychological Safety” and how does “Show Respect” help create it?
  3. What does Neuroscience research indicate about the link between “Show Respect” and “Psychological Safety?”

1)  Why “Show Respect?

Mr. Cho urging leaders to “Go See” and “Ask Why” makes sense as part of basic Toyota problem solving thinking. You want to grasp the actual conditions rather than assume you know, and you want to dig down to the underlying causes of problems rather than put band-aids on the symptoms. But why is “Show Respect” so important for Mr. Cho? Is it just because he’s a nice guy? (The team members at the Georgetown Toyota plant in Kentucky certainly felt he was when he was president there.)

We believe there is a practical business reason why Mr. Cho stresses the importance of leaders showing respect for employees. And it goes beyond the focus Toyota puts on the employees who do the work that creates value for its customers. Remember that when Mr. Cho was President and CEO of Toyota Motor Corporation (all of Toyota world-wide) he led creation of the first authorized description of the Toyota Way. Images such as the one shared above are often used to illustrate the key elements of the Toyota Way.

In most depictions of the Toyota Way, the fundamental values or pillars are the same, Continuous Improvement and Respect for People.

Mr. Cho was being very practical in his focus on “Showing Respect” as a critical management and leadership practice. If Continuous Improvement is the pursuit that helps a company solve problems, improve performance and adapt to challenges of change, Respect for People is the key to engaging employees in continuously making and sustaining improvements that makes it work. A company cannot afford enough managers, supervisors and specialists to address all the small things that need to be improved to maintain smooth flow and effective operation. The employees who do the value creating work have to willingly take on that responsibility. Employees who do not feel respected for their knowledge, capabilities and contributions are not likely to make the effort to go beyond assigned tasks and responsibilities very often.

Many in the LEI community who are involved in trying to overcome the obstacles in the cultures of their companies and engage employees in continuous improvement as part of their jobs have intuitively recognized the importance of leadership “Showing Respect” for their efforts. But we have not been successful in demonstrating to leaders and executives how their traditional management thinking and behaviors undermine their desire for the benefits of employee engagement. We hope to provide a first step toward making the case with this article.

2) What is “Psychological Safety” and how does “Show Respect” help create it?

The freedom to be yourself without fear of judgment is, in our opinion, the most significant obstacle to creating a culture of deep learning and continuous improvement.

In virtually all organizations, physical safety is a given. Most governments protect workers from the risk of accidents by enacting laws and regulations covering building codes, fire safety, ventilation, hearing and eye protection, gloves, hard hats and steel-toed boots. And most companies have programs that stress the physical safety of their employees. But there is another kind of safety that is just as critical as physical safety. It is psychological safety and we believe it has an incredible impact on an organization’s culture and the way people behave and think about their work, their colleagues and the interdependent aspects of their jobs.

In her new book The Fearless Organization, Harvard Business School Professor Amy Edmondson defines psychological safety as “the belief that the work environment is safe for interpersonal risk taking. The concept refers to the experience of feeling able to speak up with relevant ideas, questions, or concerns.” This quality is invisible, seldom managed well and, when neglected, highly influential on employees’ understanding of their role and place in their companies.  The critical question is, do employees feel it is a reasonable personal risk to speak up or not just go along?

Why is psychological safety so difficult to foster and maintain? There are many factors, but perhaps the most significant one is the way our brains are wired. Most people crave positive recognition and appreciation while avoiding criticism. We tend to be very concerned about what others think of us. We are often overly reactive to negative feedback and those who disagree with our ideas. (More on why this is so in Part 3: What does Social Neuroscience research indicate about the link between “Show Respect” and “Psychological Safety?”)

For people to engage at a much deeper level, they must feel instinctively comfortable being themselves and sharing what’s inside (ideas, concerns, ambiguities, unknows, uncertainties, hunches, etc.). This may seem obvious, but when we cannot be ourselves, we expend most of our attention protecting our image rather than engaging in meaningful dialogue! We are careful with our words, don’t talk about mistakes and withhold information – all with the purpose of managing what others think about us! This takes an incredible amount of energy and focus. The effort drains us of the spark we need to be creative, be open-minded, hear dissenting ideas and process tough feedback.

In her numerous studies of high performing teams Edmondson learned another fundamental aspect of psychological safety: it’s primarily local.  The social environment in teams and groups can vary widely across organizations. The overall culture in an organzation is a factor but it is the sense of safety within a group that is the main influence on how willing members are to speak up and speak out. And the greatest determinant of the sense of psychological safety in a group or teams appears to the behaviors and assumptions (i.e. leader knows, decides, tells) of the leader. What the leader does, does not do, expects and will not accept sets the time for the team. Edmondson’s findings are supported by a two-year Google study of performance and work environment of a 180 teams (Project Aristotle). The local leader is the primary source of members’ assumptions about the balance between fear versus safety that infleunce their sense of what is and is not a reasonable personal risk.

Continuous improvement is more difficult than anyone seems to want to admit because it’s continuous! This requires amazing reserves of drive, passion and stamina to persevere through the inexhaustible challenges, countless iterations of trial, discovery and learning, and the inevitable failures that must be embraced if we are to learn, improve and make meaningful change.

Without psychological safety, a team, a department and an organization are severely handicapped because they are deprived of the full contribution each person has the potential to provide. With psychological safety, people share everything they have to give, and everyone – and the company reap the benefits.

3) How are “Show Respect” and Psychological Safety linked?

In keeping with basic lean thinking let’s look beneath the outcome of Psychological Safety for the human processes that create or destroy it.

Neuroscience research has made significant gains in understanding the things that happen in the structures of our brains during different human activities. Using functional MRIs available since the 1990s it is possible to observe what happens inside the brain during both cognitive processing and social responses. Functional MRIs show movement of blood in the brain which indicates neural activation. In other words, neuroscientists scientists can now see which parts of the brain are engaged in specific brain activities. These insights demonstrate how respect and trust contribute to a sense of psychological safety and how their absence makes us afraid of taking risks in social situations.

Physical pain and painful social situations activate the same pain neural network and in much the same way. When we have physical injuries or experience social pain such as rejection, humiliation, embarrassment or criticism our brain reacts to them with similar physical sensations and emotions. That means we experience emotions and social pain in and with our bodies.

As an example, please close your eyes and think of a particularly embarrassing or humiliating moment in your teen years. How does your body respond? Most people experience a physical reaction such as a tightening stomach, flushing, tingling or tightening in the face, a feeling of distress. Many jerk their heads or bodies to try to shake off or get away from the feelings. The later is a flight response because your threat network has also been activated also and you experience the memory as a danger to you socially. Also consider how we describe the impact of such social situations: “I was crushed.  She broke my heart.  It was a real blow.”

Outright rejection of us or our ideas; angry or harsh criticism (especially in public), exclusion from an ingroup or inside information, the humiliation of a public put down, being discounted, disregarded or taken for granted, and being bypassed through favoritism all trigger some form of pain reaction in our bodies and some degree of feeling unsafe or threatened. Over time, experiencing these “social injuries” or seeing them inflicted on others creates impressions of “that’s what to expect around here.” Over time those impressions become unstated assumptions and form our unconscious recognition, and that of our group, of the culture of the company or organization.

Such an implicit understanding of our work environment is critical because it leads to other assumptions about whether it is safe to speak up, make suggestions, point out problems, disagree with management and your peers.  If we do not feel we can risk speaking up, stepping up, reaching out, pointing out and suggesting it is very unlikely we will commit much continuous time and energy to addressing problems and working on improvement.  If we do feel safe and respected and valued for our capabilities it is much more likely we will see it as a reasonable risk to exercise discretionary effort (meaning to go beyond what can be required or demanded) and willingly engage in continuous problem solving and performance improvement.

There is another important aspect of the brain activity related to our social lives. Pleasant physical and social experiences also activate the same reward network in our brains. That means when we sense we are included, valued, useful or given meaningful responsibility it is not just an idea, it is also a pleasurable and rewarding physical experience. Think of expressions we use to describe these moments: “Helping him warmed my heart. It gave my spirit a real lift. I felt 10 feet tall when she handed me the award.” The implication is that what we are experiencing is both physically and socially rewarding. Our human need to feel connected and accepted is being met. This makes it much more likely that we will feel safe exercising our discretionary effort and willingly take responsibility for contributing and making things better.

The equation for Discretionary Effort is simple but getting it to add up is difficult:  Respect + Acceptance + Trust = Psychological Safety.

Mr. Cho was right about the importance of RESPECT. Rodney Dangerfield complained he couldn’t get any. Aretha Franklin demanded it. According to researchers, acceptance, trust, respect and being useful were originally critical to our survival because they meant inclusion – and safety – in the family or social group. In our brains they are still essential in our new “families” and “communities” – our companies and organizations. Without this social “security” we don’t feel we can take the risk of contributing aswe are able. When respect is not demonstrated and a sense of psychological safety is not part of the culture, we are destined to see struggles such as many companies are having engaging employees in continuous improvement activities and sustaining their involvement.sustaining their involvement.

A collabroation with my good friend David Verble.

The Amazing Power of a Game – What I learned from facilitating The Pheonix Project Simulation

Comments off 2005 Views0

I recently had the opportunity to become certified to lead a simulation based on the best-selling IT book The Phoenix Project. When I went through the training, it was apparent that the developers of the simulation had created something very special. The Phoenix Project simulation is not a product as much as it is an experience. The realistic scenarios, challenges and pain points embedded in the game created a creative tension in a safe environment and allowed everyone (including me) to discover new insights into applying DevOps to improve flow throughout the value stream: from the business request through IT and to customers!

DevOps and Agile practices are built on the back of Lean principles that go back decades to before the Toyota Production System. As someone who attempted to apply Lean to IT long before DevOps came into existence, I have always said that DevOps is about creating an environment where it is safe to observe, experiment and learn based on outcomes. I was fortunate to meet with Gene Kim many times while he was writing The Phoenix Project. We always talked about lean thinking, lean systems and lean tools. Those discussion eventually morphed into The Three Ways – the core principles of DevOps!

Alignment with the business changes the feel of work

The simulation put people in a position where It was easy to see and feel the impact of not being aligned with business and not being coordinated with all the elements of it (AppDev, Engineering, IT Ops, Change Management, etc.). In each round the team was able to reflect and learn from the experience and experiment with new ways of working. What we all experienced was profound: the DevOps principles, systems and tools are effective only when the team directly experiences the frustration of a broken work system and works together to see, understand and act.

What was amazing to see was how quickly people took on the personas of the functional tole they had been assigned. The woman who took on the role of Retail Operations (you may remember Sarah in the Phoenix Project) became rather aggressive as she demanded results. The CISO (John in the book) constantly nagged people about SOX-404 issues. And of course, the CEO was a royal pain on everyone! Although we all knew this was a simulation game, everyone reported the stress and tension they felt as we embarked on round one with no real plan of how we were going to transformto a DevOps team.

You can’t improve what you can’t see

 What became instantly apparent among the chaos of trying to get the work done was that the team had no visibility of all the work nor priorities. True to life, there was more work that our people could handle so we needed a way to see the work, compare it to our capacity to do the work, identify trade offs and then work with the Business and other stakeholders to set priorities. Once the team was able to accomplish this (through some trial and error) we all could feel the alignment of purpose, see the smile on peoples’ faces as we created value and feel what collaboration between silos is really like.

 This discovery was just the tip of the iceberg. As a coach and facilitator, I was able to ask the team questions that positioned them to reflect on what had just happened and see within themselves additional changes that needed to take place to improve the quality, speed and volume of our deployments. Some of the other topics which were experienced and later expanded on include:

  • A recipe for coordination among silos
  • Making time for improvement, learning and technical debt
  • DevOps without Value Stream Mapping can be hazardous to your health

I’ll share some thoughts on these topics soon.

At the end of the day, DevOps is about creating an environment where it is safe to observe, experiment and learn based on outcomes. The Phoenix Project Simulation creates an environment to give everyone that experience. From there, they return to work and begin their journey.

 

 

 

Change Fatigue, Psychological Safety and the Leadership Void: Why Most CI Initiatives Don’t Last

Comments off 1616 Views0

Continuous improvement has been around for decades, and yet there are few examples of organiza- tions that have successfully created a lasting culture of problem solving, learning, and improvement. Many books, blogs, and workshops are available on these topics, and there is no shortage of resources on the tools and techniques of Lean process improvement. We understand the mechanics of improvement, but stumble when it comes to connecting with people so they engage and participate.

What are the factors that hold people back from investing themselves in a culture of continuous im- provement? For many years, I have served as a coach, trainer, and consultant to numerous organizations across many industries and have consistently encoun- tered three key barriers to creating a new normal, which includes daily problem solving, employee initia- tive, and higher levels of participation.

In a CI culture, improving the way we work is more important than doing the work! Most people spend their day doing their work and view improvement as an optional “when I have time” activity.

Change Fatigue

Over the years, multiple programs have been rolled out (e.g. Lean, Six Sigma, Operational Excel- lence, Agile, TPS, Total Quality, etc.) with prom- ises of making work less chaotic, creating work- life balance, and making things better. While these initiatives are well-intentioned, over time people be- come exhausted with the new “flavor of the month” and no longer get excited about the envisioned benefits of process improvement.

Psychological Safety

People need to feel comfortable sharing their thoughts, expressing when things are not working, discussing problems, asking for help, making suggestions, and even disagreeing with the way work is done. It is not easy speaking up when one feels it is risky to disagree with their boss, question current policy, or simply ask why something is done a certain way. The freedom to ask “What if ?” is not something most of us are com- fortable doing when we are not certain where the con- versation will lead.

Here’s the key: it is precisely this level of safety we all require before we will step out and speak up. The engagement and participation that is so crucial to a CI cul- ture will only develop in an environment of psychological safety and nowhere else. Improvement requires learning, learning requires experimenting, and experiments seek to better understand cause and effect. The process starts by asking questions. But no one will ask questions or speak up if they feel it is unsafe.

Leadership Void

Leaders, managers, and supervisors set the tone of the workplace and must model the behaviors necessary for a CI culture to grow. Yet all too often, they unintentionally do the very opposite. Leading with Respect is a collection of specific leader behaviors that create an authentic con- nection with people to develop a background of mutual trust. Trust is the basis of all relationships. It is the glue that makes a team a team.

Building a great organization requires effective leader- ship. A key element that is often misunderstood is what it means to lead with respect. This involves awareness of a leader’s focus and intention and how well the leader con- nects with people to create an environment of mutual trust and sustained high levels of performance. This is accom- plished through the application of seven core practices. We’ll explore why leading with respect is essential in a suc- cessful transformation, what respect looks like in practice, the seven core practices, and how they impact people to drive lasting change for the better.

The Third Way of DevOps: Stacking the Cards in Your Favor

Comments off 1580 Views0

This post was written for DevOps.com

In the first bit to this  post, “The Third Way of DevOps – From Knowing to Being,” we shared our thoughts on effectively applying knowledge to put the Three Ways of DevOps into practice. This blog explores a complementary dimension: How to build confidence when faced with a seemingly impossible task.

This is the all-too-familiar setting. You’ve seen an opportunity to improve things and genuinely want to do something about it. But you soon feel the clarity and anticipation draining out of you. First there’s the pressure of the day job. Then there’s the inertia of your co-workers, who are oblivious of or indifferent or hostile to your ideas. And finally, as if these concerns weren’t enough, you’re faced with the difficulty of unlearning old habits and developing new ones. In short, you don’t take action on what you have learned and know.

Self-efficacy

Expressed in the somewhat abstract language of the theories of Planned Behavior and Reasoned Action, there’s a gap between behavioral intention and actual behavior. A plausible explanation for the gap is low self-efficacy, defined as the conviction that one can successfully execute the behavior required to produce desired outcomes. It’s the belief we have in our own abilities, specifically our ability to meet the challenges ahead of us and complete a task successfully. This is a crucial precondition because investigations have shown that peoples’ behavior is strongly influenced by their confidence in their ability to execute that behavior.

If-Then-Else

So why doubt your ability to change? Well, when a change seems large, the gut reaction is to feel the need to come up with a project plan. Because a plan creates the confidence that when the steps are taken, the desired results will be achieved. Without a plan, we’d be irresponsible risk-takers. That’s how we’ve been taught to think. And rightly so—at least, in a predictable environment, where you can determine which steps will have which effects. If you work with IT, you are likely to think in terms of If-Then-Else. This is how we would like to believe IT always works. Predictably.

If-Then-Maybe

However—and this might be the biggest “however” you’ve come across for a while—things are not always predictable. Not unpredictable in the sense that it should have worked but something just went wrong because we didn’t do enough homework; unpredictable as in simply unknowable. Unpredictable as in possibly seeing a pattern of behavior in hindsight, but never having been able to predict it, let alone control it. Unpredictable as in “complex adaptive systems,” as they are referred to in the world of complexity thinking. It’s no longer If-Then-Else; the name of the game is If-Then-Maybe.

Complexity Thinking 

Complex adaptive systems are all around us but if you’ve been used to thinking that things are—or could or should be—predictable, you tend not to see them for what they are: one of kinds of systems that exist in nature. The Cynefin sense-making framework describes systems in terms of five domains: obvious, complicated, complex, chaotic and disorder. Obvious and complicated are both predictable domains, where something in the complicated domain needs a bit of work to discover the predictability than when it is obvious. Complex and chaotic are unpredictable domains, the main difference being that something chaotic is dangerously unpredictable and therefore needs direct action. There is a fifth domain: disorder. You are in this domain when you don’t know which of the other four domains best describes the current situation. A word of warning: People’s cognitive bias will often lead them to think that they are in their usual domain, in which they feel most comfortable.

Step by Step 

The way to introduce changes in complex systems successfully is to take it step by step. Because you can’t predict the results of a step, you have to closely monitor what effects—both desired and less so—each step creates. Then, based on your assessment of the new situation, you determine which next step to take. Rather than moving in a straight line toward a “to be” end state, you move each step to the “adjacent possible.” You make good use of the disposition of the system; in other words, where the energy is tending to flow.

No Big Answers, Just Little Questions

So, it’s not a case of looking for the big answer. It’s about a series of small questions. The Toyota Kata approach recommends asking ourselves (and others) these questions:

  • What are we trying to achieve?
  • Where are we now?
  • What obstacle is now in our way?
  • What’s our next step, and what do we expect?
  • When can we see what we’ve learned from taking that step?

A key concept is that we should work towards the next “target condition.” This is an interim goal on the way to whatever we want to achieve. It just describes where you want to be next, not how to get there. It labels the future set of circumstances that lie just beyond our current level of understanding. It will typically have to be achieved between a relatively short period between a week and a few months; otherwise, it will be ineffective. How we will get there will emerge though the process of experimentation.

Stack the Cards in Your Favor 

So the next time you feel inspired to make a (little) difference, don’t be discouraged by the prospect of having to think everything through in detail. This is often even contra-productive. The liberating realization that you can take things step by step, is good for your self-efficacy, increasing the chances of actually achieving results.

This article was co-authored by Mark Smalley.

The Third Way of DevOps: From Knowing to Being

Comments off 1208 Views0

This post was written for DevOps.com

Why is the Third Way of DevOps so difficult to master?

We all know the feeling. You’ve seen an opportunity to improve things and genuinely want to do something about is. But you soon feel the clarity and anticipation draining out of you. First there’s the pressure of the day job. Then there’s the inertia of your co-workers who are oblivious of, or indifferent or hostile to, your ideas. And finally, as if these concerns weren’t enough, you’re faced with the difficulty of unlearning old habits and developing new ones. You wonder why you bother. In a way, it’s a bit like a lottery: You buy a ticket fully knowing that the odds are stacked against you, but it’s the worth it for the uplifting short and illusory dream that it might just happen.

This is, of course, all about the Third Way of DevOps—creating a culture that fosters two things: continual experimentation, which requires taking risks and learning from success and failure, and the understanding that repetition and practice are the prerequisites of mastery. It all sounds great in theory, but why is it so difficult to put into practice?

Information Abundance  

It’s not due to lack of knowledge and skills. We have more information available to us and more easily accessible than ever in the history of our planet. We can thank technology for that. But has it really made us more effective at what we do? If I know something and don’t apply it, how is that so different than not knowing it at all? If I know how to read but choose not to, how is that so different that not knowing how to read? If I don’t use what I know, how long will I retain it and how will I integrate it with the other things I know? Most importantly, can and will I apply what I have learned to make things better?

Lifelong Learning 

We have been learning and studying all our lives in an attempt to make things better: our ability to understand IT, frameworks, methodologies, capabilities, practices, work processes and, of course, tools. Consider how many thousands of hours you invested in school, self-study, read out of curiosity, listen to podcasts and do work-related training and certification. Most of my friends proudly describe themselves as “lifelong learners” and one claims the day they stop learning shall be the day they die!

Training in Skills

We’ve also invested considerable time and effort into improving ourselves so that we may work more effectively with others: communication skills, teamwork, shared rituals, structured problem-solving, leadership and coaching all fit into this category. Who (in IT) has not been a part of some Service Management, Lean, Agile, Scrum, Kanban or DevOps training? After all of our training, you’d think we’d be further along than where we find ourselves.

Knowing and Understanding 

Knowing and understanding are not the same thing—I can know the Four P’s of IT Service Management (People, Process, Products and Partners), yet not view it as a lifecycle model and understand that to obtain the benefits of this knowledge, my team must determine the roles of people and objective of work of processes and then implement tools to automate the processes enabling people’s roles and tasks.

Understanding and Doing

Nor are understanding and doing the same thing—I can know that structured problem solving is based on the scientific method and can be broken down into four stages (Plan, Do, Check, Adjust). I may also understand that structured problem-solving is preferable to the reactive educated guesswork my team engages in whenever it encounters a problem. But if we do not change our behavior when it comes to problem-solving, our understanding will not manifest as action.

Doing and Being 

Neither are doing and being the same thing—I can be doing something and still not have internalized it so that it becomes who I am. I can know the core principles DevOps (engage in systems thinking, amplify feedback loops, foster a culture of experimentation and learning). I may understand that all three principles must be applied to foster a sustaining DevOps environment. I may be even be holding initial planning sessions with my team during which we map out the DevOps value stream, identify bottlenecks, create feedback loops and introduce changes to create a create a culture of experimentation and learning.

Moment of Truth 

But what happens when we meet with our next P1 incident? Does the knowing, new understanding and behaviors get tossed aside while we fix the problem, or do we hold fast to the new way of doing things as we grapple to not only remediate the incident but to view it within the context of DevOps?

So, What’s a Person To Do?

The velocity and degree to which we can move from knowing to being determines how effectively we can apply what we know. Here are a few things you can do to smooth the transition from knowing to being and help put the Three Ways of DevOps into practice:

  1. See and feel the potential impact from moving beyond knowing to being
  2. Use the uplift to get motivated
  3. Take action by changing something within you and your team’s circle of control
  4. Reflect on the fact that you have realized potential (this is very powerful when you share it with your team)
  5. Check and adjust based on the outcomes of step #3
  6. Allow the feedback from the previous step to motivate you to carry on!

Curiosity and Humility

This approach requires a certain attitude. One of curiosity and humility. You need to be inquisitive so you keep striving to understand. And you also need to be unassuming and you see yourself as having plenty of room to learn and grow; being deeply (almost obsessively) interested in what’s going on and how things could be improved; trying to be aware of and to set aside any preconceived ideas—adopting a beginner’s mind.

To Be Continued …

In our next post, we’ll explore specific steps you can take to leverage The Third Way of DevOps and make tangible progress based on what you know and don’t know, understand and don’t understand, and do and don’t do.

This article was co-authored by Mark Smalley.

  • Page 1 of 3
  • 1
  • 2
  • 3