sysadmin HQ

Careers in technology can be an exercise in self defeat. Many of us in technical positions will find ourselves faced with numerous internal and external problems in the work place. One of the most challenging aspects of succeeding in a technical career path is having to step back from the technology and look at ourselves, coworkers and workplaces. The very aspects of technology that drive us and enable us to succeed in technical endeavors often blinds us from seeing and responding to “the soft side” of working – interaction, socialization and office politics.

#1. “I’m Indispensable”

It’s 7:45 PM and the entire office has already gone home, except for you. You’re busy resolving a critical issue to meet a deadline or to get your companies main assets back online. Long after everyone has left for their home and families the success of your employer rests solely on your shoulders. Or is it? With tight deadlines, non-technical managers and high levels of expectation it’s easy to fall into the trap of truly believing that your employer cannot survive without you.

IT Professionals are the creators and caretakers of the very technology that allows their employer to succeed and we’ve all been called upon to do the job that nobody else was capable enough to, or willing to complete. It’s no wonder that the number one pitfall is believing that you’re irreplaceable.

It’s a compound problem that plagues organizations across the world. Take the case of Terry Childs, the former San Francisco network administrator who held his department hostage by falling into this trap. The story quickly became a media frenzy with allegations of data tampering and ”millions of dollars in damages.” Terry was the sole administrator, designer and implementor of the network that he refused to allow anyone else to have administrative rights to. He truly believed that nobody else in his department was capable of managing the network and that was the way the network was managed since the time it was implemented. That attitude and misguided belief that he had the right to restrict and protect that network landed him jail.

So what went wrong? From day one of the implementation of  the city’s FiberWAN network Terry was the one who called the shots. He was the sole implementor and maintainer of the network and naturally that would result in him believing that he was the only one capable of maintaining it. That network should have been documented and the information shared among his coworkers. The passwords and access should have been treated as critical assets, more valuable than the network itself. Terry was the only one with administrative access and both his coworkers and managers knew it and everyone accepted that fact. His managers made a critical error in allowing a single person to hold the keys to a critical asset. The very fact that this was allowed not only is the root of the issue, but a indicator of others. What if Terry had been in an accident and was unable to communicate the passwords to anyone else? (The “Hit by a bus”, or beer truck, depending on which you prefer scenario.)

Terry thought he was irreplaceable and didn’t trust anyone; now he’s in jail.

#2. “Management doesn’t understand what we/I do.”

IT departments are often autonomous departments regardless of organizational size. This autonomy and freedom creates a systemic problem that often creates an organization wide view of IT as a brick wall and gives way to making the activities of the department or individual unknown. People don’t like what they don’t understand (whether this gives in to fear or not is a whole other topic.) When departments and people become a black hole of information the result is usually distrust. There cannot be trust without understanding.

This distrust often spreads between departments or individuals and creates black holes of information and silo’s of responsibility. When we should be working together it separates us further thus exasperating the problem. At the very first sign of a problem it is imperative that extra effort is made to head off the issue before it is allowed to grow.

So what can we do? Managers need to make sure that they have at least a rudimentary understanding of what their employees are doing and this requires both manager and employee to work together to establish that understanding. It can be as simple as spending 15 minutes at a whiteboard. Unfortunately many non-technical managers of IT departments do not take the time to understand what their employee’s are doing. As a manager I would never want to be caught in the position of being asked what my team was doing and be unable to answer.

The ability to explain a topic to someone who knows nothing about it is a direct indicator of your own knowledge of that topic.

#3. Dismissing Ideas / ”That will never work.”

We’ve all seen this one – a potential solution for a problem or an implementation detail is presented and someone immediately pipes up  stating “that will never work.” They’ve usually got a point too, but the point isn’t that it won’t work it’s that there is a concern; even if the prompter isn’t aware of it. Concerns are rooted in fear and misunderstanding and as such the number one cause for rejection of an idea is simply not understanding it. The root of the issue could be inexperience with the idea or solution presented, negative past experiences or other seemingly valid reasons in view of the prompter.

