Generalists say things like, “Yeah, I’ve done something kinda like that before, and I’m sure I can figure it out again.”
Generalists get paid to learn new things fast and adapt.
Specialists say things like, “Yeah, I did that exact same task last week, and I know it forwards and backwards.”
Specialists get paid for things they already know very well.
Generalists are generally useful.
Armed with a good set of generalists, companies can generally tackle most IT problems that come their way. As a company’s tech stack changes, the generalists can learn new skills and stay productive. Therefore, generalists get hired first, and stick around for a long time.
If you’ve been a generalist for a year or two, you probably already have all of the technical skills you need to get your next job. You’re not hired for the technical skills you have today – you’re hired for the ability to rapidly learn new technical skills. It doesn’t make sense to dive deeper into any one technical stack thinking you’ll improve your hiring chances.
To get a job, generalists need to know somebody, or be able to tell this story:
- I listen well to my end users and managers
- I can quickly interpret the underlying problem
- I rapidly learn just enough of the technical tools to solve the problem
- I only do the work required to solve the business problem
- I make sure the users are delighted with the outcome
- And then I listen to hear the next pains, prioritizing them as they arrive, keeping as many of my business users as possible, as happy as possible
You probably don’t need to do this via blogging, building a big online presence, or speaking at conferences. You can have a relatively limited number of clients (like, 1 if you’re a full time employee) and do really well for a long time.
But when the generalist can’t solve an expensive problem, that’s when a specialist comes in.
Specialists are first brought in for brief bursts of work.
Most of the time, specialists would be bored at small-to-midsize companies. For example, companies with only 1-2 database servers don’t usually need a full time database administrator. When an expensive database problem pops up, companies just want to hire someone who’s already solved that very specific problem before, and can make it go away quickly.
Once the problem is solved, the relationship can end, and the company can go back to using their generalists. If the company gets big enough, they may keep a specialist around permanently – but it definitely isn’t their first choice, and they’d usually prefer to turn that specialist into a generalist, giving them other kinds of tasks to accomplish.
That means the career advice for specialist consultants is different: it’s not enough to be technically strong. You have to build your online presence. You’re going to be repeatedly going through the sales process, over and over, unless you specialize in large companies who have lots of problems in your specialty. (Even then, it’s rare to be an independent consultant for them – large companies prefer hiring other large companies.)
You can’t afford to wait for your current gig to finish – you have to start now. Start a blog, start presenting at user groups, and share what you know.
Neither generalist nor specialist is better.
Being either a generalist or a specialist doesn’t dictate your employment status as a contractor, consultant, or full time employee. However, generally I find that generalists are FTEs or contractors, and specialists tend to be consultants. (Specialists can totally become FTEs when a company is big enough to have big, expensive problems for long periods of time, too.)
You can make good money whether you’re a generalist or specialist, too. I’ve got a couple of friends who do really well as generalist consultants, giving companies application architecture advice across lots of disciplines, working in an advisory role in short-term bursts.
Personally? I used to be a generalist until I found a specialty I wildly love (making existing Microsoft SQL Servers go faster.) These days, I have a razor-sharp focus on that, and I’ve found myself shedding any work that doesn’t directly relate to that.
It’s not that I can’t build a new server from scratch, for example. I just want to focus on the very specialized work I do week in and week out, tasks that we’ve developed very specialized tools to help us with. We’re able to do those tasks way faster than a generalist could, and companies see high value in solving that expensive problem fast.
Some of my favorite podcasts on these topics:
- Ditching Hourly by Jonathan Stark – who focuses on developers, but the same topics hold true for database folks, or really any IT staff
- The Consulting Pipeline by Philip Morgan – who hasn’t been doing a lot of new episodes lately, but there’s a lot of gems if you pick through the back catalog