Managing your boss when they don’t know what you are doing.

I remember when I resigned from a previous job having a boss who promised we would spend several hours a day doing hand over so he could learn my job.  He was new to  the business and felt he needed to be across what I did.  This was cool, I do like talking about myself and my skill set so I was happy to oblige.  But as the 4 Weeks notice rolled by and my would be leader spent our scheduled hand over sessions talking on the phone to his mates, and buying stuff for his rumpus room from Grays On-line I started to get a bit jaded about the whole process.

When we finally did manage to get a session together he opened by explaining to my why the Master network Diagram was too complicated.  I calmly explained that the *master* network diagram is meant to be complicated and if someone can’t read it, that’s a good indication they should not be in the Network team.  My old boss loved that diagram, it was a central point of truth in a chaotic world, and formed a connect the dots style diagram for fault finding. It had also been my baby for the last 3 years, so I was perhaps a little disappointed by this statement, but prepared to let it slide as I thought I could learn something from this fellow.  The feeling that I wasn’t really important to this guy was compounded in our next session (which occurred after 3 missed sessions) when I started needing to explain Slash notation as a way of determining subnets.  This lead on to a 45 minute conversation on how our private network was based on super-netting supplied by head office and part of his duties would be to break /20 networks into /26 & /27’s as they  represented a nice round number for our typical branch offices.  The thing that really killed the relationship though was when he asked me to explain V-LANing to him as he seemed to think using a Cisco 3750 to join two disparate C class networks into one was some form of propriety black magic.  Despite the fact the Senior Network Engineer was sitting with us at this point and assured him that he knew how it worked (and in fact set the damn thing up) no amount of coaxing or prodding would convince the guy that this wasn’t important and that I wasn’t lieing to him and in the end I was perhaps a little blunt and questioned his technical abilities, which pretty much ended our hand over sessions. I could write a book on things I learn’t not to do from the 4 weeks I got to spend with this guy, but perhaps the most important was “Don’t ask dumb questions”.

I have a colleague doing something similar at the moment with a guy that’s leaving, Its driving me nuts and I want to point this out to him, but there’s not a delicate way to do it.  As a Tech you have an area of expertise that becomes your own little world.  Even at quite senior levels your skill set and background determine how you look at things and the way you approach problems.  As a former Network Engineer I can tell you that 90% of all problems can be solved with a Layer 3 approach (and the remaining 10% are probably Dev issues.) So for the most part techs will forgive you if you try to pull an issue back to your skill set to make sense of it, but when you out and out ask a dumb question with no reference to their skills and expertise you are heading for failure.

If you don’t get something suck it up, write a note and remember what a great man once said ‘Google is your friend.” but whatever you do don’t ask dumb questions.

One thought on “Managing your boss when they don’t know what you are doing.

  1. Pingback: The importance of listening. | Back of a Coaster

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s