Psychological safety in innovation teams: what it looks like on an ordinary Tuesday

Psychological safety is a shared belief in a team that it's safe to take interpersonal risks: to ask a basic question, admit a mistake, disagree with a senior colleague or say an idea won't work. In an innovation team, you can see it on an ordinary day: bad news comes early, the quietest person's idea gets tested, and the leader says "I don't know" without anyone flinching. You build it through small, repeated habits, not a one-off session.

What it is, and where it comes from

The definition above comes from Amy Edmondson of Harvard Business School, whose 1999 study of work teams is the foundation of the field. She found that teams with higher psychological safety engaged in more learning behaviour: asking for feedback, discussing errors, seeking information. Later, Google's Project Aristotle studied 180 of its own teams and found psychological safety was the most important of five dynamics in effective teams (the others were dependability, structure and clarity, meaning, and impact).

Two points get lost in most discussions.

First, psychological safety isn't comfort or niceness. A safe team argues more, not less, because people aren't afraid to disagree. What it removes is the fear of being humiliated or punished for speaking up. Standards can and should stay high.

Second, it matters most where work is uncertain. In routine work, you can often get by with clear procedures. In innovation work, almost everything depends on people raising doubts, sharing half-formed ideas and reporting failed tests honestly. Without safety, you get confident presentations of untested ideas.

What it looks like on an ordinary Tuesday

Forget the workshop. Here's a normal day in a team that has it.

• 9:15, stand-up. A junior designer says, "I tested the new form with three people yesterday and none of them understood the second page." Nobody sighs. The team lead asks what they think is confusing.
• 11:00, review with a director. The director asks a question nobody can answer. The project lead says, "We don't know yet. Here's how we'll find out by Friday." The director writes it down and moves on.
• 14:00, ideation. Before discussion, everyone writes ideas silently for five minutes. The newest team member's idea is chosen for a test.
• 16:30, informal chat. Someone says, "I think we're solving the wrong problem." The others don't dismiss it; they agree to look at the evidence on Thursday.

And here's the same Tuesday in a team without it: the form problem is mentioned only after the pilot launches, the project lead invents an answer for the director, the most senior person's idea wins the ideation, and the "wrong problem" comment is made in the car park, not the team room.

The difference isn't personality. It's habits, mostly set by the person leading.

How to build it: seven steps

1. Frame the work as uncertain, out loud. Edmondson's toolkit for leaders starts with setting the stage: explaining why the work needs everyone's input. Say it plainly at the start of a project: "We don't know the answer yet. I need you to tell me when something isn't working." People take interpersonal risks when they understand that their input is genuinely needed, not just tolerated.

2. Ask, then wait. Replace statements with questions in meetings. "What are we missing?" "What would make this fail?" Then stay silent long enough for people to answer. If you're the most senior person in the room, speak last. In hierarchical settings this matters even more, because people defer to seniority by habit and courtesy (see innovation in hierarchical cultures).

3. Write before you talk. Use silent methods like brainwriting, where people write ideas independently before anyone discusses them. This protects the ideas of quieter, junior or less confident team members from being drowned out. It's also good for teams working across languages.

4. Make doubt a formal step. Some people will never raise concerns spontaneously. Give them a structured moment. A premortem (Gary Klein's technique of imagining a project has failed and asking why) makes raising risks the task, not an act of disloyalty.

5. Respond well to bad news, every time. This is the step that decides everything. When someone reports a problem or a failed test, your first words should be thanks and a question: "Thanks for telling me early. What did we learn?" Edmondson calls this responding productively. One defensive or irritated reaction can undo months of work, because everyone remembers it.

6. Admit your own mistakes first. When leaders say "I got this wrong" in front of the team, they make it normal. Do it about something real, and explain what you'll do differently.

7. Review how the team works, not only what it delivers. A regular retrospective asks what helped, what got in the way, and what to change. Include one question about voice: "Was there anything you wanted to say this sprint but didn't?" Answers can be anonymous at first.

Clear roles help too. When people know who decides what, through something as simple as a RACI, they feel safer raising issues because they know where those issues go.

An example

Illustrative. A product team at a logistics company in the Netherlands is building a new delivery-tracking service. In reviews, the engineering lead always presents confidently, and the team's two researchers rarely speak. The pilot launches and customers hate it; the researchers had seen the problem in interviews weeks earlier but didn't want to contradict the lead.

The team's new manager changes three things. She starts every review with five minutes of silent writing on "what worries you about this?" She asks the researchers to present findings first, before any solution is discussed. And she runs a short retrospective every two weeks with one question about what people held back.

In the first retrospective, a researcher says she'd noticed customers misreading the delivery window. The manager thanks her and asks the team to test a simpler format that week. The test works. Over the next quarter, problems start appearing in stand-ups, not after launches. The engineering lead says later that he hadn't realised people were holding back.

Common mistakes

Do

• Treat psychological safety as a daily practice, not a training topic.
• Use silent, written methods before open discussion.
• Thank people for bad news before you ask any other question.
• Keep standards high. Safety and accountability work together.
• Make it safe to disagree with you specifically.

Don't

• Run a one-off session on psychological safety and call it done.
• Confuse it with avoiding conflict or being nice.
• Ask "any concerns?" at the end of a meeting and take silence as agreement.
• Punish the messenger, even with a sigh or a change of tone.
• Measure it by survey alone. Watch what happens in meetings.

Questions people ask

What are examples of psychological safety at work? Someone admits a mistake in a team meeting and the discussion moves straight to fixing it. A junior team member challenges a plan and the senior person asks them to explain. A failed test is reported the day it happens. A feedback capture grid is filled in honestly, including the "what didn't work" box.

How do you measure psychological safety? Edmondson's original research used a short team survey, and versions of it are widely used. Surveys help, but behaviour tells you more: how quickly bad news reaches leaders, who speaks in meetings, and whether failed tests are reported or hidden.

Can a team have too much psychological safety? Not in the sense Edmondson means. What teams can have is safety without accountability, where people feel comfortable but standards are low. The goal is both: safe to speak up, and clear about what good work looks like. For leaders, what great innovation leaders do covers the habits that combine them, and the hub pillar on innovation culture places this in the bigger picture.

Where to go next

Start with three method guides: brainwriting to protect quiet voices, the premortem to make doubt part of the process, and the retrospective to keep improving how the team works. More in the method guides.