All posts by Chris Alexander

Psychological Safety ≠ “Be Vulnerable”

Psychological Safety has (finally) entered the mainstream discourse in business communities. Particularly in the world of #agile and #agile_coaching, it is a topic I hear referenced with increasing frequency and conviction. There’s just one problem.

Most people have no idea what it actually means.

Through various discussions, online and in person, in sessions at Agile meetups, and at numerous conventions, I’ve listened to agilists and consultants preaching the importance of Psychological Safety whilst touting the research which was surfaced by Google through Project Aristotle (though pioneered by researchers like Amy Edmundson).

Yet most managers, consultants, and agilists have embraced the concept of Psychological Safety without understanding the context of the term. Instead, the term Psychological Safety is often equated with the idea of “being vulnerable with your team.” Agile Coaches and Scrum Masters, focused on achieving that Holy Grail of coaching – building a high-performing team – are in the process of co-opting the term “Psychological Safety” to mean “intra-team-member trust.

Please. Stop.

Trust within a team is certainly a fundamental and vital characteristic to develop; absolutely no question there. Team members working together need to understand one another, trust in each other, communicate, collaborate, innovate, problem-solve, make decisions, implement, improve, learn, and produce together effectively. Trust is fundamental, and team trust is an important component of Psychological Safety.

Part of building that trust means, yes, taking some (perceived) interpersonal risk. Examples of perceived “risky behavior” in this area of interpersonal trust-building within a team might include:

  • Asking questions, which risks evidencing a perceived lack of knowledge, awareness, or understanding;
  • Questioning assumptions and/or voicing opinions, which risks challenging social and sometimes formal hierarchies and upsetting power relationships;
  • Admitting mistakes, which risks appearing like an under-performer at best, or incapable and incompetent at worst;

The point is, these sorts of things are clearly trust issues, but we have a word for these issues: trust.

What, then, is the difference between Trust and Psychological Safety?

Trust in this story is inter-personal and intra-team, which means it has to do with the degree to which individuals within the same team believe in the reliability, credibility, ability, and intentions of their teammates. We certainly cannot build an environment of Psychological Safety without Trust.

Psychological Safety, on the other hand, refers not only to the degree to which team members trust one another, but also to the environment (external) in which the team operates. In fostering intra-team trust, the team is neither attempting nor able to affect the external environment in which the team operates (the business or organization, its culture, explicit and implicit rules and processes, explicit and implicit structures and hierarchies, norms, values, etc.).

The environment in which the team functions will ultimately have the greatest effect on Psychological Safety. Regardless of how much team members trust one another, if the team operates in an environment which is hostile to open and honest communication, punishes individuals and teams for mistakes, or engages in or encourages retribution for perceived protocol infractions, slights, or failure to follow dogmatic processes, all the trust in the world isn’t going to develop Psychological Safety.

Psychological Safety

What does build Psychological Safety?

First and foremost, lead by example. The truth is, and there is ample social and cognitive psychological research to prove it, that people follow – and imitate – those they identify as leaders. The basic fact of our humanity is that when we perceive someone as “doing well,” we emulate those aspects of their personality and habit which we interpret as contributing to their success. We follow them (social media, online, print, at conferences and expos, etc.) and watch what they’re doing, and what they’re saying.

How this plays into Psychological Safety is simple. If you’re in charge of a team, department, or organization, and you want people to admit to (and learn from) mistakes along the way, start by exemplifying that behavior. Walk into meetings and start admitting the last big mistake you made, what it meant, and what you learned from it and plan to adjust in order to do better, next time.

Yes, it sounds crazy, but the first step is admitting your own fallibility and creating a culture in which it is okay to do that very thing. Re-framing failure as a learning opportunity, which is the central theme of The Lean Startup (by Eric Ries), you’re showing everyone around you that failure – and owning up to it – is perfectly fine when it is followed through with thoughtful analysis, learning, and meaningful change or improvement.

Many people in leadership positions (note that I do not refer to them as leaders) are far, far too preoccupied with proving that they know what they’re doing and “getting it right,” to actually recognize whether they’re “getting it right.” This is what many refer to as a Performance Mindset.

Performance Mindset: I’m here because I’m the expert, I know what I’m doing, I’m not wrong, I don’t make mistakes, and my job (and self-image) depends on my ability to perform!

Those in leadership positions who possess a Performance Mindset are typically unable to admit mistakes or fallibility, and tend to directly or indirectly punish others for making mistakes and can be prone to rebuking those who challenge their positions or opinions. It’s tough to be challenged when your perception of self – personal and professional – is grounded in an image of expertise and infallibility.

Developing Psychological Safety in teams and organizations which are led by individuals (execs, directors, or managers) who are firmly fixed in the Performance Mindset is exceptionally challenging. I wouldn’t say impossible – I’d just say I have yet to see it done.

To be certain, there are environments in which a Performance Mindset is exceptionally useful, if not vital to success. One of the underlying principles behind Traditional (Waterfall) Project Management is in fact the manager or leader who has a Performance Mindset. For companies and organizations who operate in simple-to-complicated domains, the presence of experts who have developed vast amounts of experience and knowledge over the course of many years of work is invaluable.

Simple or complicated work streams lend themselves perfectly to the application of best practices or known-good practices. We just need experts who can apply their knowledge and experience to help us achieve predictable, known outcomes.

Now, let’s step into Complexity. Complexity is a domain in which causal connections are unclear or hidden. We can make observations and discern clear correlations emerging between events, but it is impossible to definitively prove a causal relationship between events.

Enter the Complexity Mindset.

Complexity Mindset: I’m here because I know how to enable teams and individuals to make observations, analyze goals, make decisions, execute, reflect and learn, take improvements, adjust, and iterate!

The opposite of the Performance Mindset is the Complexity Mindset. Leaders with this mindset (regardless of their designated position within a hierarchy) focus on clearly articulating a vision and intent while empowering their teams to execute with as much autonomy as possible. The ultimate expression of this mindset is a company or organization in which teams understand at deep levels what their objectives and constraints are, and guide their own execution according to those objectives and constraints.

A Complexity Minded leader not only empowers teams to execute according to principles of self-organization, but also encourages and rewards learning through both success and failure. When you don’t know how to get from A to B, mistakes will occur.

The Lean Startup is, at its essence, a prolonged essay on the execution of a Complexity Mindset. When developing a new product which we don’t know anyone will like or use, as we learn about aspects of the product people like or dislike, we’ll adjust to build more of what they like, and less of what they don’t like. If people don’t like the product at all, we’ll look for positive, leading indicators which may point us to new products which then will have a better chance of success.

We are learning, despite failures. Iterating on a product, observing its adoption, deciding what to change, changing it, and returning to observe (ODAO variant of the OODA loop), we have a much greater chance of succeeding.

Software companies like Google, Amazon, Facebook, Microsoft, and Apple do this often. Facebook’s Dislike button, Tay (the offensive AI chatbot from Microsoft), Windows Vista… you get the idea. Heck, with a roughly 90% failure rate, the entire startup scene in Silicon Valley is a fantastic example of attempting to navigate social, financial, and consumer complexity through experimentation.

The point is, companies never start out with an intent to fail or make mistakes and neither do your teams. Yet the simple fact of reality is that mistakes and failures do happen. Especially when trying to do something that’s never been done before, build something that’s never been built before, etc. A mature, resilient, learning organization knows that challenges and setbacks are inevitable, and is able to overcome and succeed.

What about responsibility and accountability?

I quite often hear this refrain. “If we don’t hold people accountable,” (a code phrase for punishing people for mistakes), “people will think they can get away with anything!” False. First, if you hear this come from a leader, beware. They have just given you an insight into how they think and how they would likely behave, if given the chance.

The truth is, the 99% majority of people, especially in knowledge industry work, are there specifically because they want to do a good job. Furthermore, yes, there are clear red lines in terms of performance and accountability. This is the difference between honest mistakes and negligence.

When Amazon Web Services went down recently, taking a considerably large portion of the internet with it, Amazon was incredibly forthcoming in sharing their root cause diagnosis and the fact of the matter was that someone incorrectly entered a piece of text specifying the amount of infrastructure to take offline. It was an honest mistake.

I once watched as a friend attempted to enter TTYL (talk to you later) into an SMS to his wife, which quickly auto-corrected the phrase to Tina. As we were on a business trip, it could have raised some pretty legitimate concerns from his wife’s perspective. Instead, he replied “sorry, stupid auto-correct – meant TTYL” and sent that, instead.

