Encourage teams to take risks

In any given moment we have two options: to step forward into growth or to step back into safety.

— Abraham Maslow

This last Sunday we went on a light hike with my mother-in-law who is in the process of converting her Ford Transit into a small camper van. Part of the process is cutting a hole in the roof to install a vent fan to keep air moving and keep it cool in the summer. As you can imagine It’s a bit intimidating to take a drill and a saw, climb on the roof of your new van, and cut away a section of it.

She did it, all on her own. Drilled the holes, cut out a section, all despite her initial intimidation at the project.

As we were walking she told me she was grateful that I always tell her she can do it. Whether it was cutting a hole in her van’s roof, or learning to drive her pickup truck and trailer. She said it always made her feel like she could do it, that she could accomplish something that she didn’t think she could.

Now, before you start thinking this is all about me, let me pull a couple of important leadership lessons from this conversation, because they are broadly applicable, and I use them every day while leading engineering teams.

The first lesson is that we should encourage people to take risks.

Encourage them to go big, to step into something that they aren’t fully comfortable with. One way to think about any kind of growth is as a series of calculated risks. You don’t get better at riding a bike by just pedaling along on your Peloton. You’ll get stronger, but strength isn’t the only skill needed to ride bikes well. To get better you have to push just a little beyond your current skill level, until that becomes your new skill level.

So whenever my Mother-in-law tells me she doesn’t think she can do something, I am quick to encourage her. To give her the confidence to try it. No matter the outcome it will be a chance to learn and grow.

Part of our job as leaders is to encourage people to take risks they are interested in taking, and that make them nervous. That brings us to our second lesson, make sure they have support in taking the risk.

To do this well we have to know our people. We have to know what they are good at, what they are bad at, and what support they are going to need to be successful in whatever they are tackling. Because now our job as leaders is to work as hard as we can to ensure they have what they need to be successful.

My mother-in-law is an artist, and very very detailed in the way she approaches her paintings. So, because I know her, I know she is going to very carefully lay everything out, and that any mistakes will be minor ones. She isn’t going to freehand a cut between equally freehanded holes. She’ll lay it out and carefully follow the cuts.

If we are working with a team member who is similarly meticulous we don’t have to worry about them blowing things up, and most of the support they need is just the encouragement to go for it.

That said, in the event it did get messy, we want there to be some guardrails to help. In this case I am the guardrail. I’ve been working on cars since I was 15 and woodworking for longer than that. If it went badly sideways, she knew she could call me at any moment and I would rush over to help sort it out based on my past experience.

In our work we may not always be the best guardrails for a team member. But, with a little work we can identify what those guardrails should be. I love using RFCs(Request For Comments) for large features and new services because they provide opportunity for team members to grow with minimal long term risk. The checkpoints and conversations help them learn architecture by doing it, and allow the team at large to help them grow.

There are many ways that we can provide support. From process, to mentors, to POCs(Proof of Concepts), to pair programming, we have a lot of tools here.

And we need to use them, because growing the people on our teams is the most important thing we can do.

There are obviously times where this can be taken too far. Maybe don’t let that intern design the core of the software ecosystem all on their own because they are enthusiastic about architecture. But maybe, give them a mentor who can guide them and let them be an integral part of developing that design.

I am not advocating throwing people in the deep end of the pool and seeing what happens. Not at all. What I am saying is that developing our teams is a massive competitive advantage.

So next time someone on our team comes to us and tells us they want to lead a project, or tackle that tricky ticket, have an open conversation with them about what resources they need to be successful. If they’re not ready, have them pair with someone who is to work on it. And make sure that they hear us encouraging them to go for it, and then finding them the support they need to grow into it.

If you enjoyed this article please share it! Also, I have a newsletter that you might enjoy as well. Thanks! -Daniel