Specializing or broadening?

Cat5

Ultimately, as far as the ability to get a higher-paying job, which is better - specializing in one specific area or broadening one's expertise to encompass a wider variety of things? I can see the benefits of both, but time constraints would prevent me from doing both. Of course, job ads want everything, but in the real world employers usually only get one or the other.

It seems to me that specializing would be the way to go. Someone who has broad but shallower knowledge won't be given a lot of responsibility, I don't think, thus less pay (generally speaking) unless it's for a smaller company that wants someone to wear many different hats.

instant000

Surgeons make more than general practicioners.
Plumbers and Electricians make more than handymen.
Just about any specialist cert in IT pulls better pay offers than generalist A+/Network+

Hope this helps.

it_consultant

instant000 wrote: »

Surgeons make more than general practicioners.
Plumbers and Electricians make more than handymen.
Just about any specialist cert in IT pulls better pay offers than generalist A+/Network+

Hope this helps.

This is true, but in those fields people are not regularly displaced by advancements in technology. Right now, I would be careful about overspecializing in networking. SDN is coming down the pike and while you will still need advanced networking knowledge, the days of jumping into a console and configuring things port by port are numbered. Almost all firewalls will be solely software based soon, making RHEL knowledge much more valuable than ASA or Palo Alto knowledge.

It is hard to stay a generalist as we generally get pigeon holed in our jobs. I recommend keeping a broad interest and knowledge so you can be flexible when the job landscape changes.

NetworkVeteran

it_consultant wrote: »

Right now, I would be careful about overspecializing in networking. SDN is coming down the pike and while you will still need advanced networking knowledge

SDN requires some folks with an even stronger knowledge of networking, but eliminates some of the grunt work.

I agree with you over-specialization can be a problem. Focusing 100% on networking is very safe. Focusing 100% on a sector of networking (such as service provider or enterprise) is relatively safe. Focusing 100% on a single technology is risky, if you don't keep your eyes open to industry trends, because today's hot technology may become a fad or legacy in five years.

If you want to be a top-paid engineer, I'd specialize. If you want to go into management or start your own company, I'd consider a more generalist path so you can struggle through most things with some time and mistakes, and know what different specialists available to you can offer when you need more advanced, accurate, or speedy work done.

it_consultant

NetworkVeteran wrote: »

SDN requires some folks with an even stronger knowledge of networking, but eliminates some of the grunt work.

I agree with you over-specialization can be a problem. Focusing 100% on networking is very safe. Focusing 100% on a sector of networking (such as service provider or enterprise) is relatively safe. Focusing 100% on a single technology is risky, if you don't keep your eyes open to industry trends, because today's hot technology may become a fad or legacy in five years.

If you want to be a top-paid engineer, I'd specialize. If you want to go into management or start your own company, I'd consider a more generalist path so you can struggle through most things with some time and mistakes, and know what different specialists available to you can offer when you need advanced, accurate, or more speedy work done.

What SDN really does is require people with an unholy knowledge both of networking and of system admining. As that technology matures, the networking part will drop off. This shift will be especially apparent in datacenters where in theory, one will never go into a switch and might not even be aware of what brand of switch is being used. It will take a bit longer for the service provider world to see this shift since a linux or windows based intel server is nowhere near as reliable as a RISC based firmware which runs in many switches. If you started now and specialized in primarily in Cisco route/switch, I think you will be at a disadvantage to people who have a more general knowledge of networking and some more specialization in sysadmining.

blargoe

You can probably make more with a narrower specialization, but if you're not careful, you could be so specialized that the winds of IT change could pass you by in a few years.

Specializing in "networking" or "security" could be very good; but narrowing your specialization to a specific flavor or vendor or implementation could be very lucrative for a while, but could be dangerous if that specific implementation of that technology falls out of favor.

I think the path most take is broader responsibilities earlier on, and then narrowing the scope later.

NetworkVeteran

it_consultant wrote: »

What SDN really does is require people with an unholy knowledge both of networking and of system admining. As that technology matures, the networking part will drop off. This shift will be especially apparent in datacenters where in theory, one will never go into a switch and might not even be aware of what brand of switch is being used.

I already work with SDN, and at least the deployments I have played with, don't require any system admin skills or experience. Consider that many networking OS already run over a Linux or Linux-like microkernel, and what we're really discussing is configuring network features in one place and applying them to multiple devices. Many networking vendors--like Cisco, Juniper, etc.--already have solid cluster or multi-chassis user interfaces. Not caring what vendor the individual switches in the cluster belong to is somewhat accurate. I probably shouldn't go much further due to multiple NDAs, but I certainly don't foresee myself needing to learn to administer Windows or Apple PCs even if SDN is a smashing success.