Honest mistake.

Now, let’s imagine a scenario in which a government worker with a security clearance decides to take some classified work home with him on a USB drive to continue reviewing at home. At home, he plugs in the USB drive and the malware on his computer instantly dumps that classified information out to Wikileaks.

This is not an honest mistake. There are federal regulations (laws) which guide the handling of classified information. Those laws (in our example) have just been broken.

This is not an honest mistake. This is negligence (or worse).

Negligent (or worse, outright illegal) behavior needs to be corrected, yes, and those engaging in it need to be held to account, perhaps outright fired. But the guy who incorrectly typed a command wasn’t being negligent – he made an honest mistake.

Honest mistakes we want to know about because they offer us great opportunities for improving our systems. For example in the AWS case – why was an individual able to take down such a large system without having to confirm their typed command entry? Why were they able to incorrectly type the command (don’t they have copy/paste, or a UI)? How could we have enabled the system to prevent this sort of outage, itself?

Conclusion

Can you tell I’m passionate about this stuff???

By now I hope you’re developing the sense that Psychological Safety in teams is not fully within the team’s ability to control. Management and leadership have a significant ability to control whether teams feel empowered to admit mistakes, learn from them, and make improvements, or hide mistakes, silo important knowledge and information, and leave systems (and the organization) to succeed or fail on their own.

To develop and enhance Psychological Safety in your complex workplace, leaders need to adopt a Complexity Mindset and focus on the following:

  • Own your mistakes. That manager at AWS who refused to take on the work to improve the automation around service outages because it seemed not worth the return on investment? They’d better be standing up right now and admitting that they made that call, it was a bad call, and that Amazon indeed needs to invest in improving their outage automation. The quote sounds like this: “It wasn’t the engineer’s fault for causing the outage, it was my fault for not allowing the engineering team to prevent an outage before it occurred. My bad. Can someone help me fix it?”
  • Support your people and your teams, especially when they make honest mistakes. Help them re-frame those mistakes as opportunities to improve systems, processes, practices, and skillsets, and then empower them to make those improvements.
  • Reward individuals and teams for sharing mistakes, challenging assumptions, questioning decisions and policies, and striving to find “better ways.” Public support and thanks are powerful signals that those are desired behaviors, and will get you more of the same.
  • Encourage open environments in which people can freely share issues, concerns, and admit when they aren’t sure about how to solve a problem. Ensure that people asking for help get help, not ridicule. A culture in which individuals pride themselves on showing everyone how smart they are is a culture in which no one admits when they don’t know something, leaving you blind to risks and pitfalls. A culture in which people feel empowered to ask for help – and then get it – in order to solve challenging issues and mitigate potential risks, is a culture which will build resilient, adaptable systems and organizations.

Agree? Questions or comments? Do you entirely disagree and feel that Psychological Safety is actually all about admitting vulnerability? Let me hear about it. If you don’t want to respond here in the comments, send me an email! I’m more than happy to hear from you, engage in constructive debate, and learn about where I have it wrong. Because I make mistakes, too.

By the way – thank you for reading!

 

This post originally appeared March 9th, 2017 on LinkedIn here: https://www.linkedin.com/pulse/psychological-safety-vulnerable-chris-alexander

Save

Save

Share This:

High-Performing Teams and Complex Algorithms: Things You Don’t Have to Figure out Alone

Personally, I can’t solve long division. I don’t do algorithms, logarithms, or any other “-ithms.” I strongly dislike even having to do my taxes (and I am married filing jointly with standard deductions, no investments, no special circumstances, and no complications). I’ll be the first to admit, I’m just not that smart.

What I am is self-aware. After years of training, learning about, working in, and teaching high-performing teams, I knew there had to be reasons – very good reasons – that our techniques, tools, and methodologies all worked as well as they did. I knew there had to be something about the way we worked and the way we trained which was grounded in something other than wild guesswork, happenstance, and luck.

Indeed, as anyone who’s operated in a high-reliability organization knows, you do the things you do for very clear, proven reasons. Often, you do them because other people have died to teach you the lessons your organization has learned, helping to increase its resiliency and robustness.

Developing high-performing teams is no different!

I encounter – daily – blogs, LinkedIn posts, articles, podcasts, papers, seminars, conferences, Meetups (you get the idea) about various aspects of developing and enhancing teams and teamwork. Some are interesting and useful, but the overwhelming majority are based on personal beliefs, ideas, conjecture, experimentation, luck, a bad experience, or any of a number of other subjective, introverted, well-meaning but ultimately wrong ideas.

Don’t misunderstand – these ideas come from really smart people who are giving their absolute best, but intentions do not equate to outcomes.

Why aren’t we hiring these same people to handle our home renovation projects, build our national infrastructure, or handle international trade and defense policies? Because putting in a lot of effort and working hard is different from knowing what you’re doing.

You may be a very dedicated, hard worker, but I prefer to have an actual plumber working on my home’s plumbing, thank you.

Unfortunately, for too many organizations around the world, this is exactly what they do in building teams. They have highly intelligent professionals who are skilled in management, process and portfolio stewardship, agile frameworks and methodologies, and any number of additional things. Yet what they are not studied, or skilled at, is team-building.

To make things worse, these well-meaning individuals also believe, wrongly, that just figuring this “team-building thing” out on their own is the best, most effective course of action. To those people I want to reflect back to my earlier admission that I know my limits. You need to realize that unless you’ve been raised in a culture of team performance and team-building or have spent considerable time studying it, you probably don’t actually know as much about it as you think you do.

Rather, there is an entire world of scientific research, based in empirical studies, and grounded in human social, behavioral, and cognitive psychology, industrial – organizational psychology, human cognition, sociology, and human evolution which informs us about the social, human-interactive skills which power team behaviors, performance, and effectiveness.

There are an abundance of knowledgeable professionals who have spent most of their adult lives studying, working with, and developing great teams.

However despite that fact, organizations, leaders, and managers continue to struggle through trying to figure these things out on their own. They read an HBR article, a few blog posts, and walk away thinking “I got it.” In technology we have a huge array of protocols, structures, frameworks, processes, methodologies, tools, etc., which are intended to somehow supplant or circumvent the real and necessary process of teaching teams and individuals the social teaming skills necessary to enable them to team together effectively.

Developing great teams is not a secret, miracle, or act of individual or organizational brilliance. The science and practice of team-building is based in the fundamental makeup that accompanies being human. Ensuring teams can develop, survive, and thrive, requires the following:

  • Right Environment. Teams need to have the support necessary to enable execution, which includes clear vision/direction, prioritization, and goal-setting from leadership, a culture which enables and rewards teaming, and the ability to identify and deal with things which threaten the team’s ability to achieve its mission or purpose. It also requires leadership and concerted inputs from other teams, as well, like Human Resources and Product Management.
  • Right Skills. Teams need to be trained in the skills which enable high-performance teamwork, and that training needs to be experience-based as well as knowledge-based. They need to learn from those who have lived it, and they need to be empowered to continually learn, grow, and improve those skill-sets. Training individuals is a critically important – and oft-overlooked – key to success. Most people are not born great team players, however as with any skill, the skills which enable effective teamwork can be developed and improved over time.
  • Right Process. A team is a group of individuals working together – interdependently – toward a common and shared goal. As such, they need to have a product which unifies the team members in pursuit of that common, shared goal, and toward which they can work interdependently. They need to be able to employ a process capable of supporting their product’s domain (simple/routine – complex – innovative), and they need to be able to realize intrinsic motivators through Autonomy, Mastery, and Purpose (a la Daniel Pink).

Most importantly, you don’t need to figure out how to develop and implement all of these things yourself, and unless you’ve spent your career studying teams, teamwork skills, and team training and development, you probably do not actually possess the knowledge necessary to successfully develop these skills in your teams.

This may seem a stark presentation of reality, and perhaps a bit harsh.

We all want to think we’re great team players and we know everything there is to know about training and developing the skills necessary for teamwork. However, unless you’ve been studying teams, teamwork, and skills, and can name specific social, non-technical, non-process-related skills which enable and enhance interpersonal communication, collaboration, and creativity, you probably aren’t that knowledgeable about what teams and individuals need to develop and enhance their teamwork. As I said in an earlier post – being able to recognize great art when you see it doesn’t make you a great artist!

Instead, you can leverage the knowledge and expertise of others whose professional existence is grounded in building and developing great teams. There are a large number of people across various industries who focus and work in exactly this domain.

