Build Your Team a Garden
Put a healthy plant in dry sand and good genetics won’t save it. Put the same plant in decent soil with water and light, and it grows with very little help. Teams work the same way. You can hire the best engineers you can find, drop them onto a team where mistakes get punished and questions get mocked, and a few months later you’ll be wondering where all that talent went.
You hired the seed
Companies put a lot of effort into choosing the seed. Interview loops, take-home exercises, calibration meetings, leveling debates. Much less goes into the environment that person lands in on day one, even though the environment decides how much of what you hired them for you ever get to see.
Strong engineers adapt to an unsafe team quickly. They stop proposing ideas in design review after the last one got picked apart in front of everyone. They pad estimates so they never have to explain a miss. They stay quiet in the retro and steer clear of the scary part of the codebase. From the outside it looks like a performance problem, and the instinct is to manage the person. Moving them or replacing them leaves the soil exactly as it was.
What psychological safety means
Amy Edmondson, the Harvard Business School professor whose research brought the idea into the mainstream, defines psychological safety as a shared belief that the team is safe for interpersonal risk-taking. When Google studied what made its own teams effective in Project Aristotle, psychological safety came out on top.
On an engineering team, interpersonal risk sounds like this:
- “I don’t understand how this service works.”
- “I pushed the change that caused the outage.”
- “I don’t think this plan makes the date.”
- “Can you look at this before I merge it? I’m not sure about it.”
Every one of those is useful information. On a safe team, people say them early, while the problem is still cheap. On an unsafe team they come out late, in the incident channel or the week of the deadline.
Safety doesn’t mean lowering the bar. You can hold people to high standards and still make it safe to say “I got this wrong.” I’d argue high standards depend on it, since a team can only fix the problems people are willing to raise.
Water it every day
Gardens get built through small, repeated work, and engineering teams have plenty of daily chances to build trust or wreck it.
Incident reviews are the big one. In Humans Out of the Loop I pointed out that the incident retro will go looking for whoever approved the bad change. On a team without trust, that search is the whole retro, and people respond by keeping their names off anything risky. A blameless postmortem asks a more useful question: what about the system made this mistake easy to make, and what would catch it next time? Before the room gets to that question, let the people closest to the incident tell it from where they sat.
Code review is the daily one. “Why would you do it this way?” and “What led you to this approach? I expected X” ask for the same information. One of them leaves the author defensive for the rest of the week.
Leaders go first. If you want people to admit mistakes, admit yours, in the same channels where you’d want them to admit theirs. Say “I don’t know” in meetings. Thank the person who brought you bad news early, even when the news ruins your week.
Trust grows slowly and dies fast
Gardens take seasons. A bed you plant in April doesn’t look like much until July. Trust is slower than that and less forgiving. Months of steady, fair responses can be undone by one public dressing-down in a team meeting, because everyone in the room recalculates what it costs to speak up.
Most of what you want from a strong team runs on that trust. An engineer will only try the risky idea if a failed experiment won’t count against them. A new hire will only ask for help if being stuck is allowed. Take that away and you get a team that ships the safe, obvious thing every time and never tells you what it’s worried about.
Before you go looking for better people, look at the soil the ones you have are planted in.