Menu dรฉroulant pour mobile

From Network Engineer v1.0 to v2.0

19 May 2017 | Written by Nicolas Michel | Published in Career

I recently relocated to the US from France/Switzerland and I have been so busy the past 2 years working on that process. Yes, It is that long! 

I have been asked about career advice twice this week and I wanted to share my thoughts about it.

Networking in 2008

I think we all agree on the fact that the networking field has been very static for the past 15 years. One of the ways to provide a better network experience to the users/applications was to add more bandwidth (or invest in WAN optimization). OSPF/BGP/EIRGRP/MPLS and spanning tree haven’t changed much since 2002 right?

All the networking manufacturers paradigm was all about releasing new hardware that could provide more bandwidth and availability. As an engineer, you had to know networking protocols but we also had to understand specifics of networking hardware. It was very useful to understand how the 6500 Crossbar was switching packets internally. Another example was the StackWise technology: who remembers that the 3750 v2 could not locally switch without sending packets on the ring?.

Every device had a specific function in the network for example (which is still true at some point). Engineers were doing was vendors told them to do and they had to standardize their deployment (Access – Distribution – Core). It was a safe bet to design to design a network using the 3 tiers architecture mentioned previously.


Some networking engineers are self-educated up to a certain point and one of the ways to learn networking back in the days was to read a Cisco Press book, buy some hardware (2950 – 3600) on eBay and do some labs on your own or using a third party training company. For these engineers, the way to get a job was to climb the traditional certification pyramid (CCENT – CCNA – CCNP – CCIE). While this is still kinda relevant, the CCIE does not automatically open doors for any jobs anymore. Matt Oswalt published a quote that makes total sense “vendor certs are basically a way of putting the vendor in control of your career. On the other hand, fundamental knowledge puts YOU in control”. 

I have a dual CCIE and studied very hard to get where I am today but the journey is far from being over (hopefully). I need to be a little less focused on proprietary certification and get some open source knowledge as well. (Damn CCDE you are tempting but I need to resist !)

Linux/Python skills were definitely not mandatory in any of the job descriptions back in the days. But as you can guess it becomes more and more a requirement nowaday.

I’ve been invited to a very interesting dinner with CIOs of Fortune 100 companies recently. They are all aware of the ongoing networking transition. They admitted it was not an easy plan to embrace this evolution but they are already preparing their teams for that.  

Speaking of technologies, which technologies are we talking about? Do we need to know everything in IT? the answer is obviously “No” but it is valuable to at least understand how all the systems are interconnecting to each other.

Here is what a job description looked like back in the days (2008):


The need for evolution

I am doing this blog post is because our field is changing and our skills need to evolve with the networking trends. Engineers are the core of the networking industry. We all have a critical function in every organization that is willing to undertake their “business digital” transformation. We need to prepare how to evolve with the upcoming technologies.
I am willing to create a blog post series on how to tackle your own networking evolution. Please do not get me wrong, we still need to understand bits and bytes of all the networking protocols in order to provide connectivity. This statement will never go away (hopefully) and there is no working overlay if the underlay as been designed carefully. What needs to evolve is the way we are able to provision services for our customers/users/applications. When was the last time you heard that the networking team was taking too long to provide connectivity between A and B? 


Networking in 2014+

Short story long, network engineers have to stay relevant throughout the years. 

Today it would be a bit different, it is definitely expected to know everything that is above right  (except maybe Cisco Works and CatOS ๐Ÿ™‚ )

Himawan Nugroho made a great Cisco Live presentation that I attended in Milan: BRKSDN-4005 – CCIE Skill transformation to SDN kungfu. The most interesting slide for me is the following one: 


He confirmed what I was explaining above. You still have to be an expert at traditional routing/switching but also have a broader knowledge of the following technologies:  Linux and Operating Systems, Scripting, Overlays (proprietary and standards) and network virtualization. 

Some new protocols and ways to provide network connectivity have recently emerged. Some of them are already dead (Trill anyone ?) and other are being used worldwide in different flavors (VXLAN anyone ?). 

We see plenty of blog post related to the eternal question: Should we learn how to script/code:

