What’s Better Than a Generalist or Specialist?

When I first started out in the technology industry back in the mid-90s, things were much simpler. There were a limited number of programming languages, a typical way of building applications, rather mundane architectures, and minimal toolkits. Fast forward to today and we have virtualization, cloud services, containers, infrastructure as code, DevSecOps, microservices, and serverless. There are more data platforms, application frameworks, and niche technology providers than you can count.

There has also been a number of emerging technology domains that have compounded the problem further. We now operate in an environment with artificial intelligence, augmented and virtual reality, internet-of-things, robotic process automation, service mesh, deep fakes, digital identity, blockchain, NFTs, distributed web, and a blossoming metaverse.

This diversity of technological magic has resulted in us collectively reaching previously unimaginable heights. Each area offering the opportunity to become an expert. But, it can be overwhelming for those who proudly claim to be a generalist.

I’m a generalist. I’ve been one my whole career. I’ve had many chances along the way to settle into speciality but I remained determined to keep my eyes wide and my experience multidimensional.

Why am I a generalist?

My first tech job out of college may have rooted this perspective. I was working for a systems integrator and our work was for varied and vastly different clients. We developed applications and custom solutions constructed from a multitude of technologies and commercial vendors. As a result, I needed to be well versed in a wide array of products and services.

In contrast, I would have become an expert in a particular technology domain if I had worked for a single product company. For example, data management would have singularly shaped and focused my career if I worked for Oracle.

Do specialists have it better?

There were many times where I contemplated the path of the specialist. Why should I be responsible for learning all of these different technologies? How many do I have to know to provide the optimal utility for my client’s needs? At times it seemed to be an incomprehensible burden.

These thoughts crossed my mind several times while building a nationwide smart card system for the federal government. The system consisted of a number of niche technologies such as smart cards, biometrics, PKI, document authentication, and workflow engines to name a few. My job as the solution architect required understanding each of these technologies individually and collectively. What were their features, capabilities, drawbacks, and challenges and how did that impact other components within the overall system? While that is the beauty of being a solution architect, it is also the bane of your existence—wrangling disparate technologies to wield a coherent and capable result.

I had numerous meetings with individual product teams to discuss integrating their particular offering. Each of the teams I met with had one responsibility, to know everything about their technology domain. That’s it. For instance, I met with companies who dug extraordinarily deep into smart card technology. The next day I met with those who knew all there was to know about PKI.  Just when I felt a bit of competency in any given area, these specialists made me realize I had only a modicum of understanding of the technology’s true capability.

I needed to cast my net a mile wide and a foot deep in order to deliver a successful solution. At times I envied what seemed to be a much simpler task of only understanding an individual technology. It seemed to me it was much easier for someone to learn one thing and learn it exceedingly well. Much easier than it was for what I was doing. I was pouring through books trying to “catch up” with their domain knowledge. Spreading my limited capacity in order to meet the width of technology needs.

What do you choose—generalist or specialist?

You will need to choose how deep you immerse yourself into particular technologies as you progress through your career. At any point you might choose a path where you gain uniquely deep knowledge of a product. As a result, you may become the go-to person for that technology. You will need to determine if you want to explore that path, embrace it, and become a specialist. Or, do you want to keep it at arm’s length and remain a generalist?

Even with the challenges of generality, I still find the path of being a generalist the most fulfilling. By serving as an independent party you have the flexibility to learn and apply skills across a variety of products. You are constantly learning.

Each solution is in effect a blank canvas. You, as the technical artist, have the ability to select products and services to craft your solution to your desires. Particular technology stacks, generic capabilities, and product roadmap release plans don’t tie your hands.

As a generalist you have the option of picking and choosing moments where you dig deeper while maintaining an overarching and unencumbered vision.

It will be up to you to determine how long and how deep you go in those moments. Do you settle into them, effectively becoming a specialist? Or do you simply wade in long enough to get the experience before moving on?

But wait, is there another option?

A middle ground might be available. Could an alternative exist If specialists are too focused and generalists are spread too thin? Something sitting nicely in the “just right” category?

I recently heard a term that might fit the bill—a capablist. The notion is you are effectively a generalist but have the capability at any moment to dig into a particular technology and achieve a significant level of proficiency. You remain a generalist yet gain deep long lasting knowledge in a subset of technologies, products, and services.

Given the pace of innovation, this might be our only hope to survive as generalists. Pick a core set of technical domains and immerse yourself in them. At the same time keep your head above water surveying the technical landscape for the next shiny object.


Posted

in

,

by

Tags: