Free tools Windows power users keep installed

One-click scans. No signup required.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

Psychological safety can make it easier to ask questions, flag risks, admit mistakes, and disagree respectfully at work. It is a shared team belief that interpersonal risk-taking is safe—not a promise that work will be free of conflict, high standards, or accountability. For developers who feel they should already know everything, that distinction matters: individual coping can help, but the team’s everyday responses shape whether speaking up feels possible.

What psychological safety means on a software team

On a psychologically safe team, a developer can say “I don’t understand this requirement,” question an implementation choice, or report a mistake without expecting humiliation or retaliation. It does not mean every suggestion is accepted or that performance expectations disappear. It means people can take ordinary interpersonal risks while the team evaluates ideas and work on their merits.

Google’s re:Work guide describes psychological safety alongside four other dynamics: dependability, structure and clarity, meaning, and impact. Its findings came from Google’s internal team research, so they are useful context rather than a universal ranking of what matters most in every organization. Google re:Work’s team-effectiveness guide.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

How common are impostor feelings among software engineers?

A 2023 survey described in the arXiv record for Impostor Phenomenon in Software Engineers received responses from 624 software engineers in 26 countries. In that sample, 52.7% reported frequent-to-intense impostor feelings; the reported proportions were 60.6% among women and 48.8% among men. These figures describe that survey’s respondents, not all developers. The source is an arXiv preprint record, so the figures should not be presented as results from a confirmed peer-reviewed publication. Study record.

Those numbers do not diagnose any individual or explain why a person feels out of place. They do show why “just be more confident” is an incomplete response: when people anticipate a punishing reaction to uncertainty, a team may make it harder to learn or surface problems.

What software-team studies say about safety and performance

Autonomy, reflection, and performance

A 2021 survey of 236 members of 43 software-development teams in Norway modeled relationships among work design, psychological safety, and team outcomes. The authors reported that autonomy was associated with psychological safety, and that safety was associated with team reflexivity and team performance. This is survey evidence about modeled relationships, not proof that changing autonomy alone causes those outcomes. Buvik and Tkalich’s study.

Norm clarity matters too

A 2018 survey across five Swedish software organizations covered 38 development teams. It found that psychological safety and clarity of team norms predicted members’ self-assessed performance and job satisfaction; norm clarity was the stronger predictor in that sample. The practical implication is not to choose norms instead of safety. Teams need both a climate where people can speak and a shared understanding of how to ask, review, escalate, and learn. Lenberg and Feldt’s study.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

The evidence is still developing

A 2025 systematic review of psychological safety in software workplaces describes a limited research base and identifies influences at individual, team, and organizational levels, including autonomy, agile practices, and leadership behavior. It summarizes potential benefits for learning, innovation, team performance, software quality, and job satisfaction, while noting gaps in understanding context, mechanisms, and practical ways to improve safety. That supports treating psychological safety as a meaningful team condition, not as a guaranteed fix for impostor feelings or burnout. Santana and colleagues’ systematic review.

How to ask for help when you feel you should already know

Make the request specific and tied to the work. You do not have to disclose private feelings to get useful clarification.

  • Name the uncertainty: “I’m not sure whether this service should retry on a timeout.”
  • Show what you have checked: “I read the current handler and the API contract; they seem to differ on this case.”
  • Ask for the missing input: “What information or feedback would help me check this assumption?”
  • Offer a next step: “I can propose a change once we confirm the expected behavior.”

This approach makes it easier for a colleague to respond to the engineering question rather than guess what kind of reassurance you need. It does not require treating every knowledge gap as a personal failing: requirements, codebases, and team conventions are learned in context.

What managers and teams can change

Psychological safety is shared, so it cannot be assigned solely to the person who feels uncertain. Managers and teammates can make interpersonal risk-taking more routine through repeated, observable behaviors.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
  • Invite questions before decisions harden. Ask what is unclear or what assumption might be wrong, and leave room for an answer.
  • Respond to mistakes with learning-oriented questions. Establish what happened, what conditions contributed, and what would prevent recurrence before assigning blame.
  • Explain decision criteria. When a proposal is declined, describe the constraints or trade-offs so disagreement does not become a guessing game about status.
  • Make working norms explicit. Agree on how to request review, flag a production risk, escalate a blocker, and discuss a defect.
  • Close the loop on raised concerns. Say what was decided and why, including when the team cannot act on a concern immediately.

These are practical applications of the studies’ emphasis on leadership, autonomy, and norms; the cited evidence does not establish any one exercise as a proven cure.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Choose improvements by the problem you want to address

Teams can avoid relying on a one-off “speak up” workshop by identifying what is actually getting in the way and choosing a response that fits it.

Observed problem Useful target Example practice What to observe
People hold back questions or concerns Leader response and repeated team behavior Leads regularly invite questions and respond without ridicule or personal penalty Whether questions, risks, and dissent are raised earlier and receive a clear response
People are unsure how to raise issues Norm clarity Agree on review, escalation, and mistake-discussion expectations Whether team members can describe and use the norms consistently
Uncertainty is treated as an individual confidence problem Individual and team conditions Pair a specific request for feedback with a team check on how requests are received Whether the person gets the information needed and whether asking becomes routine
A workshop creates a short-lived discussion Repeated practice and follow-through Revisit team norms in retrospectives and check whether agreed changes happened Perceptions of safety, observable learning behaviors, and relevant delivery or well-being indicators

No single metric captures the whole picture. Perception measures can show whether people feel safer; behavior can show whether questions and risks surface; delivery and well-being indicators can reveal other outcomes. Interpret any change in context rather than assuming it was caused by one intervention.

Psychological safety, burnout, and AI-enabled work

DORA’s 2022 research summary reports that teams with low levels of security practices had 1.4 times the odds of high burnout compared with teams with high levels of those practices. It also reports that teams with high levels of security practices were 1.6 times more likely to have high organizational performance. These comparisons concern security-practice levels, not a direct estimate of psychological safety’s effect; DORA also cautions that context affects how capabilities work. DORA’s 2022 research summary.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

AI tools do not remove the need for clear workflows, feedback, and safe ways to raise concerns. Google Cloud’s announcement of the 2025 DORA report says its analysis included more than 100 hours of qualitative data and survey responses from nearly 5,000 technology professionals. It reports that 90% of respondents used AI at work, more than 80% believed it increased their productivity, and 30% reported little or no trust in AI-generated code. Those are AI-use and trust findings, not measures of impostor feelings or psychological safety. DORA’s framing is that AI can amplify existing organizational strengths and dysfunctions. Google Cloud’s announcement of the 2025 DORA report.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.