It has become common knowledge that psychological safety is key to team performance and essential for mental health. Google’s famous quest for the perfect team (Project Aristotle) empirically led to psychological safety as the number one trait of healthy teams. Here are three observations from a 30-year career that may be undermining psychological safety on your team:
If you have expected norms around behavior, communication, work style, etc. that are implicit vs explicit, they threaten psychological safety. As you scale, it will be difficult and anxiety-ridden for everyone to remain on the same page when “the page” is in your heads.
“Smart people will figure it out” doesn’t work in teams with healthy levels of diversity (hopefully you’re not just hiring people who think like you to build an echo chamber; a topic in itself). Everyone will figure out a different way, and waste precious mental energy doing so!
The solution does not need to be draconian. A lightweight solution I’ve seen work well is the Agile Team Working Agreement. Have a team discussion, capture expected norms, and treat it as a living document which is reviewed and revised as needed. Now agreed norms can be easily referenced, encouraging accountability without wasting time and inducing stress.
We often joke about moving fast and breaking things, but most businesses want us to move fast without breaking things. As imperfect beings in an increasingly complex world, the only realistic way to accomplish that is building discipline around how we test.
Depending on your context, this may be a full-fledged “production-like” environment to build confidence or a few containers running on a laptop. What you do not want is no agreed strategy or every engineer reinventing the wheel. Similar to above, each engineer will approach the challenge differently. It’s inefficient, potentially unsafe, and undermines psychological safety.
Treat test environments like any other part of the product; standardize, document, automate and continuously refine! That means having them in version control, and owning them as a team to avoid the infamous “worked on my machine.”
I’ve worked in shops where every sub-task was micromanaged, and coming out of those it felt like a breath of fresh air to have less defined tasks. Most engineers enjoy a certain amount of creative freedom vs. having implementation details dictated.
That said, the other end of the spectrum is equally undesirable. For example, if you lack clear acceptance criteria, have no definition of done, don’t estimate stories, and don’t use due dates while silently expecting tasks to move at some implicitly understood pace; such ambiguity threatens psychological safety and will ultimately impact the team’s mental health.
This can be partially addressed through a healthy Agile Team Working Agreement, but also requires deliberate attention to how work is planned. Some loathe estimates, and I have seen those done in ways that added questionable value. Done well, they can be lightweight and serve as a mechanism for teams to better understand complexity. More than a specific practice, clearly and consistently communicating expectations is key.
As an explicit example of what to avoid: tickets without meaningful priority or due dates when management has internal expectations around delivery times. Putting in the effort to make expectations explicit and clear improves performance and protects psychological safety.
What are some of your favorite techniques to maintain psychological safety and safeguard your team’s mental health?