My take on this is that you should be able to automate your network and most of your tasks. You should not consider going too deep (for now). We are not required to become a full-time developer.

Some of the following items you will find on this list are not necessarily new but it is something that the network engineers can’t avoid to be aware of anymore. This is by no means an exhaustive list but it gives you an indication of what the current trends are in our industry. Feel free to drop a comment if you think something valuable should be added.


Acquiring all of these skills do not happen overnight so I will publish quite a few blog posts about how I am preparing my own evolution. Let me know in the comments below what you liked, disliked or if you have any question.



16 thoughts on “From Network Engineer v1.0 to v2.0

j’aime ce poste. Ce n’est pas que dans le reseau mais dans toute la stack IT (stockage / virtu / OS / application) que ce changement doit se faire. La vrai question c’est le timming. Si tu etait toujours en suisse pas sur que tu est ecris ce post aujourd’hui et pas forcement sur les meme technos.

tu l’aurais peut etre ecris dans 2 ans en parlant de powershell (sigh) plus que linux/python (bash/perl)

Hello Anthony! Indeed this transition needs to happen in the whole IT stack but since I don’t have a deep expertise in the other areas I targeted my blog post for the audience of this website.
As I said, the transition cannot happen overnight and most of the engineers can feel frustrated by the fact that they have built expertise and reputation in core routing but now, they have to start over and learn basics on something totally different.
Yes I would have done the same blog post if I was still in Switzerland. We are totally working with the same technologies, the only real change is scale maybe ๐Ÿ™‚

Yeah Powershell is something that NSX is leveraging a lot in our field but I will come to that later ๐Ÿ™‚

Interesting article! Actually, this week, I made a speech on the very same topic in Switzerland to customers and partners.
Although, it is important to keep and nurture deep technical skills, there is an opportunity for Network engineer to become much more business aware. It requires the people to embrace similar concepts than DevOps: automation (scripting, software-defined), focus on customer outcomes (customer value), leverage tools like network analytics to assess, plan and report on network performance (rather than only health monitoring: up/down, BW utilization…).
Continuous improvement is the big thing that network engineer should have in mind. “If ain’t broke, don’t fix it” is a rule of another time.

For WAN people, uCPE with KVM and automation/provisionning tool should be the focus… Single function device (a router, a firewall…) are outdated. Would you buy a cell with no application support nowadays?

Salut Nico,

Really nice & insightful …
Engineers that work in other areas should also consider following your advice, for sure …


Hello Manu !

Thanks for your words! the real advices and how I prepare to get new skills will be explained in multiple upcoming blog posts.

Say hi to everyone from me ๐Ÿ™‚

Cheers !

Yah, Actually I am exactly among the traditional networking guys that you mentioned above. I am a CCIE, however all we have to admit the trend of virtualization is so powerful and the ongoing effects are still amplified.
Although embracing virtualization & open source doesn’t mean you have to quit away from traditional networking protocols completely. But it is inevitable for you to start spending more time to focus on new things. To tell the truth, I have been studying OpenStack, VMware, Linux KVM for the whole last month. I do look forward to your next blog posts and adjust my learning goals as per your advice.

NSX leverages PowerShell because a lot of the existing administrative base uses PowerCLI and their work flows are complimentary.

That being said – NSX is not exclusive to powershell. Anything that can interact with a REST API can interact with NSX. Python/Go and other languages form the basis of PyNSXv, Ansible-NSX, and other tools.

totally agree, i think CCIE datacenter will include some of the skills that u mentioned in the post, such as python, ACI, and some virtulization, however other skills not in CISCO are highly demanded these recent years… keeps going i will follow your posts

It’s also hard to get real experience with those concept when you work for a traditional reseller that stills sells “boxes” like switches, firewall or proxies. They still want you to learn the old stuff to run the business.
And it’s also a big change for presales, They don’t know how to sell these new trends like ansible/python ?
Maybe you can sell a script that does specific stuff, but I think automation is more than just some script (there was perl or expect back in the day), I think it need continuous improvement, so not a turnkey solution.

Leave a Reply

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