The Cisco CCNA and CCNP are 80% about networking and 20% about Cisco's world view, so learning enough to pass those networking exams would help a great deal for you even if Cisco one day collapses. I'd say the same about the JNCIA. The BCNE does delve a bit more into that vendor's particular product lines in my estimation.

darkerz

I think the idea that SDN is going to obsolete network engineers is adorable, especially the "no more dive-down" approach.

We use Solar Winds for all of our monitoring, analysis and configuration management as it is. I rarely go into individual devices - I script everything so a single device, single LAN segment in a site, a single site's cluster (WAN and LAN), region, or *all* devices are troubleshot at once - take the output of various SH commands and turn it into a single page break down.

Or, use solarwinds for that as well.

That being said - Sometimes, you need to dive into a device.

A 3500XL switch isn't reachable and CDP is still working?
Output queue drops in QoS and you can't figure out why?
Interface status + Show Logging to determine MAC / L1 & L2 level issues?
Route flapping and you need to troubleshoot with an Out of band line or a user on site w/ a console connection? (Or a console server with GSM backup?)

... The list goes on.

In my opinion, SDN is going to revolutionize networking and invigorate it. No grunt, administrative, repetitive work (unless SDN goes down? bug in the current release? etc) means we can focus on isolating those errors we are seeing, those transmit discards popping up on our WAN edge, those latency issues with XO or heck - tackle bandwidth hogs, address security and optimization concerns.

To me, it sounds like an SDN solution that auto magically works would be great but the steps to get there are huge - if anything, you'd need the same or more people working it, GUI or not you need to know what the hell you are doing.

"Hmm I wonder what this default-originate button is on this shiney new GUI? It's ok, I'm a sysadmin, they fired the Cisco guys cause they're not needed anymore - what could possibly go wrong?"

it_consultant

You are not getting the point of SDN. With SDN there is no CDP, in theory. When you talk to SDN 'evangelists', who, in my case, the developers working on the code - we are talking about almost complete control of the switches management plane by a server. So yes, being familiar with your RHEL's will be come quite important. The days of needing to know the commands to set up BGP in a Cisco or a Netiron are waning. You will need to know what an AS is, answer a couple of questions and deploy to your Juniper/Cisco/Dell/Brocade/Extreme/HP etc which are running on an SDN platform.

It is true that you still need to KNOW networking, but in a different way, the openstack and openflow way.

instant000

Most organizations don't necessarily have a lot of specialized networking staff as it is.

I worked at one company, that had hundreds and hundreds of retail outlets, and about 10 main "offices" with thousands of employees.

How many network staff did they have? 4, and they provided 24x7 support for the global operation, which included retail, refineries, distributions, trade, corporate, projects, etc.

What could they do? Cut down to two and hope no one ever gets sick?

I worked at a company that virtualized the server infrastructure from 6 racks down to half of one. We didn't decrease admin headcount. We consolidated a full two rack ERP down to a couple VMs, and didn't decrease business analyst headcount, it increased because people could get more things done (with better performance), so there were a lot more requests coming in.

Maybe the person who doesn't keep their skills "up-to-date" may suffer, but the person who knows what they're doing and adapts will be just fine.

Unless we're going to make things so easy or inexpensive that end users can do it all themselves, there will continue to be a need for staff to do some things.

We could go with the New Jersey model - no one can pump their own gas - i.e., no one can connect to email on their own (no auto-discover), or we could just find other ways to innovate.

I wonder about the world when we have enough affordable robotics/automation that menial labor by humans isn't cost effective. And then what? And this line of thinking doesn't stop there. What about when robots are even doing advanced tasks? Does it mean that only robot makers/programmers are worth something? I'd hope not.

blueberries

A Network warrior will always stay sharp. We must be like Ernest Shackleton who once said "superhuman effort isn't worth a damn unless it achieves results." If SDN ever gains consciousness like Hal in 2001: A Space Odyssey, we will need network men to take it out. Despite this, I admit to disliking the technology. I feel like I am a typewriter mechanic in the mid '80s. At least that is what the virtualization guys seem to think. If SDN fails, I will experience the anti-social joy of pure schadenfreude.

Architect192

My view on this topic is this: I always keep my knowledge as broad as humanly possible (and beyond ) as I don't want to become like the 55+ year old guys who were specialists on mainframes and knew nothing else and ended up with nothing.

That said... If you want to have a life, find a limit to the extent you wish to learn

About7Narwhal

I have seen this question come up a lot in the time I have been here and I feel that the best approach is something similar to a pyramid. A wide base of knowledge with a few advanced concepts followed by a specialization.

Eg: General IT knowledge as your base, you know about phones, computers, servers, printers, networking, etc. The next level has a focus of Server OS, Networking and Security. You understand the ins and outs of the OS and networking. Beyond that you have a strong focus in Security.

The OP never stated that they wanted to focus on a specific vendor, so why can they not focus on topic X and passively grow the supporting technologies of Y and Z? Wouldn't that give him/her the opportunity to apply for a job in Security, Sys Admin, or Network Admin?

JoJoCal19

About7Narwhal wrote: »

I have seen this question come up a lot in the time I have been here and I feel that the best approach is something similar to a pyramid. A wide base of knowledge with a few advanced concepts followed by a specialization.

This. But I follow this not just in IT overall, but also in one IT area. For example I work in InfoSec and I'm studying for CISSP. It encompasses a lot of areas in InfoSec and I have a base of knowledge of several areas of InfoSec, but right now I'm really specialized in identity and access management.

instant000

About7Narwhal wrote: »

The OP never stated that they wanted to focus on a specific vendor, so why can they not focus on topic X and passively grow the supporting technologies of Y and Z?

I believe this is what we were generally suggesting. This is a certification forum, though. In that case, the specialization would be taken by us to generally mean specializing in certifications. The same way if it was a degree forum, we'd probably tend to say specialize in degrees. As we know, some of the best certifications are vendor-specific.

Regardless of that, as NetworkVeteran stated:

NetworkVeteran wrote:

The Cisco CCNA and CCNP are 80% about networking and 20% about Cisco's world view, so learning enough to pass those networking exams would help a great deal for you even if Cisco one day collapses.

About7Narwhal wrote:

... I feel that the best approach is something similar to a pyramid. A wide base of knowledge with a few advanced concepts followed by a specialization. ... Wouldn't that give him/her the opportunity to apply for a job in Security, Sys Admin, or Network Admin?

I believe that within someone's area of specialization, there is "wiggle room" if you know what you're doing, and you will have space to reinvent yourself.

I can think of several examples that used the 80% core knowledge, supplemented with 20% technology-of-the-day:

Brian Madden. I was first acquainted with him from the days when terminal server was all the rage. Now, he has basically reinvented himself to the point where he is all about "application delivery".

Ivan Pepelnjak. He is infamous for his blog on "Cisco IOS" (even called ioshints) but you can see him fluidly changing with the times, and his focus is including due consideration now for newer developments such as OpenStack, OpenFlow, OpenWhatever.

Packetpushers. Even they have transitioned to the point whereby you can see they posted a blog series on programming, as they can forsee that the network may become API-based vs. CLI-based at some point.

The quoted wasn't thinking of IT, but it's still a valid concept:

Coco Chanel wrote:

Fashion changes, but style endures.

Hope this helps.

networker050184

it_consultant wrote: »

You are not getting the point of SDN. With SDN there is no CDP, in theory. When you talk to SDN 'evangelists', who, in my case, the developers working on the code - we are talking about almost complete control of the switches management plane by a server. So yes, being familiar with your RHEL's will be come quite important. The days of needing to know the commands to set up BGP in a Cisco or a Netiron are waning. You will need to know what an AS is, answer a couple of questions and deploy to your Juniper/Cisco/Dell/Brocade/Extreme/HP etc which are running on an SDN platform.

It is true that you still need to KNOW networking, but in a different way, the openstack and openflow way.

After spending this whole week listening to SDN stuff and playing with it in the lab I have to say you are completely over simplifying openflow and SDN as a whole. While it is a software based centralized control plane, it is still just an instrument to implement your traffic strategies and network policies. It is not a point a click and it's set up for you. Someone still has to design, engineer, troubleshoot etc. They will just be using a different tool to do it. We basically have one click provisioning now without SDN but that doesn't mean no one needs to understand the underlying technologies.

Tooms

SDN does not absolve the need for network engineers. If anything it will just streamline some of our more mundane processes. People able to write software freely will never trump the stability of the networking being the utmost importance.

SDN has been up against some very specific challenges relating to scalability. It is still very much in its infancy and hasn't really taken off in the enterprise space yet. I've seen it first hand used in very specific functions in a very small and controlled environment.

Generally I perceive network engineers understanding programming more than software developers understand networking.

I think VMWare is going to be the big benefactor of SDN.

paul78

Cat5 wrote: »

