Often within teams there is a certain shared camaraderie and level of trust between team members. They chew the fat, have a moan or playful poke at other staff during a day’s work. They cover for each other and stuff usually gets done. At the end of the day, they spend more time with each other than family.
Occasionally, however, you get a lone wolf admin who gets into the team. When I say “lone wolf admin”, I am not talking about quiet or shy individuals. I'm talking about the glory hunters. Those that don’t play well within a team and are happy to throw others under the metaphorical bus. When these types get into a good and stable team, bad things can and do happen.
Lone wolves can be a danger on a number of levels, not only to good team relations but also potentially to the company’s bottom line. A lot of people may well recall Terry Childs as an example of this phenomenon. He viewed every other sysadmins around him as a clueless idiot who should not be trusted with anything more than walking the floor. He even went so far as to not commit router configs to NVRAM so that he was the one they would have to call if someone reset the device or attempted a password recovery.
These types of people have been around since the inception of the IT department. The difference is that in these modern times, IT is everything to most companies and the potential for damage a lot greater.
Recently, my team had a new guy join its ranks. Initially, he seemed fine. His credentials stacked up. I had no say in his hire or otherwise. I was called upon to show him the company way of doing stuff. He didn’t really join in the banter much, which is understandable when you’re new, but got on with his tasks in hand.
Soon afterwards, the team started to encounter issues we hadn’t really seen that much before. This guy – let’s call him “Tim” – had been given a major project and wanted to prove himself as the best of the best. He wanted to be the go-to person for this technology.
Some of the team saw it as a bit of a slap in the face, but let it slide. It wasn’t Tim’s fault, after all. After a few weeks, something strange started to come to light. A lot of the team were losing the interesting parts of their own projects. It transpired that Tim was hoovering up parts of other peoples’ projects, left, right and centre. He was going outside the department and direct to customers or managers to get the work. As a group we began to talk – and it appeared the same issue was happening to all of us.
Through other channels we found out Tim was working until 2am each morning to get these project bits done. Work started to dwindle and the team as a whole were unhappy. Tim sure wasn’t doing himself any favours. When we confronted management, we were told: “It is just his way.” The management approach to the issue should have set alarm bells going in any reasonable company.
What a lot of people miss is that when individuals hoard information and knowledge as a tool of power over others, they become a weak point in the system. Documentation and knowledge needs to be maintained, so that when something goes bang while you are eating your Sunday lunch, you aren’t scrabbling round for fragments of information to try and fix the issues. If you don’t have a Wiki-style document repository where people can add designs, hints, tips and known issues, you really are missing a trick.
Despite repeated attempts to wrangle documents and designs out of Tim, he would either point-blank refuse to share, ignore people or just plain lie and claim they were not ready, while distributing to management as a method of glorification. This caused resentment in the team and it made people feel openly hostile towards him.
Frequently, team members would attend meetings, only to find that Tim had already had previous secret meetings with a vendor and had the contacts and informal knowledge transfer sewn up. We only got to know what Tim wanted us to know.
These kinds of situations, where there is a risk to information, are exactly the reasons why forward-thinking companies send staff to places via different planes. There is a risk that all that domain knowledge – along with management functionality – could be lost, at least in the short term. If Tim had been hit by a bus, major client-facing projects would have been critically or fatally wounded. Thing was, he was getting more unpopular by the day and London buses are difficult to get hold of.
Within a month or two, two members of the team had either moved or left.
This brings me to the reason I wrote this. Often when we go for a job, a potential employer wants this certificate or that certificate. What they often miss, to their detriment, is the really important stuff of being a genuine team player. Technology can be learnt. If a new admin is a good person and fits in well, colleagues will share all their information and tips. But if that individual doesn’t work well with others, the group will potentially start to see disruption in an otherwise good and stable team. This means less will get done, even though there are more staff.
What happened to Tim? The true, honest answer? No-one knows. One day he failed to turn up to work, citing personal issues. This went on for several weeks until it was announced that Tim would not be coming back. This in effect meant the team had to rebuild what they could in missing information and timelines. Projects were hampered.
We survived, if only by the skin of our teeth and the loss of a few good admins. ®