When do You Quit Certifications?

I received a question on Twitter from my friend Fernando on feedback on when to give up on certifications:

@danieldibswe would really like to hear your thoughts/inputs about this question. https://t.co/ulNKcsiCEp

— Fernando Herrera (@Fern_HerreraJr) April 18, 2020

First of all, not everyone will agree that you even need certifications. That’s another discussion and I think there are not many reasons to avoid them entirely, but let’s assume that you already have certifications, when do you give up on them?

That is going to be a choice each person has to make, and it will depend on a number of factors, I think. Here are some that immediately come to mind:

• How do you learn?
• Current role
• Bonus models
• Future role
• Number of years in the industry
• Body of work
• Are you well known in the industry?

What’s your method for learning a new skill? People use certifications differently but for me it’s about a guided learning path. I know roughly what to study to become decently skilled at a topic. For example, when I wanted to learn more about AWS and their networking, I decided to study for the AWS Solutions Architect Associate. For me, it’s motivating to learn new things, and certs can help you with the process. Some people like to learn in different ways and that’s OK.

What is your current role? If you like me work for a systems integrator, or possibly a vendor, there’s a certain weight to having certifications when you are involved in customer projects. It shows, hopefully, that you have invested time into learning the things you are working on, and that the customer can be comfortable with that you are an expert at what you do. There may also be other factors, such as billing rate. It’s not uncommon to base billing rates on years of experience, and the level of your certifications.

Often in these type of roles, there are bonus models associated with passing and/or maintaining certifications. For example, at Cisco you get paid extra if you pass the CCIE, and also for maintaining it. I have received increases in pay for achieving certifications as well. For that reason, it may make sense, if for nothing else than financial reasons, to maintain your certifications.

What do you plan to do in the future? Do you want to stay in the same type of roles? or are you looking to do something completely different? For example, maybe you are moving into network automation, or some kind of SRE role. Certifications are likely less important there, although they do exist.

How long have you been in the industry? Starting out, there is a lot of value in certifications, and I would recommend people to go for them. If you have 10+ years in the industry, you will likely have built enough experience, and body of work, to not have to rely on them as heavily. You can show case previous projects, and the roles you’ve had will be an indicator of if you have the experience you are claiming to have. I have roughly 2.5 years until I can become CCIE Emeritus, if I wanted to, but for me, keeping my certifications active show that I am still passionate about learning.

What’s your body of work? Meaning, do you have a blog? Have you written a book? Have you run a podcast or Youtube channel? Can I find you online in any forums? Have you done training online? If you have done some of these things, there is a trail for someone to follow to see at what level you are. If you have written a book on something, hopefully you know that topic pretty well. If you have a lot of things you can display to a potential employer, similar to how artists keep a book with their work, you are not dependant on certifications to demonstrate your skill level.

How well known are you in the industry? Related to the topic above, will most of the people in the industry know about you? When you have reached that level of “fame”, having certifications to the name becomes less important. People will see your name, and expect that you know what you are talking about. Which may or may not be the case, but you will likely be given the benefit of the doubt.

Now, to give you some examples and to add a little color to this post, let’s look at a few well known people of the industry.

Greg Ferro and Ethan Banks – The founders of PacketPushers, and the most well known podcast in the networking industry. Starting out, they both had blogs and both were studying for or had achieved the CCIE. When PP was new, they were still working day jobs, and having a CCIE to your name definitely gives you some more weight when starting a podcast. Their certification served them well. Now everyone knows their name, and what they have achieved. They do PP full time. Having a cert to your name adds little, if anything. The only reason for keeping it, would probably be if you had thoughts of going back into consulting.

Ivan Pepelnjak – Ivan is very well known and respected. I would trust him with a critical network design, regardless of if he has any certifications or not. He has written books and developed a lot of training material over the years. He is easy to find, and his body of work is massive. Maintaining a certification doesn’t really add a lot to the credibility that he already has.

Now, let’s look at someone like my friend Nick Russo. He started becoming well known when he published the massive CCIE SP workbook, after passing that exam. It would be difficult to be seen as credible publishing a book like that, without actually have taken the test, and passed it. He works for Cisco so it makes sense to be Cisco certified. He also does a lot of DevNet training, and to be relevant, and up to date on what candidates are seeing, you need to put yourself in their shoes. He is also more likely hands-on than the others I mentioned.

To summarize, as in all choices in life, especially for your career, you need to carefully consider where you are now, where you want to go, and what you need to get there. Personally, I still have a passion for learning, and still consider certifications to be one of the best ways of staying on the right path, and motivating you to keep going.