.... which is better - specializing in one specific area or broadening one's expertise to encompass a wider variety of things?

Ahh... the recurring topic on specialization versus generalization of IT expertise.

If my comment seems repeative it's because I never tire of this dicussion when it comes to IT and I've posted similar sentiments in other threads.

So why do you ask this question?

It largely depends on your end-goal and I don't necessarily mean some position or role that you want to target. But more of a life-style choice and where you may want to be in 20 or 40 years. My own goal was to work in IT but I really wanted to grow and build companies. Ultimately, I do want the "higher paying job" that you mentioned.

My own career started as a specialist and has grown into a generalist IT role in management. And my path has served me very well. If anything, I plan to expand my experience into more general non-IT areas.

So a bit of background about me if anyone cares...

I started my career as a software engineer - programming Windows applications. From there, I started to generalize, first I expanded into Windows libraries. My next job was sales support, primarily phone support (that was a blast). In that same job, I started to write database applications (basically a knowledge base application).

After that stint in sales - I went back into programming but I stayed away from Microsoft desktop software so I could generalize some more and gain experience with other OS's. I spent a few years writing system-level software for UNIX and VMS mainframes. And I also had a few assignments on embedded systems.

During the dot-com boom, I left to work on work web applications, but I started managing more infrastructure - mostly Windows server administration and networking. At the same company, I started to manage operations support.

When the dot-com bubble bust, I went into consulting, mostly working short gigs - sometimes it was database architecture (designing schema's and flows), to network management, to IT management consulting (putting together IT business plans, etc.), to even setting up hosting services.

The constant consulting race started to get a bit stressful so I ended taking a partnership position which was mostly a jack-of-all-trades role for a small MSP doing everything from network admin, server admin, software architecture, and post-sale implementation. It was fun but not as lucrative as I had hope so when I had the opportunity to join a small start-up, I jumped.

At the new start-up, I ran just about everything that wasn't related to software development and product management - that included facilities, infrastructure engineering, operations, customer support, etc. etc. It was a very stressful job but that goes with the territory of a small company. We were very close-knit and we all had a lot of fun.

Our start-up was quite successful and we were able to sell it. The acquiring company made me an offer which I couldn't refuse. So I am still here. At my current employer, I basically continue to be a IT management jack-of-all-trades. I do have specific responsibilities - but for the most part, my job is to help move our line-of-business forward with technology.

As I look back on my career - and as I look forward to the rest of my career. I don't think that I would be as successful (by my own standard anyways) as I am today if I had limited my IT knowledge to a select specialty.

My observation is that over the course of a long IT career, I imagine that at a macro-level, the specialization and generalization looks more like a series of bell shape curves where someone may start off broadly, then start to specialize, but as their career progresses, it would start to widen again. It may specialize again depending on the economic conditions at the time. I.e. virtualization is big right now.

But if you look at the bell shape closely, it will probably look more like a series of peaks and valleys as technology and individual interests and opportunities change, the individual will move to specialize from area to area, eventually having a generalized knowledge in many areas.

With most the IT professionals that I know at my age level, I cannot think of anyone that doesn't have a varied list of previous technologies that they used to be immersed in.

There is a right time to specialize and a right time to move on to another area. It all depends on where you are on your career path. I often read on these forums about advice that to increase compensation, an individual has to narrow their field of expertise and go deeper. That could be true at some point in a career path. But it's more likely to be untrue, if someone has aspirations to reach senior IT management or C-suite. At those levels, a broader understanding of IT is typically more desirable.

I know that many TE members provide the analogy of medicine but I am not sure its a good analogy. While a neuro-surgeon's average compensation may be higher than the salary of their Chief Medical Officer (based on what I see on salary.com). You are highly unlikely to find a CCIE or whatever toplevel IT specialist that has a compensation level that is higher than their CIO. Also, surgeons tend to run their own practices so the commercial model is very different. If a highly specialized IT professional was to have their own business contracting and consulting than it is possible for that IT professional to make more money than your typical CIO.

Even in professions like law for example, lawyers that specialize in real estate, litigation, privacy, HR, or intellectual law are not likely to be better compensated than the Chief Counsel who has a general counsel background.

So, to answer your question on which path will get a higher-paying job. I would answer - "it depends on too many factors". For me, I would not have gotten the higher-paying job if I was a specialist.

If you read to the bottom of my long-winded post, thanks . I hope that this singular data point of information and my personal opinion is useful to someone.

Gorby

Excellent post Paul..I am facing this same issue myself on whether I want to focus or spread out my knowledge. Eventually I wanted to learn more about the systems side and programming.