The Six Year Rule: Keeping Your Skills Relevant in a Sea of Technology

I am not sure I have ever gone into detail about my career history so far here on TOC. I am more than just a binge drinking¹ IT Engineer with a penchant for Russian literature and existential angst.

I have a history you know.

In this post I am going to talk about methods for choosing what technology to learn next. I am not a career counselor, but I will detail what has worked for me over the past 2 decades.

And by the way, this is a crucial decision and I don’t mean to trivialize it. Learning new technologies leads to higher salaries (if that’s your goal), a happier you, and higher “job insurance,” since there is no such thing as, “job security”.

The Generalist vs. Specialist Debate Rabbit Hole

I don’t want to go down the, “generalist vs. specialist” debate rabbit hole. That is a different blog post altogether . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . OK, I have had 2 navy strength Churchill Martinis (no olive) and I guess I am going down the “generalist vs. specialist” debate rabbit hole:

“Specialties” have a tendency of increasing in scope over time, and then sometimes spill over into other “specialties,” particularly “specialties” that have transferrable skills.

Let’s call this specialty bloat.

Can you really do VMware Administration at scale without knowing how to automate infrastructure with vRA or Ansible or PowerCLI? Doesn’t PowerCLI transfer over into other things like straight PowerShell (or vice versa)?

And how are you going to accomplish any of these without git knowledge in the year 2021? And if you know git, that becomes a transferrable skill into a host of other coding platforms, and so on.

Therefore, if you decide to be a “specialist”, over time, you may look up from your monitor one day and be more of a “generalist” than you might think.

Nuance Alert: The Six Year Rule Explained

It is my contention that the most you can stagnate in any major IT Specialty is 6 years. What do I mean by major IT Specialty? Some examples:

Linux Administration
Virtualization
Automation
Kubernetes
Windows Administration
Public Cloud (AWS, Azure, etc.)
Binge Drinking²

(That last one I put in there just to see if you’re still paying attention.)

Let me be clear about this: Can someone remain employed in the long run in any one of these careers alone? Sure. Is it a bad thing to do one thing and do it well? Not at all.

However, remaining competitive and having a resumé that is going to be set apart from the rest of the pile requires you to embrace the aforementioned specialty bloat.

I should probably copyright that. Trademark it? I never know the difference.

I have absolutely no scientific evidence for this six year time frame. In fact, it’s anecdotal evidence from one guy: me. Some people more well versed than I am might say it’s more frequent than six years. If so, let me know at @RussianLitGuy on twitter.

But here’s where I got that number . . .

Where I Got The Six Year Rule: My Career Crossroads

In 1999 I was a public schoolteacher, recently married, and planning to start a family. Starting a family was not really possible on a teacher’s salary, so, long story short, I switched careers from being a humble public schoolteacher to getting into the IT Field.

I was sort-of a computer geek in Junior High and High School, but not really. I had a Commodore 64 and what not. Nothing fancy. As a side hustle I helped my dad with his computers at his company, but I was no Kevin Mitnik. I had never thought about IT as a career, but in 1999, the potential for income was orders of magnitude higher than teaching public school.

So, during that fateful summer in 1999, I found an ad in the paper (. . . yes, the paper!) from an IT Training Company that said: “No IT experience required, we need teachers!”

I was hired pretty much on the spot.

I started out teaching MS PowerPoint, MS Word, basic Computers, and so on. Then worked my way up into the COMPTIA certs, and then the MCSE.

I finished my Masters Degree in Information Systems Management in 2002. A lot of people who know me have no idea. And yes, the MISM Degree has been totally worth it for me.

In 2003-ish, I got LPI Certified, Levels 1 and 2. I am not sure how the LPI certs work nowadays, but at the time it was a big deal. My first crossroads decision was Windows or Linux? I went all in on Linux. It was a gamble that paid off.

Why? Because it set me apart from my peers, which is the first piece of advice I have. I have always tried to do this, from my first job working at my Dad’s company up until today.

How do you differentiate yourself from your peers? That’s easy: find a way to do things faster and cheaper than everybody else.

Then in 2009, I saw my first vMotion. Most seasoned VMware admins know that moment. And at the time, ESX was a RedHat derivative, so I’d had a transferrable skill, which is my second piece of advice.

I went all in on VMware. That gamble also paid off.

In 2015, I watched my coworker automatically stage 600 firmware updates in the blink of an eye with one command using a tool called . . . oh man . . . what was it called? . . . oh yeah . . . Ansible. Maybe you’ve heard of it? That was the moment I knew Automation would be my next gamble. I went all in on it. It has paid off for me as well.

Let’s sum up so far:

1999 – Act 1 – Entering the IT field.
2003 – Act 2 – All in on Linux.
2009 – Act 3 – All in on VMware.
2015 – Act 4 – All in on Automation.

2003, 2009, 2015 – six year increments.

Wait a minute . . . this is . . . 2021! INTERESTING. In case you aren’t picking up on where I am going with this, find x:

2015 + x = 2021

I’ll wait . . . .

RIGHT?

It’s time to figure out what Bryan’s doing for Act 5!

As it turns out, I have already decided what’s next. My choices were AWS or Kubernetes. These are both opportunities I have where I work.

What would you go with in the year 2021?

For me the choice is Kubernetes, but it wasn’t an easy one. Here’s my thought process, and I could be wrong here, no doubt. These are all calculated gambles:

1. AWS is probably the “most marketable” between the two, especially given my limited experience with public clouds. This is most definitely a valid choice.
2. Kubernetes is still a pretty limited use case, by comparison.
3. Kubernetes is still in a state of flux and far newer than AWS, and therefore it’s arguably the bigger gamble.
4. But despite the limited use case for Kubernetes (I am sure there are some K8s fanbois shaking their fist at me right now), it has lots of potential for how applications will be run in the future, on-prem or in the cloud.
5. I am not going anywhere. I love where I work and therefore, as it stands right now, I have the gift of time. And since Kubernetes is a limited use case, I may not have another opportunity like this, so I am going to cash in on it while I can.
6. AWS is not going anywhere and if I so choose, it is something I can easily learn on my own time.

Was it the right gamble? Time will tell.

But here’s a scary thought: I am 47 years old with a planned retirement age of 65. That’s 2 more cycles of technology I may have to learn over the next 12 years!

. . . And some of those technologies probably haven’t even been born yet.

THINK ABOUT THAT!

Some Pointers About Making This Decision

1. Know Your Craft – I knew Linux was going to be a thing because Open Source with vendor backing for technologies that save money have a higher chance of “being a thing”. Also, it was a transferrable skill.
2. Respect the Hype Cycle – You will need to keep up on “trends” and what’s “in” and what’s “out”. I hate this part the most because it’s all “market-y” and full of BS you have to sometimes wade through. I am a huge skeptic and a pragmatist. But maybe that’s my point?
3. Find transferrable skills – If it’s something with highly transferrable skills, then it’s at a higher priority. YAML and JSON are skills that come to mind; connecting to and using REST APIs is another, and so on.
4. Choose technologies that set you apart from your peers – This is the most important one. Do things faster and better and cheaper than your peers can do them and you are gold, but don’t forget to share with your co-workers!
5. Respect your own work-life balance – You may be thinking, “Wait a minute Bryan. 1999-2003 is only 4 years. That seems to go against your 6 year rule. What gives?”
   Well, I was 26 years old when I switched careers. You know what a driven, newly-wedded 26 year old can do? Among other things, study. Like, a lot. I remember being up until 2 AM setting up Active Directory and breaking it, then learning DNS and breaking it. I remember the cert grind. I remember those days and nights of just being in a constant state of learning. So, that time was shorter because I invested much more of my personal time.
   Although I still learn and work on my own time (I coded out a script and did my Kanban Board for my next sprint until 7PM tonight), nowadays I have other interests. I am going to take tennis lessons later this year. I want to read Das Kapital.
   Anyway, the best advice I have for you is to choose something mutually beneficial for you and the company you work for. I know that isn’t always possible, but if you can, it really accelerates your learning.
6. Don’t go chasing waterfalls – I just put this one in because I think it’s funny.

“You miss 100% of the shots you don’t take.”
– Wayne Gretzky, (allegedly).

Hit me up on twitter @RussianLitGuy or email me at bryansullins@thinkingoutcloud.org. I would love to hear from you!

¹ Dear future employers: this is a joke.
² Ibid.