[DRAFT] Specialize or Generalize?

I’ve seen some thoughts floating around today around what kind of mix of generalists or specialists should you have on an agile team. It started when I saw a tweet out from @GregerWikstrand on the topic and it got me thinking. I’m afraid of generalists. And specialists. Why?

I’m afraid of specialists because their world view is so narrow. In the words of one of my favourite science fiction writers growing up (Robert A Heinlein) “Specialization is for insects.”

If I’m a specialist in Java, I have very little exposure to what’s possible in a dynamic programming language. Or a functional programming language. Or a language that compiles to machine code. I started my career with BASIC, then C, then C++, then Perl, then Java, then JavaScript, then C#, then Ruby, then Objective C, then Swift, now I’m learning Elixir. Each language I learned taught me to solve problems in different ways, and now I can wield all of them with greater skill.

Does this make me a generalist (in programming languages)? I certainly didn’t specialize, or perhaps I specialized in many things for periods of 3-10 years. Most of those languages I’ve learned with some depth, whether exploring the nuance of concurrent development in Java, or meta-programming in Ruby. I’m pretty embarrassed to look at past code I’ve written in any language, but the further back I go, the further I see what I lacked at the time.

On the other side are generalists, to me a bit more scary than specialists. Why? Consider the original 5-stage Dreyfus skills acquisition model:

Novice < Advanced Beginner < Competent < Proficient < Expert

If, as a generalist you truly believe you can google your way to expert overnight on a topic, you’re probably sitting at the Advanced Beginner stage. That stage where you’ve learned some rules of the domain, thought “Hey, this isn’t so hard…” and are ready to jump in head first.

Personally I relish this stage, because it means when I make that jump in, I’m a short distance from competent after I blunder my way around for a while. Then the feeling sets in that “there’s more here than I thought”. Then I hit proficient. Then “holy crap how did I ever accomplish anything with this stuff in the past, I was such a fool!” And “I’ll never learn all of this if I live to be 100” as I curve through Expert.

I know I’m no expert when I’m diving in, and I think this is where ethics comes to play.

When I started my first software consultancy 14 years ago, I thought I knew how everything needed to be done. I was drunk off of the Agile Manifesto, and heading in to entrepreneurship without a freaking clue about running a business. I talked to every customer, and for every customer I was the solution to all their problems. I could do anything. I’ve seen this in a lot of small companies over the years, a reluctance to turn away business coupled with a “our dev is amazing and rules the world” attitude, with some poor 20-something soul barely out of school bright eyed and eager to take on everything.

Ahh experience. You’re a bastard of a teacher.

I loved being that person. It was exhilarating. I leaped into J2EE and began building behemoth apps like I could tame the mountain of work on my own. I built a product, it worked well, but damn it was easy to fall behind, and in the end, I lacked the time required to keep it relevant. I needed a team, but I hadn’t built a business to support a team. I discontinued the product 10 years ago and resigned myself to running a gun-for-hire consultancy shop.

Selling custom software services in a competitive market, you had to shine up the story of your team to blinding brilliance. It wasn’t too hard for me to do, I had built a good team, a group of folks who got along, were competent and hungry for learning, and I fed that desire, eventually learning to bounce the technology mix around to strategic places (or, more often than not, letting them do that). It took some effort to pull myself away from the comfy Java blanket, but wow was it worth it.

But staring out at competitors all in their shining armour façades, I was dismayed. Finding work wasn’t enough, it had to be good work that you could actually show the world. At our 10 year anniversary party a local MP was determined to find out what we did, and the guys bound by NDAs held their secrets well, to the MPs frustration. It was very hard to differentiate in a market full of “yes, we can do everything too.”

This team we had, were what I’d call multiple-disciplinary specialists.

One was extremely competent at the kind of mental gyrations needed to make a database sing. Poor guy wrote pages-long SQL queries dealing with ridiculously broken customer data. An insatiable appetite for new things, inspired us to centralize on Gentoo Linux, was the core driver away from Java Seam into Rails. Frustrated by the rest of the team’s difficulty in keeping pace.

Another deep dove into the Microsoft stack. Picked up Rails on the side, ripped through Silverlight, and became a tremendous C++ developer. When he first started with us, I was so amazed by his ability to context switch I tried overloading him. Didn’t work. He is also a tremendously compassionate person with great empathy which drove success for the client projects he took on.

I’d dug into ops, which became devops, and the three of us provided leadership to a growing band of interns and apprentices. We delivered some great projects.

I wouldn’t call any of the three of us generalists. And we couldn’t have functioned unless we’d each developed deep skill in a number of key areas. We certainly weren’t afraid to tackle new areas.

So what were we? Why did we do so well as a team for so many years? Were we a collection of specialists?

I think we were neither, and both, and that’s what held it together.

Which leads me to think that these two categories are maybe not directly relevant to the success of an agile team.

I don’t want a team full of Advanced Beginners. There’s some truth to the adage “knows enough to be dangerous.”

I don’t want a team full of specialists. When your scope is so narrow, communication outside your field becomes a challenge. Software projects are hard enough without layering on more communications challenges. Besides, I know the depth to which they can specialize is limited, because they tend to lack greater / other contexts.

I want a team of folks with varying experience, deep and shallow, like when you take a few panels with holes in different places, and put them together, you have a solid panel that won’t leak. The team, stronger together. Mix computer science and engineering folks, mix senior and junior developers, mix in testers, business analysts. Put people together who celebrate their differences, knowledge, culture or heritage, gender, age.

You may have some trouble if you’re not careful around prejudice, misogyny, agism, homophobia or transphobia, racism. These things will be obvious with the right cultural tone, and you’ll have to deal with them.

But watch them solve problems! A team like that will innovate like you’ve never seen. Once I figured out how to, this completely fed our ability to leverage tax refunds for experimental development efforts. All because the solutions they wanted to build were unique, interesting, and challenging.

Three Wise Men Inc, the custom software consultancy Stacey built had 10 people at their peak, and delivered about $5M worth of projects to a wide array of businesses in the GTA between 2002 and 2014.