2 Comments

A Generalist Theory of Relativity

relative_clocks

At Atomic Object we say that we hire generalists. I work with people who I think of as generalists. I self-identify as a generalist.

But how general can you get, practically? Well, it’s all relative, of course.

Generalization

Relative to the average maker, what makes one a generalist?

To begin, I’ll explain what I mean by “average.” I’m not ranking skill or talent, so think “mode” not “mean.” Most employed makers of software work on one aspect (programming, say) and do so in a very narrow slice of domain and experience for many years, up to their whole career. For example, some might think of themselves as “web developers” and write mostly Perl, PHP, Ruby, or Java code for the first couple of decades of their professional life.

So what makes someone more general? The term “polyglot” is a good start. I think of this as having a deeper meaning than the literal, “speaker of many languages.” I’m describing someone multi-disciplined, who dives deeply into many domains, practicing Beginner’s Mind along the way — always hungry.

While that’s a good start on the way to being more specific about generalism, I think there’s a limit to this commonly-cited aspect. There’s probably a mental and social substrate constant maximum that means you can only generalize so far. It’s like the speed of light in the universe of creative professionals.

For instance, I try to gain expertise — or at least stay proficient — in software development, software testing, product design, and data visualization all at once. Realistically, I’m never going to be a leader in all those fields while also putting them to practice creating software products for customers every day. So what else is there?

Tools

Tools decouple us from specificity.

I know a lot of tools. I know their shape, their definition, their essential purpose, their availability. A few tools I know well. For these few, I know their secrets, their faults, their warts, their hidden purposes.

But most importantly, I know about tools. I am always trying to become an expert toolsmith. I specialize in learning or making new tools. I know how to practice, compare, categorize, brush up, wear down, and throw away tools that already exist. And I know how to prototype, design, and test out new tools that I or my team can make.

To me the meta-learning that comes with understanding the nature of toolsmithing is a key ingredient to being a generalist. If you’re not an expert at becoming an expert, you can’t grow beyond the level of polyglot.

Generalists matter. Because change.

Speaking of constants: you can always depend on change. Personally, I’m getting through post-desktop, post-agile, post-OO, post-startup. Even things that seem totally locked down and static move quicker than we realize at the time. Take the iPhone for instance. Developers complained about the static, closed ecosystem in 2007. Then App Store, iPad. Everything changed, and changed so fast that it’s a constant challenge to keep up with the newest SDK.

So you need generalists because they are specialists in tools, and also because they are specialists in accepting and overcoming change.

But maybe you’ve heard that some Valley co. pivoted and is trying to hire specialists, Only The Best, trained experts in Data this or Mobile that?

Specialist preference is often retrospective.

Ahead of time, you can’t know which tools you’ll need unless you happen to already have an expert specialist. In retrospect, you might be able to point at a task and say “If only we’d hired someone who already new Hadoop really well…” But maybe you switched to Neo4J halfway through. Or maybe you could have, if you hadn’t been so sure you needed a map-reduce expert.

Beforehand, you probably didn’t even know you needed Hadoop, or something similar, or even something custom instead.

So I’m saying: a generalist that knows how to select and learn new tools is always a better choice until the domain is explored and proven tools are found. Which isn’t to say that they are always the best choice. By all means, once you have a solid business model and a firm understanding of the market, specialize. PhD up.

Just… consider keeping some generalists around. You never know when a new theory will come along.