Westrum’s Organisational Cultural Typologies and Psychological Safety

“Culture Eats Strategy for Breakfast”

A statement famously attributed to Peter Drucker, by which he means that however much you work on your strategy, you ultimately cannot ignore the “people factor”. It is people that execute your strategy and it is through people that it will succeed or fail.

People Create Culture

The most important aspect for any organisation is people and how they interact. Not strategy, not processes, not operations, and not even finance. An organisation is built of relationships between people (plus some processes, and software) and people create culture. If strategy consists of the rules of the game, culture will determine how the game is played. Culture is how people behave and communicate.

Psychological safety is often an emergent property of great organisational culture, but that doesn’t mean you can’t explicitly and purposefully work towards it and state that one of your goals for the organisation is to possess a great degree of psychological safety. Indeed, the first step in an intelligent journey to build psychological safety is often stating your goal and asking for help in getting there.

Psychological Safety and Culture

I’ve previously written about how to measure psychological safety, but measuring culture can be more challenging. Dr. Ron Westrum wrote in 2003 about The Typologies of Organisational Cultures that reflect how information flows through an organisation. He wrote: “organisational culture bears a predictive relationship with safety and that particular kinds of organisational culture improve safety…” That is to say, because information flow is influential and indicative of other aspects of culture, it can be used to predict how organisations or parts of them will behave when problems arise.

Westrum was focussed on real-world safety measures in the realm of healthcare and aviation, but in our technology world we should strive to adopt the same diligent approach to safety for the sake not just of the products we build but for the humans on our teams as well.

Culture is the almost intangible aspect of an organisation that so often reflects the CEO’s personality or the stance of the board members. As Westrum states: “Culture is shaped by the preoccupations of management.”

For example, if management, particularly senior management, are most concerned about exposure to risk, the organisational culture will reflect that, with processes and checks in place to ensure risk is reduced wherever possible; this usually results in a decreased focus on innovation, lower speed to market, and a low appetite for change.

In 2015, Jez Humble, Joanne Molesky, and Barry O’Reilly wrote the book “Lean Enterprise: How High Performance Organizations Innovate at Scale”, which highlighted how critical culture is to performance, and highlighted Westrum’s Typology model. “Instead of creating controls to compensate for pathological cultures, the solution is to create a culture in which people take responsibility for the consequences of their actions”

The 2016 state of DevOps Report also showed that Generative, performance-oriented cultures improve software delivery performance, alongside market share, productivity and profitability.

Westrum’s Typologies subsequently appeared in Nicole Forsgren’s book “Accelerate” in 2018, where she was able to show that generative cultures were associated with improved software delivery performance (the four Accelerate Metrics) and other organisational capabilities for learning.

Westrum’s Organisational Typologies

See the table below for Westrum’s organisational typology model. Each column describes a broad cultural typology: Pathological, Bureaucratic, or Generative, and six aspects of those cultures. It is clear from the table that the Generative culture that Westrum describes is a broadly psychologically safe culture where team members cooperate, share their fears, admit failure and continually improve.

 

Pathological Bureaucratic Generative
Power oriented Rule oriented Performance oriented
Low cooperation Modest cooperation High cooperation
Messengers “shot” Messengers neglected Messengers trained
Responsibilities shirked Narrow responsibilities Risks are shared
Bridging discouraged Bridging tolerated Bridging encouraged
Failure leads to scapegoating Failure leads to justice Failure leads to inquiry
Novelty crushed Novelty leads to problems Novelty implemented

The Westrum organisational typology model: How organizations process information ( Ron Westrum, “A typology of organisation culture),” BMJ Quality & Safety 13, no. 2 (2004), doi:10.1136/qshc.2003.009522.)

By surveying people across the organisation, you can establish the broad typology in which your organisational culture sits, and identify measures to improve. Ask respondents to rate their agreement on a 1-5 scale (1 being not at all, 5 being complete agreement) with the below statements:

  • On my team, information is actively sought.
  • On my team, failures are learning opportunities, and messengers of them are not punished.
  • On my team, responsibilities are shared.
  • On my team, cross-functional collaboration is encouraged and rewarded.
  • On my team, failure causes enquiry.
  • On my team, new ideas are welcomed.

