As always, opinions in this post are solely those of my own, and not necessarily those of any organization I am currently affiliated with or have been in the past.

First posted 2/28/2021

The year is 2007. I just finished up my CompTIA certification trifecta, I’m playing Halo 3 with all my friends every night, and the Microsoft Zune is heavily marketed as the must-have superior iPod replacement. One of the things I miss the most about those pre-CCNA days is when you’re starting out in IT, you have a somewhat obvious path towards getting a bachelor’s degree, associate-level certifications, and gaining work experience. You might have a little analysis paralysis when deciding which school to enroll in, which internship to take or which certifications to pursue. But in the grand scheme of things, you’re well on the way towards a good non-helpdesk job by getting that degree + CCNA. I deeply miss such a nice, linear path towards technological knowledge growth!

Fast forward to the year 2019. I just finished my CCNP, none of my friends play the same exact online videogame anymore (if they even game at all), and the Microsoft Zune‘s legacy is an epic failure. Having a CCNP and a CCNP-type job is amazing, but after getting a master’s degree or working in a mid-level IT role, that obvious path towards degrees and certifications can turn into a non-linear mess of antipatterns. It’s so easy to get overwhelmed with “what’s the next step” questions like the following on your mind:

Should I bother with the massive time commitment for JNCIE-ENT? Maybe I should get CISSP? Then again, perhaps I should beef up my automation skills before pursuing any more certs? Actually, that awesome new Cisco ISE Certification book is out, should I invest the time to pass that test for CCNP continuing education credit? Or is now the best time in my career to think about a doctorate? Maybe this internet fad is running out and I should get a Commercial Drivers License before the autonomous vehicles take over?

Ok, so that last question was a bit ridiculous, but I think you get the point that deciding what technologies/certifications to master & which ones to defer/avoid can be quite mentally taxing mid-career. I wish someone told me earlier in my career that as much as I might try, it’s impossible to achieve expert-level knowledge in all disciplines of IT, and it’s not a big deal if something you master goes the way of the Microsoft Zune. Figuring out which “tools to keep sharp in your IT career toolbox” is an art. Occasionally it’s in your best interest to throw away tools you’ve spent lots of resources on in an effort to make room for newer ones, as painful as that might be. Just printing Cisco’s A-Z product index is 24 pages of data alone, it’s simply not possible to become an expert at their entire product line, and that’s only for a single IT vendor!

So how does one decide on which technologies they should keep sharp in their IT career knowledge toolbox, and which ones to toss in the recycle bin? Well, to be honest, I don’t think there’s ever going to be a one-size-fits all answer to that question. In fact, I’m sure I will spend a gratuitous amount of time sharpening at least one IT skill over the next year that will become hopelessly irrelevant to my career 10 years from now. I’d like to share a pair of practices & personal experiences which have helped me quite a bit on the mental gymnastics associated with choosing which IT skills I want to improve. Your mileage will vary, and I hope to hear your thoughts about the following in the comments:

Practice #1: Try to focus your career on things that produce “flow” whenever possible

If you’re not familiar with “flow“, I’d strongly recommend watching the following Ted talk, it’s well worth the 18 min:

I’m a big fan of trying to maximize the number of things that produce flow for me at work. There’s only so many hours in the day, and there’s always going to be work things that nobody wants to do, but I try to do at least one tiny task per day that truly brings me flow. Recently I’ve gotten a lot of flow from better automating small firewall changes using Python, but there was a time when I hated the idea of doing anything with coding, which leads us to the following experience:

Experience #1: Learning certain things like subnetting & coding basics might not give you flow, but they’ll lead you to things that will!

Turning back the clock to 2007 again, I had the huge advantage of working a computer repair job where my Cisco Networking Academy trained boss was willing to help me learn ipv4 subnetting while I was studying for the CompTIA Network+. While I hated subnetting at the time, eventually I got the hang of it, and that paid dividends when I was at USMC Data Systems Technician school a year later. Almost everyone else in that USMC job school was having a terrible time during the week we learned subnetting, some even doing 16+ hour days trying to avoid failing out of the course, while I ended up playing a lot of Xbox that week since I already knew it well πŸ™‚

In hindsight, I probably should have done more to help my classmates, and 18 year old me didn’t appreciate just how lucky I was to have learned subnetting in a far less stressful environment with an expert tutor. Very few people enjoy learning to subnet, but it’s a prerequisite to doing far more exciting networking things that will bring you flow. You really need to have the self-discipline to learn it, otherwise you’re not going to grow as a network admin. It’s a necessary evil.

Now let’s fast forward a decade to 2017. I’m doing 16+ hour days trying to get some datacenter refresh projects completed within a specified maintenance window. My team lead is insisting I use some fancy new network automation templates instead of doing the hand-crafted switch configurations I’ve always done. The automation templates were outside of my comfort zone, so I got really frustrated and had to fumble my through a mess of manual configs because of my stubbornness to learn coding fundamentals. I guess “what comes around goes around” is true; because I was now in the same stressful position as my USMC classmates were a decade earlier trying to learn a tricky new skill under a time crunch!

To make matters worse, I was severely lacking the motivation to improve as I’d make excuses about having too many other datacentery things to do instead of powering through a Python for Network Engineers course. Eventually I found out very few people enjoy the initial plunge into automation (especially Python), but it’s a prerequisite to doing far more exiting automation things that will free up your time for other stuff that will bring you flow. It’s a necessary evil. Just like subnetting.