Instead of trying to reinvent the wheel yourself, wouldn’t it make more sense to talk to a car manufacturer who can actually help you get where you’re going?

Rather than devising or borrowing lists of protocols and processes to help you get the behaviors you desire out of individual team members, wouldn’t it make far more sense to simply train them in the skills and behaviors they need to team together effectively, provide them feedback, and enable them to execute and succeed together? The knowledge to do so is out there, resident in professionals across various industries and academia. When you find yourself confronted with these sorts of problems, I’d recommend you do what the best leaders always do…

…find and engage the best people to get the job you need done, effectively.

 

Chris Alexander (that’s me) is a former F-14 Tomcat RIO & instructor, and co-founder of AGLX Consulting, where he co-developed High-Performance Teaming™ – a training methodology focused on teaching individuals and teams the social, interactive skills necessary to help them achieve high-performance. He currently works as an agile coach at Qumulo, Inc. in Seattle, Washington.

This post originally published on LinkedIn: https://www.linkedin.com/pulse/high-performing-teams-complex-algorithms-things-you-dont-alexander

Share This:

To Build Great Teams You Need a Plan, Not a Picture

Take a look at the painting below…

Vincent Van Gogh - Cafe Terrace at Night

Notice the way the painter (van Gogh, of course) uses color to create light and shadow, which helps add contour. He draws with perspective, which creates depth. Brush strokes create the illusion of texture, such as cobblestones on the street, or wood on the frame of the doorway. Figures and shapes create the impression of movement, action, and build a scene which our minds can easily interpret.  Now you understand some of the most critical elements in painting, right? So… now you should be able to paint a replica of this masterpiece, or at least be able to create something similar which is just as impressive and iconic.

Can’t do it? Neither can I. We can probably almost universally agree that one cannot simply be shown a great painting, told what techniques, brushes, paints, and colors the artist used in painting it, and then be expected to reproduce it.

There is a fundamental difference between knowing what one needs to do, and actually developing the skills and ability to do it.

Yet we are currently living through exactly this sort of coaching fallacy every day. All around us, thought-leaders, authors, managers, coaches, just about everyone – are deluging the internet with just about everything they can image about the characteristics and behaviors of great teams. For example:

High-performing teams deliver amazing results with high quality.

High-performing teams collaborate together to solve the most difficult problems with ease.

High-performing teams have a common purpose. They work toward shared goals.

High-performing teams manage inter-team conflict and are balanced.

High-performing teams celebrate diversity.

In fact, let me share a little collection of just some of the various attributes, characteristics, and skills found in various articles and publications about “how to build high-performing teams.” Spoiler alert! Like looking at a piece of art, this information doesn’t tell you anything about the things you need to do to start developing your teams toward high-performance. It just shows you a pretty picture of what awesomeness looks like.

characteristics_behaviors_and_skills_breakdown

So what? We, as individuals, managers, leaders – as a culture – are often far too focused on what things look like – great teams, great cultures, great companies, great innovation – and in trying to explain how incredible, amazing, wonderful, efficient, or effective that greatness is, we fail to consider or share with people the more important knowledge about how they can actually start to improve, themselves.

It’s the difference between showing someone a great painting, instead of helping them develop into a better painter. Or to use a sports metaphor, watching Messi and Ronaldo score goals doesn’t help me to become a better soccer player. To improve, I have to develop my own skills.

I suspect the harsh truth is that most of the enthusiastic authors who blog about and are so excited about high-performing teams have never worked in one, never led one, and never built one. Maybe they’ve seen one or two up close? I don’t want to detract from their exuberance, and I applaud the enthusiasm. Yet I also acknowledge the fact that people need more than pretty pictures to help them improve their own situations.

Fortunately, the skills that high-performing teams and organizations use to normalize greatness are skills that every individual, every team, and every organization can develop, too. Communication, collaboration, situational awareness, problem-solving, agility, leadership – even and especially empathy – are all highly trainable skills which empower the dynamic, human interactions and cooperation upon which great teams are built.

The knowledge and information needed to build effective, powerful teams is out there. It is grounded in decades of experience and scientific research in a multitude of fields across a diverse array of work domains spanning every industry. The teams which employ those skills work in the most demanding environments on (or off) our planet, solve the toughest problems, innovate, collaborate, and perform at incomprehensible levels.

To build great teams you need more than pictures and descriptions. You need a plan to train your teams and based on knowledge, research, and experience. That plan starts with the skills which fuel every kind of team, everywhere. Skills which are transcendent and universal because they leverage one powerful fact:

we are all human.

 

Chris Alexander is a former F-14 Tomcat RIO & instructor, co-founder of AGLX Consulting, High-Performance Teaming™ coach, Agile coach, Scrum Master, and is passionate about high-performing teams, teamwork, and enabling people to achieve great things.

This post originally published on LinkedIn: https://www.linkedin.com/pulse/build-great-teams-you-need-plan-picture-chris-alexander

Share This:

Psychological Safety is Just One Piece of the Larger Puzzle – Where Google’s Project Aristotle Missed the Bigger Picture

Google recently released the results of a five-year study, known as Project Aristotle, through which they determined that the common attribute – or what Google termed “key dynamic” – which successful teams exhibited was something known as psychological safety.

Unfortunately, Google’s expensive, five-year foray into teamwork is a great example of what can happen when technologists undertake studies in team and cognitive psychology, human interaction, sociology, and complex adaptive systems (among other disciplines), and base their findings entirely on self-collected metrics and their own statistical analyses of that data. What Google found was that psychological safety is a statistically significant attribute (key dynamic) associated with high-performing teams, but unfortunately this doesn’t tell the full story or help other teams or organizations to understand what they need to do to create those same conditions in their own environments.

I certainly do not want to impugn or belittle the considerable efforts or discipline of the team conducting Google’s study. However, I might have suggested beginning with a review of existing research in some of those disciplines (teamwork, sociology, human behavior, cognitive psychology, etc.) relating to team performance and teamwork. As it turns out, there is quite a lot.

In fact, so much that today there are meta-studies covering these topics. Among other critical areas not studied by Google, team performance is directly tied to the number and quality of social interactions between team members [1], the existence of Shared Mental Models within the team, shared expectations regarding behavioral norms (what we call Known Stable Social Interfaces), as well as organizational issues such as the leadership and management culture.

Which isn’t to imply that psychological safety isn’t important; indeed it is. Amy Edmondson in her book Teaming points out that psychological safety is of critical importance to effective teams:

“An environment of psychological safety is an essential element of organizations that succeed in today’s complex and uncertain world. The term psychological safety describes a climate in which people feel free to express relevant thoughts and feelings without fear of being penalized…In corporations, hospitals, and government agencies, my research has found that interpersonal fear frequently gives rise to poor decisions and incomplete execution.” [2]

Psychological safety is important. Yet psychological safety is not a team skill. For example, we can teach a team and individual team members to communicate more effectively using certain techniques and behaviors. Similarly, we can train a team to communicate in more assertive ways. However, we cannot train teams to simply “be psychologically safe.”

As Edmondson states in the quote above, “psychological safety is an essential element of organizations…” (emphasis added) – it isn’t a team skill or behavior.

This critical fact is where so much of the literature, and Google’s study in particular, come up short. Knowing that successful teams operate in an environment of psychological safety does not enable leadership, management, or coaches to build psychologically safe environments any more than looking at a painting enables me to paint a replica of it.

The real challenge is determining how one can mindfully, purposefully build a psychologically safe environment within an organization. To answer this question, we need to first understand what, exactly, psychological safety is. I define the term slightly differently than many textbook definitions:

Psychological safety is the existence of an environment in which individuals proactively exercise assertiveness, state opinions, challenge assumptions, provide feedback to teammates and leadership, while openly sharing mistakes and failures.

Many traditional definitions of psychological safety make use of the term “feel,” as does Edmondson: “The term psychological safety describes a climate in which people feel free to express relevant thoughts and feelings. Although it sounds simple, the ability to seek help and tolerate mistakes while colleagues watch can be unexpectedly difficult.” [3] (Emphasis added.)

However, I purposefully make use of the word “exercise.” Although this may seem a semantic difference at first glance, since we’re concerned with factors such as team performance, quality, and effectiveness, the existence of a psychologically safe environment in which no one actually admits mistakes or states opinions (although they feel free to) is undesirable. We need not only the environment, but also the actual actualization of the skills and behaviors necessary to realize the environment’s benefits.

How to build psychological safety in teams and organizations.

