From Employable Generalist to Successful Efficiencer

For regular followers, I bet you thought I forgot about reader question Fridays last week.  I didn’t.  Friday is a relatively low traffic day for bloggers, so I’ve decided to switch over to reader question Monday.  But, on Sunday night, I did forget about the post draft, so the first reader question Monday is actually Tuesday’s post.  I know.  I’m a little disoriented too.  But we’ll figure it out.

About a year ago, I wrote a post about niching down.  I asked readers to imagine if, instead of listing the services that they provided, housing contractors described the number of years they’d spent using their tools.  “I have 6 years of hammer, 3 years of reciprocating saw, etc.”  From that, they left it up to you to figure out if you could translate those skill into something useful, like fixing your garage door.  That’s us, in the software development world.  “Here are my experience tuples, and now I just need some kind of manager to figure out how to turn me into a useful resource.”

Given my tone, you can probably infer that I advise against this approach.  In fact, I frequently suggest specializing and figuring out how to solve business problems.  But as a few people have now pointed out via reader questions, I’ve not offered a lot in the way of advice to bridge the gap.   A reader in the Developer Hegemony Facebook group put it quite succinctly, in the parlance of my old post.

How do you translate 3 years C#, 6 years C++, etc… into “I can fix your garage”?

It’s a good question.

My Own Journey

When I reflect on my career, it strikes me that I never really figured this out in the person.  At least, I didn’t in any sort of intentional way.

Currently, I have a specialized consulting practice around a productized service, as well as a content marketing business.  But I never actually sat back and plotted this out in the way that people are asking about.  I actually kind of stumbled into it.

After leaving full time employment and starting on my own, I took what work I could get.  As more work came into my queue, I gradually began to optimize for doing work that I enjoyed and felt well suited for.  Eventually, this became a self-reinforcing trend.

I did a Pluralsight course about static analysis and another one about test driven development (TDD).  Then I started to get calls about those things.  I wrote a lot of blog posts, and developer tools companies started to reach out and ask me to write for them.  When I’d do those gigs, I’d enjoy them, get better at them, and seek out more of them.

After a while, I realized that I’d developed some specialties, and I flipped over and embraced that.  It’s given me interesting perspective, and I’ve learned a lot.

The Specialist is a Short Timer

So, reflecting on my own choices, optimal and sub-optimal alike, I’ll offer you a guide to get to helpful specializing a lot faster than I did.  But the first piece of advice is one of adjusting your mindset.

Learn to view gigs not as open-ended affairs lasting years, but as surgical operations lasting months at most (and probably weeks).  This is utterly counter-intuitive to the salaried employee, but it’ll get you into the specialist mindset much faster.  I talk more at length about this idea here, but suffice it to say that generalists and perpetual employment go hand and hand.  You make yourself attractive to employers for serial, decades-long employment precisely by making yourself a generalist, capable of handling whatever unknowable thing they’re going to need in 5, 10, or 20 years.

Of course, exceptions exist.  You could specialize in something and tour a Fortune 100 company, doing it over and over again in every department, as an employee.  Or, you could have a codependent, silo-ed specialty, like “I’m the build troll; no one else can do the build and that’s all I do.”  But don’t count on that sort of thing.  If you want to serially provide business value with a marketable specialty, you should probably prepare to do it frequently, in short term engagements, and for different companies.

Start with What You Do, Rather than What You Love

Now, onto the advice around choosing.  Some might tell you to figure out what you’re passionate about or something.  This sounds like solid advice.  But, even though it makes me a hypocrite, since I sort of followed this path, I’ll counsel against it.

Specializing in solving a business problem is, first and foremost, a question of what others need.  It’s not a question of what you like to do.  Obviously, you’d be well suited to find the intersection of these things, particularly to make a sustainable career out of it.  But I wouldn’t start there, or you’ll learn some esoteric functional programming language, and then spend the rest of your career trying to browbeat people into caring it, like a guy with a giant hammer who thinks he can just yell at things until they turn into nails.