These 6 statements are from Dr Nicole Forsgren’s research into high performing teams at DORA.

Each of these statements align with a row in the table above, so by collecting and analysing the average scores, you can quantitatively determine where your organisation resides in Westrum’s Typologies. Analyse the standard deviation of the scores to determine both the range of scores and the degree of statistical significance of the results.

Average these scores for your summative Westrum’s Typology score. Close to zero suggests your culture is towards “Pathological”, 2-3 suggests Bureaucratic, and 4-5 suggests a Generative culture:

The individual statement scores suggest areas for improvement. For example, if your score for statement 4 is particularly low, investigate and employ practices to improve collaboration between different functional teams, ask teams what challenges they face in communication and collaboration, and facilitate informal gatherings or events where people in different teams can get to know each other.

Intra-Organisational Psychological Safety

Ron Westrum describes a culture of “safety” in Generative organisations, and it’s easy to see how psychological safety is both increased in, and fundamental to, Generative cultures. Amy Edmondson, in 2008, described “Learning Organisations” in her paper “Is yours a learning organization?” and similarly suggested an assessment framework to measure how well a company learns and how adeptly it refines its strategies and processes.

There are many ways to improve the psychological safety of your team and your organisation, but sometimes as a leader, your influence may not extend very far outside of your team, and as a result, you may decide to build a high-performing, psychologically safe team within an environment of much lower psychological safety. This is admirable, and most likely the best course of action, but it is one of the most difficult places to put yourself as a leader.

Consider the “safety gradient” between your team boundary and the wider organisation. In a pathological or bureaucratic organisation, with varying degrees of toxic culture, that safety gradient is steep, and can be very hard to maintain as the strong leader of a high performing team. You may elect as your strategy to lead by example from within the organisation, and hope that your high-performing, psychologically safe team highlights good practice, and combined with a degree of evangelicalism and support, you can change the culture from “bottom-up”, not “top-down”.

This can work, and it will certainly be rewarding if you succeed, but a more effective strategy may be to build your effective team whilst lobbying, persuading and influencing senior management with hard data and a business case for psychological safety that demonstrates the competitive advantage that it can bring.

Create Psychological Safety

Take a look at my Psychological Safety Action pack, with a ready-made business case and background information, workshops and templates, to give yourself a shortcut to influencing and build a high performance, psychologically safe, and Generative organisational culture.

For any further information on how to build high performing organisations and teams, get in touch at tom@tomgeraghty.co.uk.

 

Measuring Psychological Safety in your Team

measuring psychological safety

We know psychological safety is crucial for high performance teams, and particularly so for technical delivery teams. Innovation is so critical for creating products that delight customers and serve critical business needs, and psychological safety is a fundamental enabler of innovation.

Below are ten questions that you can ask yourself or your teams to determine the level of psychological safety in your team. Rate agreement with the below statements on a scale of 1 – 5. 5 being “completely agree” and 1 being “completely disagree”.

When carrying this exercise out with your team, perform the survey anonymously – if it’s possible that your team are psychologically unsafe, they will be more likely to be honest if the survey is anonymous. If the team are very psychologically safe, then it won’t matter if the survey is anonymous or not.

It is also important to allow for qualitative, verbose feedback for each question as well, because that verbose feedback will facilitate and clarify some of the actions that you may need to take in order to improve these scores.

  1. On this team, I understand what is expected of me.
  2. We value outcomes more than outputs or inputs, and nobody needs to “look busy”.
  3. If I make a mistake on this team, it is never held against me.
  4. When something goes wrong, we work as a team to find the systemic cause.
  5. All members of this team feel able to bring up problems and tough issues.
  6. Members of this team never reject others for being different and nobody is left out.
  7. It is safe for me to take a risk on this team.
  8. It is easy for me to ask other members of this team for help.
  9. Nobody on this team would deliberately act in a way that undermines my efforts.
  10. Working with members of this team, my unique skills and talents are valued and utilised.

To explain the context behind each question:

1 – On this team, I understand what is expected of me.