Although I’ve only glossed over the considerable amount of theory and research, I also don’t want to try to provide a Reader’s Digest version of decades of knowledge here. I’d rather get right to the point. What do leaders, managers, coaches, and teams need to do to purposefully build psychological safety in their environment, today?

First, significantly reduce the focus on processes and frameworks. The existence of a specific environment or culture is largely independent of the business process employed in an organization’s daily operations. Some frameworks and methodologies are structured to support the types of psychologically safe environments necessary to enhance team performance and effectiveness, but they do not guarantee it.

As Lyssa Adkins, author of Coaching Agile Teams, stated in her Closing Keynote at the 2016 Global Scrum Gathering in Orlando, Florida:

“I thought we would have transformed the world of work by now. People, we’ve been at this for fifteen years…Transforming the world of work is literally a human development challenge. So we are awesome, we are so good in this community at process and business agility. We’ve got that handled people, and we’ve had that handled for a while. What we’re not so good at, what I want to see us become just as great at, is human systems agility. Because that’s the other piece of it…You know, those organizations – they’re all made of humans, aren’t they? So, human systems agility is a piece of business agility. Not the only one, but an important one; and one that we’re not as good at.” [4]

Business processes and frameworks, including Agile systems such as Scrum and Lean, can only help create a structure capable of supporting the ways in which teams and individuals need to work to reach the highest levels of performance, effectiveness, and innovation. What those teams – from executive to functional – need, is a shared mental model, a Known Stable Social Interface for interacting and working collaboratively together, and which enables them to develop and exercise the interpersonal skills and behaviors necessary for psychological safety.

Leadership and management must initiate the formation of a psychologically safe environment by welcoming opinions (including dissent) on goals and strategies from peers and subordinates. People in management or leadership roles who fear questioning or are more focused on their ideas than on the right ideas need to either learn, adapt, and grow, or move on. They are obstacles, roadblocks, and hindrances to organizational effectiveness, performance, and innovation.

Steps leadership and management can take to start to create psychological safety:

  • Establish and clearly communicate expectations
  • Receive training themselves
  • Provide training for their employees
  • Ensure follow-through with dedicated coaching and regular check-ins

Then, learn about and employ the following behaviors and skills:

  • Frame mistakes and errors as learning and opportunities for improvement.
  • Encourage lessons learned to be shared instead of hidden, focused toward helping others to learn, grow, and avoid similar mistakes.
  • Embrace the value of failure for learning by admitting to mistakes they’ve made themselves.
  • Understand the difference between failures and subversion, sabotage, incompetence, and lack of ability.
  • Learn about the interpersonal, social skills which power team effectiveness, including Leadership, Communication, Assertiveness, Situational Awareness, Goal Analysis, and Decision-Making. Those skills include the explicit behaviors necessary to build psychological safety in the organizational environment.

“If I focus on using your mistake as a way to blame and punish you, I’ll never hear about your mistakes until a catastrophe ensues. If I focus on using your mistake as a way for us to learn and improve collectively, then our entire process, system, and business will be better after every mistake.”

Individuals and teams can also help to build and enable psychologically safe environments:

  • Seek training about and learn the interpersonal, social skills which power team effectiveness, including Leadership, Communication, Assertiveness, Goal Analysis, Decision-Making, Situational Awareness, Agility, and Empathy.
  • Advocate for and build a climate in which learning and improvement is possible through open and honest analysis of failures / mistakes.
  • Frame and focus discussions on the plans, strategies, and ideas supporting what is right, not who is right.
  • Assume responsibility for their own psychological safety and proactively help build it as a fundamental attribute of their teams’ work environment.

Psychological safety is a key organizational characteristic which is critical to the growth of high-performing teams. However, it isn’t a holy grail and most organizations, coaches, and consultants do not know how to purposefully create a psychologically safe environment, nor why it makes sense to do so. Yet mindfully organizing to build high-performing teams is not only possible, it is something which many organizations have been doing for decades.

 

Chris Alexander is a former F-14D Flight Officer, the co-founder of AGLX Consulting, High-Performance Teaming™ coach, Agile coach, and Scrum Master, and has a passion for working with high-performing teams. Learn more at https://www.aglx.consulting.

References:

  1. Pentland, Alex (2014­01­30). Social Physics: How Good Ideas Spread – ­The Lessons from a New Science (p. 90). Penguin Publishing Group. Kindle Edition.
  2. Edmondson, Amy C. (2012­03­16). Teaming: How Organizations Learn, Innovate, and Compete in the Knowledge Economy (Kindle Locations 1474­-76, 2139-40). Wiley. Kindle Edition.
  3. Ibid, 2141-2144.
  4. https://www.youtube.com/watch?v=LDKYehwuirw

Share This:

High-Performing Teams: Built from the Basic Skills of Human Interaction

I’ve struggled my whole life to connect the dots. I’m the smartest dumb person I know, and I at times amaze even myself with the brilliance of my own insights, which generally occur simultaneously alongside my forgetting to turn off the stove, or turn on the dishwasher (which I’ve just finished loading).

I recall quite vividly sitting in Instrument Ground School, well along my way to becoming an F-14 Tomcat Radar Intercept Officer (RIO), and learning about Crew Resource Management (CRM) for the first time. My overwhelming thought at the time was, “why do they insist on teaching us things we already know?”

Of course, they weren’t. Instead, once again, I was both intelligent enough to recognize the value of CRM for what it meant to my situation immediately, but not smart enough to appreciate, in any sense whatsoever, the importance of its formation and history, nor its incredible potential to help people everywhere to work together, in any environment or on any problem; from operating rooms to oil rigs, from ocean floors to outer space.

High-Performance Teaming™, one of Crew Resource Management’s successors, leverages those same skills which have been proven to help teams perform and succeed in High-Reliability Organizations across cultures and industries to include NASA, surgical teams, nuclear power stations, civil and military aviation, and special forces units, to name just a few.

The simple reason that these tools work across such diverse types of teams is not because they are based in the newest or most proven processes, or the latest in business operating frameworks or methodologies. Rather, these tools work because they focus on building the skills which enable dynamic, positive, and powerful human interaction.

By leveraging our shared human abilities to learn and improve, and targeting the skills specifically connected to the human capability to effectively function as part of a team, we can develop high-performing teams regardless of functional level or the domain of work.

Take, for example, rock climbing.

I know – “whaaaat?” Stick with me. I was recently asking one of the teams I work with what they would like to do to celebrate our successful (and early) completion of a software feature. Typically I would expect the standard answers: go to a team lunch, after-work drinks, trip to the pinball museum, Friday-night pool – the usual things teams choose to do. Yet, as is becoming standard, the team surprised me.

“The weather Thursday is supposed to be beautiful. How about if we do a team rock climbing day?”

Now I’m a climber and so are a couple of other people on the team, and going climbing together is something we’d half-joked about plenty of times, but this was a real suggestion. So I asked around, gave it some thought, and realized we could use the experience to not only have fun and bond further as a team, but to actually train with the skills we’d been talking about at the office in an entirely different context. My hypothesis was that a team of individuals climbing together is still a team, and the same skills which drive human interactions within teams in an office environment, an operating room, or in a cockpit, should be congruent.

So we went rock climbing, and discussed the litmus test. Here’s how I set up the day and the High-Performance Teaming skills we discussed in the context of our day on the rock.

Communication. As it was actually quite windy at the climb site and we were a few hundred feet up the side of a hill beside a busy interstate, the conditions for clear and easy communication were not good. Yet communication is critical to good team performance. Personal tendencies, culture, speech, choice of words and a standard vocabulary, not to mention overcoming environmental challenges (wind, noise, etc.) were all critical to our performance.

Assertiveness. Given the challenges already acknowledged to our communication, combined with the fact that we had a few new climbers who hadn’t done this sort of thing before, we recognized the need for everyone to assume an assertive role in helping the team ensure that we achieved our goals. We needed everyone to speak up when something didn’t look right or make sense, or when they did not understand anything about what they were being asked to do.

Goal (or Mission) Analysis. I asked the team at the parking lot to state what they believed was our goal for the day. “Go climbing,” “have fun,” “enjoy the outdoors,” “bond as a team” were a few of the responses. All noble and understandable goals, to be sure, but I offered another: “come back safely.” Understanding what your primary goal or goals are isn’t always intuitive, obvious, or easy, but getting it wrong can create a cascade of mistakes due to your team being misaligned on the very fundamental issues around why they’re doing what they’re doing.

