Imagine a hypothetical scenario in Medtech IT solutions where their team loses four hours of troubleshooting what should have been a simple EHR integration. Why? Because a junior developer was petrified to admit they had forgotten to update a configuration file. By the time they finally spoke up, with welled up eyes the damage was done—not just to the timeline, but to the team morale.

That moment changed how Medtech IT solutions lead healthcare IT teams.

After 25 years in this field, I have seen how psychological safety makes or breaks projects that directly impact patient care. I have watched brilliant developers sit silently in meetings, their game-changing ideas never seeing the light of day. I have also seen what happens when teams get it right—how they catch potential disasters before they happen and create solutions that genuinely improve healthcare delivery.

This is not just management theory. It is about whether your team can build technology that healthcare providers want to use and patients can trust with their lives.

Who This Is For

If you are:

• A healthcare IT manager wondering why your talented team is not performing.
• A developer who hesitates to point out problems in code reviews.
• An analyst who has spotted a workflow issue but fears being labeled “difficult.”
• A C suite trying to figure out why the sales cycle of digital products keeps stalling.

…then grab a cuppa and settle in. This might just change how you work tomorrow.

What Does Psychological Safety Look Like in Healthcare IT?

Amy Edmondson coined the term “psychological safety” back in 1999, but what does it look like in a healthcare IT context?

It’s the QA tester who feels comfortable saying, “I think this patient matching algorithm might create duplicate records for people with hyphenated names,” even when everyone’s eager to launch.

It’s the scrum master who admits, “I think we need to reconsider our sprint commitment—I missed something in the requirements.”

It’s the product owner who says, “I was wrong about that feature priority. Let’s pivot based on what we learned from the clinicians.”

When I talk about psychological safety (Edmondson, 2019), I am not talking about a workplace where everyone gets participation trophies and critical feedback never happens. I am talking about a place where:

• Truth matters more than harmony.
• Learning matters more than looking good.
• Clinician needs and Patient safety matters more than project timelines.

And where everyone from the newest intern to the leadership team can speak these truths without fear.

Why Healthcare IT Teams Need This More Than Most

The stakes in healthcare IT are ridiculously high. A bug in a banking app might mean a temporary financial inconvenience. A bug in medication ordering software could harm or even kill someone.

This creates a paradox: we need people to speak up about potential problems more than in almost any other industry, yet the high stakes can make people more afraid to do so.

Consider these scenarios I’ve witnessed:

• A digital security architect in a hospital noticed a potential security vulnerability but didn’t mention it because the last person who delayed a go-live was reassigned to a less prestigious project.
• A systems analyst realized a workflow would not work for night shift nurses but stayed quiet because they had been labelled “not a team player” after previous feedback.
• A database administrator had concerns about data migration integrity but did not voice them because “the decision had already been made.”

Each of these situations leads to preventable problems that ultimately impact patient care.

A recent study explores the impact of psychological safety (PS) on agile teams’ behaviors that enhance software quality. Findings indicate that PS fosters quality-related behaviors, such as speaking up about issues, admitting mistakes, helping colleagues, and engaging in problem-solving, creating a supportive environment where errors are reported more frequently, leading to error correction and prevention. PS also promotes knowledge sharing, collaboration, and collective problem-solving, driving innovation and better solutions to quality challenges. The study concludes that PS is a crucial social factor for improving software quality and suggests combining social strategies with technical tools. It also highlights the need for future research, including case studies and longitudinal studies, to explore the relationship between PS and software quality. Data and materials from the study are publicly available for further examination (Alami et al., 2024).

Imagine a large health system baffled by why its $50 million EHR implementation was floundering despite having top talent. What if the issue was that employees were hesitant to report problems or deliver bad news to higher management? As a result, decisions were being made based on what leadership wanted to hear, rather than the reality on the ground.

Maslow’s Hierarchy in the Server Room

Remember Maslow’s Hierarchy of Needs (Maslow, 2022)? It turns out it applies perfectly to healthcare IT teams as well.

Physiological and Safety Needs

When I stepped into my role as a subject matter expert back then in 2004, I inherited a team that was working 80-hour weeks during a critical system implementation. They were sleeping under their desks, subsisting on vending machine food, and missing family events. Some were worried about losing their jobs if they did not comply.

Nothing I did to encourage innovation or collaboration mattered until I addressed those basic needs: implementing realistic work hours, ensuring job security, and creating predictable schedules.

As one of my senior developers told me, “I can’t worry about improving our code quality when I’m worried about whether I’ll see my kids this weekend.”

Belonging and Esteem Needs

Once those basics were covered, we could focus on creating a sense of belonging and recognition. This meant:

• Celebrating team wins (not just individual heroics)
• Creating spaces for people to connect beyond work tasks.
• Ensuring everyone—regardless of role, background, or personality type—felt their contribution mattered.

One practice that could move the needle: is by starting a “contribution mapping” during project retrospectives. Instead of just discussing what went well or poorly, teams could explicitly map out how each person’s work contributed to the outcome. This could help everyone see how their piece fits into the bigger picture, especially for those in less visible roles.

Self-Actualization in Healthcare IT

At the top of the hierarchy, we want teams that are innovating, finding meaning in their work, and reaching their full potential. This is where healthcare IT can be exceptionally rewarding—few technical fields offer the same opportunity to directly impact human lives.

When a team member told us, “I showed my mom the patient portal I helped design, and she cried because it was the first time she could understand her medical information,” we will know we were reaching this level.

