Daniel Pinho

§ 10 Breathable Atmosphere

Context

In their work, software developers often do their jobs within an organisation that includes more than just them, with other different roles and stakeholders.

Problem

The developers’ daily lives at their place of work will be influenced by the interactions that happen between them and their co-workers.

How can organisations foster a comfortable work environment?

Forces

  • Large organisations have more resources and their structure can bring stability, but their many layers can impede vertical communication and intensify the competitiveness between teams.
  • Freedom to explore ideas invites innovation into the organisation, but it is important to keep everyone on track to avoid wasting effort and resources.
  • Stakeholders know the business priorities and often make decisions, but developers work on the development tasks and drive progress themselves, having a specific view on the intricacies of the project.

Solution

Fostering developers’ psychological safety gives them comfort and helps them to do their jobs without fear of failure. This can be done through giving them the space to speak up, share ideas, take initiative, and build working relationships with their co-workers.

\todo[inline]{add illustration}

Psychological safety is a term coined by Carl Rogers in the 1950s[1] dealing with creativity, with discussions on the topic moving to the organisational[2][3][4] and software development[5] areas during the latter half of the 20th century and into the early 21st century. It relates to how team members can take risks and be safe that the team can deal with their outcomes, regardless of these being positive or negative.

Software development tasks are full of tasks where developers are dependent on each other, such as code reviews, agile ceremonies, or other technical debates on how to approach a given feature. Software development is inherently prone to change and uncertainty[6], with shifting requirements or the need to explore new technologies. Hybrid or distributed teams are fairly common in a post-pandemic landscape[7] and bring their own fair share of collaboration hurdles to overcome, thanks to the distance or the reliance on asynchronous communication[8][9][10]. For a team to succeed facing all of these factors, it is important that developers are not afraid to speak up and communicate with their colleagues, whether they are other developers from their team or business stakeholders.

Bringing psychological safety into a team can, thus, give the developers in it the room to be bold and take initiative[11], ask for help without fear of being poorly perceived[2], provide honest feedback and speak constructively to higher-ups[12], and learn from the failures that may come along the way[13].

Fostering psychological safety can start from small practices that, in essence, give developers and stakeholders the freedom to intervene in their work without fear of retribution if things don’t pan out, bringing into the environment values like respect and trust. Examples of these practices include periodic retrospectives and post-mortems that focus on continuous improvement without blaming people for their mistakes[5][14][15], employing constructive feedback in code reviews[16][17], making use of meeting facilitation techniques such as including icebreakers, group discussions, and voting[18], and having leaders assume a posture that is curious and imperfect, where they ask for questions, recognise when there are unknowns, and admit their mistakes[19].

Another thing that is important is holding onto that atmosphere where developers feel safe to do their work: this can be done by having periodic pulse checks within the team (such as in a retrospective), making decisions and rationales visible, and revisiting these norms when teams change so that everyone is up to speed.

Examples

  • Team retrospectives (such as, for example, those found in Scrum) are examples where a team can build their psychological safety through honest feedback and assessing any mistakes that happened during a Sprint[5].
  • Google’s Project Aristotle identified psychological safety as the top predictor of team effectiveness, noting that teams that normalised speaking up, admitting mistakes, and asking questions consistently outperformed those that didn’t[20].
  • Pair and mob programming foster respectful and trusting real-time collaboration around code, enabling developers to feel safer in asking questions, surfacing concerns, and sharing ownership. This reinforces trust and builds psychological safety within the team[21][22][23].

Consequences

  • Psychological safety encourages taking risks, enabling developers to take initiative and be autonomous. This can help increase productivity and bring forth the occasional breakthrough.
  • Openness lowers barriers to speaking up and increases the flow of ideas between the people involved in the project.
  • Building a good atmosphere requires its values to be constantly reinforced within the organisation.
  • Fostering psychological safety requires a collective buy-in and support from people beyond the development team, such as stakeholders.
  • Having open communication, if not supported by facilitation tools and guidelines, can lead to meandering discussions or even conflicts.