Situational Awareness. Understanding that we’re going to have to make decisions about which routes to climb, who will be climbing belaying, whether we need to clean routes behind us, and a host of other potential situations (what happens if someone is injured?) requires us all to constantly re-assess and evaluate where we are in our day, what we are doing, and what we are trying to do. We need to ensure that we are fully aware of what is going on around us, and what is supposed to be going on around us.

Decision-Making. Early in the day our ability to decide on which routes to climb and which partners would climb/belay in what order was affected by stress, but as the day wore on and the stress of working together in a new team diminished, fatigue and the potential for complacency set in. Our ability to make the right decisions in important situations such as who climbs next, when to clean the route and move, who leads, where and when to relocate, when to take a break, and when to stop for the day, hinged on our ability to communicate well, maintain our situational awareness, and maintain focus on our primary goal – a safe return.

Agility. Many people talk about being Adaptable, however I prefer the term Agility. Agility, I’ve heard said, is Adaptability in a timebox. We had no sooner hiked around the corner to our climbing site to begin execution of our plan to climb the first two pitches (which were not challenging by design), then we had to adjust our plan due to the fact that both routes were already being worked by the local fire department, also out for a day of cliff rescue training in some gorgeous weather. So we quickly re-planned and moved to an alternate site.

Leadership. In a team of peers, leadership is often a revolving position. In a team with three experienced climbers and three beginners, we needed to rotate leadership responsibilities at different times based on the situation. Yet what most people get totally wrong is what the leader actually does. The leader isn’t there to make decisions and pass out orders, rather to pull the team together, ensure everyone understands what is occurring and what the plan is, solicit feedback and invite constructive dissent, to support assertiveness, and to leverage the collective wisdom of the team in analyzing goals and making collective decisions. Leadership is not about being right, it is about what is right. As each of us moved through moments of assuming leadership, our interactions were all similar: does everyone understand and agree with the plan? Does everyone understand what is being asked of them? Are you ready to move forward? Are we all ready for the next step?

Empathy. The ability to recognize and respond appropriately to the emotional state of others is a fundamentally human skill which powers every other social interaction skill. Looking at my climbing partner who is about to start on the route, I ask “ready?” The novice climber looks back tentatively and responds “ready.” However I see in his stance, face, and eyes that he is struggling with fear, doubt, and uncertainty. I encourage him to begin the route by pulling the rope tight and responding “on belay – I’ve got you.” This gives him some confidence. I don’t want to take his fear and uncertainty away – I want him to work through it on his own, which I know he can. This is empathy in action.

The skills required to enable and power high-performance teamwork are grounded in our fundamental ability to interact with other humans. This statement will continue to be true until the day arrives when we need to team with robots or aliens, at which point it is conceivable that other skills might be required. However for the entirety of human existence, people have needed to work together and have, unsurprisingly, evolved to do just that. The amazing thing in our growing technological age is that some of those natural, instinctual, basic social skills are incredibly difficult to recall and apply. Yet train, learn, and apply them we can, and in doing so we can actually help build and become the incredibly high-performing teams we’ve always envisioned.

 

Chris Alexander is a former F-14D Flight Officer, the co-founder of AGLX Consulting, High-Performance Teaming™ coach, Agile coach, and Scrum Master, and has a passion for working with high-performing teams. Learn more at https://www.aglx.consulting.

Share This:

Risk Management and Error Trapping in Software and Hardware Development, Part 3

This is part 3 of a 3-part piece on risk management and error trapping in software and hardware development. The first post is located here (and should be read first to provide context on the content below), and part 2 is located here.

Root Cause Analysis and Process Improvement

Once a bug has been discovered and risk analysis / decision-making has been completed (see below), a retrospective-style analysis on the circumstances surrounding the engineering practices which failed to effectively trap the bug completes the cycle.

The purpose of the retrospective is not to assign blame or find fault, but rather to understand the cause of the failure to trap the bug, inspect the layers of the system, and determine if any additional layers, procedures, or process changes could effectively improve collective engineering surety and help to prevent future bugs emerging from similar causes.

Methodology

  1. Review sequence of events that led to the anomaly / bug.
  2. Determine root cause.
  3. Map the root cause to our defense-in-depth (Swiss cheese) model.
  4. Decide if there are remediation efforts or improvements which would be effective in supporting or restructuring the system to increase its effectiveness at error trapping.
  5. Implement any changes identified, sharing them publicly to ensure everyone understands the changes and the reasoning behind them.
  6. Monitor the changes, adjusting as necessary.

Review sequence of events

With appropriate representatives from engineering teams, certification, hardware, operations, customer success, etc., review the discovery path which led to finding the bug. The point is to understand the processes used, which ones worked, and which let the bug pass through.

Determine root cause and analyze the optimum layers for improvement

What caused the bug? There are many enablers and contributing factors, but typically only one or two root causes. The root cause is one or a possible combination of Organization, Communication, Knowledge, Experience, Discipline, Teamwork, or Leadership.

  • Organization – typically latent, organizational root causes include things like existing processes, tools, practices, habits, customs, etc., which the company or organization as a whole employs in carrying out its work.
  • Communication – a failure to convey necessary, important, or vital information to or among an individual or team who required it for the successful accomplishment of their work.
  • Knowledge – an individual, team, or organization did not possess the knowledge necessary to succeed. This is the root cause for knowledge-based errors.
  • Experience – an individual, team, or organization did not possess the experience necessary to successfully accomplish a task (as opposed to the knowledge about what to do). Experience is often a root cause in skill-based errors of omission.
  • Discipline – an individual, team, or organization did not possess the discipline necessary to apply their knowledge and experience to solving a problem. Discipline is often a root cause in skill-based errors of commission.
  • Teamwork – individuals, possibly at multiple levels, failed to work together as a team, support one another, and check one another against errors. Additional root causes may be knowledge, experience, communication, or discipline.
  • Leadership – less often seen at smaller organizations, a Leadership failure is typically a root cause when a leader and/or manager has not effectively communicated expectations or empowered execution regarding those expectations.

Map the root cause to the layer(s) which should have trapped the error

Given the root cause analysis, determine where in the system (which layer or layers) the bug should have been trapped. Often there will be multiple locations at which the bug should or could have been trapped, however the best location to identify is the one which most closely corresponds to the root cause of the bug. Consideration should also be given to timeliness. The earlier an error can be caught or prevented (trapped), the less costly it is in terms of both time (to find, fix, and eliminate the bug) and effort (a bug in production requires more effort from more people than a developer discovering a bug while checking their own unit test).

While we should seek to apply fixes at the locations best suited for them, the earliest point at which a bug could have been caught and prevented will often be the optimum place to improve the system.

For example, if a bug was traced back to a team’s discipline in writing and using tests (root cause: discipline and experience), then it would map to layers dealing with testing practices (TDD/ATDD), pair programming, acceptance criteria, definition of “Done,” etc. Those layers to which the team can most readily apply improvements and which will trap the error sooner rather than later should be the focus for improvement efforts.

Decide on improvements to increase system effectiveness

Based on the knowledge gained through analyzing and mapping the root cause, decisions are made on how to improve the effectiveness of the system at the layers identified. Using the testing example above, a team could decide that they need to adjust their definition of Done to include listing which tests a story has been tested against and their pass/fail conditions.

Implement the changes identified, and monitor them for effectiveness.

Risk Analysis

Should our preventative measures fail to stop a bug from escaping into a production environment, an analysis of the level of risk needs to be explicitly completed. (This is often done, but in an implicit way.) The analysis of the level of risk derives from two areas.

Risk Severity – the degree of impact the bug can be expected to have to the data, operations, or functionality of affected parties (the company, vendors, customers, etc.).

Blocking A bug that is so bad, or a feature that is so important, that we would not ship the next release until it is fixed/completed. Could also signify a bug that is currently impacting a customer’s operations, or one that is blocking development.
Critical A bug that needs to be resolved ASAP, but for which we wouldn’t stop everything. Bugs in this category are not impacting operations (a customer’s, or ours), but they are significantly challenging to warrant attention.
Major Best judgement should be used to determine how this stacks against other work. The bug is serious enough that it needs to be resolved, but the value of other work and timing should be considered. If a bug sits in major for too long, its categorization should be reviewed and either upgraded or downgraded.
Minor A bug that is known, but which we have explicitly de-prioritized. Such a bug will be fixed as time allows.
Trivial Should really consider closing this level of bug. At best these should be put into the “Long Tail” for tracking.

