Being a generalist is great fun. There is much joy to be had in jumping between programmer and artist, project manager and product designer, bug finder and bug maker. You can also be a musician and athlete, parent and world traveller, superfan, superstar, and whatever else strikes your fancy if you invest the time. The world is your bivalve!
Generalists are ideal team members for startups and small product teams. Product teams that are themselves generalists – they are capable of working on many kinds of products – are also primed for success in a tech industry that walks ever randomly. Heinlein said “Specialization is for insects”, and he was mostly right.
There’s one problem though: it’s hard to sell somebody a mixed bag.
“So tell me, what are you good at?”
“Well sir, I’m okay at everything.”
“Sure, but what’s an example of a really exceptional project you’ve worked on?”
“Uh, well, I made a proof-of-concept Rails app, I designed some reasonable labels for a craft brewery, I wrote a pretty okay musical…”
“Right fine, let’s switch gears. How many times have you written a realtime video app?”
“Well, I haven’t yet, but… I’m a fast learner?”
This is kind of shitty, since a lifelong learner with broad skills is actually a great addition to most teams – it’s just hard to stand out in a crowd of other self-proclaimed fast learners.
Whether you’re trying to get hired as an individual or as a company, there’s a trick to getting work: start by becoming a world expert.
Insert training montage
In some industries and some eras, becoming a world expert was a Herculean undertaking. After decades of training to become a master sushi chef like his father, Jiro Ono’s son was still working in the back, making the rice and toasting the seaweed. I mean, I bet he toasted some damn good seaweed, but… damn.
In modern software development, on the other hand, becoming an expert is just a thing you do. Part of the fun of software is that the tools and methodologies change at least yearly – or if you’re using JavaScript, they change every 16 minutes.
And thanks to the wonder of the Information Superhighway, you can typically experiment with and learn new technologies before they’re even formally released. You just need to play with some beta releases, read a couple mailing lists, and otherwise gather knowledge from sources that are just inconvenient enough that most people don’t bother. Next thing you know, you’re top banana at an exciting new technology.
Of course, nobody can be an early adopter like this for every technology – in fact, most developers, especially ones at larger companies, won’t be early adopters for any technology. They’re content to let the indies and enthusiasts research, experiment, and occasionally blow themselves up due to some dire documentation or dubious dependency.
In return though, the experimenters benefit from great demand for the lessons they’ve learned. As the bleeding edge becomes just the cutting edge, bigger teams and companies start investing in the latest new-fangled wizardry and need folks to help.
I learned the value of this by accident when we started Steamclock. At my previous job, I’d become pretty experienced with a relatively obscure web framework called SproutCore. When I struck out on my own, I started getting inquiries out of the blue from big businesses that needed help with their SproutCore apps. It turned out that as a young open source project, very few people outside Apple knew the framework, so when companies wanted to experiment with it, Steamclock’s site popped up in the search results. This got us a couple of our big early clients, and taught us the value in specialization – intentional or not.
Each time new technology debuts, new experts emerge. Erica Sadun jumped into Swift on day one, and has now authored more Swift language proposals than anybody in the world. When Angelina Fabbro worked at Steamclock, she went from checking out a draft spec for Web Components to touring the world giving talks how to implement them before I could blink. And of course, friend of the show James Thomson – under the guise of developing a calculator app – has rapidly remade his career as a world expert in ARKit bananas. Which is bananas. But also, wonderful.
Back in the day, there was an interview show on 5by5 called CMD-Space. Each episode, the first question host Myke asked was:
“What do you like to be known for?”
While it served its intended purpose of kicking off many a good interview, it also slowly worked itself slowly into the audience’s brains – a question worth having an answer to. “What am I known for? What do I want to be known for?”
As a product studio, Steamclock does client work in order to fund our own product work, so having a good answer to these questions is critical. If we’re not known for anything in particular, we’re stuck knocking on people’s doors, trying to get in the lowest bid on Tinder for Bananas. On the other hand, if we’re known for doing great work of a certain kind, leads will knock on our proverbial door. Almost all of our work comes from this kind of lead today, and it makes for a far healthier business.
The thing is, it’s not enough to be able to say you’re good at building apps for companies – you need to be great at something specific. Maybe you’re great at building beautiful apps for ecommerce companies. Maybe you’re great at building secure apps for enterprise companies. Maybe you’re great at building dumb blockchain apps for excessively funded companies. You can stay a generalist – generalists are great. Just be sure to specialize in something too.
Seek out the surprisingly attainable goal of becoming a world expert.
If you don’t, you’re bananas.