Over the past weeks, I’ve had a lot of talks, webinars, and podcast interviews (the launch of The Tech Executive Operating System is going well, thanks for asking!). I often talk about the magic that happens when you incorporate regular innovation into your team’s schedule. Unsurprisingly, I notice the same sorts of objections again and again from leaders all over the world and of teams of all sizes. They all seem to have the same knee-jerk response, full of incredulity, “you mean we should just let them do what they want??”

I have thoughts about tackling this objection in the specific case I bring up in my talks, but in this article, I want to tackle the issue at the root of this and how it connects with poor engineering impact.

The Fear

In all ranks of leadership and management, from team leads to the upper echelons, there’s frequently a reluctance to genuinely let the staff do things on their own. This might be based on bad past experience or general disbelief that the team can be given this freedom.

Left to their own devices, you’re thinking, the team might waste days and days doing irrelevant stuff. They might step on other people’s toes (e.g., add features that Product specifically didn’t want). Perhaps they’ll use a tech stack so bleeding edge that you’ll never be able to hire a single soul that has prior experience. I’m sure you can already list out quite a few nightmare scenarios.

But, as long as you have this fear, you will not be able to truly let your team grow and become autonomous. Our end goal for doubling and tripling impact-per-engineer is to create an organization where we can trust the people to work in structures of fully autonomous and empowered product teams. But, that will never happen as long as you feel the need to keep them on a leash.

It Takes Two to Tango

No doubt, you can list out good reasons not to provide your team with more leeway. However, I’m here to say that your team isn’t working in a vacuum. Whatever you fear will happen is only possible if you and the rest of the leadership team enable it. More often than not, this fear is rooted in too much ego on the leadership side to let the team fail and learn on its own. There’s no malicious behavior here. It’s merely an issue of acquiring a skewed perspective with time. There’s a natural bias to view others as less capable of achieving things you think you know how to do. It’s a weird trick our brain plays on us that makes us have gatekeeping-like thoughts even if we don’t realize it.

You’ve spent dozens, hundreds, and sometimes thousands of hours to acquire this talent in your team. You’re paying them a small fortune every month. And yet, you think they cannot be given some freedom to decide about the next steps or what they should do.

There are two common issues here. The first is that there’s this belief, this gatekeeping bias I talked about. The fix starts with you—stop thinking they can’t do it. I always use the example of my service in the Israeli Intelligence Corps: can you imagine having a bunch of 18-year-olds with no prior experience in charge of systems that provide mission-critical and life-critical intelligence? Knowing that a bug might be the difference between a terror attack prevented on time?

That’s due to many reasons, but one of them is the fact that an experience acceleration pressure-cooker is created (one of the subjects of my upcoming Did You Just Waste a Good Crisis? free webinar. This then rapidly pushes people through a “seniorification” process that mints Product Engineers. Instead of trying to protect your ego from seeing the team succeed without you (or seeing them fail under your supervision), and rather than coddling them, let’s set them up to become independent. Don’t be a master of puppets pulling their strings—let them become real kids like Pinocchio! (Ok, I’ll stop it with the analogies here)

The second underlying issue is that your team might be prone to doing the wrong thing because you’re not teaching them what really matters. When you expect them to not be able to discern where their focus would be best applied, it means that you’ve failed to provide that focus in the first place. I go on and on about Product Mastery (the subject of two different chapters in The Tech Executive Operating System) precisely because it is an enabler for getting alignment. This mastery is dependent on the guidance of the leadership team, not the engineers.

All this to say that whatever it is that’s blocking your team from more autonomy, the root cause—almost always—is a leadership team that needs to up its game. I’ve seen this transition happen successfully at clients worldwide; you can do it too. Make a leap of faith and let go of guiding them. Then create the organization around them to enable their growth. There’s no other route to success.