Risk Probability – the likelihood, expressed against a percentage, that those potentially affected by the bug will actually experience it (ie., always, only if they have a power outage, or only if the sun aligns with Jupiter during the slackwater phase of a diurnal tide in the northeastern hemisphere between 44 and 45 degrees Latitude).

Definite 100% – issue will occur in every case
Probable 60-99% – issue will occur in most cases
Possible 30-60% – coin-flip; issue may or may not occur
Unlikely 2-30% – issue will occur in less than 50% of cases
Won’t 1% – occurrence of the issue will be exceptionally rare

Given Risk Severity and Probability, the risk can be assessed according to the following matrix and assigned a Risk Assessment Code (RAC).

Risk Assessment Matrix Probability
Definite Probable Possible Unlikely Won’t
Severity Blocker 1 1 1 2 3
Critical 1 1 2 2 3
Major 2 2 2 3 4
Minor 3 3 3 4 5
Trivial 3 4 4 5 5

Risk Assessment Codes
1 – Strategic     2 – Significant     3 – Moderate     4 – Low     5 – Negligible

The Risk Assessment Codes are a significant factor in Risk decision-making.

  1. Strategic – the risk to the business or customers is significant enough that its realization could threaten operations, basic functioning, and/or professional reputation to the point that the basic survival of the business could be in jeopardy. As Arnold said in Predator: “We make a stand now, or there will be nobody left to go to the chopper!”
  2. Significant – the risk poses considerable, but not life-threatening, challenges for the business or its customers. If left unchecked, these risks may elevate to strategic levels.
  3. Moderate – the risk to business operations, continuity, and/or reputation is significant enough to warrant consideration against other business priorities and issues, but not significant enough to trigger higher responses.
  4. Low – the risk to the business is not significant enough to warrant special consideration of the risk against other priorities. Issues should be dealt with in routine, predictable, and business-as-usual ways.
  5. Negligible – the risk to the business is not significant enough to warrant further consideration except in exceptional circumstances (ie., we literally have nothing better to do).

Risk Decision

The risk decision is the point at which a decision is made about the risk. Typically, risk decisions take the form of:

  • Accept – accept the risk as it is and do not mitigate or take additional steps.
  • Delay – for less critical issues or dependencies, a decision about whether to accept or mitigate a risk may be delayed until additional information, research, or steps are completed.
  • Mitigate – establish a mitigation strategy and deal with the risk.

For risk mitigation, feasible Courses of Action (CoAs) should be developed to assist in making the mitigation plan. These potential actions comprise the mitigation and or reaction plan. Specifically, given a specific bug’s risk severity, probability, and resulting RAC, the courses of action are the possible mitigate solutions for the risk. Examples include:

— Pre-release —

  • Apply software fix / patch
  • Code refactor
  • Code rewrite
  • Release without the code integrated (re-build)
  • Hold the release and await code fix
  • Cancel the release

— In production —

  • Add to normal backlog and prioritize with normal workflow
  • Pull / create a team to triage and fix
  • Swarm / mob multiple teams on fix
  • Pull back / recall release
  • Release an additional fix as a micro-upgrade

For all risk decisions, those decisions should be recorded and those which remain active need to be tracked. There are many methods available for logging and tracking risk decisions, from spreadsheets to documentation to support tickets. There are entire software platforms expressly designed to track and monitor risk status and record decisions taken (or not) about risks.

Decisions to delay risk mitigations are the most important to track, as they require action and at the speed most business move today, a real risk exists of losing track of risk delay decisions. Therefore a Risk Log or Review should be used to routinely review the status of pending risk decisions and reevaluate them. Risk changes constantly, and risks may significantly change in severity and probability overnight. In reviewing risk decisions regularly, leadership is able to simultaneously ensure both that emerging risks are mitigated and that effort is not wasted unnecessarily (as when effort is put against a risk which has significantly declined in impact due to changes external to the business).

Conclusion

I hope you’ve enjoyed this 3-part series. Risk management and error trapping is a complicated and – at times – complex topic. There are many ways to approach these types of systems and many variations on the defense-in-depth model.

The specific implementation your business or organization chooses to adopt should reflect the reality and environment in which you operate, but the basic framework has proven useful across many domains, industries, and is directly adapted from Operational Risk Management as I used to practice and teach it in the military.

Understanding the root cause of your errors, where they slipped through your system, and how to improve your system’s resiliency and robustness are critical skills which you need to develop if they are not already functional. A mindful, purposeful approach to risk decision-making throughout your organization is also critical to your business operations.

Good luck!

 

Chris Alexander is a former U.S. Naval Officer who was an F-14 Tomcat flight officer and instructor. He is Co-Founder and Executive Team Member of AGLX Consulting, creators of the High-Performance Teaming™ model, a Scrum Trainer, Scrum Master, and Agile Coach.

Share This:

Risk Management and Error Trapping in Software and Hardware Development, Part 2

This is part 2 of a 3-part piece on risk management and error trapping in software and hardware development. The first post is located here (and should be read first to provide context on the content below).

Error Causality, Detection & Prevention

Errors occurring during software and hardware development (resulting in bugs) can be classified into two broad categories: (1) skill-based errors, and (2) knowledge-based errors.

Skill-based errors

Skill-based errors are those errors which emerge through the application of knowledge and experience. They are differentiated from knowledge-based errors in that they arise not from a lack of knowing what to do, but instead from either misapplication or failure to apply what is known. The two types of skill-based errors are errors of commission, and errors of omission.

Errors of commission are the mis-application of a previously learned behavior or  knowledge. To use a rock-climbing metaphor, if I tied my climbing rope to my harness with the wrong type of knot, I would be committing an error of commission. I know I need a knot and I know which knot to use and I know how to tie the correct knot – I simply did not do it correctly. In software development, one example of an error of commission might be an engineer providing the wrong variable to a function call, as in:

var x = 1;        // variable to call
var y = false;    // variable not to call
public function callVariable(x) {
return x;
}
callVariable(y); // should have provided “x” but gave “y” instead

Errors of omission, by contrast, are the failure to apply knowledge or experience (previously learned behaviors) to the given problem. In my climbing example, not tying the climbing rope to my harness (at all) before beginning to climb is an error of omission. (Don’t laugh – this actually happens.) In software development, an example of an error of omission would be an engineer forgetting to provide a variable to a function call (or forgetting to add the function call at all), as in:

var x = 1;              // variable to call
var y = false;          // variable not to call
public function callVariable(x) {
return x;
}
callVariable();   // should have provided “x” but left empty

Knowledge-based errors

Knowledge-based errors, in contrast to skill-based errors, arise from the failure to know the correct behavior to apply (if any). An example of a knowledge-based error would be a developer checking in code without any unit, integration, or system tests. If the developer is new and has never been indoctrinated to the requirements for code check-in as including having written and run a suite of automated unit, integration, and system tests, this is an error caused by a lack of knowledge (as opposed to omission, where the developer had been informed of the need to write and run the tests but failed to do so).

Defense-in-depth, the Swiss cheese model, bug prevention and detection

Prevention comprises the systems and processes employed to trap bugs and stop them from getting through development environments and into certification and/or production environments (depending on your software / hardware release process). In envisioning our Swiss cheese model, we need to understand that the layers include both latent and active types of error traps, and are designed to mitigate against certain types of errors.

The following are intended to aid in preventing bugs.

Tools & methods to mitigate against Skill-based errors in bug prevention:

  • Code base and architecture [latent]
  • Automated test coverage [active]
  • Manual test coverage [active]
  • Unit, feature, integration, system, and story tests [active]
  • TDD / ATDD / BDD / FDD practices [active]
  • Code reviews [active]
  • Pair Programming [active]
  • Performance testing [active]
  • Software development framework / methodology (ie, Scrum, Kanban, DevOps, etc.) [latent]

Tools & methods to mitigate against Knowledge-based errors in bug prevention:

  • Education & background [latent]
  • Recruiting and hiring practices [active]
  • New-hire Onboarding [active]
  • Performance feedback & professional development [active]
  • Design documents [active]
  • Definition of Done [active]
  • User Story Acceptance Criteria [active]
  • Code reviews [active]
  • Pair Programming [active]
  • Information Radiators [latent]

Detection is the term for the ways in which we find bugs, hopefully in the development environment but this phase would also include certification if your organization has a certification / QA phase. The primary focus of detection methods is to ensure no bugs escape into production. As such, the entire software certification system itself may be considered one, large, active layer of error trapping. In fact, in many enterprise companies, the certification or QA team (if you have one) is actually the last line of defense.

