Connect in some way

Connect

I’d already been heavily involved in Unix/Linux for nearly twenty years by the time I found myself assigned as the leader/manager of the Windows Engineering team.

Even some of my closest colleagues scoffed when they heard the news. How could I ever be successful without deep Windows knowledge? How could I ever gain their trust after promoting Unix/Linux solutions for so long? The previous manager didn’t have much technical Windows knowledge either and the prevailing theory was that they needed a Windows giant who could rally them around being hardcore Windows Engineers again, not some guy from Unix Operations.

Never waste a crisis

I started with the team in 2008 about the time the “Dan Kaminsky bug” came out. Patching it was an enormous coordinated effort, not just at my employer (and for my new team) but around the globe. It was pretty easy to get geeked out about it. I remember asking our Microsoft patch guru about this vulnerability and the urgency. I’m not certain he expected me to understand but he took the effort to provide an explanation.

The internet had chosen to break in an area I was already familiar with: BIND. For my first “crisis”, I was lucky. (Or perhaps my experience was sufficiently broad enough.) I understood his explanation, agreed with his urgency and let him get back to getting ready to roll out this patch.

By using what I already knew about BIND and DNS to quickly understand the situation, I connected with the team in a way that started the process of building trust.

Champion the team

Change Management is the only ITIL process purposefully designed to slow things down.¹ After all, poorly-planned or executed changes are still reported as the single-largest cause of incidents. Beyond the sheer effort of rolling out patches to a large number of systems in a short amount of time, what the team needed right then was a champion: someone to navigate and remove the roadblocks while they got ready to deploy patches.

When a manager champions a team and takes their causes for his own, it speaks volumes about how far they can trust him. Rather than ignoring the urgency of the situation, not understanding the technical details or bringing in some petty Unix vs Windows argument, taking the cause to upper management to push through the change quickly showed them early on how important the success of the team was to me.

Ultimately, we were successful and the patch was rolled out in a timely fashion without the vulnerability being exploited in our environment.

This situation gave me a few things to think about.

1. A manager needs a certain level of technical knowledge. Like a symphony conductor, he needs to understand music and have a working knowledge of many of the instruments. But he doesn’t need to be a virtuoso on all the instruments to effectively conduct.
2. A manager needs to champion his team. The last thing your team needs in a crisis situation is to be burdened by roadblocks. Navigate, hurdle and remove them (and when things quiet down, teach them how to do the same).
3. A manager needs to connect with the team. The image I chose for this post is a trio of interlocked carabiners. The connection doesn’t have to be quite so mechanical or so strong as this example, but a connected manager will notice a difference in how the team is managed.

Readers, what do you think? Do you have any examples of how being connected helped you as a manager?