I began my professional career after college by starting in route/switch. Although I still do plenty of route/switch work, I have also recently taken on responsibilities focused on more datacenter-centric technologies like virtualization, and storage, in addition to the networking in the back-end that makes it all work. Much to the stress of my schedule (and my……stress), one has not trumped the other - they simply exist in parallel.

I’m not alone - many engineers branch out into new technologies beyond what they view as their core competency. It’s part of what defines an energetic, passionate technologist: the desire - or in some cases, need - to learn more about what is currently a blind spot. However, this “branching out” manifests itself in many different ways, and although many engineers are adopting this, still a vast number remain isolated in one area and don’t like to go too far outside their comfort zone.

I haven’t done any polls or studies, so I won’t pretend to know what percent of the technology industry actually does this. The point isn’t “who’s doing this” or “who isn’t”. The point is that this “Unified Skillset” I’m going to talk about is an option for enhancing your professional career. This isn’t a commercial for Cisco; the “Unified______” pun was intentional but meant to apply to a concept that transcends vendors and borders. This style is not for everyone, but I believe by approaching your technical career in this fashion, you gain the ability to write your own checks, both in the financial and non-financial sense.

We live in a world where data is now co-habitating with voice. Storage with network. We no longer rely on dedicated physical servers (those that haven’t been under a rock) for running our business; we now cram as many virtual servers as we can into physical hosts, thereby reducing physical footprint as well as numerous other factors. These are not new ideas - the technologies are modern, but the need to be more and more efficient, even if it’s marginal improvements, is something society in general has always been about. Especially in light of the aforementioned “convergence” technologies, businesses have realized the benefit of doing more with less. The technology matured to the point where it became feasible, and we haven’t looked back.

This post, in summary, is about the fact that although the convergence of technology came first, the convergence of the engineers will come very soon after, and in many cases, has already begun.

Perspective

Most folks in any sort of technology-based role can think back to the beginning and remember what first grabbed their attention, or the role that first gave them entry into this industry. For some, it’s system administration, or route/switch, or even software development. We all come from different backgrounds, and for most, that role has changed and evolved over time and across different employers. I would say most if not all of us can pick one of those skills as “home base” - that core competency that you either enjoyed most or were best at, and that’s now your thing. Despite what I might say in the paragraphs to come, that skillset for me is route/switch. I am VERY interested and engaged in my current role as a datacenter architect, and I love working with all kinds of related technologies, not just route/switch.

As a result, any time I spend in other areas will still be seen from the perspective of that core skillset. If I’m learning a new topic related to blade computing, or explaining it to someone else, I will always use that background as a jumping-off point to produce analogies and comparisons to make it make more sense. Now - and this is just an opinion - I feel that route/switch is the BEST core competency or “starting point” to have, because I feel that it’s most conducive to this kind of thing. I believe that if you learn route/switch first, the other skills come more naturally because you’re following the technologies up the stack. Again, just an opinion, and it’s a biased one at that, since it worked for me. Another approach may work for you. My point is that we all have that starting point, and we won’t ever be able to get away with it, with the possible exception of completely abandoning and forgetting it for years.

Sometimes this can be a good thing. For instance, a security engineer can really bring a unique perspective to a project where virtualization is being rolled out and either already has some unique security requirements, or the design put forth would have had some serious security issues had the engineer not been there to take a look. The engineer can probably interpret between the two fields relatively easily. I think any technology-savvy person can learn both and be good at it, but those that adopt both and approach both areas with the same passion can gain the experience necessary to REALLY be good at both - to  know where to look, and what to see. A good example is the fact that vXLAN requires the use of Proxy ARP. Most virtualization engineers will look at that requirement and simply say “Okay network guys, it says I need this, so turn it on”. Most security engineers will understand that simply enabling this without some serious considerations is a general bad idea, but then again, they probably don’t understand the value of a technology like vXLAN in the first place. Someone who has put in the time to experience both worlds will not only understand the requirements, but will be able to also engineer a solution around both areas without getting someone else involved that’s more specialized in one area. This engineer did inside their brain what at least two specialists with opposing backgrounds would have to discuss at length over a whiteboard.

However, this can also be a curse. If you spread yourself too thin, it’s easy to simply become too weak in ALL areas, commonly referred to as a “jack-of-all-trades, master of none” or “mile wide, inch deep”. It’s important to remember that while I do recommend branching out, and going as close to a “mile wide” as you can, I will also recommend that you go as deep as you can. This is a big reason why this style is not for everyone - because in order to really make this work for you, you have to make a pretty big time and energy commitment to do it right. More on this later.

Another dangerous position is the idea of an engineer that’s so set in their ways that they can’t see the big picture. What if the security engineer was so stubborn (admit it, they often can be) that they are not able or willing to engineer around a potential security problem, and they simply say “no” to something like “please turn on Proxy ARP”? Take, for instance, the whole argument about IPv6 and NAT. It’s my (well-informed) opinion that the majority of those arguing to keep NAT around for an IPv6-connected world have simply lost touch with what NAT does and does not do, or more importantly, what it should and should not do. They are so used to seeing configs that involve NAT, that they simply will not accept a world where it is not necessary. They’ve lost their big-picture perspective, and because of this, they won’t even consider the benefits of an internet without NAT. Gaining perspective from multiple angles allows us to drop the confrontational behavior, and truly understand the technologies we’re talking about.

Relevant Anecdote: I was part of a project that included the roll-out of a VDI solution. The team responsible for actually setting up the VDI software (I was responsible for the compute, and storage portions of the solution) were having problems getting the desktops to pull DHCP addresses. The helper addresses on the VLAN gateways had been set up correctly, and I could even statically assign an address and ping the DHCP server, so it was very difficult to see why it wasn’t working, since it didn’t seem to be a routing issue. The firewall team was engaged to troubleshoot this issue, and they verified that there was no way that a firewall was a factor - wasn’t even in traffic path.

