A common pattern endemic to the world of technical people is that we’re inclined to identify ourselves by the technology we work with. This is both natural and an inherently limiting philosophy when left unchecked.

Let me use myself as an example.

I started my technical career as an email admin responsible for a reasonably large-scale environment. Roughly six months into the role, I started to notice something: this zany Gmail thing was all the rage, and starting to make inroads with small businesses.

It was far from alone; Yahoo Mail was doing the same thing, and a whole host of providers were springing up as third-party SaaS email services as well.

It was pretty clear that, longer term, the current status quo of “most companies above a certain size need a dedicated email administrator in-house” was going the way of the dodo. (I was, incidentally, correct on this; the job boards don’t have a whole lot of email administrator roles, my beloved Postfix isn’t listed as a requirement for basically any role in 2021, and it’s clear that history has largely proven me right on all counts when it comes to this issue.)

I’m a believer in the “T-shaped engineer,” where you’re broad across a wide variety of technologies but deep in one or two areas. If email systems were my area of deep specialization, what was next?

It was time to find something new.

Pivoting and pivoting again

I puttered around and got deep with configuration management systems—first by contributing to SaltStack then by becoming a trainer for Puppet Labs.

This was going swimmingly until the industry fell in love with DockerDockerDocker and took a hard pivot towards immutable infrastructure wherein stateful configuration of nodes was more a curiosity than a deep competence required by most shops.

I pivoted again and became a subject matter expert in AWS. This more or less brings my technical backstory up to the present day.

Now, let’s say AWS loses favor. Amazon decides that horsewhipping its employees is more entertaining than selling computing services for whatever reason, or Azure eclipses it in the marketplace, or there’s such a backlash against tech that running our own environments inside of data centers becomes in vogue again.

I’ll be faced with that same choice again: do I focus on the technology I already know that’s now in decline or do I once again change my technical speciality to something that’s being widely adopted?

The right answer here comes down to how you see yourself in terms of your own identity.

You are not the technology

I posit that you’re not the technology you work on. Letting it become a cornerstone of your identity leads to all manner of negative outcomes.

There are still to this day people who are Perl experts, Solaris admins, AIX engineers, and more. They’re just significantly less broadly employable than they were a decade ago.

We see the same patterns emerging now, with folks pushing back against cloud adoption in no small part due to the fact that it cuts against their own definitions of their professional identity.

If you’re a database admin and management proposes migrating off of bespoke databases that you manage yourself on top of VMs or bare metal and onto RDS or some other kind of managed database, what will that mean for you?

Worse, even if you have no personal stake in the outcome, any legitimate grievance you have against migrating to a managed service will be seen as coming from a place of self-interest rather than a well-reasoned technical rebuttal.

It will happen to you, too

If you’re a Serverless expert, what will that mean for you in a few years when nobody cares about Serverless anymore?

And let’s be very clear: That day will absolutely come.

Nothing lasts forever in technology. I’d argue that remarkably few things last for the majority of someone’s career.

What’s going to happen to the Kubernetes experts who are in such high demand now, once Kubernetes is ubiquitous enough to vanish below the surface of awareness in a few years and the list of companies who need in-depth k8s expertise drops from “most of them” to “a couple of dozen?”

Firewall engineers used to be a thing; now, anyone with a network admin credential is expected to handle firewall configuration as a baseline part of their duties. And let’s not even get into how few network engineering roles there are today versus 15 years ago.

Back when I was running training sessions for Puppet, the folks adopting the technology ran the gamut. They were senior and junior at companies large and small, old and new.

Today, it’s not a growth technology.

This is one of the reasons I suggest interviewing at other companies periodically. You’ll get a stronger sense for what skills you have that are in demand—and those which just don’t come up in conversation any more.

I’m not saying that you want to let hype and trends dictate your career.

But, by the same token, being unaware of the broader applicability of your skillset remains a choice I’d strongly advise against.

—

Whether you’re looking for your next gig or are just trying to sharpen your interviewing chops while seeing what skills are in demand today, take a look at our open positions and see if there’s anything that tickles your fancy.