Managers: Coach Psych Safety For Better Outcomes

As managers or executives, the most important thing we do is hold the bar high for our company culture and values, both up and down the org chart. If you want teams that have the high psychological safety necessary in order to take risks and innovate, it means building that into every day team processes and conversations.

How do you hope your team would be described when it comes to collaborating? What do you intentionally do in order to make that happen? We’ve talked about coaching reports on proposals, and how your team leaders can contribute to giving healthy feedback that folks are most likely to be receptive to. Managers play a big part in making this successful.

Empathy for Past and Future Teams

When we talk about empathy in the workforce, it counts for past projects, too. A high risk area I often see is expressing anger with past teams, rather than curiosity. It can be easy when you’re frustrated or when something is already going seriously wrong to throw your hands up in the air and say, “What were these idiots thinking?” Those idiots were usually just like you, but working with different trade-offs and resources than you might have at present.

I was on a team where we inherited a mess of code. It was difficult to wrap your head around and build context for the world. The only standard seemed to be to do things in a non-standard way. The documentation was all over the place. As a junior team member it felt impossible to make progress or learn the right way to do things. I felt set up for failure and it was wearing on me. The senior engineers on the team constantly were laughing at how awful some code was or saying how they would never write something so horrible. How were those engineers even working at the same company as them? Clearly, the previous engineers were all simply unworthy.

Then, one day, I met one of the first engineers on the project and I heard the story of how the application came to be. It was originally built as a 20% project, but then the idea caught on. It was still a massive improvement over the mess of spreadsheets the company was previously using but their little tool that they hacked together was now a critical piece of infrastructure. They had no FTEs, no product manager, and no one to push back and say no for them. The code needed to be overhauled because, at the time, it wasn’t built for most of the current use cases in mind.

The original band of 20%ers managed to get something that worked better, but not necessarily something that worked well. Fast. Cheap. Good. Choose two. Sometimes engineers are surprised when the business picks Cheap and Fast, but there are times when that’s the right move. They had proved this was something the business needed. Now I was part of the staffed team that was an investment in doing things well instead.

When this kind of blaming behavior doesn’t get shut down, (especially) more junior team members become more hesitant to speak up. They don’t want their teammates wondering why they’re stupid, like the last group that was on this project, if something goes wrong or they make a mistake. Every time your team thinks it's okay to talk about past coworkers the way those “senior” engineers did, the newer engineers will also take note. I know I did. You won’t get their fresh perspectives or new ideas this way.

Some manager playbook plays to use when you’re hearing or seeing your reports start to blame, insult, or shame:

Shut it down: Hey, we don’t do that here.

This is for the stuff that’s just straight up mean. I’m all for giving feedback in a way that allows people to save face, but remember, sometimes the rest of the team needs to see what lines you don’t tolerate crossing. The important part is to move the conversation on swiftly. This is not up for debate, and we can acknowledge the person understands the misstep. We saw something bad, we called it out, we’re moving on.

Retake: Would you like to try that again?

I had a mentee refer to this as “getting Clippy’d” by me once, and I laughed. It’s a good descriptor. “Hey, it looks like you’re trying to improve a complex system. would you like to phrase that kinder?” I find this one to be most useful in a private chat, but the Clippy version of it often gets at least an awkward-dissipating laugh out of groups in the right situation.

Trebek: Please state your objection in the form of a suggestion.

If discussions are steering into the unproductive lane, this can be a great way to keep it actionable. My proudest moment was in a heated group discussion when an engineer who did not report to me said, “Ok we all know Steph is about to ask us what’s actionable, so let’s all take a breath and focus on that.”

Turn the Table: How would you coach an engineer to avoid this situation? What about an engineer who was already in it?

This is great for when the feedback might not be unkind, but it is uncharitable. Challenging your manager or senior engineers to think about how they’d coach the behavior pushes them back into what they actually need to do at the moment. That can often be enough to get their “ah ha” moment back on track.

• Curiosity Cat: I find this is best done in a 1:1, though I know a handful of managers and staff engineers who do this well in groups live and in the moment. Start by asking questions meant to guide empathy. “Why do you think they might have done that?” “How would you have handled this?” “What do you know now that they might not have at the time?” The important part here is to ask with a plain and curious tone. NOT as if you already know the answer. Challenge them on their philosophy. I’ve successfully guided multiple engineers to quietly realize “for themselves” that they’re the asshole in the situation.

Celebrate the Good

Culture is what you reward and what you punish. 90% of that comes from the reward side. When you’re seeing engineers do a spectacular job with empathy, whether it’s for a past project team, a customer, or a co-worker in another department, put a spotlight on it for everyone to see.

At Loop, my current gig, the company makes a point to publicly call out wins daily. It makes me so happy when I see my folks called out for fantastic work. It creates psychological safety when people see others having difficult conversations and getting rewarded when they work it out and move on.

At Google, I’ve kept messages from when more senior folks thanked me for challenging them. Each one made it a little bit easier to take the risk for the next one. Private or public, make sure you’re acknowledging the person who is trying to do the right thing, even when it’s scary.

Failure makes you better, but only if you let it.

If you or your team find yourselves thinking, “Wait. Why is this hard?” you’re probably about to fall into a trap. Ask around to see if you can find someone who can shed light on what didn’t go well on a project. I’ve often found that these are usually the people who have been at the company for a while. They unofficially become the historians, and they can tell you who to talk to about why your problem might be harder than it initially looks. Challenge your engineers to shake out that history and improve their solutions.

On one of the projects I was most proud of at Google, our managers had us do exactly that. We were attempting to do something a previous team had tried. They (constructively and graciously) tried to warn us off of the idea, and they talked to us about where things failed for them and how.

I remember sending our updated requirements to the team after listening to them, and I received a comment from a senior engineer I really respected who said something to the effect of, “Ok, now I think you might be onto something here.” Their feedback had been heard, valued, and acted upon. Their confidence in turn built our confidence.

A few years later, the project was no longer an experiment, but a successful system. I was now the manager of the team who owned it, and I was encouraging other teams to adopt the same model we used. In the process, I got to work with the previous manager of the failed attempt and one of the engineers from the failed team. In both cases, the manager and the engineer were thrilled to hear that something great had come out of what had been a tough situation for the team at the time.

It would have been commendable for that team to just shake off that bad experience and move on to the next idea. But by making sure the company got the full value out of their failed attempt, they had a huge hand in making the next attempt successful.

If your team winds up with a failed project despite everyone’s best efforts, it’s time to reflect and it’s time to storytell. A retrospective that gets shared or presented widely just might be the piece that pushes another team forward. As a manager, I’ll always take failures building into later successes as a sign of a mature engineering organization.

So go forth. Fail productively. Engineer with psych safety.