There’s virtually no chance that you’re reading this and don’t already know that the key to unlocking your team’s effectiveness is empowering them. I don’t see many tech executives who need to be told this. You can directly see that when you don’t empower them and don’t delegate, you end up micromanaging them, and they cannot be as creative and impactful as they otherwise might be.
Micromanagement is still too prevalent in many organizations, big and small. However, I have noticed the opposite happen as well. That is when we veer too far here and provide vast autonomy without proper guidance and constraints. When that happens, there are two direct consequences. First, without the right constraints, teams often end up pursuing things that are of interest to them but that don’t end up moving the needle. Think about technology for technology’s sake or a “labs”-like team that does novel things that no one cares about at the end of the day. Second is that this freedom for the team ends up limiting the influence of the leaders.
This might sound weird at first. We’re talking on and on about empowerment, and then here I am saying that it can be harmful? That’s because there’s no on/off switch here. It’s not that you either empower and delegate or that you don’t. In fact, there’s a tradeoff here, and you have to strike the right balance for your team and your unique situation. There’s no scientific formula here; you will have to work to get the balance that’s “just right” for your circumstances.
Nevertheless, you can take a few steps right now to mitigate the issues of too much freedom. Here are the two that I’ve found most useful when advising clients (they are covered in more detail in my upcoming book, The Tech Executive Operating System, along with more impact recipes. See below for details).
Impact or No Act
First, you have to put a stop to any pointless work. You have to supply all efforts with a focusing lens—your company’s objectives and goals—so that the team achieves tangible impact.
It is sometimes better to do nothing at all than do work that does not end up moving the needle. Think of the thousands of lines of code that were written to support future cases that never ended up happening or the dozens of features that the team has to keep maintaining even though virtually no one is using them.
As autonomous and empowered as the team can be, it has to work within the constraint of achieving business results. Otherwise, you’re not running a business. You might think that this relentless focus on business goals is too demanding, but I’ve seen too many teams chugging along and pushing out features, only to realize later that it was all pointless—it didn’t matter. That tends to burn out teams faster than working long days.
It is your role to convey the company’s objectives and strategy clearly to your organization. Tech executives are often the bridge in the company between the business side of things and the technical side.
Guidelines with Commander’s Intent
Another concept that’s extremely valuable both for allowing you to work on what really requires your attention and for maximizing your impact, is thinking in guidelines, not solutions. In the Israeli Defense Forces, the term “commander’s intent” is used quite a lot to talk about leadership that does not require constant supervision. Soldiers who are in the middle of an operation and lose radio communication should know what to do even when they cannot get to their commander (just to be clear, I served in the IDF but solely as a keyboard jockey! Risk for me was having my phone’s battery run out). Having a framework to weigh different options and know what is the better one to take is understanding the commander’s intent. That is only achieved when the team is not spoon-fed solutions whenever there’s an issue.
You can apply the same kind of thinking to your day-to-day. Rather than having a default response of answering the question you were asked, try to address the meta-level issue first. Why is your input needed? How do you formulate your decision and how can those rules be explicitly shared with the team? Can you draw a straight line from your company’s value to your actions?
When you are vigilant about noticing these issues and do not succumb to the urge to merely supply an answer, you slowly accumulate guidelines that your team can then use on their own. I used to recommend to clients to write these down only if they were managing big teams, but recently with the spread of remote and asynchronous work I realized this is incredibly useful at any stage. No, you are not likely to have anything as thorough as the McDonald’s employee handbook, but you can get close enough.
Mindfully forming these guidelines is also a way for you to drive your impact across the company. You don’t need to be involved in every single decision, but you do need to ensure that those decisions will be made using the right considerations and thinking.
These guidelines end up serving as constraints that amplify autonomy rather than curtail it. They help the team make decisions faster, work on the right things, and spend their time solving the right kinds of problems.