As it turns out, DHCP snooping had been turned on in the data center switches. This makes sense never before have we had to be able to pull DHCP addresses from within the server infrastructure until technology like VDI came out. The troubleshooting was mainly difficult because the two teams came from COMPLETELY different backgrounds. The firewall and network folks were just that - firewall and network folks. They outright didn’t trust the VDI guys, or their software. On the other hand, the VDI guys had absolutely NO networking know-how, so they defaulted to what many non-networkers go to frequently - it absolutely MUST be the network/firewall! The problem was that neither group knew the right questions to ask, and communication simply broke down. It finally took someone with a little experience on both sides to bridge the gap and go through the appropriate troubleshooting steps to identify DHCP snooping as the issue. In case it sounds like I’m tooting my own horn, that engineer was not me in this case. Someone else stepped up and bridged the gap, and I write to you now as a proud observer of this instance.

This is one of the reasons why I mentioned that my opinion is that route/switch is one of the best core competencies, or “starting points” to have. Eventually everything has to hit the wire - everything has to touch the network - so your ability to narrow down to the root cause of a problem is much higher. This is less likely with things like Microsoft technologies, where you’re pretty much bound to what the logs tell you. If you learn route/switch on at least a basic level, you’ll know at the very least what kind of troubleshooting you need to do and what information you can proactively gather for the route/switch engineers that will be troubleshooting the problem.

Labels and Experience

About 5 months ago, I made the decision to stop introducing myself as a “network guy”, or “server guy” or “storage guy”. Truth is, I do all three. Am I the best at any of them? Absolutely not. I am, however, very passionate and excited about all three.

I have found what seems to be a universal constant in IT - people will always have preconceived notions about your skillset based on how you identify yourself to them. If I introduce myself (explicitly or implicitly) as a “storage guy”, people start going through in their minds what I can and cannot do, based on their experiences. I do the same - if someone comes up to me and says they’re a server guy, they could be a really smart engineer, and good to work with - but the moment they come up to me with an issue they’re having, where they say they can’t connect to ____, my thoughts immediately go to “Oh, here we go again. Server guy trying to understand networking”. Is that a helpful attitude? No.

A good example of a modern-day unified engineer is someone who works in virtualization. It is now pretty rare to find a good virtualization engineer that doesn’t have a pretty good working knowledge of physical server architectures as well as administering Windows, at least on a basic level.

Many small-to-medium enterprise IT admins have branched out to areas outside of their core skillset, mostly out of necessity, but it’s usually much harder to keep this skillset from becoming stale and watered-down because day-in and day-out, they only work with the infrastructure that’s under their control. Change comes slowly and infrequently in many environments like these.

A large number of those that go the other direction, which is to specialize HARD in one or two specific areas, tend to gravitate to industry segments like professional services (like a VAR or vendor) since those organizations tend to be project-based or contract-based and need specialized skillsets for the simple reason of being able to guarantee quality of work to their customers.

The Unified Skillset and the Unified Engineer

I want to be clear - my description of the “Unified Engineer” is by no means the definition of success in the technology industry. When I talk about the need for the Unified Engineer, I’m not at all saying that those that choose to focus in one specific area are less talented, or will be less successful. The adoption of several skill-sets is a trend that we’re seeing more and more of, and will define the success of SOME technology professionals in the near future - but this is and always will be up to the individual’s background, mindset, and lifestyle. Many of those who adopt a multi-skilled mentality have been far less successful than those that specialize, as well as vice-versa.

The quest for the “Unified Skillset” is not an easy one. It requires intense dedication, sacrifices, and lots and lots of sleepless nights. In the future, it will not be enough to be a “jack of all trades, master of none”. It’s very possible that engineers will soon be expected to be a jack of all trades, and a master of as much as you can stand without going insane.

From the perspective of the organizations that are out there hiring these engineers: investing in multi-skilled engineers does a few things. Yes, it could potentially cut down on the number of engineers you really NEED, but it also does something you may not consider - the amount of time spent communicating between two engineers can be dramatically cut, if those two engineers can be condensed to one - it’s all just thought processes.

The Verdict: “Specialist” vs. “Jack-of-all-Trades”

It’s been said that specializing in one area can tend to be more financially profitable, since it allows you to focus on growing that particular brand of experience and technology and becoming that ______ ninja that we all aspire to become.

Then again, if you consolidate roles onto yourself, the argument can be made to the employer that you’re taking on more roles and more responsibilities, and doing them well, so a bump in pay is expected. In most cases, this ends up being cheaper than hiring individual engineers for these roles.

Also, it shouldn’t have to be said, but I’m going to say it - brain-dumping or cert-hunting is absolutely NOT what I mean when I say be a jack or even near-master of all trades. By no means am I suggesting that you adopt the shotgun approach. If you go out and get a bunch of certifictations on your resume because you think it looks “badass”, think again, because if the interviewer is anything like me, that interview is going to suck for you.

That leads me into the conclusion of all this. If branching out is going to cause you to perform poorly in that new role, or lack in other areas, like the skillset you started with, then it’s not worth it! This approach is not meant for everyone, and if specializing in one area keeps you focused and competent in that area, then by all means - stay the course, you’re doing amazing. This decision is up to the individual - weighing circumstances and quite frankly - life to feel out the best way to participate in this industry.

This idea of “Jack-of-All-Trades, Master of None” vs “Specialist” is really a moot argument, when you think about it. The way I see it, the decision is to either be a Specialist, or a “Jack-of-All-Trades, Master of As Much As They’ll Let Me”. The decision is yours - but no matter what, be vigilant, be disciplined, and take a break every once in a while to enjoy life.