How to Differentiate Yourself in the Job Market

Most readers of this newsletter can safely be classified as experts in the field of networking. This article is intended to provide advice on how to differentiate yourself in the field, and perhaps leverage your unique experience into a more profitable career. 

This post was inspired by the Seth Godin’s Akimbo podcast, specifically episode 12 . While the podcast episode is geared toward freelancers, I think we should all consider ourselves freelance network engineers. If you work for a consulting firm, you are basically a freelancer with a specific employer. Especially at the level of most CCDEs and CCDE candidates, it is the marketing of your personal experience and reputation which allows your consulting employer to find work. If you work for an end-user organization (ISP, enterprise, content provider), you may not be with the same organization for your entire career. It is quite rare for an individual to spend their entire career with a supportive, successful employer. You should do what is necessary to prepare for a move to another employer, even if you intend to stay in one place as long as possible. The best time to prepare for your next job is when you don’t need one.

There are at least one million active network engineers in the world. In the US alone, there are nearly 400,000. How can you stand out in the field? Getting certified is a big help! There are about 50,000 CCIEs in the world, and only about 400 CCDEs (many of which are reading this article). But that isn’t enough. To truly stand out, I suggest experts find a small networking niche and dominate it. The aforementioned podcast defines the term Minimum Viable Market. This is the smallest market which will support an individual freelancer’s business. Defining and owning a Minimum Viable Market seems counterintuitive; after all, why would someone want to narrowly focus their career? Isn’t it better to broaden your market so you can be open to additional opportunities? Surprisingly, no, it isn’t. The reason for this is “available time”. Once you’ve become an expert, your compensation is defined as the product of your time and your bill rate:

Hours x Rate = Income

Of these two inputs, the number of hours available is fairly static. For most, it is around 30 - 50 hours per week, or roughly 2000 hours per year. If you push yourself, you may get to 2500 or even 3000 billable hours in a year. And if you’ve tried working this many hours in a year, you’ll realize quickly that it isn’t sustainable. The range is pretty much fixed.

The actual variable in the equation is your Bill Rate. This is the lever you can push to increase compensation. The best way to do this is to become the world renowned expert in your chosen niche. The tighter you define that niche, the more likely you can stake out your position. Proving to the world that you are the best ISP engineer is difficult. You have a ton of competition, and the field is incredibly broad. It would be much better to work toward defining yourself as the world’s expert on DOCSIS 4.0 in suburban cable deployments. Rather than claiming to be the most experienced wireless access network designer, define yourself as the world’s expert in designing wireless access networks for open-air sports stadiums. IPv6 expert? Instead, IPv6 deployment for content delivery networks. I’m sure you can think of many additional examples. When determining your niche, look at your experience. We all have unique backgrounds; there should be something in there to leverage going forward.

Once you have chosen your niche, how do you stake it out? Writing books and articles will surely help. The more publicity you can generate specific to your niche, the better. Speaking engagements, especially in front of your target audience, are wonderful opportunities to define yourself to your market. You should attempt to focus your future work on opportunities in your chosen niche. This will build your reference file. I also highly recommend starting a website or blog and focusing it on the type of business you wish to work with. Name it something like “Stadium Focused Networking” and publish articles about the problems faced by these organizations. Be sure to include recommended solutions and links to other publications that address the same challenges. Your goal is to be the first person thought of when a new project in your niche begins. Rather than competing with the masses, you will be the go-to architect for you area of expertise. This makes rate negotiation much easier. Instead of competing for the opportunity, companies will be competing for your time (eventually.. hopefully).

Obviously, this sort of transition can’t be completed overnight. Like anything worthwhile, it will take work. But it is work you likely to do anyway; the goal of this article is to help you focus your work in a way that provides additional value over the long term.

By the way, I don’t recommend focusing on a specific piece of networking equipment or even a vendor. Companies generally look for experts in their field. It is better to define yourself from the business perspective instead of the technical side.

If you do decide to go down this path, I wrote an article once about Books or Blogs. I recommend reading it, as well as Scott Lowe’s well-informed reaction post. Scott’s point is valid; writing a book is quite different than writing a blog. If writing a book is something you wish to do, I recommend defining your professional goals in advance of the effort. Writing a technical book does not lead directly to profits; but writing a book to define yourself as the expert in a field is potentially worthwhile.

That Time I Taught My First CCDE Training Class

I recently noticed a great infographic floating around the inter-webs regarding the Imposter Syndrome:

It struck me that:

• Everyone I’ve had a meaningful conversation with on this topic has admitted to suffering from this affliction
• No one thinks anyone else suffers from this affliction

And I do mean it -- I have spoken with dozens of people about this topic, from all walks of life. The very best network architects I know may even suffer from Imposter Syndrome to a greater degree than less experienced members of the industry. Perhaps this is a factor in their success; they never feel like they belong (technically), so they continue to study technology and achieve certifications in a quixotic attempt to finally feel like they have accomplished ‘enough’ to fit in.

And perhaps no one experiences this as much as I do. [See what I did there… I fell into the very trap that everyone else falls into, thinking that I have it worse than the rest with regards to this affliction]. The logical, calculating portion of my brain knows this is a farce. I have lots of great experience, many successful CCDE students and multiple high-level certifications that should provide proof of my abilities. In fact, they do, to everyone but myself.

---

So what does this have to do with my First CCDE Training Class (the title of this blog post)? I’m sure you can guess.

About a year after I earned my CCDE certification, I found myself in a classroom, tasked with teaching a group of network engineers how to prepare for the CCDE Practical exam. Well, they weren’t just a ‘group of network engineers;’ they were a self-selected class of fifteen Cisco SEs and NCEs. We began the class in traditional fashion, where I introduced myself and then gave each participant a few moments to do the same. As I recall, every member of the class had at least one CCIE certification, and in total there were over 40 earned CCIEs in the room. Only one of those was mine... Talk about the Imposter Syndrome! As one candidate briefly summed up his background (two Cisco Press books published, developer of the CCIE DC exam, etc, etc) the thought occurred to me — "I got lucky, passed a tough exam, agreed to teach a class I had no business leading, and now I’m going to melt into the floor at a Cisco office in Chicago once this class realizes I’m a fraud."

Fortunately, this class was full of extremely kind and patient students. The materials 

provided by the training vendor were not sufficient to help prepare the class, so I spent several late nights during the week preparing additional case studies. At the end of the week one of the students kindly photocopied my handwritten composition notebook to share with the class. A handful of class members had already attempted the exam and they had specific strategies that they wanted me to help them work through. One wanted to go through a merger scenario, so we worked up something on the whiteboard. As we proceeded through the various topics and designs that could be on the exam, we occasionally reached a topic that I had difficulty teaching. Each time one or another member of the class stepped in to guide the discussion.