This is one of those situations where experience is sometimes a hinderance. We’ve been around long enough to know what works and what doesn’t but those same attributes which are the culmination of years of labour can also lead us in the wrong direction, limiting our view. People get comfortable with a way of doing things and deviation from that norm is foreign and uncomfortable. It’s uncomfortable because we don’t trust it. We’ve learned to rely on our experience and our knowledge so it seems counter intuitive to consider alternatives; after all our experience has been reliable and hasn’t posed a problem.

In cases like this it’s usually best to step back with an open mind as soon as soon as you feel yourself dismissing the idea. Being open to an idea doesn’t mean acceptance and it doesn’t mean you’re comfortable with it but being receptive and working together towards a goal will broaden your horizons and lead to you down a better path, a path you likely never considered.

#4. Seeing technology as the entire solution, as opposed to a tool that supports a solution.

When experienced technology professionals are asked for their input to a product or solution they more often than not immediately begin rattling off ideas in their heads about the programs or code they’ll have to write to support what they’re being asked. We’ve amassed enough experience and exposure in our careers to have a solution to a given problem that we can immediately begin thinking about how we’re going to implement it.

There are usually many good reasons for this, notably time constraints. It’s easier to rehash something you’ve done before than it is to fly back up to 10,000 feet and understand the intricate details what’s being asked of you before you dive into the details. The downside of this method of thinking is the danger of implimenting either an incomplete, or outright wrong, solution.  Lets face it, we as tech workers are in this line of work because (hopefully) we love technology, so of course we want to immediatly roll up our sleaves and start building.

It’s important to put the brakes on, and make sure you have a complete picture of the requirements and intended objectives of your project before you start building the tool. After all, it might be easier than you thought and you’ll be more of a team player than just a technical guru.

#5. “That’s non-standard, so I / my team can’t allow it”

Surprisingly, many organizations have no standards or policies defined at a management level. Maybe this isn’t so surprising, since some organizations view their IT infrastructure no differently than their plumbing or electrical infrastructure. At best, senior management delegates the creation of any IT policies to the resident floor manager or senior systems admin. You often get a “whatever you want is fine with me” response from managment, which unfortanatly results in a couple of problems. First, you have IT creating policies that directly impact business, when they likely don’t have a large enough view of the organization to truly gauge the impact of said policies. Second, since management didn’t participate in the creation of the policy, they have not bought into it and therfor the policy is toothless.

Now, this post is themed around the pitfalls of tech workers, not the companies they work for so we will focus on the first of the two points mentioned above. Many systems admins, especially those in charge of internal systems, live and die by the standards they have set forth for the operating environment. Whether it be the operating system, hardware or office automation suite, they refuse to even consider allowing something outside the norm into the environment.  This isn’t necessarily an invalid stance to take depending on the resources in your IT department and its mandate, but unfortunately it often stems from a fear of the unknown, or in the worst cases, plain laziness.  Absolutism is dangerous and often alienates people.  I’ve seen more than a few organizations that claim major “PR” problems between the IT department and the rest of the company.  A lot of the times these problems stem from IT being viewed as a hindrance towards getting things done as opposed to a valued resource.

#6. Platform Zealotry

As you may have guessed, Platform Zealtory (or PZ) means your one of those guys who lives and breathes one particular operating system or tool and will stick your nose up at anything and everything else under the sun. PZ is a great way to ensure your career will remain on a flat plateau.  This is because no one takes a Platform Zealot seriously.  PZ is synonymous with narrow views, rigid thinking and inflexibility.  It also is a sure fire way to demonstrate you can’t cope in a heterogernous environment. Sysadmins who get respect and advancement always bring a balanced, unbaised viewpoint.

It’s fine to have a preference and its fine to have opinions.  Just make sure you temper them with objective thinking, facts, and (at least) the appearance of an open mind.