5.06.2011

Teams Trump Groups When Creating Software

Managing software development is my vocation. It has been for nearly three decades. I’ve been asked by various peers to write down some of my observations, theories, opinions, techniques, and suggestions. Thus begins various comments regarding managing software teams.
Software is written by people. It all starts there. Some people are better than others at working together. Some just don’t know how. It all ends there. In a nutshell, what I’ve found is this: manage the work, and let the people manage themselves. Ensure they do so as a team. Why?
Without software, contemporary civilization could not exist. Billions and billions of lines of computer code are necessary to keep our lives in working order -- code that is expensive and difficult to author, and then yet more challenging to maintain. Defects are common, sometimes glaring. Although software automates much of the world, and underlies all contemporary communications and financial transactions, the act of creating code is in itself a painstaking and individual activity. Building any software system, irrespective of whether for services, infrastructure, tools or products, has been repeatedly shown as frightfully expensive[1] and a high-risk undertaking in terms of both time and money. Economic returns are highly variable. Disappointment abounds. Nonetheless, this tiger can be tamed.
Creating and maintaining software is challenging and difficult work -- far more difficult than anyone who doesn’t do it can realistically imagine. The act of authoring software requires razor-sharp technical acumen, extensively refined knowledge, proficiency with algorithms and languages, adeptness with tools, and all while requiring an excruciating attention to detail as a clock is ticking and people are pushing. Nonetheless, the mental aspects of coding can be intoxicating, highly satisfying for those with an intellectual bent and those who truly enjoy the life of the mind.
Mastery of the art when it comes to coding does demand an attentive physical activity of dexterous keyboarding, coupled with creative mental focus, usually amidst noisy and distracting surroundings. For the developer, coding can be a combination of wonderful mind flights and wizardry skill. It’s what produces “that nifty code” that “does that shiny thing”. The work of the best of them is brilliantly beautiful. The act of authoring software can be a great solo experience. And the pay is really good.
Yet, in the interests of the employer, superior economic value, in a sustainable manner, cannot be based on the actions of individuals, of solo performers. Instead, enduring economic returns are founded on the collective actions of several or more people, preferable acting as a team where all members pitch-in to ensure that the tasks to be done get done in a timely and effective manner. It takes people who see to the mentoring of each other, and who keep systems running, and continually improve[2]: (1) how they work together; (2) the tools they work with; and (3) with whom they work.
With a team, forward progress on a project never stalls. In contrast, if a deliverable depends solely on the actions of an individual, progress on that task just freezes should that individual be sick tomorrow, go on vacation, or be called out of town. The underlying challenge for the manager is to reward team performance while recognizing individual excellence. It’s harder than one might think at first glance.
Many paths lead to success. The activities suggested in this series of posts are among those that experience and observation have taught me do indeed lead there. Every manager can take simple steps to foster outstanding performance among software developers.
The suggested activities described in this series of posts will be a breath of fresh air for many developers yet an anathema for some others. Why? Because the first requirement for having a software team is to expect, empower, and reward teamwork -- which is much more elusive and difficult than popular management literature reveals. And not everyone in an org wants to be part of a team; especially in celebrity milieus where individual results are rewarded disproportionally over team performance, irrespective of whether the true accomplishment was that of a team. The mindset and methods presented here, however, are team activities for sets of team players. Personal experience suggests that outstanding performance will result from practicing the approaches described in these posts.

Stay tuned!
____________________________________________
1. C.f., Robert Charette, "Why Software Fails", IEEE Spectrum 2005