Some network engineers think that CCIE's (no matter what track) are all-powerful...that passing the lab exam somehow endows the CCIE with super-powers that cause any IOS device to bow in respect. Even non-Cisco network devices are perceived to bow to the will of the mighty, keyboard-wielding CCIE. (Don't I wish...)
Reality is different from the perception of an omnipotent, cape-wearing superhero with a number emblazoned on his chest. When the newly minted CCIE returns to their workplace after conquering the lab, they aren't all that much different than before. What has changed is their level of knowledge about certain topics. Concepts that were shrouded in mystery are now clear. Outages previously without explanation are now understood. Bad practices are brought to light. But...the CCIE's knowledge is still finite. The CCIE doesn't know all there is to know about every piece of Cisco hardware or software, or even IOS. Knowledge will vary with track.
Like many of you, I am a routing and switching CCIE. That means that while I can configure the daylights out of spanning-tree, EIGRP, and a host of other protocols, I don't know as much as I might about, say, X.25 over TCP. Now, I can read the syntax, and I have a pretty good idea of what's happening. But if my workplace is having major issues with an X.25 gateway, I'm not the guy that's going to fix the problem most quickly. Why? X.25 isn't part of the course of study for CCIE routing and switching. The same goes for ASA firewalls. Sure, I used to teach the PIX class back in the day. But lately, I haven't spent much time with Cisco security devices; the ASA platform is not covered by the routing and switching track.
In that sense, dealing with your workplace can be frustrating. "Hey, you're a CCIE. What do you think about this issue?" "Uh, you're talking about a Call Manager cluster. That's not really my area." As soon as the words come our of your mouth, they sound lame (even to you). Your co-workers look behind you to see where your cape went, as if you somehow betrayed your digits by claiming ignorance about a Cisco product you've never laid eyes on. Reminding them you weren't on the voice track won't help - your digits imply omniscience, remember?
The pain can be worse during conversations where you are, in actuality, a subject matter expert. "Hey boss, we need to get serious about rapid spanning-tree. The advantages over PVST+ are many, not the least of which is fast convergence." To which your boss responds, "But we've never used rapid spanning-tree before. I'm scared. Hold me!" The frustration can be enormous when you know what the right thing is to do, and you know how to get there, but the guy approving your change control doesn't understand what's going on well enough to let you do your job. Or worse, he thinks he *does* know enough about a given topic to argue with you, when in fact he can barely find his car in the parking lot at the end of the workday.
Coping with these situations has been an important part of my career growth since passing the lab.
(1) I've put my ego on the shelf. Yes, I have a good bit of experience. Yes, I've been in a lead role on large networks for several years. Yes, I've even earned the coveted CCIE certification. But no, my peers have not suddenly become ignorant cave-dwellers. Valuing someone else's input, even if their input is ultimately meritless, makes it easier to gain consensus. People want to be heard and respected for their views.
(2) I've gotten serious about knowledge transfer. If I understand a technical concept, and a co-worker asks for my input, I don't brush them off. Nor do I try to take over for myself whatever it is they are working on. Instead, I try to teach - to mentor. I used to think that if I mentored, I'd come off as an arrogant know-it-all trying to impress everyone with how much he knows. But if your coworkers respect you, and if you don't act pompous or impatient, mentoring helps make your entire team stronger.
(3) I've realized that the right technical answer isn't always feasible. Every network I've been a part of has been a compromise. Limited budgets are often a source of this compromise. Cisco design guides outline network nirvana, but the chances are that your company can't afford nirvana. Thus, you do the best you can with the financial resources you're allocated. Some environments are so intolerant of packet loss, that compromise exists only because a recommended change would cause a forwarding interruption. Learning to live with design compromise has proven important to my mental well-being.
(4) I'm not too proud to admit when I don't know (or when I'm wrong). I've heard many engineers bluff their way through an answer because someone put them on the spot. They were too proud to admit they weren't sure, so they spoke as an authority, leading others astray who rely on their expertise. No one wins in this situation. CCIE or not, there's plenty of questions I can't answer off of the top of my head. My ignorance only poses a problem when I let my pride get in the way. Being wrong is only problem if I actually believe I'm incapable of making a mistake.
Ethan Banks is CCIE #20655. When he's not blogging at cciecandidate.com, he's slaving away at a leading payment card processor servicing North America.