Geek Bonding (or How I Learned to Stop Worrying and Love Star Trek)

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.

MORE ON TEAM BUILDING WITH PROGRAMMERS

Creating Synergy and Pride in Software Testing Departments

Building Sustainable High-Performance IT Teams

Communicating IT Value: How to Translate Geek Speak

When Team Bonding Falls Apart

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.

Generic Happy Fun Time Activities

Many morale- and community-building activities employed by organizations don’t make much of an impact on IT personnel, and particularly on programmers. It’s not necessarily that programmers are socially awkward, but often a kind of cynicism is prevalent. For reasons that could take a book to investigate and articulate, IT staff tends to run toward a stoic cynicism (with an occasional hyperdramatic diva case).

The upshot is that I’ve never seen a companywide picnic, dinner, dance or potluck that actually strengthened an IT team. Or perhaps the cause and effect is reversed: It’s easy for IT to feel like it has to constantly justify its own existence and defend itself from users who have found that “the computer is down” is a good way to avoid work. Generic companywide boosterism can have a hollow ring.

There’s also a wide variety of social comfort levels and workloads. I’ve attended several potlucks or company-sponsored luncheons where IT simply grabbed food and went back to work. That doesn’t create much of a team feeling—but then neither does trying to force people who are uncomfortable or busy into socializing.

Little Things Mean a Lot

You may gather that I’ve seen a lot of disasters in my day, but I’ve also seen things that were effective. Not surprisingly, the common thread among them is commonality. In other words, to build a team, you have to build on shared ground. (This is true in all cases; it’s just that the IT department shares less common ground with other departments.) Here are a few little things that can go a surprisingly long way.

• You think Kirk vs. Picard is the ultimate geek debate? Try Mountain Dew versus Dr Pepper. I’ve heard far more conversations about caffeine, sugar and artificial sweeteners than I have about any TV show. Does this mean that you need to provide free drinks? Not necessarily, though that’s a cheap way to generate goodwill, as will providing IT with its own stash area.

• Free food is another cheap bonding mechanism. I’m sure there are programmers who don’t like pizza, but I’ve never met one who admitted it. I don’t quite understand why, but the only other group I’ve run into that responds to free food in the same way as programmers is musicians.

• It should come as no surprise to anyone that IT folk are idiosyncratic in terms of the hours they keep and the clothes they wear. Of course, some (especially larger) companies are more conservative with what they allow, but you can be a hero of sorts by allowing whatever freedoms-from-conventions you can to your crew.

• Passing around links, songs or videos, while seemingly trivial, creates a common “culture.” Again, keep your eye on the final product. A bunch of tech guys sitting around joking may seem like a waste, but it might just mean that things are going really smoothly.

• Respect the team’s oddities. For example, I prefer to work in low natural light or the dark. This isn’t unusual among programmers, though very often I’ve found them reticent to turn off lights because some executives seem to think they’re filling a parental role. (“You’ll ruin your eyes!”)

Of course, some executives are just disturbed by anything different. This tends to put them into opposition with the natural state of an IT department and perhaps explains why so many companies keep the computer guys in the basement or tucked away in some other hard-to-find places. Your best defense against criticism is your crew’s productivity.

In some cases, this is vital. One guy I worked with had serious concentration issues that he handled by constantly listening to TV or music through headphones while he worked. Your crew’s productivity depends on you being able to shield them from irrelevancies.

Traditions

The above are passive, even somewhat defensive approaches that will nonetheless lay the groundwork for more active team building. Let’s start by considering a traditional and widely misused team-building tool: the meeting.

A good meeting for an IT department is almost like football strategizing (down to a whiteboard covered with arrows and squiggles). It should be short and broad, covering only those things that everyone needs to be aware of, and not bogging down in details. The more specific the team, the more detailed the meeting can be. If you’re running a pure programming group, meetings can get into the minutiae of coding standards, complete with heated debates. The main thing is to keep the meeting at the level of those who are attending: Don’t bog down your hardware guys with discussions on indentation and don’t burden your programmers with the latest computer installation issues.

A list of all the things one can do wrong in a meeting—which should be one of the most basic and effective tools in your team-building chest—could fill a book. I’m only going to point out one major error here because I see it so often: Do not berate your crew, either singly or en masse. The only time I’ve ever seen or heard of that working is in military and quasi-military situations. Meetings should be more like pep rallies.

Besides the meeting, other traditional forms of socializing, like the potluck, can also work—especially if limited to IT and a few sympathetic coworkers. This, again, isn’t necessarily specific to IT: A companywide potluck for even a small company of 50 people can be a big deal, where one for a five- to 10-person department is more casual and intimate. My current team sometimes augments the occasional potluck with a movie showing, the selection of which is often hotly debated. The movie itself isn’t really all that important (though it’s always something rather politically incorrect), but the debate is, as is the shared experience of having seen the film together (no matter how many times you’ve seen it before).

Getting Technical

The best IT crews have people who are passionate about tech. The best managers appreciate their crew’s love of tech and keep an eye out for ways to foster that. (Nontechnical managers usually don’t realize how much they profit from individuals’ pursuit of technical passions on their own time.)

One programming crew I worked with gave one employee time each Monday to prepare a presentation on technical issues for Tuesday. Tuesday morning was spent eating bagels and discussing a concept related to programming. For a very low cost, the company increased both community and skill, to say nothing of goodwill. This type of thing is a little trickier to expand to a more diverse IT department but can be worthwhile even then.

Books on coding techniques, design philosophies and other esoteric topics can give programmers the opportunity to debate that they might not otherwise have. Having been the sole programmer on more than one IT team, I can vouch for the loneliness of wrestling with interesting technical issues that nobody around me understood. Programmers can introvert heavily when involved in some heavy problem, and having common books to refer to can spur discussion and reverse that tendency.

For other techs, you can get a similar effect by having gadgets, devices and little things that may or may not immediately impact the job. One of my bosses in a seasonal business very cleverly spent the off-season encouraging investigation of all gadgets and software that might impact the business positively. If you have a mixed team, techs and programmers may be able to combine their talents on a device in a way that turns an idle interest into a revolutionary asset.

On the other end of the spectrum, another boss gave out little remote controlled cars for Christmas, resulting in some chaotic fun as the little things raced around the office. It didn’t result in anything revolutionary, but it did build the team. (There’s a reason ThinkGeek sells so many toys.)

Another not particularly productive, low-cost team-building activity is LAN gaming. While not all techs are gamers, quite a few are, and this sort of activity acts much in the same way a company baseball team does, without uniforms and sweating. (Sports teams can work as well, but I’ve never seen a tech team where enough people had an aptitude for the same sport.)

Higher cost activities can include things like attending user group meetings or even conventions. Industry-specific conventions are all right, but IT conventions are probably going to be more exciting to the team. If you’re in certain high-tech areas, a convention can be a day trip and doesn’t need to be expensive.

In a similar vein, if you have remote locations, road trips can serve the purpose of reminding those bound to a central office of the bigger picture, but in my experience, whether that builds the team up depends a lot on how they feel about traveling.

Wrap It Up

Programmers and techs tend to be very bottom-line oriented. Not on money, but on getting results. And they respect others who can recognize that and disregard the oddities and trivialities. While I’ve outlined a few key dos and don’ts, and mentioned a few activities, your best bet is to look at what your department is, and what it needs.

Remember: It isn’t hard to make a small gesture that goes a long way.