Geek Bonding (or How I Learned to Stop Worrying and Love Star Trek)
The manager of a team of programmers is faced with a unique challenge: how to apply general principles to the weird and lead the unleadable so as to create a functioning group out of the unsocial. Blake Watson examines techniques and stereotypes that serve to create strong teams.
Wed, August 01, 2007
CIO — Fostering good relations between team members is particularly important in IT, whether you're managing a group of programmers developing a product or running an assortment of professionals with a variety of technical skills. But it must be confessed that IT tends to be composed of idiosyncratic and often downright odd people.
In the nearly 30 years I've worked with computers, I've had a chance to assume many roles on many different teams. I've also witnessed a variety of managers in their efforts to build something out of the irregular raw material that comprises most IT departments.
Perhaps it shouldn't need pointing out, but the subtitle of the article is a joke. There is no IT monoculture, and assuming that your geeks are Star Trek geeks is a good way to have them write you off. There is, unfortunately, no shortcut to knowing your particular crew.
“We're All Individuals”
The good news is that the same basic rules apply for programmers as for other employees: Treat them well individually and you'll find them more willing to form bonds with others on the team. Pit them against each other, throw them to the wolves when things get rough and demand they take responsibility for things (while not giving them the actual power to do those things properly), and you'll find no amount of team-building exercises will work.
As an egregious example, I once worked for a fellow who would randomly direct a tantrum at some employee. This actually managed to create a kind of bond, the sort of post-traumatic stress disorder bond you might find among hostages. It turned out not to be strong enough to sustain through the similarly random hirings and firings.
A less obvious example occurred in another company, where a group of new IT execs had signed on to implement one of those "Big Shiny New Systems That Solve All IT Problems Forever." They developed a hostility to the legacy system crew, who, they argued, made their job harder by continuing to extend the old system. This got worse as the project was (predictably) delayed.
The split went all the way to the top, unfortunately, so there was no one to encourage the groups to work together. As a result, a lot of work was duplicated and most of the crew from both teams were gone inside of a year.
