Stop giving your team the answer

I had an extraordinary opportunity early in my career to learn a valuable lesson about leadership.

I had smart people on my team who, nonetheless, seemed to not be operating at full horsepower. They seemed bored. They seemed like they had so much extra fuel in the tank and yet weren't utilizing it. You could tell - they weren't energized, they weren't coming in to work excited.

I couldn't understand why. We had a bunch of hard engineering challenges. We had junior people who needed coaching. We had experiments we wanted to run, and people's lives we could directly impact with our work.

I even asked them about this and none of them could tell me what was up.

It hit me weeks later as I read "Turn the Ship Around" by David Marquet.

In his book (and his talks on youtube, go find them!) he talks about being a "know all, tell not" leader. This is a leader that understands the power of not telling your team the answer, of not assuming that you even know the answer (even if you do, and you're right about it).

The problem with giving your team the answers when they have problems is that you're robbing the team of the ability to use their brains and figure out the answers themselves.

I know what you're thinking. "Won't this hurt productivity? Isn't it bad to let my team spin its wheels?"

Well, yes, it's not always great to let your team spin their wheels. That is an altogether different problem than not knowing the answer. Staring at a wall when you don't know the answer is one of many possible solutions to being in the unknown.

And, yes, it will hurt productivity. But only in the short term, and I'd argue only in the extreme short term.

On any other timescale, what you're doing is forcing them to engage. You're giving them an actual challenge, not a theoretical one. "Design this fancy architecture" sounds great but in practice is rarely actually engaging. "Why does this particular bug keep happening, and only to this particular user?" is a more interesting question. You, as the leader, may know the answer because you wrote the code 5 years ago and have seen the issue before.

But by telling your team the answer to this question, you are robbing them of the most valuable reason they (likely) joined your team: to learn. And they don't learn by being told the answer. They learn by figuring it out.

So next time you're tempted to chime in with the answer, refuse. Trust the team to figure it out. They'll come through and they'll feel better about themselves. And, as a bonus, you'll have extricated yourself from the process.

Now you can go home and eat dinner.