Instead, look around a little.  What do you do for your team that nobody else does?  Are there tasks everyone else hates, but that you find tolerable?  Do you have a “superpower” that nobody else seems to have?  Maybe nobody but you likes to touch old VB6 code, or maybe you just get parallel programming in a way that others don’t.

Test the Waters Beyond Your Immediate Surroundings

It may take you a while to amass a sufficient list.  And I do encourage you to make a list, rather than just latching onto the first potential specialty.  Bonus points if they relate and you can improve at them simultaneously.

Your next step involves finding ways to see if they translate beyond your team.  I mean, if you’re on a team of 6 people who are brand new to programming, your role of “relative C# guru” will hardly translate beyond the team.  You need to find skills that translate to other situations.

For instance, take the idea of touching old VB6 code (and, maybe, porting it to modern C#).  There’s a good chance that other groups exist with this legacy code and that their developers also don’t want to touch it.  If you can tolerate this and you’re good at it, you can go looking for a market capable of sustaining you.

This could make for a post in and of itself, but you have two main concerns here.  First, do enough shops out there have this problem that you’d have sustained business in helping them.  And, secondly, do they value your solution enough for you to earn a living?  To figure this out, you need to do a bit of research and get creative.  Identify such shops, and have casual conversations with them about what they’d pay to get that legacy code ported.

Practice via Moonlighting or Internal Efforts

Maybe, if you’re not risk averse, you’re ready to open up your own practice, “The Foobar VB6 Fixorama” or whatever.  But if this seems a bride too far, I relate.  I’d want some proof, myself.

So practice a bit.  Within your company, offer to help other teams or departments out, if applicable.  Your pitch to management is a dress rehearsal for your eventual sales pitch at other organizations.  Doing the work becomes your eventual operations, and your satisfied ‘customers’ might become testimonials down the line.  Alternatively, practice by moonlighting.

I suggest this route because nobody conceives the perfect business out of the gate.  You’ll discover that it can’t work for certain teams or that you need to expand to more legacy languages, or that it only makes economic sense if you can automatically port to .NET and then upgrade to modern language versions.  You’ll stumble, have hiccups, learn lessons, and flounder around a bit.

But, do you know what?  That process will start to make you a legitimate expert.  In a sea of generalists that might only ever do something like this once, you do it a bunch of times, with all sorts of different variations.  You learn lessons, bring new tools to bear, and come to understand both the business and tech of your offering with deep expertise.

Start the Brainstorming Now

Perhaps the hardest part of all of this is finding your version of porting VB6 to modern C# (or whatever).  With all of the different readers of this blog and all of the different tech stacks you represents, it’s hard for me to even give broad heuristic advice for how to tackle this.

But what I can tell you to do is start brainstorming about this now, and to start looking at everything you do through a new lens.  “Could I see this helping more people than my immediate teammates and stakeholders and, if so, could I make a business out of it that I’d want to run?”  You do a lot of stuff as a generalist, so you’ll have a lot of fodder for brainstorming.  Look at it, ask yourself who benefits from it, who would pay for it, and why, and whether you could turn that into a side hustle (or full time hustle).

It’ll feel weird at first, but keep doing it.  And remember, you don’t have to pick something that nobody’s done before.  You just have to pick something that you can help with repeatedly, speak intelligently about, and solve problems with.  And always remember to think not in terms of your tools, but in terms of outcomes — what you’ll do for people rather than how you’ll do it.

Fire Away with More Questions!

If you have a question, please feel free to ask:

And, by the way…

If you like the wisdom here, such as it is, you can get a whole lot of that more in my recently released book, Developer Hegemony.  If you want a sample of that, you can sign up to download some chapters below.

Want more content like this?

Sign up for my mailing list, and get about 10 posts' worth of content, excerpted from my latest book as a PDF. (Don't worry about signing up again -- the list is smart enough to keep each email only once.)

Get the content!