The following are intended to aid in detecting bugs:

Tools & methods to mitigate against Skill-based errors in detecting bugs:

  • Automated test coverage [active]
  • Manual test coverage [active]
  • Unit, feature, integration, system, and story tests [active]
  • TDD / ATDD / BDD / FDD practices [active]
  • Release certification testing [active]
  • Performance testing [active]
  • User Story Acceptance Criteria [active]
  • User Story “Done” Criteria [active]
  • Bug tracking software [active]
  • Triage reports [active]

Tools & methods to mitigate against Knowledge-based errors in detecting bugs:

  • Education & background [latent]
  • Professional development (individual / organizational) [latent / active]
  • Code reviews [active]
  • Automated & manual test coverage [active]
  • Unit, feature, integration, system, story tests [active]

When bugs “escape” the preventative measures of your Defense-in-depth system and are discovered in either the development or production environment, a root cause analysis should be conducted on your system based on the nature of the bug and how it could have been prevented and / or detected earlier. Based upon the findings of your root cause analysis, your system can be improved in specific, meaningful ways to increase both its robustness and resilience.

How an organization should, specifically, conduct root cause analysis, analyze risk and make purposeful decisions about risk, and how they should improve their system is the subject of part 3 in this series, available here.

 

Chris Alexander is a former U.S. Naval Officer who was an F-14 Tomcat flight officer and instructor. He is Co-Founder and Executive Team Member of AGLX Consulting, creators of the High-Performance Teaming™ model, a Scrum Trainer, Scrum Master, and Agile Coach.

Share This:

Risk Management and Error Trapping in Software and Hardware Development, Part 1

The way in which we conceptualize and analyze risk and error management in technology projects has never received quite the same degree of scrutiny which business process frameworks and methodologies such as Scrum, Lean, or Traditional Project Management have. Yet risk is inherent in everything we do, every day, regardless of our industry, sector, work domain, or process.

We actually practice risk management in our everyday lives, often without consciously realizing that what we are doing is designed to manage levels of risk against degrees of potential reward, and either prevent errors from occurring or minimizing their impact when they do.

For example, I recently took a trip to the San Juan islands with my wife and parents. I woke up early, made coffee, roused the troops, and checked the weather. I’d filled up the gas thank the day before, and booked our ferry tickets online. I checked the weather and recommended we each take an extra layer. We departed the house a bit earlier than really necessary, but ended up encountering a detour along the way due to a traffic accident on the Interstate. Nevertheless, we made it to the ferry terminal with about 10 minutes to spare, and just in time to drive onto the ferry and depart for Friday Harbor.

My personal example is relatively simple but, with a little analysis, demonstrates how intuitively we assess and manage risk:

  • Wake up early: mitigates risk of oversleeping and departing late (which could result further in forgetting important things, leaving coffee pot/equipment on, etc.), waiting on others in the bathroom, and not being able to prepare and enjoy some morning coffee (serious risk).
  • Check the weather: understanding the environment we are entering into is critical to mitigating environment-related risks, in this case real environmental concerns such as temperature, weather, wind, and precipitation, enabling us to mitigate potentially negative effects and capitalize on positives. Bad weather may even result in our changing our travel plans entirely – a clear form of risk mitigation in which we determine that our chance for a successful journey is low compared against the value we would derive from undertaking the journey in the first place, and decide the goal is not sufficient to accept present risk levels.
  • Book ferry tickets online: a mitigation against the risk of arriving late and having to wait in line to purchase tickets, which could result in us missing the ferry due to either running out of time or the ferry already being completely booked.
  • Departing earlier than necessary: a mitigation against unforeseen and unknowable specific risk, in this case the generic risk of en route delays, which we did encounter on this occasion.

As you can see, as a story my preparations for our trip seem rather routine and unremarkable, but when viewed through the lens of risk mitigation and error management, each action and decision can be seen as specifically targeted to mitigate one or more specific risks or minimize the potential effects of an error. Unfortunately, our everyday intuitive actions and mental processes seldom translate into our work environments in such direct and meaningful ways.

Risk and Error Management in Software and Hardware Development – Defense-in-Depth and the Swiss Cheese Model

Any risk management system can be seen as a series of layers designed to employ a variety of means to mitigate risk and prevent errors from progressing further through the system. We call this “trapping errors.” Additionally, each of these layers is often just one part of a larger system. A system constructed with these layers  is referred to as having “defense-in-depth.”

Defense-in-depth reflects the simple idea that instead of employing one single, catch-all solution for eliminating risk and trapping errors, a layered approach which employs both latent and active controls in different areas throughout the system will be far more effective in both detecting and preventing errors from escaping.

These layers are often envisioned as slices of Swiss cheese, with each slice representing a different part of the larger system. As a potential risk or error progresses through holes in the system’s layers, it should eventually be trapped in one of the layers.

Risk and errors are then only able to impact the system when all the holes in the system’s Swiss cheese layers “line up.”

Latent and Active Layers

There are two basic types of layers (or traps) in any system: latent and active. In your day to day life, latent traps are things such as the tires on your car or the surface of the road. Active traps are things such as checking the weather, putting on safety gear, wearing a helmet, or deciding not to go out into the weather.

Latent layers in software or hardware development may be things such as the original (legacy) code base, development language(s) used, system architecture & design, hardware (types of disk drives, manufacturer), and so forth. It may even include educational requirements for hiring, hiring practices, and company values.

Active layers in software and hardware development may include release processes, User Story writing and acceptance criteria, and development practices like TDD/ATDD, test automation, code reviews, and pair programming.

Separation of Risk and Error Management Concerns

To better focus on dealing with the most appropriate work at the appropriate time in responding to error detection, triage, and risk mitigation, we can separate our risk and error analysis into the following areas:

During development: focus on trapping errors

  • Prevention – the practices, procedures, and techniques we undertake in engineering disciplines to help ensure we do not release bugs or errors into our code base or hardware products.
  • Detection – the methods available to us as individual engineers, teams, and the organization as a whole to find and respond to errors in our code base or hardware products (which includes reporting and tracking).

Risk mitigation: steps for errors that have escaped into certification or production environments

  • Risk Analysis – the steps required to analyze the severity and impact of an error.
  • Risk Decision-making – the process of ensuring decisions about risk avoidance, acceptance, or mitigation are made at appropriate levels with full transparency.

Continuous Improvement in every case

Improvement – the process of improving workflows and practices through shared knowledge and experience in order to improve engineering practices and further harden our release cycles. This step uses root cause analysis to help close the holes we find in the layers of our Swiss cheese model.

Here is one conceptualization of what a Defense-in-depth Risk Management model might look like. Bear in mind that this is simply one way to conceive of layers at a more macro level, and each layer could easily itself be broken down into a set of layers, or you could conceive of it as one very large model.

swiss_cheese

Given our model and our new ability to conceive of Risk and Error Management in this more meaningful and purposeful way, our next step is to understand error causality and what we can do to apply our causal analysis to strengthening our software and hardware risk management and error trapping system.

Continue reading in part 2 of this 3-part series.

 

Chris Alexander is a former U.S. Naval Officer who was an F-14 Tomcat flight officer and instructor. He is Co-Founder and Executive Team Member of AGLX Consulting, creators of the High-Performance Teaming™ model, a Scrum Trainer, Scrum Master, and Agile Coach.

Share This:

The Missing Half of Team Performance: The Social Skills Behind High-Performance Teaming™

The overwhelming majority of businesses and organizations today are incredibly focused on adopting processes, tools, and frameworks to supercharge their teams’ productivity and quality, but in doing so they are solving for only half of the problem.

Whereas the team approach is often seen as a solution to cognitively complex tasks, it also introduces an additional layer of cognitive requirements that are associated with the demands of working together effectively with others. [1]

We are incontrovertibly human. When working in teams, we are humans working with other humans. Unlike a software program, the daily inputs and outputs of our lives are far too complex and changing to conceivably map and understand in a finite way; the potential derivations of our interpretations and reactions throughout the course of simply living our lives is, literally, infinite and unknowable.

Yet in virtually every business, organization, and team across America, we are focusing our efforts on establishing and implementing process, creating standardized operating procedures, rules, guidelines, policies, and training programs to build great (productive) teams. In doing so, we are ignoring the very thing which actually creates a high-performing team: us.

It actually isn’t rocket science: the interactions of the team members, not their individual intelligence, experience, education, or technical skill, is what determines how effective and how high-performance the team will be.

