How often have you had to deal with a crotchety admin, or an academic who does it all by the book, or worse - the loose wheel who is sure he knows it all? If your experience is anything like mine, there is at least one of these folks on every team. As frustrating as these people can be, they often have some value. To quote Harvey B. Mackay, author of the book Swim with the Sharks without Being Eaten Alive, “It isn’t the people you fire that make your life miserable, it’s the people you don’t fire that make your life miserable.” As leaders, we have to deal with customers, vendors, our own leadership and highly technical people every day. And, as with all people, they come in all shapes, sizes and temperaments. I thought it might be of interest to reflect on some of these stereotypes as well as some of the techniques I have developed to work with them in relative harmony.
The Crotchety Admin
This one is so obvious to everyone that there are dozens of parodies on TV and film. My team named the problem CAS (Crotchety Admin Syndrome) many years ago. There is that one person in the back room that barks at anyone who doesn’t speak the language of their technical discipline. These people are somehow paradoxically dangerous and saviors at the same time. When I am researching or trying to understand a new project, I will seek this person out because they will tell you just how they see it. They know what not to do, and what should be done without any consideration of financial, cultural, or political impact. It’s critical as a manager to collect their information and consider it carefully. This gives you a good place to start your planning that’s grounded in reality. Every organization needs one of these. Make sure their role is not customer facing and insulate them to a healthy degree, but not any further. Make sure they have to mentor and train future crotchety admins. The things they know are not in any books.
"It’s critical as a manager to collect their information and consider it carefully"
In theory, academics know exactly what they are doing. These folks are easy to spot. They have alphabet soup after their name on their business card or email signature. We used to call this “paper CNE’s” in the Novell days. I have nothing against academics. I consider myself one to a degree. The theory is that people that know what to do generally can’t pass the required certification tests. This is because their real world experience has taught them that the technically correct answers don’t work very well and that nobody worth their salt would use it. These folks are great on your team to work on organizational issues, doing analysis and evaluations, but don’t expect them to build servers, or slam out switches and routers.
The Loose Wheel
This is the most dangerous person on any team. This is the person who thinks they know what they are doing but does not have the experience, or has simply not spent the time studying to understand the impact of their actions. The unintended consequences can be huge. Make sure to implement the policies, processes and governance to keep these folks from doing harm. I advocate leaving the decision to give someone admin level access up to the senior folks on your team and to deliberately leave it an informal process. At the senior level, they own their environment and should know best about something that is incredibly hard to gauge as a manager with our own perceptions and biases. And in the long run, they will be responsible for fixing whatever this person does wrong.
Every vendor has a “guy” somewhere. This is the person that has worked there since their garage startup days and understands things about their product that no one else does. If you have a problem with a certain product that has gone on too long, you need to find this person. The “guy” will take it personally and be excited that you have found a bug in their system. They will welcome the opportunity to dive into the complexities required to resolve it. A warning: Be prepared to be deservedly humiliated if your escalated problem isn’t truly a problem but something stupid you did. Interestingly, when you ask about the “guy”, your vendor will instinctively know who this is
Other things to look for in Technical People
There are many, but I want to point out a few that I always look for. The biggest red flag for me is the technical people with a dedicated fervor about an operating system, manufacturer, or application. What this means to me is that their field of expertise is narrow, and if you have to make a quick left as an organization, they are worthless in that effort. I prefer folks who may be very experienced at certain things, but have enough general knowledge to pretty much “figure it out”.
Another is folks who don’t have some sort of plan to perpetually self-educate. This is a clear indicator of their passion for their craft. This could simply be subscribing to trade rags or attending regular meetings of a shared knowledge group. Techs need to compare notes with others and have a sounding board for their ideas with people who get what they are talking about. This is critical in our business as things change so quickly. I insist on this on every person in my team and do it for myself.
Last is folks who can’t immediately answer where their function stands in the overall big picture. This could be poor communication from management, but even then, they should have some general idea. In my book, failure to do so basically means that they either don’t care, or haven’t taken the time to consider their impact on your organization.
I have been collecting hundreds of these little observations for years and am never wanting for more examples to fill the pages. The way I see it, it’s our job to identify these folks, place them in the right positions, and to make sure they have what they need. That way we all succeed together.