At the end of the week, I thanked the class for allowing me the opportunity to assist them with their pursuit of the CCDE certification. I remarked that they had been an incredibly patient group and they had made me, a first-time instructor, very comfortable. Immediately several students expressed surprise that I wasn’t a seasoned teacher. Each of them remarked about how at ease I appeared during the class and how well I handled such a difficult group. My internal read on the situation was exactly the opposite of theirs. Several months after the class concluded, I began to receive emails from students thanking me for the assistance I provided, and letting me know about their success on the CCDE Practical exam. By my count, five of the seven students who ultimately attempted the CCDE Practical passed after our class.

You would think this experience had put my mind at ease, and teaching future classes would be much easier. Well, I’ve taught well over a dozen week-long CCDE bootcamps, and many more online classes, and I still get nervous before I introduce myself at the beginning of each session. The Imposter Syndrome is a part of my professional life, and I’ve come to accept it. In fact, I count on it to ‘keep me hungry,’ so I continue to study the various technologies involved in network design just as I did in 1997, when I truly did not know anything about networking.

---

I do in some ways fear that as the Imposter Syndrome is more openly discussed, it will become less prevalent. This could have the unfortunate effect of causing overconfidence, where everyone who knows about this syndrome thinks they suffer from it, even when they are, in fact, under-informed about their chosen craft. I somehow doubt this will be an issue except for the small minority who never actually had the condition to begin with.

---

Here are a few more references to Imposter Syndrome from @aliciatweet. She appears to be the source of the image at the top of this post, or at least the original infographic that this was based on:

Overcoming Imposter Syndrome - https://medium.com/@aliciatweet/overcoming-impostor-syndrome-bdae04e46ec5

You Don’t Have Imposter Syndrome - https://medium.com/@aliciatweet/you-don-t-have-impostor-syndrome-126e4c4bdcc

---

Jeremy Filliben is a network architect and CCDE instructor. He has assisted over 80 students in their successful pursuit of the Cisco Certified Design Expert designation. His next CCDE Practical Bootcamp class is scheduled for July 25th. More details can be found on his website at www.jeremyfilliben.com. 

Is Network Design an Art?

I get a little worked up when I see network designers describing our craft as an ‘art.’ I understand where the thought comes from; there is certainly a level of creativity required to arrive at an optimal network design for a given set of constraints and business challenges. It is nevertheless my opinion that we are working within a science, not an art. The key differentiator is whether we can judge one network design to be superior to another. With the traditional arts, it not objectively possible to say one song/painting/movie is ‘better’ than another. We can measure them on various points (Rotten Tomatoes [link] scores for movies, sale price for paintings, etc), but how any one individual perceives an artist’s creation is not open to debate. I like Dumb & Dumber more than Casablanca, and no amount of objective information is going to change my mind! 😃 

This is not true with network design. If two network designers review a set of business and technical requirements, they may generate unique proposals. When this occurs, invariably one or more of the following are at the root of the disagreement.

A) They interpreted the requirements differently, or the requirements were defined well enough

With good network designers, this is often the root cause. It is possible that they did not receive the same requirement information. More often, one of the engineers overlooked a key piece of information, such as a customer preference or existing technology choice that must be taken into account. If the requirements were not well-defined, assumptions must be made. These assumptions become quasi-requirements, which lead to different solutions.

B) Have differing personal opinions on the implementation details of a solution

Also known as ‘practical experience’ — These are the biases that we have developed over the years of deploying and managing technologies. Pretty much every network engineer has a preferred IGP, for example. Perhaps you have worked more often with OSPF networks, and therefore you are more comfortable using it to solve most problems. That does not make it the right choice for every proposed network design. This point of disagreement can also result from negative experiences, especially as they relate to implementation-level problems. Remember that Cisco OSPF in IOS-XR bug that kept you up for several consecutive nights, or the time IS-IS ‘blew up’ for you because you added a Juniper router to a Cisco network (hopefully not real examples for you). While implementation-level details should factor into real-world designs, do not let them talk you out of the correct technology solution (especially on a CCDE exam, hint hint).

C) Do not share the same knowledge base / understanding of the design elements

This is the category of disagreement related to the knowledge of our network designers. If one engineer proposes an IS-IS solution, and the other engineer has no experience with the protocol, there is very likely to be a disagreement.

For humble network architects, this should not be a problem. We all have our areas of expertise, and I can assure you no one is an expert in all possible technologies. Those technologies with which I have less practical experience can still be valid solutions to a problem. It is my responsibility as a network architect to have a solid understanding of these options, and if one appears viable I must put in the time to study it to see if there is a place for it in my proposal. I recommend knowing enough about each networking technology to answer the following questions:

1) What problems can it solve?

2) What are the pre-requisites?

3) How well can it scale?

4) How manageable is the resulting design?

That short list is in my experience sufficient to know when/where a technology can be useful. I can quickly rule out those that won’t fit (for example, if L2 adjacency is required, I can rule out L3VPN) and then spend time researching the remaining options to find the best answer.

---

Note that none of these points of disagreement allow us to develop unique, equally-valid solutions to the original problem.  Perhaps in the simplest cases it does not matter if we choose OSPF or EIGRP as our IGP, but with enough probing we should be able to find information that leads us to one specific solution. Maybe we could ask the following questions:

1) Are you concerned with vendor lock-in?

2) What is your convergence requirement?

3) Does your support team have operational experience with either protocol?

4) To what size do you intend to scale the network?

5) Might you deploy dynamically-calculated MPLS-TE tunnels in the future?

After getting honest answers to these questions, two network designers should be able to come to an agreement on the correct IGP.

BTW, I am not disagreeing with the core tenet of Art of Network Architecture, and not just because Russ and Denise are two of my favorite people in networking. The point I am making is that there is a difference between network architecture and design.

---

Jeremy Filliben is a network architect and CCDE instructor for Pristine Packets. Details about his training can be found on his website, www.jeremyfilliben.com. Jeremy has trained over 80 CCDEs in his 7 years in the industry. 

Don’t Let Twitter Distract You From Your Goals

First, congratulations to the five students of mine who successfully completed the CCDE Practical Exam on May 30th. For students (and others) who were unsuccessful, please let me know what I can do to help you achieve your goal. This is a difficult exam program, so don't get discouraged!

Everyone knows Twitter and blog reading can be a huge distraction. It is easy to 'jump on Twitter' after your morning coffee and before you know it, it's time to go grab lunch. Where did the time go?!? That's just the obvious way that 'the web' can distract you from achieving your goals. The more insidious type of distraction is how what we read on Twitter and our favorite blogs causes us to question our goals. How many times have you read a particularly insightful 140-character post from @etherealmind or @ioshints and thought to yourself 'Wow! I've got it all wrong; I need to drop my pursuit of <Technology A> and start studying <Technology B>, now!' (as an aside... how do these folks make salient points in 140 characters? My initial Twitter posts are always witty and insightful, but they're also 300+ characters. Once I distill them down to 140 characters they all end up saying the equivalent of "Yeah, me too" or "Ntwkring is imprtnt!!!")