This pattern contributes to §3 Good Feelings, while relying on quality §8 Team Players and strong §9 Stakeholder Relationships. This pattern can benefit from the Scrum Patterns[24] \href{https://scrumbook.org/product-organization-pattern-language/development-team/autonomous-team.html}{Autonomous Team} and \href{https://scrumbook.org/product-organization-pattern-language/development-team/self-organizing-team.html}{Self-Organizing Team}.

References

  1. C. R. Rogers, “Toward a Theory of Creativity,” ETC: A Review of General Semantics, vol. 11, no. 4, pp. 249–260, 1954, Accessed: Mar. 11, 2025. [Online]. Available: https://www.jstor.org/stable/42581167
  2. A. Edmondson, “Psychological Safety and Learning Behavior in Work Teams,” Administrative Science Quarterly, vol. 44, no. 2, pp. 350–383, June 1999, doi: 10.2307/2666999.
  3. W. A. Kahn, “Psychological Conditions of Personal Engagement and Disengagement at Work,” The Academy of Management Journal, vol. 33, no. 4, pp. 692–724, 1990, doi: 10.2307/256287.
  4. E. H. Schein and W. G. Bennis, Personal and Organizational Change Through Group Methods: The Laboratory Approach. John Wiley & Sons, 1965.
  5. A. Alami, M. Zahedi, and O. Krancher, “Antecedents of psychological safety in agile software development teams,” Information and Software Technology, vol. 162, p. 107267, Oct. 2023, doi: 10.1016/j.infsof.2023.107267.
  6. F. P. Brooks Jr., “The Mythical Man-Month,” in The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition., Reading (Mass.): Addison-Wesley, 1995, pp. 13–26.
  7. F. Jansen and R. De Souza Santos, “Remote Communication Trends Among Developers and Testers in Post-Pandemic Work Environments,” in 2024 IEEE International Conference on Software Maintenance and Evolution (ICSME), Oct. 2024, pp. 672–677. doi: 10.1109/ICSME58944.2024.00071.
  8. A. Alami, M. Zahedi, and O. Krancher, “The role of psychological safety in promoting software quality in agile teams,” Empir Software Eng, vol. 29, no. 5, p. 119, Sept. 2024, doi: 10.1007/s10664-024-10512-1.
  9. J. D. Herbsleb, A. Mockus, T. A. Finholt, and R. E. Grinter, “An empirical study of global software development: Distance and speed,” in Proceedings of the 23rd International Conference on Software Engineering. ICSE 2001, Toronto, Ont., Canada: IEEE Comput. Soc, 2001, pp. 81–90. doi: 10.1109/ICSE.2001.919083.
  10. G. M. Olson and J. S. Olson, “Distance Matters,” Human–Computer Interaction, vol. 15, no. 2–3, pp. 139–178, Sept. 2000, doi: 10.1207/S15327051HCI1523_4.
  11. L. Delizonna, “High-Performing Teams Need Psychological Safety. Here’s How to Create It,” Harvard Business Review, no. 8, Aug. 24, 2017.
  12. A. C. Edmondson and Z. Lei, “Psychological Safety: The History, Renaissance, and Future of an Interpersonal Construct,” Annual Review of Organizational Psychology and Organizational Behavior, vol. 1, pp. 23–43, Mar. 2014, doi: 10.1146/annurev-orgpsych-031413-091305.
  13. M. Baer and M. Frese, “Innovation is not enough: Climates for initiative and psychological safety, process innovations, and firm performance,” J Organ Behavior, vol. 24, no. 1, pp. 45–68, Feb. 2003, doi: 10.1002/job.179.
  14. E. Derby and D. Larsen, Agile retrospectives: Making good teams great. Raleigh, NC: Pragmatic Bookshelf, 2006.
  15. John Lunney and Sue Leder, “Postmortem Culture: Learning from Failure,” in Site Reliability Engineering: How Google Runs Production Systems, Gary O’Connor, Ed., O’Reilly, 2016. Available: https://books.google.com?id=81UrjwEACAAJ
  16. S. D. Gunawardena, P. Devine, I. Beaumont, L. P. Garden, E. Murphy-Hill, and K. Blincoe, “Destructive Criticism in Software Code Review Impacts Inclusion,” Proc. ACM Hum.-Comput. Interact., vol. 6, pp. 1–29, Nov. 2022, doi: 10.1145/3555183.
  17. E. Sesari, F. Sarro, and A. Rastogi, “Safe to Stay: Psychological Safety Sustains Participation in Pull-based Open Source Projects,” 2025, doi: 10.48550/ARXIV.2504.17510.
  18. D. Khanna and X. Wang, “Are Your Online Agile Retrospectives Psychologically Safe? The Usage of Online Tools,” in Agile Processes in Software Engineering and Extreme Programming, vol. 445, V. Stray, K.-J. Stol, M. Paasivaara, and P. Kruchten, Eds., Cham: Springer International Publishing, 2022, pp. 35–51. doi: 10.1007/978-3-031-08169-9_3.
  19. A. C. Edmondson, “Psychological Safety, Trust, and Learning in Organizations: A Group-level Lens,” in Trust and Distrust In Organizations: Dilemmas and Approaches, R. M. Kramer and K. S. Cook, Eds., Russell Sage Foundation, 2004, pp. 239–272.
  20. Google re:Work, “Guide: Understand team effectiveness.” Accessed: Sept. 19, 2025. [Online]. Available: https://rework.withgoogle.com/intl/en/guides/understanding-team-effectiveness
  21. A. Cockburn and L. Williams, “The Costs and Benefits of Pair Programming,” Feb. 2000.
  22. L. Williams and R. R. Kessler, Pair Programming Illuminated. Addison-Wesley Professional, 2003.
  23. W. Zuill, “Mob programming: A whole team approach,” in Agile 2014 Conference, Orlando, FL, US, 2016, pp. 1–11.
  24. J. Sutherland, J. O. Coplien, L. Heasman, M. den Hollander, and C. Ramos, “Scrum Patterns,” Scrum Patterns. http://scrumbook.org/.

Last updated: December 18, 2025