To specialize or generalize?

Hi Ian,

I like the idea of the specializing generalist. The phrase is of my coinage, but I must credit the inspiration for it to Scott Ambler. He discussed this exact question of specialist vs. generalist in his Software Development Magazine column a few years ago. The context in which he discusses the idea is in how to build an effective agile team, but I think it's easy to extrapolate his advice to one's own career. Here is an excerpt from Ambler:

Clearly, neither extreme works well—instead, what you want is something in the middle. One approach is to build a combined team of generalists and specialists. The generalists provide the glue, focusing on the bigger picture, while the specialists deal with the project's detailed complexities. This works well because the generalists' strengths balance the specialists' weaknesses—and vice versa.

An even better approach is to build a team comprised of people who are generalists with one or two specialties. For example, I'd claim that I'm a generalist. I have a pretty good handle on how the software process fits together, yet I have specialties in business application software modeling, object persistence and Java programming. One of my current coworkers is a generalist with specialties in modeling, EJB development and testing, whereas another is a generalist with specialties in telecommunications networking and Java programming. The advantage of building teams from generalists who have one or more specialties is that they quickly find common ground with their coworkers—after all, they're generalists, with the necessary background to appreciate the importance of other specialties. The main disadvantage is that these people are often very senior, and thus are difficult to find—it can easily take ten to 20 years to gain sufficient experience to become a generalist.

This rings true for me. I try to focus my own energy along these lines. On the one hand, to really make complex systems sing, we must be a specialist in some language, platform, toolset, etc. Platforms like J2EE, .NET, Windows/COM/COM+/IIS/ASP, and Linux/Apache/PHP demand deep knowledge of complex modular systems--and that's before we even get into programming languages.

On the other hand, if we don't have a broad range of knowledge, our highly specialized skills are like a table without enough legs. There are so many areas in which a professional must have at least some knowledge: development processes and methodologies; configuration management; quality assurance; operating systems; hardware; networks; writing; troubleshooting; project management; etc, etc.

I also like to extend the idea of generalization beyond technology itself. The Gerald Weinberg essay recently published here and Edward Nilges's recent blog posts demonstrate expertly how other disciplines such as philosophy, history, and culture can help us understand our technical work more fully.

Here is a link to the Scott Ambler piece. You'll need a Software Development Magazine account to read it:

Agile Developers: Generalists or Specialists?

As to the trivial matter of coinage of the phrase "specializing generalist," using Google I found this blog post that also uses the phrase:

Hallmarks of a Great Tester

It's a good phrase, I think. Doesn't really matter who thought it up.

Finally, I can't resist pointing to an essay I wrote on this subject a couple years ago: here is Part 1 and Part 2 of the essay, which is called "Specialties and Strategies."

Dan

Hello Ian,

My name is also Ian Joyce. That really blows because I thought I was special before now. It sucks that you took my name, and I think you should change yours ASAP!! I think Namestealer Joyce sounds good. It fits your personality. Just as there was a only one highlander, there must only be one Ian Joyce.

Your name-twin
Ian Joyce