Psychological safety for managing risk in embedded software development

Mistakes have led to some of the world’s most valuable inventions. Pacemakers. Penicillin. Post-It Notes.

But when it comes to embedded software or hardware, mistakes do not often lead to anything good or safe. Back to pacemakers, when embedded developers get something wrong, and a device makes it to market, the consequences can be grave before a recall happens. The same can be said for numerous embedded systems that are cornerstones in infrastructure, transport and aerospace, medtech and more. Getting something wrong here can have terrible consequences.

Process and tools can let you down

Software and hardware teams worldwide working in safety-critical embedded systems often follow a mix of risk analysis methodologies and use quality management systems and technical and project processes (including Agile or Extreme Programming) to reduce errors and risk in what they do. However, the challenge comes when we consider the things those operating modes often can’t handle.

No amount of test-first software development or completed failure mode and effects analysis will help when something you didn’t plan for crops up and no one mentions it. In a team with good psychological safety, these kinds of things will be pointed out and actioned, with stakeholders agreeing that something needs to be done, whether that’s a head of quality or a team lead. That agreement will translate to action, regardless of the cost.

It’s the teams (and businesses) without psychological safety that you need to worry about. You only need to look at testimony that uncovered what happened with the development of Boeing’s 737 MAX 8 to see what teams without psychological safety can lead to. (It can lead to scores dead and a fine of $2.5 billion for fraud conspiracy.)

What is psychological safety?

So, what do we mean by psychological safety? We're advocates of the definition developed by Timothy R. Clark in his book “The 4 Stages of Psychological Safety: Defining the Path to Inclusion and Innovation”. Clark describes psychological safety as:

“[…] a condition in which you feel (1) included, (2) safe to learn, (3) safe to contribute, and (4) safe to challenge the status quo—all without fear of being embarrassed, marginalized, or punished in some way.”

Here, “included” means you help individuals and teams to feel included, encouraging them to do the same with each other and the rest of the business. It being “safe to learn” means that there’s an acceptance of failure while encouraging learning, exchanging knowledge and giving the time to do this.

An environment where it’s “safe to contribute” means that people will put forward ideas and, if competent, be given the space to work without fearing micromanagement. And “safe to challenge the status quo” means that you make it okay for people to say what they see (even if it’s unpopular), and leaders ensure people can speak up.

Without these four elements in place, it can be impossible for individuals and teams to let stakeholders know that something might be or is wrong. Or if they do, their insights are suppressed, and they’re discouraged from speaking further, as in the case of the MAX 8’s development.

Four issues in embedded software development that can be tackled with psychological safety

1. Fear of voicing concerns: In embedded software development, challenges often arise from complex hardware-software interactions, changing requirements, and unforeseen glitches. These issues can be daunting, mainly when they appear late in development. When there’s an absence of psychological safety, these issues may go unreported due to fear of blame, leading to defects that may prove disastrous when the system is deployed. Conversely, in a psychologically safe environment, team members feel confident about bringing up such concerns, which can be promptly addressed, saving time, money and reputation.

2. Resistance to change: Embedded software development is an evolving field, with constant advancements in tools, languages, and methods. However, an unsafe environment can stifle innovation, as team members may hesitate to suggest changes for fear of being seen as disruptive or insubordinate. Psychological safety, however, fosters an environment where individuals can challenge the status quo and propose innovative solutions.

3. Miscommunication: Effective communication is vital as embedded systems often integrate components developed by different teams. Without psychological safety, team members might withhold information, hesitate to ask questions, or not clarify ambiguous instructions, which could lead to misunderstandings and incorrect implementations. In a psychologically safe environment, everyone feels empowered to communicate effectively and clarify doubts without fear of judgement or retribution. This is regardless of whether the teams involved are in-house, outsourced, or contractors.

4. Burnout: Embedded software development can be stressful due to high stakes and tight schedules. An environment lacking psychological safety can worsen this stress, leading to burnout and a decline in productivity and quality of work. Psychological safety can help manage this by fostering an environment where it’s safe to express and manage stress and where workload and deadlines can be openly discussed and adjusted.

Role of psychological safety in enhancing Agile practices

Agile practices are often seen as a means to an end for enhancing software development. They’re seen to foster adaptability, continuous improvement, and user satisfaction. However, their success hinges on there being a high level of psychological safety within the organisation.

In Agile methodology, teams work in short iterations, frequently reassessing and adjusting their work. This requires open communication, collaboration, and mutual trust—elements that can only flourish in a psychologically safe environment. An Agile team must feel safe to admit mistakes, ask questions, and challenge decisions, to continuously adapt and improve their processes and product.

Retrospectives, a critical practice in Agile, involve reflecting on what went well and what didn’t in each iteration. This exercise is meaningless in an environment where team members are afraid to admit mistakes or suggest improvements. However, retrospectives can become powerful tools for collective learning and process improvement in a psychologically safe environment.

Similarly, Agile encourages self-organising teams where every member has a voice and can contribute to decisions. This is unattainable in an environment where people fear being marginalised or punished for expressing their thoughts. Every team member feels included, valued, and heard in a psychologically safe environment, allowing Agile practices to thrive.

Avoiding the worst and enhancing innovation

Psychological safety is not just about avoiding major catastrophes but building a resilient, adaptive, inclusive, and innovative organisation. While it’s crucial in managing risk in embedded software development, it’s equally vital for successfully implementing Agile practices. Organisations can tap into their team’s full potential by cultivating psychological safety and improving product quality and colleague satisfaction.

Suppose you’d like to learn more about the implications of psychological safety to enhance risk reduction in embedded systems. In that case, you can download Bluefruit Software’s ebook on software risk and psychological safety.

But what do you think about the role of psychological safety in software teams? Let us know in the comments.

?