As a network engineer, you take pride in your hard earned skills, and so you should.  You’ve learned how to design networks. You’ve learned how to install, upgrade and configure routers.  You’ve figured out how to sniff out and fix faults.  If you study your craft and hone your technical skills then you deserve to be rewarded.  However, unless you can work with the people and process in an organization, you won’t get the career success you deserve.

Getting Started

When you start out in network engineering, everything takes too long. I like to call it the first-time-tax.  Everything is new and there are many things to be learned.  You have to  move slowly and ask for help.  Eventually you learn how to do the majority of tasks, and make fewer mistakes.  The more you know about networking, the more tasks you can get done in your limited time.  You have become technically ‘proficient’.
Remember though that you only deliver value if you can apply your proficiency to tasks that are important to your organization.  More importantly, you need to get those tasks completed with minimal friction and that is easier said than done.  You’ve got to deal with people and process; to negotiate and bargain and more importantly to build trust and credibility.

Navigating a change

There is no better test to your skills than the challenge of navigating a change management process.  Here’s a high-level view of a typical change management process.

1. you need to put together a proposed change plan
2. your change plan will need to adhere to your change management policy
3. you need your peers to sign off on the plan
4. you may need a peer to execute the plan
5. the change is executed

Your change is either successful, aborted or you cause an outage. Ouch.  If it fails then you have to look at what happens and try again.  If it works first time, well done.
But it looks like there’s a lot to do before you get to step 5; execute the changes.  You can rail against the process if you’d like but you can’t stop the process.  However change management makes sense, and you’ll need to skill-up on the process itself to get your job done.  You could have crafted the most beautiful piece of configuration ever devised, but unless it aligns with your change-management process you have wasted your time.

Building trust or losing it?

When you start working in an organization at first, nobody knows you or has any reason to trust you.   It takes a little time to get used to the process, and the changes you propose will most likely be rejected or modified at first.   This is perfectly normal and you’ve just got to roll with it.  Remember, you haven’t been effective until your change is completed successfully.
But you need to learn fast or your effectiveness will drop through the floor.   If you try to go too fast, if your reduce the quality of your changes, or take too many risks then life gets tricky.  If a negative pattern emerges, then your peers in the change management process will lose faith in you. The result is increased scrutiny and could even end with a complete loss of trust.

A tale from the trenches

When I was a network manager I hired a network engineer who had excellent technical skills.  Let’s call him Rob for the sake of illustration.  Rob very, very confident in his technical chops, perhaps deservedly so.  Our team prepared the network designs and configurations and relied upon an operations team to execute our changes.   Operations (Ops) raised a few objections during the design review, but unfortunately Rob just dismissed them and told them the implementation would be easy, “just plug and play”.  The Ops guys felt like they were being talked down to, and unfortunately they held a grudge.
When Rob submitted his changes the first change caused an outage. Of course the Ops were vociferous in their objections, but secretly they were delighted with this turn of events.    The second and subsequent changes received increasing levels of scrutiny from the operations team, and were continually rejected.  While this was going on other members of my team might typo a command and Ops would just correct it on the fly, or pop a quick email back and move on.  But each and every one of Rob’s changes were rejected from there onward.  Senior management became aware of this and started asking serious questions about my team.  Remember that Rob was completely capable of executing the configuration task and was a solid engineer, but he failed to appreciate the need to build trust.  Ultimately Rob had to leave the company as he simply couldn’t get any work done.

Sherpa Summary

So what’s the take-away here.  Firstly build your technical skills and become proficient at as many tasks as possible.  But please place your technical skills in context.  You must work with change management procedures and build trust.  Build relationships, follow the process and perform quality work and you will be become a trusted and effective engineer.