It is essential that team members understand what is expected of them in terms of delivery (speed, quality, cost, and other factors) and behaviour (everything from dress code and punctuality to coding standards) to foster psychological safety. Ensure tasks are clear and well defined, behaviour expectations are explicit, and negative behaviours are dealt with.

2 – We value outcomes more than outputs or inputs, and nobody needs to “look busy”.

Outcomes (such as revenue generated or satisfied customers) matter more than outputs (emails sent, lines of code written, or meetings attended). If the team focus on what truly matters to the business, they are safe to make decisions that can improve outcomes, even if those decisions reduce output. The ideal is a team that possesses enough psychological safety to decide not to do something that could make them look good in the eyes of others, but doesn’t deliver outcomes for the business.

3 – If I make a mistake on this team, it is never held against me.

A psychologically safe team will never blame a member of the team for a genuine mistake if their intentions were good. Indeed, by enabling mistakes to be made without a fear of blame, you enable innovation and risk taking that can drive your organisation ahead of the competition. Utilise systems thinking and DevOps approaches to prevent mistakes before they happen or mitigate the impact of mistakes when they do.

4 – When something goes wrong, we work as a team to find the systemic cause.

Related to the previous point but important enough to warrant its own question, a system of discovering the root causes of mistakes and failures means that not only do team members feel able to take risks without being blamed, but every single “failure” is an opportunity for learning and improvement. By building psychological safety through these retrospective exercises, everyone on the team gets to learn from mistakes, meaning mistakes are a gift, not a threat.

5 – All members of this team feel able to bring up problems and tough issues.

In a psychologically safe team, all members of the team are able to bring up problems and tough issues, ranging from personal struggles to concerns about other (even senior) members of the team. This psychological safety is crucial for allowing both vulnerability to show when you’re struggling and need help, and courage to raise difficult topics.

6 – Members of this team never reject others for being different and nobody is left out.

Evidence shows that diversity in a team results in higher quality products and happier team members, but diversity in itself is not enough: it is crucial that team members are all included in decision making and delivering results. To facilitate psychological safety (and high performance) every member of the team needs to be invested in the decisions made and the outcomes generated. This is particularly crucial for remote and distributed teams, where it is more difficult to see if a team member is becoming disengaged.

7 – It is safe for me to take a risk on this team.

Mistakes happen unintentionally, but risks are about taking actions that might not work, or may have unintended consequences. Psychological safety provides the framework for positive risk-taking, enabling innovation and ultimately, competitive advantage.

8 – It is easy for me to ask other members of this team for help.

In psychologically unsafe teams, team members try to hide their perceived weaknesses or vulnerabilities, which prevents them from asking for help. In a psychologically safe team, members prioritise the team goals over individual goals. Helping others helps achieve the team goal, and because team members feel safe to ask for that help, psychologically safe teams achieve more of their goals than unsafe teams.

9 – Nobody on this team would deliberately act in a way that undermines my efforts. 

In an unsafe team, members compete with each other to achieve their individual goals, and may even undermine other team members if it could benefit them or it is perceived that doing so may elevate their “rank” within the team or organisation. In a psychologically safe team, that counter-productive competition doesn’t exist, and the success of the team is more important looking good in the eyes of others.

10 – Working with members of this team, my unique skills and talents are valued and utilised.

We all bring our own unique experience, skills and knowledge to the teams that we’re in, but we also bring our own prejudices and biases. In a psychologically safe team where members are valued for being their true selves, biases are less likely to manifest. Indeed, team members may feel safe enough to identify, raise, and discuss their own biases or those of other team members. By doing so, we provide space for each individual to maximise their potential from utilising their own unique skills and talents.

Regularly Measuring Psychological Safety

By measuring the degree of psychological safety on your team, you can begin to build your own unique strategy for developing and maintaining it. For instance, this may involve running more regular retrospectives or by workshopping the team’s values and behaviours.

Measurement is only a tiny part of the process. Download a complete Psychological Safety Action Pack full of workshops, tools, resources, and posters to help you measure, build, and maintain Psychological Safety in your teams.

Remember to be patient: this is a journey, not a destination, and work on your own psychological safety too. You can’t effectively help others if you don’t look after yourself.

Take this survey for yourself.

DevOps, Psychological Safety and Resilience Engineering

