The master value of software teams
Software teams have two identities
The first one you notice is the one the team presents to the world. This is the productive persona of the team - the one who's work is measured in bugs squashed, features delivered, recurring revenue incrementally increased and performance improved. The health of this identity is the degree to which these measurements are improving. The second identity is the one I'm covering today - this is the inner life of the team, the texture and context of which is appreciable to its members. This is the team's psychology.
The shape of the psychological life of a team is determined by the tension between what is expected and what is tolerated. As with most things, there are certain values and orientations that affect the long term happiness, motivation and self-actualization of the humans that work together. Chief among the values that highly effective teams enshrine is that of psychological safety.
Feeling Unsafe
We feel unsafe when we're afraid. What are engineers working in psychologically unsafe teams afraid of?
- Failure, and having that failure held against them
- Looking stupid in front of colleagues and superiors
- Losing professional reputation
- Being seen as a troublemaker, standing out negatively somehow.
And here's the thing - those are rational fears. If you know or suspect that your colleagues won't have your back and that your manager is most interested in assigning blame, you keep your head down and watch your own back. Here's what you'll expect to see in teams like this:
- Lack of initiative - better not to try than to risk failure
- Desire to not rock the boat. Just keep on going, even if its clear the wheels are falling off
- Covering your butt. Making sure you’re not there when the penny drops
- Culture of blame
- No joint ownership of the codebase/product. ‘Not my problem’ thinking.
The contract between a great software team and it's members goes something like this:
"You (as an individual contributor) will work in a way that prioritizes the longterm health of the business over your individual interests. The team will support you, mentor you, help you when you need help and always assume that you're doing the best you can."
The common thread through the above examples is one of individuals prioritizing themselves over the health of the business. The inverse of each of these is a trait you'd like to see in a high-performing software team. What's happened?
At some point, one party to this contract has become convinced that another does not intend to uphold their end of the bargain. Whether or not this is true is beside the point. The team needs to immediately come together to hear everyone's positions in an open and fearless way, and find a path back to universal commitment to the contract of healthy software teams. It's kind of like Tinkerbell - it only works if you believe in it.
If you're currently working in a psychologically unsafe team, the first thing to do is to bring it up. Say your piece honestly and clearly - very likely there are others on the team who feel the same dynamic but just haven't articulated it in this way. There's much more to the topic of psychological safety and this barely scratches the surface. John Looney's excellent post is a great resource if you'd like to learn more.