Don't get me wrong -- These Twitter and blog posts can (and should) be a source of great inspiration for your career and life goals. The problem is that constantly churning your goals is self-defeating. You will never get anywhere if keep changing your destination. My strategy for dealing with these sorts of distractions is to reserve a couple of hours every few months to evaluate my written goals and determine if I have learned anything new over the preceding months that require me to modify my goals. Often I do make adjustments because facts have changed or because I have achieved one or more goals. In fact, I'm quite surprised on the rare occasion where my goals remain intact after a review.

BTW, you did write down your goals, didn't you? If you didn't, minimize this browser window or put down your smartphone/tablet and spend 15 minutes writing down your professional goals. I can't think of a single person who has told me that they were better off for not having written down their goals, once they've done it.

What is the downside to this strategy? Well, infrequently I will find that a course correction is necessary, and I could have saved myself some unnecessary work if I had modified my goal earlier. On the flip side, I have more often found that the shiny object that drew my attention in a blog post isn't quite as brilliant with the passage of a few weeks' time. Or it may still be hugely important, but isn't worth my time yet based on the items already on my plate. It's surprising how slowly technology develops... There is almost always time to defer to others for the initial exploration. Once they figure it out, sweep in and grab the benefit of their knowledge-sharing. You shouldn't feel bad about this either; it is more efficient for the industry as a whole. The whole thing is reciprocal, if you are publicly sharing the knowledge that you are gaining in pursuit of your own goals!

Next time you see something that seems valuable on Twitter or in a blog post, write it down or clip it in Evernote. Then review all these scraps of paper at your next 'Goal Review' meeting with yourself. If the information is going to change your life, it's okay to put it off for a few weeks. After all, you'll have decades to reap the benefits. Delaying for a month is not going to matter much in hindsight.

CCDE Numbering and Requirements

This article is cross-posted from the CCIE Flyer March Issue

Upcoming CCDE Training

A quick note concerning upcoming training offerings. The next CCDE Practice Exam online offering is scheduled for April 27th. Details can be found at http://www.jeremyfilliben.com/p/ccde-practice-exams.html. The next CCDE Practical Bootcamps I am offering are in Cairo, Egypt in May, and Orlando, Florida in July. Details can be found at http://www.jeremyfilliben.com/p/ccde-practical-bootcamp.html.

Future of the CCDE Program

We’ve covered the history of the CCDE over the previous two articles... But what about the future? I expect the number of successful CCDE candidates in 2013 will easily beat 2011’s record of 28. Why? For several reasons:

• Increased Interest in the CCDE Program - I am already seeing record demand for my training offerings. I am also noticing increased activity on the Cisco Learning Network CCDE discussion board. More interest = more candidates!
• Immediate Test Results - This development (introduced in November 2012) will allow unsuccessful candidates to immediately begin preparing for their subsequent attempts. It was common in the early days of the program for candidates to skip every other test date, since they often would not get their results until a few weeks before the next exam offering.
• More Test Dates and Locations - Cisco has already announced four test dates for the CCDE Practical exam, covering a whopping 16 locations. Details can be found at https://learningnetwork.cisco.com/community/certifications/ccde/practical_exam?tab=4.

We’ve already seen a record number of successful candidates during the February testing date -- at least 15, including four of my students! In summary, I am quite confident that the CCDE program is here to stay. This was somewhat in doubt among networkers in the earlier years. I suspect this was due in part to the small number of successful candidates in 2008 - 2010, plus the short life of the CCIE Design certification in the early 2000s. With nearly 100 CCDEs to date, plus the fact that the CCDE is a necessary step on the way to the Cisco Certified Architect program, it is highly unlikely that this certification will be retired. In fact, I suspect the CCDE will broaden into other topics, much like the CCIE. Might there be a CCDE Data Center or CCDE Security in our future?

Certification Requirements

Now that we’ve covered the history and my best guess at a future direction for the CCDE program, how does one actual earn this certification? Like the CCIE program, there is no certification prerequisite needed for the CCDE program. Although CCDE sits on the top of the Network Design pyramid above CCDA and CCDP, neither certification is necessary to attempt the CCDE written exam.

The CCDE written exam is a 120 minute, 90 - 110 question exam that is delivered worldwide at Pearson Vue testing centers. The exam blueprint is quite extensive! Candidates should have strong familiarity with routing protocols, tunneling, quality of service, network management and network security. In contrast to the Practical exam, each written exam question is self-contained. Like all current Cisco exams, it is not possible to go back to previous questions or skip questions during the exam. I really miss that feature of Cisco exams! Without going into any details (respect the NDA!) I am willing to say that there are fewer ‘trivia’ questions on the CCDE written, as compared to the various CCIE-track exams I have taken. Most questions assume a high level of technical knowledge. The questions are more about how to use or evaluate technologies, rather than defining technical terms.

Passing the CCDE written exam recertifies any lower-level Cisco certification (CCNx, CCDx, etc). It also recertifies any current CCIE or CCDE certification. Lastly, passing the exam qualifies you to schedule and take the CCDE Practical exam. Your first CCDE Practical attempt must take place within 18 months of passing the CCDE written exam. You must pass the CCDE Practical within three years of your written exam; if you fail to do so you will be required to retake the written exam prior to any subsequent Practical exam attempts. If you fail the CCDE written exam you must wait six calendar days before re-attempting, and if you pass the exam you must wait six months before retaking the exam.

The CCDE Practical exam is an eight-hour exam that is offered on specific dates and at specific Pearson Vue testing centers. Upcoming test dates can be found on the Cisco Learning Network. The exam currently consists of four distinct scenarios, each consisting of 25 - 35 questions relating to a single network. Each scenario is self-contained; once you complete a scenario there is no reason to remember it for the next test segment. According to the Cisco Learning Network, candidates are required to complete the first and second scenarios in the four hour exam session prior to lunch. After four hours, all participants are escorted to lunch for one hour. Upon returning to the test center, all candidates will begin the third scenario. The third and fourth scenarios must be completed in the four hour exam session that begins after lunch. So in a way you can consider the exam to be two separate four-hour exams, separated by a one hour lunch.

When you have completed the final question of scenario four, your test will end. As you collect your belongings and exit, the Pearson Vue proctor will hand you your score report, with either a “PASS” or “FAIL” result. If you are unsuccessful, the score report will give you a brief breakdown of your results based on the question types present on the exam. If you passed, congratulations! Within a week (and likely sooner) you will receive notification of your CCDE number!

Recertification Requirements

Successful CCDE candidates must maintain their certification credentials by completing one of the following exams every two years:

• Any CCIE Track Written Exam
• Any CCIE Track Lab Exam
• The CCDE Written Exam
• The CCDE Practical Exam - has anyone done this for recertification?
• Successful Completion of the CCAr Program (Both Interview and Board Review) - This one is special, as it recertifies all lower-level certifications for five years... If my reading of the recertification policies correct.

CCDE Numbering System

As many know, the CCIE certification numbering policy began at #1025 and has increased sequentially from there. During the initial public unveiling of the CCDE program in 2007, the team requested thoughts on how CCDEs should be identified. There were several humorous responses, including binary and hexadecimal. The team settled on an eight-digit decimal string. The first four digits signify the year in which a candidate passed the Practical exam. The second four digits uniquely identify the candidate among those that passed in that year. My CCDE number is 20090003, which means I passed in 2009. From the “0003” portion you can infer that I passed early in the year, as compared to someone whose number is significantly higher. For example, four candidates passed during my February 2009 test date. We were given the numbers 20090001 - 20090004. The next test date had five successful candidates, who were given numbers 20090005 - 20090009. According to Cisco, there is no specific meaning about which number you receive during a test date. In fact, my original paperwork indicated my number would be 20090004, but the plaque I received had number 20090003.

It appears now that Cisco is also numbering CCDE candidates by theatre. All of the candidates that I know of that passed in Sydney in February 2013 received low 2013 numbers (20130001 - 20130003, at least). So a bit more information is conveyed by the numbering system. This was not the case in the earlier days of the CCDE program.

There are two other common representations of the CCDE number. The first is the use of a double-colon “::” to eliminate a string of zeros. Using this makes my number 2009::3. I certainly hope every recognizes the IPv6 aspect of this! It is also common to see the second half of the CCDE number represented in hex, especially if it makes it more interesting. For example, 2009::13 is more fun to write as 2009::D.

Next month's article will cover the preparation methods that successful candidates have used.

About Jeremy:

Jeremy Filliben is a 15 year CCIE (Routing/Switching #3851) and a CCDE-certified network architect. Jeremy was a member of the CCDE beta program and passed practical exam in 2009. Jeremy has trained 16 of the ~80 individuals who have passed the CCDE practical exam since 2010 (more than all other training organizations combined). His next CCDE Practical Bootcamp is scheduled for the week of July 29th in Orlando, Florida. More information on Jeremy's CCDE training offerings can be found at www.jeremyfilliben.com.

Goals for 2013

Over the final months of 2012 I started considering my professional and personal goals. After starting with a large list, I’ve narrowed it down to the following. I am comfortable committing to these publicly, which I hope will encourage me to keep to them.

1) Assist in developing the careers of my co-workers - I work with a great team of network engineers, and I consider one of my primary responsibilities to assist them with their professional development goals. I do this by providing recommendations for training and assigning skill-stretching projects to my team. They always respond well to these challenges. I already get helpful feedback from my team, so I will continue to rely on this feedback to measure my success.

2) Continue offering industry-leading training for the Cisco Certified Design Expert program – I’ve been fortunate to assist dozens of excellent engineers with their pursuit of CCDE credentials. In 2013 I will continue offering my CCDE Practice Exam Training, as well as further develop my classroom-based CCDE Bootcamp offering. If you are interested in attending in-person classroom training for the CCDE, please send me an email. I will measure my success by the feedback I receive from training participants.

3) Spend at least 40% of my professional time creating – In past years one my goals has been related to learning. That one was always too easy, as I find that I am constantly reading and studying simply to keep up with the industry and my projects. This year I am going to flip this around and hold myself accountable for creating content. In this category I am including blog posts, course development, writing projects and professional projects. My plan is to measure this based on output, with some guesstimating about the amount of time each project requires. It’s an art, not a science!

4) Get healthier – This is clearly a personal goal, and it is my hope that by publicly announcing it I’ll do a better job of sticking to it. I will measure this goal’s results by feedback from my physician during my annual physical, plus on whether I keep to my exercise goals. I also committed to my son that we would run a 5K in the spring. I *think* I am on track for this… wish me luck! We also run the Newark Main Street Mile in October. I intend to beat my 2012 time by 30 seconds.

I’m going to keep this list to four items. Any more and I will lose focus. If at the end of the year I neglect to provide a ‘How did I do?’ post, please let me know!

Thank you for reading!
Jeremy

Python Programming and the Network Engineer

I’ve recently rediscovered my interest in computer programming.  As I mentioned before, I once was an avid programmer.  In my youth I hacked around in C++ and x86 assembler, making interesting little programs that didn’t accomplish much, but which gave me a great sense of accomplishment.  In high school, I was a member of the third place team in a national computer programming competition.  One of my teammates is now a software engineer at Google, so maybe I wasn’t exactly the star of the show, but my contributions seemed important at the time.  :)
My college years went a long way toward suppressing any interest I had in programming computers.  The rote, repetitive routine of programming compilers, operating systems, database engines, etc, drove me directly into a career of infrastructure work.  I have no professional regrets, but I do sort of miss the thrill of writing working code.  There is a great sense of satisfaction derived from formulating an idea and seeing it through from a blank Notepad++ document to a working, debugged applicati0n.
A couple of months ago I was faced with a project that resurrected my interest in programming.  My team and I have been working steadily toward standardizing our network deployments.  Standardization is a key requirement to effectively managing a large network with a small number of engineers.  Prior to this effort, such things as VLAN numbering and port-level configurations varied between our locations, even when two offices were roughly similar in size.  One of the causes of this was the melding of several different IT organizations when my employer was created.  We also acquired several smaller companies since our genesis in 2004.
To accomplish our switchport standardization, we use the description field to identify the type of device that is connected to a specific switchport.  If a PBX is connected to a port, the description field would be something like:

interface Gigabit1/1
description PBX; Name_of_PBX

and if the port is connected to an end user, we would use:

interface Gigabit1/2
description USR; John Doe – patch-panel 1A

The text after the semi-colon is free-form, and can be defined on a site-by-site basis to be whatever is relevant to the local support team.
PBX ports require a different set of configuration statements than USR ports.  For one example, we need a “DSCP trust” statement on the PBX port, while we remark USR traffic with a specific QoS policy using the “service-policy input USR-POLICY” command.
Our standardization effort is now largely complete.  Our latest challenge is making sure our configurations stay standardized.  VLAN identifiers are easy, since it is quite painful to change them.  Switchport configurations are a very different story.  It is quite easy for a switchport to be configured incorrectly but still work in a suboptimal fashion.  For example, if the wrong QoS marking policy is installed, basic testing will work (ping, etc), but under load there will likely be performance issues.  Even if the proper template is used to activate a port, it can be difficult to prevent that port from being reused for another purpose.
My solution to this issue was to implement an audit process that would take a baseline configuration and compare it to our production switch configurations.  I first reached out to our primary network tools provider, Solarwinds.  Their current feature provides some of the features I need, such as verifying that specific lines exist in the configuration.  But they cannot yet do context-sensitive configuration checking.  Other vendors (such as Netcordia) could perform this task, but I had recently championed a network tools consolidation project, so it would be a bit hypocritical of me to request funding for a new tool.  I decided to learn a scripting language to try and tackle this need.  A friend suggested that Python or Perl would fit the need nicely, so I chose Python (for no particularly good reason) and began learning.
I was quite surprised as how easily I learned the language and was able to solve my problem.  I spent a total of eight hours from the time I settled on Python until I had a working prototype.  The small investment of time is primarily due to the ease of use of the Python language, and not my programming acumen.
The entire script is a few hundred lines, including comments, and it meets all of my needs.  I wouldn’t say it is terribly user friendly, and I have a laundry list of additional features and ‘opportunities for improvement’, but I am happy with the result.  If I can find the time (and there is interest), I’ll clean it up and publish it in separate blog post.  It is generic enough that other organizations can probably use it without a lot of rewriting.