The Links Between Psychological Safety, Resilience Engineering and DevOps

Note: since writing this, I’ve learned a lot more about resilience engineering and its relation to DevOps and psychological safety. 


Psychological safety is cited as the key factor in team performance by numerous studies including Google’s Project Aristotle and the DORA/Google State Of DevOps Reports. The evidence shows that teams that operate in psychologically safe environments where they can present their true selves at work, take risks, admit mistakes, and ask for support from their teammates, significantly outperform other organisations

However, establishing psychological safety is rarely prioritised by delivery-focussed leaders who use output-oriented metrics. Instead, these leaders tend to focus on objectives, metrics, and modern practices such as value-stream alignment and cross-functional teams. While these have great value, and will go some way, or indeed a long way, to drive performance and delivery, they are not the full picture.

It can be very challenging, particularly for less experienced leaders, or capable leaders in difficult circumstances, to build and facilitate psychologically safe environments. This is particularly true in technologically-oriented organisations where the domain is complex and failure is explicit, obvious and can generate a large blast radius. 

Mistakes happen. They must happen.

In a psychologically unsafe team, a software engineer who makes a mistake in a complex system and releases a small flaw into production that later causes an outage may be blamed for the mistake. The flaw will be easily attributable, and the impact of the outage can be significant. In many organisations, the resultant fear of error can dramatically slow down the rate of change and speed to market.

Of course, the converse is not appealing either; it’s not acceptable to tolerate errors, outages, and mistakes. Speed to market with a faulty product or service may be equally as bad as a significant delay to reach the market. Customers do not tolerate poor quality services, so we need to build high quality services and do it at velocity. This delivery at pace is one of the key tenets of DevOps, and an effective DevOps culture requires psychological safety.

Resilience Engineering and Psychological Safety

In my work on psychological safety in high performance teams, I’m often asked about how to achieve it, and whilst there are many general approaches that overlap significantly with principles of excellence in servant (or empathetic) leadership, there are also specific actions and approaches that are suitable specifically for technology teams. Here, we’re going to drill down into one of the key aspects of a DevOps approach: Resilience Engineering, and how psychological safety is a fundamental component of resilience.

Resilience Engineering is a field of study that emerged from cognitive system engineering in the early 2000s, largely in response to NASA events in 1999 and 2000, including the failure of the Mars Climate Orbiter. It is defined as “The intrinsic ability of a system to adjust its functioning prior to, during, or following changes and disturbances, so that it can sustain required operations under both expected and unexpected conditions.” Erik Hollnagel

Resilience Engineering is the intentional engineering of a system (a sociotechnical system, such as a community,  organisation, or nation) to anticipate, detect and respond to both external and internal changes, planned or unplanned, to the system itself and continue to operate whilst change occurs.

Very little theory within this domain has been generated that doesn’t emerge from studies of real work; Resilience Engineering exists within high-stakes domains such as aviation, construction, surgery, military agencies and law enforcement and is becoming more visible in DevOps and Digital Transformation.

There is a difference between robustness and resilience engineering,  as described by David Woods, Professor, Integrated Systems Engineering Faculty, Ohio State University. Technological measures such as autoscaling, failovers, retries and queues, for example, only really contribute to robustness, not resilience:

  • Decoupling and reducing dependencies between components
  • Utilising microservices and containerisation
  • Autoscaling applications based on demand
  • Creating self-healing applications and systems
  • Using monitoring and visibility tools to facilitate responses to out-of-bounds events
  • Adopting error budgeting instead of (or in addition to) uptime measures
  • Using automated code testing, continuous integration and advanced deployment practices

robustness vs resilience

These approaches extend to concepts such as chaos engineering. This is where flaws and interruptions are intentionally introduced in order to examine how the system behaves and help engineers identify how they can improve it.

DevOps practices such as these help to build and improve psychological safety, through facilitating safe risk taking , and resilience Engineering requires psychological safety to be present, because it is only psychological safety that enables people (the adaptable component of a system) to anticipate, respond and adapt to changes and challenges.

The formation of DevOps teams

