Author: Tim Fiola
With s-foils locked in attack position, these X-wings are optimizing their heat dissipation and targeting in much the same way that learning coding and automation will optimize your market value.
pic from https://www.syfy.com/sites/syfy/files/styles/2280x1280/public/wire/legacy/Xwings_trenchrun.png
In aggregate, there is much more value in using coding and automation to solve problems around the network than there is in getting a vendor certification. To maximize the value they provide, and thus the salary they can command, many network engineers would be better served by spending time learning coding and automation, versus pursuit of a vendor certification.
Many network engineers would be better served by spending time learning coding and automation, versus the pursuit of a vendor certification
In his books The Innovator's Dilemma and The Innovator's Solution, Clayton Christiansen asserts and supports a few points:
As a network engineer, you are becoming a commodity
This article is not going to offer all the support for Christiansen's assertions above because his books do that much better than I could. I'd encourage everyone to read them. But if you're willing to take the above assertions as true, then please keep reading to see how they affect the network engineering job market.
The value lies where the solution is not good enough. There are many engineers that are good enough; network automation is NOT good enough
Looking at the current market for networking engineering, there are a few realities
Looking at the value of an integrated solution, the value opportunity here for the network engineer is to offer himself or herself an integrated solution: network domain expertise and the ability to automate and/or code away the pain points of managing large/complex/quickly-growing networks. This includes addressing the problem of scaling and the capability to reliably reproduce operations on the network. Having the integrated solution of a network engineer that can automate and code, you go a long way towards complete control of the interface and thus reduce all the potential interface problems between the network and development disciplines.
The value opportunity here for the network engineer is to offer himself or herself an integrated solution
Another approach to an integrated solution is the integrated team, where a developer or two are matched up with a handful of network engineers. Proponents of this approach argue that an integrated team reduces the friction in the interface between a group of developers and a group of network engineers. I argue, however, that this is not a truly integrated solution: it is a permutation of the modular approach and an evolution of the integrated individual. It is not truly integrated because there is still friction in the modular interface between the devs on the team and the engineers. With each person having a distinct skill set, there is still a lot of potential for misunderstanding and miscommunication in the interface (communication) between the two disciplines. The integrated team can be very powerful and is likely required for a solution to scale massively, but I will also put forth that if the network engineers on that integrated team have some automation and development experience, the friction on the modular interface between the two disciplines is greatly reduced because the network engineers have a better understanding of the constraints and considerations of the development process. In that respect, the integrated team is an evolution of, rather than a replacement for, the individual network engineer with automation/coding capabilities.
The integrated team of Devs and Network Engineers is an evolution of, rather than a replacement for, the individual network engineer with automation/coding capabilities
Now that I've covered the benefits of building the coding and automation capabilities, let's discuss the vendor certifications. To level set on this point, I want to point out I earned Juniper Networks Certified Internet Expert - Service Provider (JNCIE-SP) number 419. I did, however, let my cert expire after a few years. There were a couple of reasons for this, which are beyond the scope of this article, but one of the reasons is indeed the subject of this article.
JNCIE-SP 419. Also, a Super Star Destroyer because it's awesome.
A lot of good comes from the pursuit of a cert: it focuses your efforts on a measurable goal and builds your skills along the way. It makes sense to perhaps at least pursue a cert for those benefits, but if you have put in the time but don't get the cert, don't fret too much as you have most certainly improved yourself along the way: it's the journey that counts, not the destination.
A typical vendor cert test will require you to fix or build a network, and then expand the network's capabilities to account for new requirements. However, the certification environment, by its nature, is very unrealistic and artificial because it requires you to do all this in an artificially short time span that does not allow you sufficient access to documentation or your own notes. This is ridiculous: the same constraints that make the test a real test also invalidate the test's credibility, up to a point, because most legit organizations would not put those constraints on their engineers.
The same constraints that make the test a real test also invalidate the test's credibility, up to a point
Proponents of vendor certs almost always point out that a person with a certification likely looks better on paper, and thus is more likely to get an interview, than a person without a certification. I do agree with this point, but it's not nearly as important anymore.
The confirmed capability to build a network to specs in a few hour time span overserves the market: no employer (or very few) are willing to pay additional comp for an employee who can engineer a network in a few hours. Being able to do so is a great accomplishment and capability, but it's not a capability sought by network operators. Generally, a network operator is fine with an engineer who learns concepts quickly, proceeds deliberately in applying those concepts, and then engineers the network over the course of a few days or even months. Again, there IS value (and skill) in being able to do that engineering in a few hours, but that is not as likely to get you additional compensation.
By earning a cert, you may be more likely to get to the front of the line for an interview, but you are interviewing for a job that does not pay as well anymore because it has become commoditized
Earlier, I asserted that a network engineer is a commodity, and as such, is likely to be paid less and not be treated as well by their employer. By earning a cert, you are more likely to get to the front of the line to interview, but you are interviewing for a job that does not pay as well anymore because it has become commoditized. And, since being able to engineer a network in a few hours overserves what the market needs, the ability to do so is not likely to increase your salary a significant amount.
Contrast the certified engineer with an engineer who has also invested time in building coding and automation skills.
Look at the differentiators for a vendor-certified candidate; most of them will be very effective at getting the candidate an interview:
The biggest differentiator for a certification is not necessarily one that employers will pay extra for: the ability to engineer a network in a few hours
This is a strong set of differentiators, to be certain. However, the biggest differentiator is not necessarily one that employers will pay extra for: the ability to engineer a network in a few hours. Additionally, none of these explicitly align with common strategic goals such as reducing opex, improving scalability and repeatability of network operations, and automating workflows. To be sure, a well engineered network will fall in line with some of those strategic goals, but a well engineered network is a few levels down from these explicit, higher-level strategic goals.
Now consider the differentiators for a candidate with automation and coding experience:
The engineer with coding/automation capability is offering an integrated solution: she can help the network scale and get much more work done than someone without the coding and automation skills. In addition, she can also offer herself to be an effective part of a team with integrated developers since her experience with coding and automation allows her to communicate and collaborate with the developers and understand the development process much better than her non-coding peer.
The coding/automation differentiators will tend to get the candidate an interview, an offer, and a better salary because they tend to align more with a company's strategic objectives.
Vendor certifications are a legitimate and good use of time because they help the candidate get an interview and help build skills and experience. Automation and coding skills, along with networking experience, by contrast, help the network engineer get an interview and a better salary because they provide additional value (features) that the market actually needs.
The additional skills and experience gained by a vendor cert are certainly helpful. But, consider this option:
These skills will stand out on a resumé and increase the value a network engineer can provide.
The analysis above combines my experience and macro analysis of the job market for network engineers and the macro concepts explained in Clayton Christiansen's books. It is meant to provide some insight as to where to spend your time improving your skills to increase the value you provide. I am curious to hear your thoughts on the matter as well.
BACK TO TOP