Psychological Safety at Work: How to Tell If a Team Has It
November 13, 2026
Amir Tavafi
12 min read
Psychological safety at work is the team condition everyone agrees matters and almost nobody measures well. Most companies ask about it in an annual survey, read a number, and then argue about what moved it. We build workforce intelligence at Abloomify, and the pattern I keep seeing in customer data is that safety leaves traces in the work itself, weeks or months before a survey picks anything up.
Key Takeaways
Q: What is psychological safety at work?
A: Psychological safety at work is the shared belief that you can ask a question, admit a mistake, or disagree without being punished for it. Amy Edmondson named it in 1999. Google's Project Aristotle later reported it as the strongest predictor of team effectiveness among the dynamics it studied.
Q: How do you know if a team has psychological safety?
A: Watch behaviour instead of mood. Questions get asked in public channels rather than DMs. Pull requests get looked at by more than one person. Bad news arrives while it is still fixable. Post-incident reviews name the system that failed, not the engineer who was on call.
Q: Can you measure psychological safety without a survey?
A: Partly. Team-level work patterns show the behaviour: review wait time, self-merge rate, how widely reviews spread, after-hours activity, meeting load. Abloomify reads those from GitHub, Jira, and calendars through API integrations, PII-free. A short survey still tells you how the week felt, which no metric does.
Q: Does employee monitoring reduce psychological safety?
A: Screenshots and keystroke logs tell a team you expect the worst of them. 2026 survey research found 1 in 6 workers would quit over surveillance, and a Personnel Psychology meta-analysis found no evidence that monitoring improves performance. You cannot audit your way into candour.
Q: Who owns psychological safety on a team?
A: The manager sets most of it, mainly through how they react the first time someone brings bad news. Executives set the ceiling. If a VP takes apart a missed date in front of forty people, team-level warmth will not survive it.
What is psychological safety at work?
Psychological safety at work is the shared belief inside a team that you can ask a question, admit a mistake, raise a risk, or disagree with a decision without being punished, mocked, or quietly marked down for it, and it describes the team you are in rather than how brave you happen to be. Amy Edmondson named it in 1999 while studying hospital teams, and found something counterintuitive: the better teams reported more errors, not fewer. They were not worse. They were willing to say so. Google's Project Aristotle landed on the same idea years later and reported psychological safety as the strongest of the team dynamics it looked at.
The part that gets lost in most workplace versions of this is that safety is not comfort. Edmondson pairs it with high standards. A team that feels safe and is held to a low bar is just pleasant. The useful combination is a team that can be told its work is not good enough and will say so about yours.
Why the annual survey is a lagging indicator
The annual engagement survey is a lagging indicator of psychological safety because it asks people to self-report candour on a form their employer administers, which means the teams with the least safety are exactly the teams whose answers you can trust least, and it arrives months after the behaviour it is describing has already settled into habit. I am not against surveys. They capture how a quarter felt, and nothing in a dashboard does that. The problem is timing and self-report. By the time a score drops in the platform team, the senior engineer who stopped flagging risks did that in March, and two juniors have already learned from watching her.
There is a second failure that is harder to talk about. When the score comes back low, the instinct is to run a workshop. Workshops do not change the thing that taught people to stay quiet, which is usually one specific meeting where someone got taken apart in public.
What psychological safety looks like in work data
Psychological safety shows up in work data as a set of behaviours a team either does or avoids: asking questions where everyone can see them, putting up a draft before it is finished, getting code reviewed by someone other than the one friendly teammate, raising a slipping date early, and talking about a failed deploy as a system problem. None of those is a mood. Each of them leaves a record in GitHub, Jira, Slack metadata, or a calendar, and each has an opposite that is just as visible. Review wait times stretching to days. Self-merges climbing. Reviews concentrating in one or two people. Retro notes that stop mentioning anything that went wrong.
The ones I would look at first, in order:
- Time to first review. Long waits teach people that asking for help is expensive, so they stop asking and ship bigger changes alone.
- Self-merge rate. A rising share of pull requests merged with no review usually means review feels like a tax or a trial.
- Review spread. If three engineers review everything and the rest review nothing, knowledge and permission are both concentrated. Our piece on measuring engineering collaboration without monitoring goes through this in more detail.
- Change failure rate and what happens after. Failures are normal. Whether they get discussed openly is the signal. DORA metrics give you the first half of that.
- After-hours work and meeting load. Both predict the state where nobody has the energy to raise anything. Sustained overload reads a lot like disengagement, and it shows up in the same burnout detection signals.
Read these at team level and as trends. A single engineer's self-merge rate is noise, and treating it as a verdict is how you turn a health metric into a performance accusation, which costs you the safety you were trying to measure.
Does monitoring software destroy psychological safety?
Monitoring software undermines psychological safety because the install itself is a message, and the message is that leadership expects people to cheat and has decided to watch for it, which is a strange thing to say to a team you then want to bring you bad news early. The research is not kind here either. 2026 survey research found 1 in 6 workers would quit over surveillance, and a Personnel Psychology meta-analysis found no evidence that monitoring improves performance. So the trade is real cost against an unproven benefit.
The other thing surveillance does is corrupt the data you wanted. People optimise for the metric that is being watched: mouse movement, green dots, keystrokes. We wrote about the mouse jiggler problem because it is the clearest example of a monitoring stack measuring theatre and reporting it as productivity.
Abloomify sits on the other side of that line by architecture. Two data layers: 100+ API integrations that read PII-free signals (no email content, no message content, no file content), and optional privacy-first device agents that report aggregated usage with no screenshots, no keyloggers, and no screen recording. Leaders see delivery and collaboration patterns. Nobody reads anyone's messages.
The four stages of psychological safety
Timothy Clark's four stages give you a ladder instead of a single score, and they are worth knowing because teams tend to stall at a predictable rung: inclusion safety (you are accepted as a member of this group), learner safety (you can ask, experiment, and be wrong out loud), contributor safety (your work is treated as real contribution), and challenger safety (you can question the plan, including your manager's plan, without it costing you). Most tech teams I have seen get the first two reasonably well. Stage three gets uneven as teams grow and credit concentrates. Stage four is rare, and it is the one that saves money.
Challenger safety is where the actual return is. It is the difference between four people privately thinking the migration date is fiction and one person saying it in the planning meeting. This is also where AI has quietly raised the stakes. Large language models are very good at making you feel confident about a bad decision, which means a team that will not challenge a plan now has a tireless machine ready to agree with it. Someone has to push back on the calls that matter.
How to raise psychological safety on an engineering team
Raising psychological safety on an engineering team is mostly a matter of changing a handful of visible norms and then keeping them when it is inconvenient, because people calibrate on what happens during the bad week rather than on what the values page says. Here is the short list I would actually run, and each item has a signal you can watch to see whether it took.
- Run blameless post-incident reviews and publish them. Signal: incidents that produce written reviews, and whether those documents name systems rather than people.
- Set a review service level, something like first review inside one working day, and treat a breach as a team problem. Signal: time to first review, trending down.
- Rotate reviewers deliberately. Signal: review spread across the team instead of two bottlenecks.
- Ask for problems directly in one-on-ones. "What is the thing you have not told me yet" beats "any blockers?" Signal: how often risks surface before a date slips.
- Let people see the data you are reading about them. A team that knows what is measured stops guessing, and the measurement stops feeling like a trap.
- Watch the manager's load before blaming the team. A manager with 14 reports and 25 meeting hours a week does not have the attention this requires.
I will admit the uncomfortable part of this. Some of what looks like low psychological safety is low trust in a specific person, and no norm fixes that. The data gets you to the conversation faster. It does not have the conversation for you.
How to measure psychological safety without surveillance
Measure psychological safety at work by combining a short recurring survey with team-level behavioural signals from more than one system, keep the analysis at team level, and show the team the same view you are looking at, because measurement that happens in secret produces the exact silence you are trying to detect. The survey answers how it feels. The work data answers whether behaviour matches. When they disagree, that gap is the most useful thing on the page: a team that reports high safety while self-merging 40% of its pull requests is telling you something about which answer was the safe one to give.
This is the part Abloomify is built for. Connect GitHub, Jira, Google Workspace or Microsoft 365, and the signals above get computed for you, PII-free, with role-aware permissions on who can see what. Bloomy, our AI analyst, can run the review on a schedule and email a team health brief every Monday, and each run stays open as a conversation you can push on. You get a trend instead of a once-a-year number.
None of this makes a team safe. Norms and managers do that. The data just means you find out in week two instead of at the exit interview.
If you want to see your own review patterns, workload, and delivery signals on real data, book a demo and we will walk through it with you.
FAQ
What is psychological safety at work?
Psychological safety at work is the shared belief inside a team that you can ask a question, admit a mistake, or disagree with a decision without being punished or humiliated for it. Amy Edmondson named the concept in her 1999 research on hospital teams. It describes a team condition, not an individual personality trait.
What are the four stages of psychological safety?
Timothy Clark describes four stages: inclusion safety (you belong here), learner safety (you can ask and get things wrong), contributor safety (your work counts), and challenger safety (you can push back on the plan). Most teams get the first two and stall before the fourth, which is the one that catches expensive mistakes.
How do you measure psychological safety at work?
Use a short recurring survey for how it feels, then check behaviour in team-level work data: time to first review, self-merge rate, how widely reviews spread across the team, after-hours activity, and meeting load. Abloomify reads those from GitHub, Jira, and calendars through API integrations, PII-free, with no screenshots and no keyloggers.
Can a team have too much psychological safety?
A team can confuse safety with comfort. Edmondson pairs psychological safety with high standards, and the combination is the point. Safety without standards produces a pleasant team that ships late. Standards without safety produce a quiet team that hides problems until they are expensive.
Does remote work make psychological safety harder?
It removes the cheap signals. You cannot read a room over Slack, and silence looks the same as agreement. Remote teams have to make safety explicit: written decisions, questions in public channels, reviews spread across people, and managers who ask directly instead of waiting for someone to volunteer a problem.
Amir Tavafi
Co-Founder & CEO
Product leader and innovator with over 15 years of experience in the tech sector, grounded in AI and robotics. Previously led product development in fraud detection and AI solutions at Nasdaq Verafin.