Rules, Rules, Rules... Being a Nice Network Geek

by Ed Hagihara

Being someone that has to partake in large amount of responsibility for a network on a regular basis, I can definitely say that it's easy for one to get extremely angry and frustrated by the 'non-techies' who just don't get it.  However, having said that, here are some general suggestions that I still TRY to live by after having been a network geek for about 7+ years.

1. Always be willing to help people out - I'm a strong believer that what goes around, comes around. (Keeping in mind to beware that there are those who would assume this and seek to abuse the privilege). Don't completely snub the small requests (you can put them off for a little while if you're in the middle of something). Some of your biggest kudos can come back to you from people that you'd never, ever, expect.
2. Always return your calls - you'd be amazed at the level of customer service people appreciate when you always return calls - it helps build trust that you're going to get things done.
3. Be proactive - I have several thoughts on this one:
   1. Make status calls / e-mails - If you've promised to do something for someone, give them a timeline in which you think you can *realistically* have it done. If you haven't done it by then, take the initiative to make the call to that person to give them status and give a revised timeline. People are way more receptive to this kind of treatment if they don't have to call you.
   2. Be observant of potential issues - If you see a problem, even if it's going to have to be handled by you, let someone know so that you're on top of the game. Any major potential concerns should always be documented and someone (preferably your boss) should be notified. Keep documentation of the notifications for CYA purposes.
   3. Problems with people (this is important!) - It's impossible to completely get along with everyone, no matter how hard you try. If you get someone that's going to be irate at you for whatever reason, think about the potential for the situation to be escalated. Most of the time, you can kind of tell as to whether or not it'll get escalated to your boss. If you even THINK it'll get escalated, let your boss know in order to protect yourself and your boss. If your boss gets blindsided, he/she can't help you. In most cases, this will work in your favor since when the issue does hit, your boss can assist in mitigating the situation.
4. Be patient - I feel strongly enough about this one that I should really make this number one.  I've known many people that won't take the time to explain the basics to someone who doesn't understand. Most of the time, it's been my experience that the people are grateful for a little primer, and you'd be surprised how much a little patience can go a long, long way. The flip side of this is that there are also many people that really *don't* want to know and could possibly care less.  Use your best judgment -  in those cases, just fix the problem and move on.
5. Learn to keep good documentation - This is critical when you come walking into a new network job, *especially* if the network is unwieldy. If you document the items as you learn them, you'll always have a frame of reference and it will make it easier for someone else to pick up in case you want to take a vacation.
6. Good teamwork - make sure that you share the information with your team members. The ones to watch out for are the kind of teammates that keeps critical knowledge to themselves because they like to be the 'hero'. Often when things blow up they're nowhere to be found. Trust me - you make yourself WAAAY more valuable by keeping the information flow going - these are people that you work with, and you need to learn to cover each other's backs.
7. Take responsibility for your actions - If I mess up, I'm usually the first one to admit it. In some cases, if I think I've screwed up bad enough, I'm likely to tell my boss about it rather than let him/her find out about it from someone else. It shows significant responsibility on your part and credibility for screw-ups that are not yours.  This brings me to my next point:
8. Don't assign blame, just fix the stupid problem - When something catastrophic does happen - and it will - many people start pointing fingers.  You can defend yourself if you've covered yourself sufficiently, but it makes everyone's life easier if you can just focus on the problem and worry about the fallout later.
9. Don't be afraid to take some initiative - This is kind of a double-edged sword that requires some serious judgment on your part - it may or may not be appropriate in some situations.  I can't imagine being a senior tech and not having some opinions about how things should be run.  Speak up honestly about how you feel the direction should go, but also make sure to understand that this may open you up for some criticism - think about what you're putting on the line.
   
   Having said that, as a general rule, I've found that those who are willing to put themselves at risk are people that are showing a desire to move farther (yes, I know some people do this just to be obnoxious too). However, this usually needs to be tempered because you don't want the risk to be become reckless.
   
   Me, I have kind of a tendency to always bite off a little more than I can chew - this comes about from having an attitude of "I'd rather be kicking myself for failing than to never have tried at all". And unfortunately, as much as I hate to admit it, I do my best work and learn the most when I'm under extreme stress - usually at the short-term expense of other things that's happening in my life.
   
   The absolute worst for me was the tail end of 2001 (Oct. - Dec.), when I had to execute a datacenter move that entailed about 50+ servers, AND get a Solaris Cluster / Veritas Netbackup solution into place with our vendor, AND get a web-based e-commerce production environment out the door by Jan. 1 of the next year. It didn't necessarily help that our development team had a 'cowboy' that would recommend the entire restructure of the environment after almost all of it was in place! I STILL can't believe that that was pulled off without a hitch. I hope I never have to do that again.
   
   The truly amazing thing about the datacenter move was that afterwards, I expected a tremendous amount of fallout. Well, when I came in that Monday morning, it was, well... silent. It was downright scary - I kept waiting for the other shoe to drop, but it never did. We had a few minor glitches, but really, we pulled it off without anything extreme happening!
   
   
10. Work till the job is done - I'm a firm believer that if you're holed up with something, stick around and finish it so you don't have to worry about it later. Again, if you can't make the deadline, make sure the communication piece has happened. But also be realistic:
    
    I recently did a Novell 4.x to Win2k migration over the course of a couple of weekends. The first weekend I started the migration too late. Once I realized that I was going to run out of time in doing it, I postponed it an additional weekend, which gave me a little more breathing room to prepare for other additional things I didn't realize that I hadn't accounted for. This also kept me from trying to kill myself finishing it up.