[T]he number one factor in making a group effective is skill at deep human interaction. That’s a remarkable finding in itself when we consider that groups are hardly ever evaluated on that basis. Everyone seems to think that other factors— leadership, mix of technical skills, vision, motivation— are more important. They matter, but not nearly as much as social skills… Social skills were the most important factor in group effectiveness because they encourage those patterns of “idea flow,” to use [Dr. Alex] Pentland’s term. Slicing the data in another way, those three elements of interaction [short & rapid idea generation, “dense interacting,” and turn-taking on idea-sharing and feedback] were more important than any other factor in explaining the excellent performance of the best groups; in fact, they were about as important as all the other factors— individual intelligence, technical skills, members’ personalities, and anything else you could think of— put together. [2]

To put the above a bit more succinctly, the best teams are not characterized by having the most intelligent, most skilled individuals; they are characterized by the quality and quantity of the team members’ social interactions.

There is an incredibly valuable point in this: the traditional focus on an individual’s knowledge, experience, and skills in a technical or process domain is only half of the story in building high-performing teams. The other half of the story is understanding how they perform in team environments and how well they contribute to a team’s overall performance and effectiveness.

Teaming Metaphors

A useful metaphor for the technical versus non-technical and social skills is live theater. Think of technical skills, scholastic education, and work experience as simply foundational elements of your business’ or organization’s ability to perform.

They are the stage, the lighting, the seating, the curtain, the orchestra’s space. Those elements are the theater.

However, the actors’ and actresses’ abilities to perform on that stage, to create something memorable and incredible – those are the social skills, the non-technical “secret sauce” of how the team actually performs together. For that great performance to occur, you need more than just the stage and the lighting – you need the performers and the magic that happens when a great team produces what a great team can.

Or consider the difference between watching a great football player play, and a great football team play. (This applies to both types of football.) A team of individuals with a star or two will never come close to achieving what an amazing team can achieve, regardless of their star power.

As I reported in my Harvard Business Review article “The New Science of Building Great Teams,” my research group and I have collected hundreds of gigabytes of data from dozens of workplaces. What we found was that the patterns of face-to-face engagement and exploration within corporations were often the largest factors in both productivity and creative output. [3]

Learning Social Skills

So what happens when you’ve hired the most technically skilled, scholastically educated people, and their social and teaming skills are virtually non-existent? Fear not – there is great news

Growing numbers of companies have discovered what the military learned long ago, that the supposedly ineffable, intractable, untrainable skills of deep human interaction are in fact trainable… Businesses can’t even begin to get better until leaders acknowledge that these skills are the key to competitive advantage, that methods of developing them may be unfamiliar, and that measuring the results will never be as easy as gauging operating efficiencies. If companies can get past those obstacles, which in most organizations are more than enough to stop managerial innovations dead in their tracks, then they have a chance. [4]

Yes – trainable.

Although it should come as no surprise, due to the fact that we all share the common trait of being – well, human – it is good to know that we can actually focus on and learn those critical skills which enable us to team effectively with other humans.

The military and commercial aviation have been doing this for decades already.

Yes – decades.

The fact that the social and non-technical skills teams need to reach high-performance are trainable and able to be improved upon over time, just as one would improve their knowledge of emerging coding practices or new technologies, is not conjecture or hypothetical experimentation. In fact, it has been operationalized and regularly improved for years.

High-Performance Teaming™

Founded in Crew-Resource Management (CRM) fundamentals, High-Performance Teaming™ provides teams at every and any level with the social, non-technical skills they need to perform at the highest levels. It targets exactly what makes effective teams – the ability for team members to engage in regular, high-quality interactions and input-feedback cycles to build the Shared Mental Models (SMMs) and communication loops which drive team performance and output.

Specifically, High-Performance Teaming™ builds the critical social skills teams need in:

  • Communication – the mechanics behind speaking and listening, non-verbal signals and cues, the human factors (culture, language, personality) which influence our communication patterns, and how to affect them through awareness.
  • Assertiveness – the behaviors behind respectfully asserting knowledge and opinion, and how to handle those assertions in a team.
  • Situation Awareness (SA) – the team’s ability to build a shared conception of their environment, and the degree to which it matches reality; requires Shared Mental Models, operational analysis, spatial awareness, etc.
  • Goal / Mission Analysis – the ways in which the team plans, executes, and learns based on their shared model of tactical to strategic goals; driven by alignment, communication, SA, and powers Decision-Making.
  • Decision-Making – utilizing collective intelligence of the team and leveraging the team’s SA combined with Goal / Mission Analysis to build consensus on solutions to complex problems, which in turn will drive execution and directly impact performance.
  • Agility – the ability to remain flexible and adapt to change; resilience in the face of a changing environment and rapidly evolving problem-set.
  • Leadership – one of the critical enablers to team effectiveness in non-flat environments, effective leadership is vital to creating Assertiveness, leveraging team collective intelligence in building SA and Goal / Mission Analysis, and getting to the correct decisions which enable organizational execution in a time-critical manner.
  • Culture – another enabler of team cohesiveness and resiliency; purposefully constructed and monitored through Shared Mental Models, Culture is a powerful contributor to Alignment, which is critical to reducing waste/churn and helping teams remain resilient and goal-oriented.
  • Empathy – the foundational element in every social skill; the ability to recognize and respond appropriately to the thoughts and feelings of others.

If you’ve gone through multiple team processes (traditional project management, Scrum, XP, SAFe, etc.), and you’re still wondering why your teams are not producing and improving, ask yourself if you’ve been solely concentrating on the Technical Skill & Process side of the equation – the side which only effects what processes teams are using to organize and conduct their work.

If you have, perhaps it is time to start giving your teams the social and non-technical skills they need to actually improve how they work together. Scrum (for example) is a great process which sets the stage for the performance, but High-Performance Teaming™, grounded in the science behind Crew Resource Management and team effectiveness, is the tool set your teams need to actually perform.

Contact AGLX Consulting today to bring those social skills to your teams!

 

Chris Alexander is a former U.S. Naval Officer who flew the F-14 Tomcat, and is Co-Founder and Executive Team Member of AGLX Consulting, creators of the High-Performance Teaming model.

  1. Cooke, N. J., Salas, E., Cannon-Bowers, J. A., & Stout, R. (2000). “Measuring team knowledge.” Human Factors, 42, 151-173.
  2. Colvin, Geoff (2015-08-04). Humans Are Underrated: What High Achievers Know That Brilliant Machines Never Will (pp. 126-7). Penguin Publishing Group. Kindle Edition.
  3. Pentland, Alex (2014-01-30). Social Physics: How Good Ideas Spread – The Lessons from a New Science (p. 93). Penguin Publishing Group. Kindle Edition.
  4. Colvin, 2015 (p. 204).

Share This:

High-Performing Teams: Writing Code is Not Your Problem

Regardless of the software or hardware development processes used in your business domain, chances are if you are worried about your teams’ performance levels, their ability to write code or build hardware solutions is not your concern.

How do you build teams which are truly high-performing?

Teams which are able to work together toward levels of truly high-performance remain relatively elusive and seldom in most industries. Regardless of which frameworks, methodologies, and tools teams adopt and adapt, their productivity remains relatively average. This hurts the bottom line of the business, which has often agreed to accept certain restrictions on current productivity on the promise of significantly increased productivity once the new methodology or framework is in place and humming.

Sound familiar? This is a situation in which the application of multiple solutions entirely fails to address the actual problem.

Teams do not form around processes, methodologies, and frameworks; they form around the members of the team. Or, more specifically, they form around the social, non-technical interactions of the individuals within the team. When a team fails to effectively bond together, several problems are typically the root:

  1. The level of empathy at the team level is relatively low
  2. The number, type, and quality of social interactions is low
  3. There is low to no feedback within the group

Despite what you may believe, social skills are highly trainable and can be learned. Teams can build their social, non-technical skills in order to team together more effectively and achieve those levels of high-performance.

Moreover, leadership can directly enable these teaming activities by learning about how high-performing teams function and what they can do to enable those teams to coalesce and perform. The secret to leading highly-performing teams is that it actually isn’t that hard – but it does take a level of discipline and rigor which many leaders find exceptionally challenging.

If you want to learn about High-Performance Teaming™ and what you or your organization can do to get to those levels of high-performance, reach out to us at AGLX Consulting today.

Chris Alexander is a former Navy Lieutenant Commander, F-14 Tomcat RIO, software developer, Agile Coach, and Executive Team Member at AGLX Consulting, LLC.

Share This: