Helicopter CIOs: stop micromanaging

The term “helicopter parenting” (or its less appealing alternatives like “lawnmower parenting,” “cosseting parent” or “bulldoze parenting”) describes parents involved in all aspects of their children’s life, leaving kids no space for improvisation or independence… or in business terms: micromanaging!

Now, typically, CIOs have developed and grown past the micromanagement issues, but sometimes we cannot stop ourselves from diving too deep into a topic, especially ones close to our heart, like the technologies that gave our careers their start.

I am not exempt from this behavior. For example, one of my directors is in charge of all of our SAP technology, an area where I started my career and gained over 20 years of experience. The realization came when he told me that this shared knowledge was both a great advantage and an even greater curse! He went on to explain that he never worked with a CIO who understood the intricacies of SAP and the challenges of building, deploying and running such a system globally. While this made for easier conversations and decisions, there have been times where my suggestions have lead him to question his own or, more importantly, his boss’s ideas or guidance. A tough situation indeed.

So why are CIOs such fans of the deep dive?

It feels good!

CIOs spend most of their time dealing with the complexity of strategy (are we going digital? What does that even mean?), finance (another budget cut), human resources, and plenty of other fun things. It does feel good from time to time to go back to core technology and the appeal of being an individual contributor. Yes, I admit having logged in SAP for a few days now trying to “help” with supply chain issues. But, the problem is that as leaders, we are not an individual contributor anymore and our vote outweighs everybody else’s. Your team will follow your advice irrelevant of its quality.

Fear of consequences and anxiety

Let’s face it: CIOs did not get into IT because it is the land of pink unicorns and rainbows. Every decision and every project we undertake is a mixture of risks and rewards. As leaders, we are always focused on costs, resource availability, customer perception and the list goes on. As a consequence, risk reviews can become a painful step-by-step critique of the smallest details (Failure Mode Effect Analysis anybody?). Sometimes the intent is also to be protective of the team and make sure, for their own good, that they did not miss anything. But where do you draw the line between providing experience-based assistance and micromanagement?

Overcompensation

We all had a nightmare project (or many…) that went so poorly that it redefined and skewed our perception of a particular technology (did I mention SAP before?) or process (outsourcing nightmares). So now, any time such a project comes around, we look at it like milk on the fire… will it boil over?

Peer pressure

Apparently, a CIO’s peers expect them to know everything, soup to nuts, of the hundreds of projects and initiatives going on. I am not sure where this comes from, but when was the last time a CFO was supposed to know the intricacies of asset accounting in South Korea or a VP of Supply Chain the make and model of the LTL truck picking up products at an East European Factory. We are expected to know and so we ask… and dive.

I am sure there are plenty more excuses (these are mine) on why CIOs are big fans of diving into the weeds. We need to consider the consequences of our behavior. Short project reviews which become large, deep dive exercises can take a toll on the team productivity: at best, a few hours of meetings, at worst, days and days of agonizing over PowerPoint slides. Day-to-day conversations on low-level specifics (or what we called earlier opinions) are even more disturbing. They put a lot of stress on team members, especially if they don’t have a readily available answer, undermine the leadership of functional heads and reduce the ability to innovate (I need to run my ideas by the boss) and cope with problems or failure. The leader becomes a permanent safety blanket, curbing initiative and reducing accountability — your leaders are then either leaving (A-type looking for growth) or settling into a routine.

Like many other things, the first step is to admit you have a problem and then find ways to tackle it. Since my first leadership role, I have attempted to implement some techniques to avoid the helicopter role.

• Be clear and precise of expectations from your team — you define the What and the When but stay away from the How.

• As I learned how to better dive, I make clear to my teams that my advice is what it is, just  advice. If I want something done a certain way, I will make it crystal clear.

• I am more comfortable saying “I don’t know, you should talk to XYZ in my team” when peers ask detailed questions. It’s important to realize and admit that you don’t know everything.

• I seek feedback regularly from my leaders and ask them to be diligent in telling me to get out of the way.

• I try to stay out of technical reviews, detailed workshops and process mapping if I know my inner boilings are not going to allow me to keep my mouth shut… and wait for the consensus output from the team.

The first job of a CIO is to be a leader. It can be argued that you are not a leader if you don’t have followers, and one way to get people on board is to demonstrate to them that you are not simply a disconnected guy in a suit. Rolling up your sleeves and helping at a more technical level — even more so in critical situations — shows the people who may not have known you back in the day that you are born of their world and are in fact one of them. But it has to be the exception for the right situation at the right time.

We need to change our own behaviors as we progress to help coach and manage our teams to success. A key is to adjust our need for details from a push supply chain (forcing your technical input) to a pull / Kanban model where the team will come to you and ask for support when needed.