As a new DevOps-oriented team moves through Tuckman’s Forming-Storming-Norming-Performing cycle, it relies more and more on cultures and practices that facilitate risk taking and admitting mistakes. If these practices are not embedded, the team will never be able to progress to the “performing” stage, because high performance explicitly requires innovation, and therefore, risk taking. Without psychological safety, teams will cycle around the Storming and Norming phases as elements change in or around the team, such as people leaving or joining.

It is only once an engineering team reaches the high performing stage that they can truly deliver high quality services at velocity. By utilising resilience engineering principles and DevOps practices, engineers are supported to take risks, experiment, deploy changes and recover quickly. They can feel comfortable in the knowledge that if something did go wrong, they’d find out straight away, before customers start calling. These practices, far from being so-called “soft” skills, are measurable by solid metrics that describe velocity whilst maintaining reliability, such as Change Rate, Mean Time Between Failures (MTBF) and Mean Time To Restore (MTTR).

Engineering Team Topologies

Resilience Engineering echoes many capabilities with the concept of Site Reliability Engineering (SRE), introduced by Ben Traynor’s team at Google in 2004. SRE practices and capabilities may be implemented by an expert, dedicated, shared SRE team, or it may suit your organisation to embed an SRE function into each stream-aligned (SA) team if the products and systems are large enough to justify it. Alternatively, it may be feasible to empower software engineers themselves to carry out SRE responsibilities if your systems are small enough.

In addition to expert leadership practice, well organised teams, adopted shared values, systemic root causes being diagnosed in retrospectives, and an embrace of continuous improvement, we must adopt capabilities that empower team members to carry out their roles without fear of failure. In a technology team, those capabilities are the very same ones that enable high velocity change, security, and reliability. 

For more information regarding technology team organisation, Matthew Skelton and Manuel Pais explore in great depth how software teams can be organised to deliver most value, safety, and performance in their book “Team Topologies”, where they examine how the concepts of Conways Law, Cognitive Load and Organisational Evolution converge. 

Resilience engineering is about entire organisations, not just technology.

Whatever team you’re on, or whatever team you lead, considering resilience engineering principles will improve delivery, safety, happiness, and performance. This enables people to work without fear, psychologically safe in the knowledge that errors do not flow downstream. This place is where true high performance, speed to market, quality and innovation happens.

Psychological safety is also a core component of Agile delivery teams, as it fundamentally enables truthful communication, response to change, and the ability to make mistakes and innovate.

Build your own high performing teams with psychological safety

For more information about high performance teams, psychological safety, DevOps, or any of the other concepts covered in this article, get in touch. I’m always for collaboration, speaking at events, podcasts, or other ways to get involved and help teams become more productive, safer, and most importantly, happier.

Download a complete Psychological Safety Action Pack full of workshops, tools, resources, and posters to help you measure, build, and maintain Psychological Safety in your teams.

@tom_geraghty

tom@tomgeraghty.co.uk 

Psychological Safety in High Performing Teams – Digital Lincoln Meetup April 2020

This is a recording of a webinar I did for the meetup group Digital Lincoln on the 28th April 2020.

Psychological Safety in High Performing and Distributed Teams

Safety isn’t just necessary in order to prevent disasters, it’s also crucial to building and maintaining high performance teams and organisations.

Building high performing software requires high performing teams, in which team members need to feel able to express their creativity, talents and skills without self-censoring, self-silencing, or fear of failure. In this talk, Tom introduces the latest research in high performance technology teams, and provides actionable concepts to help you build and elevate your team, whether co-located or distributed and remote.

Download a complete Psychological Safety Action Pack full of workshops, tools, resources, and posters to help you measure, build, and maintain Psychological Safety in your teams.

Find out about Psychological Safety and Information Security, and more here about high performing design teams who utilise psychological safety.

Tom is an expert in transforming team performance. A “veteran technology team builder” according to Computing Magazine, Over his 15 years as a technology leader, he has come to believe that culture trumps strategy, and happiness precedes success.

Tom is currently the Head of Technology at MoreNiche in Nottingham, CTO of Ydentity, an identity protection startup, and a management consultant for Q5. Outside of work, Tom is a yoga teacher and mountain biker.

https://www.crowdcast.io/e/missile-destroyers