So how is this experience related to the “you can’t fit every tool in your toolbox” conversation? It’s because I now strongly feel if you want to advance in the networking world, you NEED to have some level of network automation in your toolbox, just like you NEED to have some level of subnetting knowledge. This was not the case 10 years ago, and I feel like network automation skills will be even more valuable 10 years from now. I spent far more time than I should have in the comfort & fear zones when it came to adding network automation into my toolbox. Don’t worry if you’ve struggled with programming basics in the past! With enough practice & time, anything is possible.

Comfort Zone Graphic

Practice #2: Listen to vendors & non-vendors about where they see the future going

Per the kd9cpb.com homepage, it’s no secret that I’m a big fan of the Packetpushers podcast network. My favorite production of theirs is the weekly network break, where I absolutely love hearing what the packetpushers crew has to say about the most recent technologies getting pushed by the vendors. This information is really important not only for awareness of the latest networking trends, but also to help you decide on which technologies might be worth learning more about. Finding the time to keep track of podcasts & listening to them can be an uphill battle, especially if you’re working from home during the pandemic. As of this writing I’m pretty behind on the NetworkCollective podcast, and I hope to fix that soon. Whether it’s on a longer drive or on a treadmill, try to take a network podcast break, it’ll really help you decide which tools you should keep sharp in my opinion.

It’s important to listen to what vendors are saying, but you also need to take everything you hear with a grain of salt, which is why I love packetpushers and r/networking so much. If you only listened to what vendors have to say, you could have fallen into the pain that was trying to make Cisco IWAN or Windows Vista work in enterprise IT! Having a vendor come on-site and work with a reseller to solve your organization’s problems is a good thing and very much necessary in some cases. That service comes with the tax of a vendor (and possibly reseller) not having your organization’s best interests in mind, so be sure to keep your assertiveness skills sharp for when you need to breakup with a salesperson too.

Experience #2: Sometimes you’ll sharpen tools that become worthless. It’s ok, that’s part of IT.

Flipping back to 2007, I got pretty good at Novell Groupwise and Open Enterprise Server (Both the Netware and Linux flavors!) for small business clients at my first job, as they were using Novell products since the early days of PC networking in the 90’s. There was even a Novell server running in my parent’s crawlspace at one point, I had really bought into their “Your Linux is ready” campaign! Much to my surprise, Groupwise is still alive in 2021, but nearly all of that knowledge I learned to support those Novell products is totally irrelevant post-pandemic. That’s perfectly ok! I occasionally miss those simpler pre-cloud Novell times. But I know that throwing my Novell skillset out years ago to focus on CCNA was the right thing to do, as painful as it was to give up on their dream Linuxey future. Earlier in the pandemic I found my ancient IBM Thinkpad T23 I kept around that still had Novell Client for Windows XP installed, which makes for a fun pandemic themed photo for this post, but otherwise not useful for much else:

While it was frustrating to see so many hours of sharpening up my Novell skills get thrown in the recycle bin, that’s just part of being in IT. I got paid to learn Novell, I got paid to learn mainframe printing, and I’ll get paid to learn some other technology that becomes irrelevant at least a dozen more times. It’s part of the job. I learned a ton about Linux thanks to Novell buying SuSE, but all those hours of experience troubleshooting Groupwise isn’t going to do anything for my career going forward.

Sometimes you get lucky and learn skillsets that stay relevant for many years in IT. Sometimes you learn a promising product (Like supporting Novell Desktop Linux or repairing the Microsoft Zune) and it doesn’t survive. Don’t get too upset when this happens, if anything consider it a rite of passage within the IT world πŸ™‚ Remember that RFC1925 says it best: Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.

Whenever I find myself caught in a terrible bet I made about the future of technology, I have to remind myself that the author of one of my favorite cybersecurity books ever also published a book about eCommerce being a bunch of baloney in 1995, which has aged as well as milk:

To Cliff Stoll’s credit, he’s owned this mistake and is still a highly respected cybersecurity icon. I’ve made way more mistakes & failed technology predictions than I care to admit over the years, it happens. Don’t beat yourself up when you get things wrong, and use that knowledge to build an awesome growth mindset, you’ll be glad you did!

Conclusion

Some days, I want to just focus on sharpening my hard IT skills in the homelab without having to deal with any humans. Other times, I want to focus on sharpening my soft professional skills so that I don’t have to work as hard πŸ™‚ All joking aside, it is possible to be the smartest engineer in the room, yet nobody wants to work with you due to a lack of professional skills. I’ve seen people do that, and it’s really sad when it happens. For this reason, I would recommend not only trying out some of the above ideas for keeping the IT skills sharpened, but also spend some time at the library reading up on various IT management topics. I personally like reading the IT Revolution books the most, but that’s just my $0.02.

All of the stuff I mentioned in this post takes valuable time out of your day, and I think it’s worth repeating that nobody can be an expert in everything IT related. Get some time away from the screen and make sure you’re not getting burned out, sometimes that can be the most effective tool in your toolbox after a stressful technology migration project. I hope some of these ideas help any CCNA candidates or newer CCNAs out there who feel like they need to master all 24 pages of that Cisco A-Z product index. It’s not feasible to master all the skills necessary to support everything. So don’t make yourself crazy trying to do so!

Special thanks to everyone I ran into at USMC Data Schoolhouses over the years.


You’ve reached the end of the post! Click here to go back to the list of all CCNA candidate toolbox posts.

You should also know I may earn commissions on qualifying Amazon purchases made via kd9cpb.com links to defray the cost of otherwise ad-free web hosting.

You can’t fit every tool in your IT career toolbox

Post navigation


2 thoughts on “You can’t fit every tool in your IT career toolbox

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.