CCIEs and Social Skills

In the late 90s, CCIE certified networkers were hard to come by.  If I recall correctly, there were fewer than a half-dozen CCIEs in my state when I passed the exam in 1998.  Granted, Delaware is a small state, so that may not be saying a lot.  But trust me, there were not many CCIEs floating around.  I had met and spoken with a grand total of two CCIEs prior to earning my own cert.  Marty Adkins was my instructor for Cisco Internetworking Troubleshooting and a one day mock CCIE lab.  Doug Willard was a former employee of the company I worked for.  I ran into him at a Cisco presentation a few weeks prior to my first CCIE lab attempt, and he provided useful time management advice.  I’ve lost contact with Doug, but I still keep in touch with Marty.  Both gentleman were polite, well-spoken and a joy to deal with.

Fast-forward a year or so.  I was now CCIE certified and working for a consulting company.  My new job put me in contact with my other networking professionals.  I quickly learned that not all CCIEs carried themselves with the same professionalism as Marty & Doug.  During one sales opportunity with Netigy, we sent one of our newer CCIEs to meet with a prospective client’s technical staff.  The client had a CCIE on staff as a contractor, and he immediately took control of the meeting by declaring that Netigy’s CCIE had a higher number (It was in the 5000s, gasp!), and therefore was too inexperienced to help out.  The sales call was basically postponed for a few days until I was available to attend, since my number was low enough to satisfy this guy’s requirement.  Once that BS was settled, it was determined that our original CCIE was by far the most experienced of the three CCIEs involved with this particular network design, and he eventually spent several months with the client solving their issues.

While this was nonsense, at least it led to work for my employer.  My least favorite situation was visiting a prospective client who had already met or worked with a CCIE who had a bad attitude.  As I mentioned before, Delaware is a small state, and one of the few CCIEs who pre-dated me was notorious for his poor social skills.  As I came to learn, he threw temper tantrums at client sites and denigrated other non-CCIE engineers when mistakes were made.  His reputation was known throughout the area, and his attitude was associated as much with the CCIE credentials as it was with his employer.  Following that act into a sales situation was difficult.  Everyone began the meeting on the defensive, as if they were expecting all CCIEs to behave the same way.  Eventually the client would determine that not all of us acted with an air of superiority, and real work could be accomplished.

I don’t see this behavior from CCIEs much any more.  There are still many who border on ‘pompous’, but that isn’t so terrible.  Most CCIEs have a well-earned sense of confidence in their skills… and there is a fine line between ‘pompous’ and ‘confident’.  But it is now rare to find networkers who function like the ones described above.  I suppose it has a lot to do with the vast number of active CCIEs in the world.  I long ago lost count of the numbers in my area, but I am certain there are now hundreds in my metro area of Philadelphia.  With the loss of exclusivity, poor social skills are no longer tolerated in the work place.  That’s a good thing.  It also appears that the first two dozen CCDEs are for the most part a humble, well-mannered group.  We may occasionally stray on the dark side of the confident/pompous line , but peer pressure will surely rein us in before we get too out of line.  I’d hate to have to battle the same stereotypes over the next few years of my career!

Cisco Live 2010

 

This will be my fourth consecutive year attending Networkers @ Cisco Live. That qualifies me as a NetVet, which I always figured was a way of identifying employees of companies that receive too many Cisco Learning Credits. Now that I've been recognized, I see that it is a badge of honor for dedicated network learners, or something like that! :)

How and why have I attended Cisco Live for four straight years? When I decided to go to Cisco Live 2007, I hadn't been to formal Cisco training in six years. I had last attended Networkers (Orlando) in 2000, and frankly I didn't feel like I got much out of the experience. Most of it was my fault, as I brought my wife and two year old son with me.  I had also attended the year before in New Orleans, and several of my seminars repeated material.  Cisco Live Anaheim in 2007 was a great experience for me.  I reconnected with many former colleagues and built new relationships with Cisco enthusiasts.  When I saw that Cisco Live 2008 would be in Orlando, I decided to attend that one as well.  Orlando is my adopted summer home, so the travel costs were negligible.  Two colleagues from my employer attended as well, which added an additional team-building component to the experience.  We also were able to use Cisco Learning Credits from a major network upgrade purchase to keep our training costs down.

I had no plans to attend Cisco Live in 2009.  Two of my direct reports were scheduled to attend the San Francisco event.  My intention was to take a hands-on Nexus 5000/7000 class to prepare for a new Data Center deployment.  One of my other team members took the Nexus course in the spring of 2009 and reported that the experience was less than ideal.  So I shifted gears and applied my CLCs to Cisco Live 2009, with the added component of two hands-on Nexus Labs (Hands on Nexus 7000 and a VPC lab).  I also chose a number of Nexus-based Breakout sessions.  By focusing on a specific technology area I was able to sidestep the seminars I had attended over the previous years.

This year I’ll be focusing on the topics of Data Center LAN Extension and IPv6.  To this end I registered for an Overlay Transport Virtualization (OTV) Lab and a number of Data Center and IPv6 breakout sessions.  Two members of my team are also attending, along with my manager and another co-worker.

How do I get value out of repeat visits to Cisco Live?

• Attend with co-workers – I derive a lot of value from meal times, visits to the World of Solutions and attending breakout sessions with my team members.  Last year we had a Meet the Engineer session about Performance Routing that was extremely helpful as well.  My team is distributed among three company offices, and I work from home, so face time with co-workers is very valuable.
• Don’t attend the same sessions – This might seem obvious, but it needs to be said.  The sessions will not change considerably from year to year, so even if you love BGP, pick something else to concentrate on.  You WILL get bored by the first 75% of any presentation, even the ‘Advances in BGP’ session.  If you absolutely need to know the latest in BGP, write yourself a note to watch the session on Cisco Live Virtual once it is posted.
• Visit the World Of S0lutions – The WoS does change from year to year.  I’m not much of a fan of the trinkets, but I do like visiting booths to see what is new in the field.  I’ll usually grab a couple of items for souvenirs for the kids.
• Take a Certification Test – It’s free, so it would be a waste not to take advantage of this benefit.  I generally take an exam that will recertify me.  This year I’ll be retaking the CCDE Written exam.  Wish me luck :)

