It’s a staple of old science fiction novels: the telepath or the spaceship crew member with extrasensory perception (ESP). In the books, you can always tell who has telekinetic powers, because, while everyone else on the ship is freshly scrubbed and wearing out their arm saluting passing officers, the psychic loafs around like a bum, never shaving and rarely taking a bath. All the rest of the crew have regular duties, but the telepath just lounges around watching holographic TV and eating ice cream—until the captain needs someone to read an alien’s mind or something.

I bring this up because of some conversations I’ve had over the past few months with IT executives about their development staff. Almost uniformly, they talk about their programmers the way I imagine those spaceship captains talked about their ESPers: undisciplined, unorganized, fantastically creative—and critical to the success of the organization.

Now don’t get me wrong. The fact that executives finally recognize the importance of their developers is real progress. On the other hand, too many organizations (and for that matter, too many IT managers) still treat their programmers like a different breed. In this column, I’m going to argue that this is counterproductive—both for your department and for your developers.

Are programmers different, and if so, how?
Before we dive too far into this topic, I need to make a point. Much about what has been said and written about the development culture the past couple of years has been tied explicitly with analysis of Internet start-ups and the New Economy.

In other words, too many people, when talking about the trappings of Silicon Valley firms—Hawaiian shirts, mountains of Mountain Dew, and the obligatory Foosball table—assume that the majority of developers work for such companies.

Of course, that was never true, and with the current malaise in the Valley, it’s less true with every passing day. Today, developers work in too many different environments to generalize. Here are a few of the main ones, off the top of my head (and I’m sure you can think of others):

  • ·        Fortune 1000 firms: Many large firms have permanent development staffs, which may be either centralized or farmed out, either by project, business line, programming specialty, or even geographical location.
  • ·        Consultancies: Of course, many organizations outsource some or all of their development needs to consulting companies. Many developers work for consultancies of all sizes.
  • ·        “Oh…that’s our developer”: Many small to midsize IT organizations have one or two people tasked to do all the custom application development for the entire group.
  • ·        Independent consultants: Lots of men and women work as freelance consultants, picking up work with firms or with larger consultancies.

The point I’m trying to make is that there are different kinds of developers working for all different kinds of organizations. Therefore, it’s not really possible to generalize about developers.

That doesn’t stop people from trying, of course. Too many IT managers stereotype developers. If you disagree with my assessment, try this experiment some time: Go up to a fellow technical manager and ask him or her what adjectives come to mind when you say the word “developer.” Odds are, you’ll get back a verbal portrait of some Gen-X type, perhaps with multiple piercings, skateboarding down the hall with an armful of O’Reilly books under one arm.

The developer as professional
You might be asking: Who cares? What difference does it make what managers think about programmers, so long as the code gets written and debugged?

This is important, because treating developers as something other than professionals is bad both for them and for you.

At first glance, developers might enjoy the relative lack of expectations bestowed upon them by managers who treat them as extremely talented eccentrics. However, in the long run, developers suffer from such treatment, for these reasons:

  • ·        They get cut out of strategic discussions about the organization’s goals.
  • ·        They have fewer chances for career training and guidance.
  • ·        Some people function better with fairly aggressive oversight.
  • ·        In general, they aren’t treated as part of the organization.

For IT managers, treating developers like genius misfits carries a whole new set of problems:

  • ·        If your programmers don’t feel a part of your team, they’re more likely to leave for a better offer.
  • ·        Treating developers differently than the rest of your staff builds resentment and distrust.
  • ·        By viewing your developers as technological idiot savants, you miss the insights they could provide to other problems confronting you.

I’m not saying to change your corporate culture or to get rid of any perks. I am saying to be consistent. Sure, developers are talented—but so is your Exchange Administrator. You shouldn’t treat them any differently.

Join the discussion and win a mug

As an IT manager, how do you deal with personality diversity in your shop? Join the discussion by posting a comment below. Each week, the person who provides the best feedback to an Artner’s Law column will win a free TechRepublic coffee mug