Soloists vs. The Choir
I discovered blogs a few years ago reading Eric Sink's blog, Eric.Weblog(). I was led to his blog by his regular columns on the (the series is still posted there): The Business of Software. For those who do not know, I once earned my daily bread running a small business. Eric expressed things about the software business that I had learned (or wished I'd learned) during that time. His blog remains at the top of my bloglines favorites - right next to Joel Spolsky - legend and founder of Fog Creek Software - whose blog I discovered through links on Eric's blog (isn't the internet wonderful?). The thing I admire most about these guys is their obvious passion for the business of great software development.
During the summer, Joel posted an awesome tome entitled Hitting the High Notes. In it, he delves into one motivation for starting a software company in the first place: "building the company where the best software developers in the world would want to work." Joel's premise is the Best Working Conditions lead to the Best Programmers which lead to the Best Software which leads to Profit! His post deals with a cornerstone of this philosophy: Is there really that great a difference between good and great programmers?
Joel cites some impressive statistics gleaned from Yale Professor Stanley Eisenstat, who teaches a software development class. The scatter plot says it all.
As Joel notes, "There's just nothing to see here, and that's the point. The quality of the work and the amount of time spent are simply uncorrelated." His conclusion: "You can't afford to be number two, or to have a 'good enough' product. It has to be remarkably good, by which I mean, so good that people remark about it. The lagniappe that you get from the really, really, really talented software developers is your only hope for remarkableness." (For my fellow vocabulary-challenged readers, lagniappe means "an unexpected added benefit." I had to look it up... isn't the internet wonderful?)
Please read the post in its entirety, I'm sure you will get more out of it than this summary provides.
A couple months after Joel's post, Eric responded with a post entitled My Comments on "Hitting the High Notes". Eric's post emphasizes the importance of teamwork in developing great software. The contrast in the two paradigms is summed in three paragraphs:
"For a soloist, hitting the high notes is an essential skill. In a choir, the essential skill is the ability to blend. Some of the most gifted soloists just don't have the stuff it takes to fit in a really great choir.
Sometimes, they can't blend. Their voice is the problem. A really distinctive voice is an asset to a soloist but is a disadvantage in a choir. They can't blend because that's just the way their voice is.
More commonly, they won't blend. Participation in a serious choir requires a generosity that simply is not present in everyone. Choir members don't get individual accolades or fame. Soloists do."
The remainder of Eric's article answers the question: "So are you saying we should forget about the high notes? Certainly not. I am not suggesting that you hire 'mediocre programmers'." His conclusions (summarized by me):
- "Be it a choir or a team, you want every member to be at the highest possible talent level. But the people on your team have to be willing and able to blend."
- "Great developers don't just make the product better -- they make everybody around them better."
Again, please read Eric's post in its entirety for the full effect.
I am interested in your thoughts on the matter.
Is solo talent the key to great software development? Is it team talent that leads to greatness? Or is it some combination of the two? Is such a combination possible and/or necessary? What do you think?
My two cents:
My experience has shown results matter - regardless of your market. But - and this is key - markets are different.
If you are, or work for, a small software shop, your results are directly tied to the consumer of your software products. This is your market. You don't have to guess whether you did a good job or not - you merely need to examine the corporate checking account.
If you work for a larger firm as part of an IT department, your market is comprised largely of internal customers. Internal customers consist of business people and analysts of all sorts, shapes and sizes; most of whom have or are seeking advanced degrees in business or marketing. This is your market. Your measure of success is feedback from these good people.
To sum:
- Small software company, consumer, bottom line is your critical success factor (CSF).
- Larger organization, MBA, feedback is your CSF.
Herein, I believe, lies a cultural disconnect.
Teamwork is essential in a large organization. If you cannot "play well with others" you will find your(talented)self out of corporate life quicker than you can say "I hate Microsoft" or "Open source rules." And yet, why can't we find a way in the corporate world to professionally and successfully manage talented, yet difficult, people?
My friend Mike Potts, the Efficient Coder, perhaps characterizes the bane of the coporate coder best in his essay entitled Where are you OOP??: "Developers in these shops are typically doing all they can just to meet their deadlines, probably have a very low team morale with hardly enough time to do their jobs much less truly analyze anything. A little Psycho meets MS Project."
Is managing talent that hard?
I've been a manager a couple times - most recently in the IT infrastructure for a large corporation (trust me, you would recognize the slogan...). I can criticize my peers and myself alike for errors handling talented individuals - but managing talented individuals comes down to some simple, yet often difficult, concepts:
- Don't do anything stupid.
- Don't tick off the talent.
Actually, ticking off the talent is kind of stupid, so Concept 1 would probably suffice.
Sometimes, however, the scales tip in the opposite direction and the talented individual hijacks an organization (or appears to) as discussed in this thread.
My experience managing talented people has been double-edged. It's great when you find a way to communicate the harsh realities of corporate culture in a manner which actually penetrates the talented psyche; and it cuts like nothing else when you fail at this endeavor. My practical advice to corporate IT managers:
- Don't be intimidated by talent - lead it.
- Communicate the (sometimes harsh) realities of the current corporate culture to your team - then challenge institutional bureaucracy at every opportunity.
- Greet individual or team success and failure with a predictable and balanced response - and protect your team members from unpredictable and unbalanced responses. Remember: You must be free to fail before you are free to succeed.
:{> Andy
PS - Every IT manager (ok, professional) in large corporations should read Career Calculus - another great post by Eric Sink.