I’ll post my schedule once I have a finalized version.  I generally change my plans repeatedly as I learn more about the sessions.  The one must-see breakout for me is BRKRST-3500, Designing Multipoint WAN QoS.  It’s a tricky issue, and I’m very curious to see how the problem is solved.  I also know the presenter, so I know it’ll be a good session.

Thoughts on Recertification

 

I know several former CCIE-certified individuals who have let their certifications lapse.  Most did it because their careers had taken them (at least temporarily) far enough away from the technical realm to make recertification difficult.  The easy decision at the time was to forego the effort of recertification.  In a few of these cases, circumstances eventually led them back into the technical field, where I’m sure they regretted letting the CCIE certification go dark.  Interestingly, I’ve never heard of anyone going back to take the lab to restore their CCIE certification.

Is recertification difficult?  Sure, at times it can be.  The first three times I recertified my CCIE, I took the old CCIE WAN Switching exam.  I would have taken it a fourth time, but the track was retired in 2006.  Because I was in a somewhat non-technical role, I decided to take the “easy” way out and recertify with the CCIE R/S exam.  Somehow I forgot about the “S” part, and went into the exam woefully unprepared for the switching questions.  My score report was a bit lopsided, with high marks for Routing, Security, etc, but extremely low marks for Switching.  I did not pass.  After a significant study break I retook the exam and passed.  Since then, I’ve taken the CCIE Security exam and the CCDE Written.  This summer I plan to take the CCDE Written again at Cisco Live.  I won’t say I’ll never take another CCIE recertification exam, but I think it is highly likely that I’ll continue retaking the CCDE Written for my future recertification requirements.

There is one certification that I have let lapse.  In 2003, I earned the CISSP certification.  At the time I was performing contract work at General Electric, and there was a lot of talk about moving my work offshore.  I felt it was the right time to add some new credentials to my resume, and security was a hot field.  About a year later I found a new opportunity that did not require my CISSP credentials, so I had no strong reason to keep my certification active.  I was also quite disappointed by the convoluted continuing education requirements and the yearly renewal fee.  For that matter, I don’t know anyone who has been satisfied with the CISSP program.  I may be too cynical, but it seems like a profit center for ISC2, rather than certification program.

Cost Estimate for the CCDE

Yesterday I received an interesting comment to one of my previous CCDE blog posts.  Jack asked:

My employer is asking for cost estimates for the whole process [CCDE]. I have seen that your estimate is 3000 dollars. Does this include the tests themselves or just the materials?

I contend that the real cost of this certification is in the time required to master the material.  That said, the actual out of pocket costs are very important too!  Here is a breakdown.

 

Costs

Fixed Costs

Cost	Item
$350 (each attempt)	Written Exam (352-001)
$1400 (each attempt)	Practical Exam (352-011)

Variable Costs

Cost	Item
Minimal	Travel to Written Exam
Potentially Expensive	Travel to Practical Exam
~$400	Books
Unknown	Formal Training

You almost must factor in the opportunity costs of your time, as many of aspiring candidates need to delay or avoid other time commitments.  At the very least, you’ll likely miss some family and friend events to concentrate on studying.

 

Travel to Written Exam

Hopefully this is minimal for everyone.  The exam is offered at all Vue testing centers, so this should be a short car or bus ride away.

 

Travel to Practical Exam

Currently, the practical exam is offered in Hong Kong, London, and Chicago.  Historically it’s been offered every six months, but that pace is expected to pick up to meet increased demand for the exam.  As of this writing, the exam was most recently offered in August, and the next scheduled offering is in December.  I expect the practical to be offered quarterly beginning in 2010.

Travel to/from these selected testing locations is not trivial.  My three day / two night trip to Chicago (from Delaware) cost approximately $1100.  That probably comes in at the low end of most candidates travel costs, as my airfare was only $350.  International travel can be considerably more expensive.  Of course, if you’re fortunate enough to be local to one of these cities, you’ll save a bundle!  Also keep in mind that it is probably wise to budget for two trips, to prepare for the possibility of failure on the first attempt.  This is an area where I wouldn’t cut corners.  For a big exam (or business meeting, etc), be sure to arrive in plenty of time (early afternoon on the prior day for me) and don’t be rushed to leave.  The exam is enough to think about, without adding travel concerns to the mix.

Books

I’ve given my book recommendations before, but I’ll repeat them here:

Optimal Routing Design – One of the authors (Russ White) is also author of most of the CCDE Practical content to date.  It helps to get into the mind of the test writer!  Besides that, this book is the best resource for Enterprise routing design, and specifically, IGP design.

Definitive MPLS Designs – This book covers MPLS Service Provider designs, as well as a bit of Internet Service Provider design.  More than any other resource, this book gives a great feel for the style of the CCDE practical exam.

BGP Design & Implementation – This book focuses almost exclusively on Internet Service Provider design.  It gives the “Why” behind route-reflectors and confederations.

End-to-End QoS Network Design – This book does for QoS what the above three books do for IP Routing & MPLS.  It uses great examples to describe class-based traffic-shaping and other QoS concepts.  For the purposes of this exam, you can disregard the configurations.

These four books cover the basics of network design.  In addition to these resources, candidates may also want to pick up Network Management Fundamentals.  This book gives an overview of Network Management design, and a few specifics on Network Management technologies.

Note that these books don’t necessarily cover the basic technology particularly well.  Each of these books has a primer section, but none of them go into the depth necessary to teach someone new to the respective technologies.  If you need more basic information on the technologies, I would suggest following the reading suggestions available from the appropriate CCIE track.  For example, if you need information on VPLS or AToM, read Layer 2 VPN Architectures.

Formal Training

 

I’ve noticed that there are now at least two formal training classes available for the CCDE.  One is being offered in Europe, and is taught by an actual CCDE certified instructor.  The second is offered in the US.  I suspect this is not being taught by a CCDE.  I’m not sure what to think of formal training for this exam.  It likely depends heavily on how the course is structured.  I do not believe that one or two weeks of classroom training can prepare a candidate for the broad range of technical topics covered in the blueprint.

On the other hand, a week of classroom training could be great for learning design methodology.  Assuming the student already has a fundamental grasp of most of the technology, an instructor-led class that teaches by example could be a positive addition to a candidates preparation plan.  It may not even take a full week to prepare a qualified candidate for the style of the exam.

I will be interested to hear feedback and test results from the first wave of candidates who partake in these classroom training offerings.  Before I hear firsthand whether the candidates felt prepared, I won’t be able to recommend this strategy.

 