Building Psychological Safety: What Works?

1. Make “I Don’t Know” and “I Made a Mistake” Normal

The most powerful moment in changing our team culture comes during a high-stakes meeting with the C-suite. When asked about a timeline issue, instead of spinning or deflecting, what if we were to say “I don’t have that information right now, and I need to investigate before giving you an answer.”

Seeing us admit we did not know something changes our perspective. If you can do that, I can admit when I’m stuck instead of suffering in silence.”

Try this tomorrow: Start your next team meeting by sharing something you got wrong or don’t know. Ask for help. Watch what happens.

2. Create Feedback Channels That Match Your Team’s Diversity

Some of my most valuable insights have come from team members who never speak up in meetings but have sent thoughtful emails or comments in collaborative documents.

What if establishing multiple feedback channels could do the trick:

• Anonymous digital suggestion box.
• Regular one-on-ones with a “What’s one thing we could improve?” agenda item.
• End-of-sprint retrospectives with both verbal and written components.
• “Open door Fridays” where anyone could drop in with concerns.

The key is recognizing that different people communicate differently. Their most introverted infrastructure engineer rarely speaks in meetings but provides critical insights through written channels.

Try this tomorrow: Identify your quietest team member and create a specific opportunity for them to provide input in a way that matches their communication style.

3. Bring in the Outsiders

In healthcare IT, we often become so focused on technical constraints that we lose sight of the human impact of our work. One practice that has transformed my teams is regularly bringing in “outsiders” to provide perspective:

• Nurses who will use the systems we are building
• Patients who will interact with our patient portals
• IT professionals from non-healthcare sectors who can challenge our “that’s how healthcare works” assumptions

When you are designing a new clinical documentation system, why not invite a group of night shift nurses to review your prototypes? Their feedback could completely change your approach to the user interface—they could point out that the bright white backgrounds you’d designed would be painful to use during nighttime hours and suggest an alternative that we’d never have considered on our own.

Try this tomorrow: Identify someone outside your immediate team whose perspective you have not considered. Invite them to your next design review or planning session.

4. Make Purpose Visceral, Not Just Intellectual

Healthcare IT professionals generally understand intellectually that their work matters. But when they feel it emotionally, everything changes. That’s when the ‘Meaning’ aspect of PERMA comes into play (Charles-Leija et al., 2023).

The IT team could participate in what they call “Shadow Days,” where team members spend half a day following clinicians who use their systems. Watching a nurse struggle with a search function that was designed by a UX expert —while a patient is waiting in pain—changes how we prioritize work forever.

How about in your teams you keep a “Lives Improved” board where we post stories and thank-you notes from clinicians and patients? During stressful projects, it could remind everyone why the work matters.

Try this tomorrow: Share a specific story about how your team’s work directly impacted patient care—positively or negatively. Make it concrete and personal.

5. Reward the Behaviors You Want

In one organization I worked with, leaders said they wanted innovation and open communication. But when performance review time came around, they rewarded people who:

• Never missed deadlines (even if that meant cutting corners).
• Never “caused problems” by raising concerns
• Always said “yes” to timeline pressure

The result? Everyone learned to shut up and comply.

What if I had the opportunity to revamp their performance review system, I would have added specific metrics around:

• Identifying potential issues before they become problems.
• Contributing ideas that improved patient safety or user experience.
• Helping colleagues learn from mistakes.

The entire team dynamic could shift. People may start speaking up because they know it would be rewarded, not punished.

Try this tomorrow: At the leadership level look at your last three performance reviews. What behaviors are you rewarding? Do they align with the culture you want to create?

The Hard Truth About Psychological Safety

Here is the thing about creating psychological safety: it requires vulnerability from leaders first. You cannot expect your team to admit mistakes if you never do. You cannot expect them to speak truth to power if you punish those who do.

The most challenging moment in leadership comes when we must stand before our team and admit that we pushed for an unrealistic timeline, which resulted in quality issues. When leaders begin to acknowledge that we failed to listen to the team’s concerns due to pressures from executive leadership, trust can begin to be rebuilt.

That admission is most uncomfortable, but it can create a space for honest conversation that ultimately saves the project.

Conclusion

Building psychological safety in healthcare IT is not some soft, nice-to-have initiative. It is a critical factor in whether your team will build systems that help or harm patients.

Start small. Pick one practice from this article and try it tomorrow. Notice what happens. Then try another.

The journey toward psychological safety is ongoing. There will be setbacks, but it can help transform teams from groups of scared, siloed individuals into cohesive units capable of solving healthcare’s most complex technical challenges.

Your end users are counting on it. Your team is waiting for it, and if you are reading this, you are probably ready to lead it.

References

1. Alami, A., Zahedi, M. & Krancher, O., 2024. The role of psychological safety in promoting software quality in agile teams. Empirical Software Engineering, 29, 119. https://doi.org/10.1007/s10664-024-10512-1
2. Charles-Leija, H., Castro, C.G., Toledo, M. & Ballesteros-Valdés, R., 2023. Meaningful work, happiness at work, and turnover intentions. International Journal of Environmental Research and Public Health, 20, 3565. https://doi.org/10.3390/ijerph20043565
3. Edmondson, A.C., 2019. The fearless organization: Creating psychological safety in the workplace for learning, innovation, and growth. Wiley, Hoboken, New Jersey.
4. Maslow, A.H., 2022. A theory of human motivation: A psychological research that helped change the field for good. General Press, New Delhi, India.