Generalist Myth

I consider myself a generalist. I like to think I have a layered understanding of a lot of technology and how those pieces connect to each other. I am the kind of guy when an interviewer says "So I see you know ASP.Net, how's your HTML?", I kinda cock my head to the side like a dog and say "Well, it's really good.", because to me, one lends itself to the other. I'm a better C# web app developer because I'm also skilled at HTML. Similarly, I also write better HTML because of my experience working with OOP.

Now the question "How does that play into a team?" comes into play. David Christiansen says that he wants a team of Will Reads (a scary thought, especially if you're Matt) when starting out, then progress to specialists. And this completely makes sense. Up until 2004 all of my work was essentially solitary. To compensate for not having a DB guy, a UI guy, and a Java expert gal at my ready, I did my best to become all of those things. I naturally created a team of sub-specialists within me. It's the same way with a small company that's finding new legs. Do you want the guys that really know about the details of Oracle's implementation of the currency type, or do you want the guy who can flip from pretty good architecture design, to dealing with a customer bug, to filling the coffee pot when it's empty? Me? I don't like coffee very much.

No problem, it's half a year in the future of the dot com boom and you now have more developers than you can shake a stick at. Along the way you needed some specialists because you needed to know how to scale well, and you wanted some great design on the next product line, and you really needed someone who could make UI that blew the pants off your users (which is a really nice feature if you happen to be making a porn site). Now you're wondering if you can make a team of specialists, or do you need a healthy dose of generalists to mellow out the silo of knowledge? This is where Scott Ambler talks about generalizing specialists. These are people who have a specialty, but are also inclined to learn about the domains that neighbor their own.

In the case of a highly functional Agile team, you really can't prevent specialists from learning about other areas, not that you would want to. There's just too much communication for that knowledge to not spread amongst team members. You can facilitate it, encourage it, though various mechanisms like pair programming, but you can't stop it if the team works to its fullest potential.

What really should be going through your head is this: Why am I even interested in this topic? The answer is undoubtedly the #1 concern of Agile: FEAR. Project managers are afraid that somehow their company will hire 600 people who love to work with databases, only four guys who know how to write the application layer, and they'll contract a guy to do the UI "as needed". Their fear is warranted because a team of database experts is going to have a hard time making the jump to the application layer on their own. However, a team of five database experts and one application layer lady stands a much better chance of becoming a cross-functional team that can deliver on features; and at the end of the day, that's really what matters most. If Susan decides that in order for her team to deliver on time, she has to crank out some Java instead of SQL, then it really shouldn't matter to anyone but the team. It also shouldn't matter to anyone outside of the team that the other five developers aren't "well rounded" if they are meeting expectations. If the team is not meeting expectations, then the team needs to be made aware, but beyond that, it is up to them to fix the problem. That's the beauty of a self-organizing team.

Agile is built for generalists like me. It is also built for specialists. Fear is what Agile eliminates. Agile relies on the team to react to changing job requirements, and empowers the team to make the changes needed. This gets the team to invest themselves in what they produce. I believe for these reasons that it does not matter if you hire generalists or specialists, only that you hire people who are willing to adapt, people who are willing to be Agile.