Conclusion

 

To sum this up (literally!), I spent about $3000 in actual dollars to achieve the CCDE certification (note, I took the written during the beta period, so my numbers don’t quite add up).  I am fortunate to have a supportive employer who covered most of these costs.  A candidate can spend far more than this in their quest for the CCDE certification.  If I were coming at this today, I would budget for two attempts for the written exam ($700), two attempts for the practical ($2800) + travel for the practical ($2200 for me, but varies wildly depending on your location).  I would also budget $400 for books, and depending on student feedback, I might budget for a formal class.  Without the class, my total budget would be $6100.

Technical Writing.. Books or Blogs?

I’ve been thinking lately about whether it still makes sense to write technical books.  Years ago, I had a contract to write a book for Cisco Press.  Due to a job change, I was only able to complete a few chapters, and after handing it off to another author, it seemed to die a quiet death.  I used to be able to find a reference to it on one of the Amazon websites, but a recent search turned up nothing.

About six months ago, the writing bug bit me again, and I created a proposal for “Enterprise Network Designs” and sent it off to Cisco Press for feedback.  In the (long) time between sending that email and receiving a meaningful response, I chose instead to begin writing this blog.  Blogging fits my schedule better, and it provides a more interactive communication platform.  IIRC, I felt a good deal of deadline pressure and a bit of nervousness about making mistakes.  Once information is committed to paper, it’s difficult to fix it.

As a result of these events, I’ve been trying to determine if we’ve reached the end of the technical book publishing industry.  I don’t recall the Cisco Press contract being especially lucrative.. something like 10 – 15 percent of gross revenues go to the author, minus some expenses.  As several technical authors have mentioned, you don’t get into the field for the money.  Maybe they’re just trying to keep the competition out, but for some reason I doubt that’s the case.

Why wouldn’t technical authors go the blog route, and cut out the publishing middleman?  This would eliminate much of the overhead of publishing, as well as free the author from official deadlines.  Revenue can be generated by monetizing the blog, as well as follow-on contract work.  If the content is well-written and relevant, the professional prestige gained from the effort should be comparable to being a published author.  Technical book readers are by definition technical, so reading a blog should be well within their comfort zone.

 

What would the author be missing?  A few items are:

Deadlines - Is that good or bad?  Depends on the author, I suppose

Copy Editor – Go with a freelance editor?

Book Signings – Not sure a substitute is available for the blogger

Seeing Name in Print – Ditto.. no obvious substitute available

Copyright Protection – There must be a good solution to this, right?

Publisher Credibility – Cisco-related books from Cisco Press probably significantly outsell books from Pearson Publishing, even though they’re the same publishing house.  The lack of a well-known imprint could make it difficult to build an audience.

 

What are the advantages?

Full control over content

Easier publishing process (arguable, I suppose)

Infinite ability to revise content after publishing

Better interaction with readers

Better for the environment, if that is meaningful

 

I would think it would be relatively easy to monetize the content through eBooks, like the Kindle.  Some technical blogs are already syndicated on that platform, such as Jeremy Stretch’s Packet Life blog.  Thirty cents per month per user probably isn’t terribly lucrative, but for hassle-free revenue, why not?

Monetization Strategy

Google Adwords

eBook syndication

Professional consulting

Partnership with training vendor (depending on blog content)

 

 

I’d love to get some feedback, especially from authors (books and blogs).  Have you considered something like this, or are you already do it?  What are the challenges you’ve faced?

Corporate Versus Consulting Jobs

One question that repeatedly comes up in conversation is whether corporate or consulting jobs are better.  Once I get past the obvious ‘It Depends’ response, there are some clear differences that aren’t necessarily apparent at first glance.  Here is my take on the question.

 

Career Versus Job

I’m definitely not breaking new ground when I say there is a clear distinction between a career and a job.  My chosen career is computer networking (or less specifically, Information Technology), and my current job is a network manager / architect for a Fortune 500 insurance company.  I’ve had several jobs in my career, but only one actual career.  Your career is generally the answer to “What do you do?”, while your job is the answer to “Where do you work?”  When I’m asked, my answers are “I build and maintain computer networks” and “I work for an insurance company” respectively.  It is extremely important to put the emphasis on your career.  Often times, focusing on your career and focusing on your job go hand-in-hand, but occasionally they will diverge.  For example, after I earned my CCIE certification, I sat down for my first performance review.  My manager, who I respected very much, was thrilled with my performance, but could only offer a modest increase in compensation on a low base salary.  He mentioned that the plastics industry (my employer’s field) was in bad shape, and he would have offered more if it was possible.  I understood the predicament, but later I realized that I didn’t work in the plastics industry.  I work in the computer networking industry, and things were going quite well there.

Don’t take this advice to an unwise extreme.  Demonstrating a history of indifference to your employer will undoubtedly decrease your value over the long term.  It would be very difficult to find a suitable job if your resume is long on experience but short on loyalty.  As a manager, I can easily understand early career applicants showing a few employers, especially if the increase in responsibility and experience demonstrates a logical pattern.  If the pattern continues into the applicant’s later career, I’d be inclined to wonder why things weren’t working out with so many different organizations.

 

Categories of Networking Jobs

I broadly separate my employment history into two categories:  Corporate positions and Consulting positions.  Within the networking field, corporate positions entail working in a specific environment to solve problems for your organization.  You don’t necessarily need to be a full-time employee of the organization; I’ve had corporate jobs where I was a contractor.  Consulting positions usually have all the responsibility of corporate positions, plus an extra layer of organizational overhead.  To be truly successful in a consulting position, you’ll need to focus on the profitability and success of your consulting organization first, while also fulfilling the needs of your customer (the corporate entity).  I’m leaving out reseller positions, primarily because I’ve never had one, so I haven’t given much thought to the environment.  I’ll theorize that it is similar to consulting, with the added pressure of pushing products (physical, rather than labor) on the customer, but that’s just a guess.

I spent three years (1998 – 2001) in consulting, and nine years in corporate environments.  My consulting roles were during the heyday (and later the crash) of IT consulting.  Maybe things are different now, so keep that in mind while considering my thoughts below.

 

Points of Comparison

Suitability for Early Career

I’ve frequently questioned the suitability of consulting for early career engineers.  At my local Netigy Corporation office I saw the drawbacks of hiring junior engineers.  They’re often the first to go during tough times, and without suitable assignments, it is very difficult to learn new skills.  Most engineers need meaningful work to build their skills, and at times, it can be a challenge to find that in a consulting environment.  Consulting organizations are hesitant to place an engineer in a role where they haven’t already proven their abilities.  Corporate environments generally provide better opportunities to acquire and utilize new skills.  There is also a great advantage to implementing a solution to a problem and then seeing how it works over the long term.  This is more likely to happen in a corporate environment.

Compensation

