cancel
Showing results for 
Search instead for 
Did you mean: 

When Being an Expert Isn’t Good Enough: Master of All Trades, Jack of None

cxi
Level 12

Has this situation happened to you? You've dedicated your professional career -- and let's be honest -- your life, on a subject, only to find “that's not good enough.” Maybe it comes from having too many irons in the fire, or it could be that there are just too many fires to be chasing.

Ericsson (1990) says that it takes 10,000 hours (20 hours for 50 weeks a year for ten years = 10,000) of deliberate practice to become an expert in almost anything.

I’m sure you’ve heard that Ericsson figure before, but in any normal field, the expectation is that you will gain and garner that expertise over the course of 10 years. How many of you can attest to spending 20 hours a day for multiple days to even multiple weeks in a row as you tackle whatever catastrophe the business demands, often driven by a lack of planning on their part? (Apparently, a lack of planning IS our emergency when it comes to keeping that paycheck coming in!)

I got my start way back in Security and Development (the latter of which I won’t admit if you ask me to code anything Smiley Happy). As time progressed, the basic underpinnings of security began delving into other spaces. The message became, “If you want to do ANYTHING in security, you need networking skills or you won’t get very far.” To understand the systems you’re working on, you have to have a firm grasp of the underlying Operating Systems and kernels. But if you’re doing that, you better understand the applications. Oh, and in the late 1990s, VMware came out, which made performing most of this significantly easier and more scalable. Meanwhile, understanding what and how people do the things they do only made sense if you understood System Operations. And nearly every task along the way wasn’t a casual few hours here or there, especially if your goal was to immerse yourself in something to truly understand it. Doing so would quickly become a way of life, and before long you'd quickly find yourself striving for and achieving expertise in far too many areas, updating your skill sets along the way.

As my career moved on, I found there to be far more overlap of specializations and subject matter expertise, rather than clearly delineated silos. Where this would come to head as a strong positive was when I worked with organizations as a SME in storage, virtualization, networking and security, finding that the larger the organization, the more these groups would refuse to talk to each other. More specifically, if there was a problem, the normal workflow or blame assignment would look something like this picture. Feel free to provide your own version of events that you experience.

pastedImage_2.png

Given this very atypical approach to support by finger-pointing, having expertise in multiple domains would become a strong asset since security people will only talk to other security people. Okay, not always, but also, yes, very much always. And if you understand what they’re saying and where they’re coming from, pointing out, “Hey, do you have a firewall here?” means a lot more coming from someone who understands policy than from one of the other silos, which they seemingly have nothing but disdain for. Often, a simple network question posed by one network person to another could move mountains, because each party respects the ability or premise of the other. Storage and virtualization folks typically take the brunt of the damage because they regularly have to prove that problems aren’t their fault because they’re the easiest point of blame due to storage pool consolidation or hardware pool consolidation. Finally, the application guys simply won’t talk to us half the time, let alone mention that they made countless changes without understanding what WE did wrong to make their application suddenly stop working the way it should. (Spoiler alert: It was an application problem.)

Have you found yourself pursuing one or more subject matter domains of expertise, either just get your job done, or to navigate the shark-infested waters of office politics? Share your stories!

12 Comments
shuckyshark
Level 13

I love it...but don't talk to me...it's the server's fault.

rschroeder
Level 21

I've seen lots of attempts to fix this problem; many are not very joyful.  One common one is to hire staff at prevailing rates, then don't train them and don't give them salary increases that keep them happy and in your employ.  Tell them they aren't supposed to be experts, that the company pays for experts via service & support contracts from vendors & VARs & third parties.  Finally, dump massive amounts of work hours on too-few employees, increase their stress as far as possible by demanding perfect design and implementation skills without training & certifying them.  That company's motto is "The absolute best design and implementation--with NO down time--is the minimum acceptable level of performance."

Just get the Solarwinds products appropriate for your environment, budget for the right number of staff and for their proper training, do the same with your other technical & security staff (including Apps, Databases, Help Desk, System Administration, Telecom staff, etc.) and be done with it.  Everything will be a LOT simpler, and you'll be doing the best by your customers and employees.

That's Rick's answer to "The Meaning Of Business Life & Employment and Customer Satisfaction and EVERYTHING."

This doesn't take 7 1/2 million years to discover, nor does it take Douglas Adams deciding on "an ordinary, smallish number" like 42.

tallyrich
Level 15

Ah yes, finger pointing and blame. Some of that is nature - we want to protect ourselves, but more often I think it's culture. Good management builds a culture where we aren't afraid to fail. (Not every problem comes from a failure, but it often feels like it's a failure on our part when something goes awry) I remember a motivational statement from a coach - don't remember who - that told his players that the team that wins today will be the team that makes the most mistakes. The thinking being that if you don't make any mistakes, i.e. never fail, then you aren't taking any risks. Some failures will come from risks, some from human error, some just because life does that to us. Good management encourages people to stretch themselves and that will cause mistakes and occasional failure. Embrace it, own it and Learn from it. Once culture gets your team to that point everyone will grow more and the finger pointing can go away.

joepoutre
Level 12

Somewhere in your company there will be, or should be, a small set of people with knowledge of a broad base of technologies and disciplines - networking, hardware, OSes, multiple scripting languages, databases, internal and third party application, automation. Each member should or will have a different, overlapping skill set so they work together depending on the issue, problem, challenge, or exercise. Think of them as a kind of router where the other teams come together. Call them the Tools team and have them near to the CTO and CIO.

mtgilmore1
Level 13

Let's see, I guess I will work on Storage or maybe networking today:

Image result for photo of jacks

vinay.by
Level 16

Nice article

tinmann0715
Level 16

I have made my career on being the "Man in the Middle." Far too often I have been the dumbest man in the room and I've been okay with that because I was always surrounded by SME's from different disciplines. My role was to get them to thinking cohesively and work towards the common goal, "Solve the Problem!" If the effort was multi-day then I had to keep them focused. All of this involved a lot of silo-busting, a lot of ego feeding, plenty of rah! rah! speeches, escalations, fierce conversations, negotiating, sobbing, and begging & pleading. I must have had a knack for it because I was very successful and I was never fake, I never lied, and I got a lot of respect.

In my experiences the databases were always the most blamed, but most often it was hardware/infrastructure, and then OS/Systems level. My lesson learned: Always start at the bottom of the OSI Model and work up, and there is nothing wrong with rebooting.

cxi
Level 12

Extra super-props for being someone who works at the bottom of the OSI Model and works their way up

And it's not limited to IT Problems! I'll deal with problems all throughout life that particular way with all electronics and so many other circumstances.

It's no coincidence that "Is it plugged in" is represented by Physical in the OSI model

gfsutherland
Level 14

Excellent job.... After too many years to mention of cleaning up after the elephant:

Uncle George's rules are as follows:

1. Believe half of what you hear

2. It's a mix of at least two things

3. Have a tool belt.

4. Remember mom's adage that finger pointing leaves three fingers pointing at you.

5. It's your job to fix the problem..

When that doesn't work...........

pastedImage_0.jpg

ecklerwr1
Level 19

I'm probably a jack of all trades and master of a few...

mcgyver.jpg

mcam
Level 14

adding more solarwinds products always helps - especially now Perfstack is around to join the data together

of course having the organization (or re-organization) to prevent the finger pointing silos is a big help as well

cultural shifts are always the most painful

ggehle
Level 8

I'm with you on this. As a manager, it often comes to me to be that man in the middle, and fortunately I've got enough knowledge of various technologies to by dangerous and annoying to other SMEs in the room. My staff (largely due to where I am) is very inexperienced and struggles with cause-and-effect troubleshooting. Just because they re-addressed a branch office doesn't mean they created a connectivity issue on the LAN...

About the Author
CTO at @Xiologix - EVP of Engineering, Technology Evangelist, vExpert, EMC Elect, BDA, CISSP, MCT, Cloud, Ninja, Vegan, Single, Father, Cat, Humorist, Author