Perhaps the best way to understand compensation is to think about what makes an engineer valuable to an organization.  In consulting, I’d say about ninety percent of your value is tied to your revenue (bill rate X utilization).  I was once directly told that my compensation had hit a peak because my bill rate didn’t support an increase.  This was despite my efforts to grow my account from two to seven consultants, often at significantly higher rates than I was billing.  More sophisticated consulting companies will factor this in, plus mentoring / leadership, pre-sales work and other factors, but ultimately profitability comes down to individual revenue versus expense.  Compensation is not as easy to understand in a corporate environment.  You can look at replacement cost (how much would it cost to higher a new engineer for the same role), corporate salary structures, value delivered, etc, but it’s less quantifiable than in consulting.

It has become apparent to me that corporate salary structures are getting much closer to the consulting environment.  In the late 90s, I found it necessary to enter consulting to achieve the full value of my experience.  Even in 2001, when the consulting market was beginning to crumble, I couldn’t justify moving back to the corporate world on the basis of compensation.  I chose to stick with Netigy until they closed their doors in September 2001.  Only then did it make sense for me to move back to the corporate world, this time as a contractor.  In talking with other engineers who have recently changed jobs, I can see that the pay disparity has shrunk considerably, and when you add in the value of non-cash benefits, we may be nearing parity.

Job Security

In consulting, your job security is dependent on your ability to bring in revenue.  There’s always a place for cash-flow-positive consultants.  In the corporate world, again, things are not so clear.  Because there is no direct correlation between job performance and revenue, job security comes down to relationships, replacement value, the organization’s view on the value of IT, and countless other factors.  You also need to look at the viability of the organization.  If your employer (whether consulting or corporate) isn’t able to keep the doors open, it doesn’t really matter how good you are at your job.

I prefer to look at job security more broadly, in terms of employability.  It never much mattered to me if my current job was secure, as long as I could be confident that I would find another job in a reasonable amount of time.  This viewpoint allowed me to find a wonderful opportunity when Netigy went out of business.  If I had been focused on my specific job’s security, I would certainly have left Netigy for another organization before they went bankrupt.  It also served to calm my nerves a bit in March 2009 when the stock market seemed to indicate that my current employer would not make it through the financial crisis.  If this viewpoint appeals to you, be sure to save some money.  I’m sure you can find better financial advice from others, but I suggest having a considerable amount of available cash to handle the inevitable periods of unemployment.

Relationship Building

Without a doubt, I met more people from the networking industry in my three years of consulting than I did in nine years in the corporate world.  Some of the relationships I’ve built have lasted for a decade or more, and several have resulted in jobs for both me and my counterparts.  In fact, I’ve dragged one guy between three different companies, and I wouldn’t hesitate to call him again if the need arose.  In the corporate world, it is easier to create lasting relationships, but I still suggest acquiring the ability to quickly build rapport.  Use social networking (Twitter, LinkedIn, Cisco Learning Network, etc) and get to know people in training classes and seminars.  Don’t think of this as creating a network to use later, but as a way to add a social component to your career.  No one wants to be used, and if that’s your intention, it will be obvious.

Work/Life Balance

Bear in mind, I’m coming at this category as a married father of three boys.  What I want out of this category may be wildly different than your needs.  In my experience, a corporate position provides the better work/life balance.  I am sure there are corporate positions that require travel, and there are consulting positions that allow you to be home every evening.  I’ve done the constant travel thing, and it has a few benefits:  Frequent flyer / hotel points, plenty of study time, seeing new places, etc.  If I weren’t a family man, I would probably find even more great things about the traveling lifestyle.  Even in my corporate positions, I’ve found opportunities to do some travel, and it has been a nice change of pace.  My worst work/life balance issue in the corporate world was the three years of long (90+ mile each way) commuting I signed on for.  And of course I still get to ‘carry the pager’ for on-call work and escalations, as well as work the strange hours that our change windows dictate.  In return, I get to work from home and put my kids on the school bus in the mornings.

These are rather gross generalizations of the two environments.  I know of one consultant who has worked almost exclusively with the same government client for a dozen years.  He lives near his client and seems to have worked out a great work/life balance for himself.  I have also worked for a consulting company that strived to keep everyone local.  Every situation is unique, so don’t rely on these generalizations.  Do your homework if you are interested in changing jobs.

Need for Certification

Consultants need credentials to find work.  Consulting organizations use certifications in their marketing and sales pitches.  It’s a required part of the game, and it benefits the consultants, as their value in the industry increases because of it.  I once pursued my CCIE in WAN Switching to help out my consulting employer.  I got as far as the CCNP and CCIE written, and was scheduled to take the lab when I got sidetracked.  It assisted us in landing a significant engagement and allowed me to broaden my horizons a bit.  I only rarely used the knowledge, and by now, it’s almost completely gone, but it was a great experience.

As I mentioned in a previous post, corporate employees should also acquire certifications.  It makes life significantly easier when you find the need to market yourself via a resume.  Don’t shortchange yourself, especially if you can a supportive employer who is willing to assist you in achieving your goals.  If you are having trouble selling the idea of getting certified to your employer, remind them there are benefits for them too.  My pursuit of the CCDE cost my employer approximately $3000, including travel, books and registration fees.  In return, they got dozens of hours of evening/weekend study time, and in my opinion, a more qualified Network Architect.  All for less than the cost of a one-week training course.  If that doesn’t convince them, remind your employer that CCIEs get priority escalation for TAC cases, which will cut down on MTTR.

 

Additional Thoughts

I certainly don’t want to come across as recommending that you should always chase the money.  A friend commented on my last post that there are other factors to job/career satisfaction other than money, and he’s 100% correct.  I would not take or stay at a job that didn’t meet my work/life balance requirements, even if the money was excellent.  As a matter of fact, I worked with David at a previous employer, where I left for this very reason.  He doesn’t remember, but in fairness, I was only there for six weeks before I realized the fit wasn’t right.

David made a second point that bears repeating.  Non-technical skills are very important, and need to be developed alongside technical ones.  It’s a bit more difficult to build that into a study plan.  My recommendation is to emulate successful people at your job.  If you don’t see any, well, you’re probably not with a very good company and you should be considering whether you’re at the right place.  Most people are happy to provide advice and mentoring.  It’s one of the best parts of my current job.

 

Summary

Again, remember that my consulting experience is from about a decade ago.  Things may have changed significantly since then.  If they have, please add your thoughts in the comment section so I can be more accurate in future posts.  As for me, I’m reasonably happy with my current job.  It has given me the flexibility to pursue my career interests, including management.  I have also been able to do a bit of consulting to maintain skills in technical areas that don’t exist in my employer’s environment.

Hopefully these descriptions will help you make the right career decisions.  Keep in mind, if you ever do make an unwise career move, you can always make another move to get back on track.  I don’t know many people in this field who haven’t made a bad career move at least once...  I know I have!