IT strategy. Managing your techies is easy when you know what they're really like

Understanding what makes technical people tick is the key to motivating and retaining them. So working out what makes your IT people happy, hard working and likely to stick around is pretty important, even for those FDs who aren’t IT bosses.

The first thing to get clear is that technical tasks like software development are, contrary to the image, highly social. Complex software can’t be produced by an isolated kid in a bedroom – and it isn’t. The stereotype of the dysfunctional but technically-gifted adolescent with no social skills is just that – a stereotype. Even if some tech people are rather introverted and graceless, they still have to participate in an intensively cooperative process to get their jobs done.

However, the mechanisms and rules of IT are different to those that operate among managers. For a start, most technical jobs are head-down rather than head up. They demand periods of intense, focused concentration on the task in hand, as opposed to head-up jobs where the emphasis is on a broad awareness of what’s happening, which requires face-to-face contact with other people. This is unfortunate for technical people, as most high-level management jobs are strongly head-up, and head-down tasks in consequence tend to have low prestige in most companies.

The importance of this head-up/head-down distinction is partly obscured by the high profile enjoyed by the people wandering around our offices doing IT user support. But such help-desk work, particularly for common products such as Microsoft Office, is at the low-skilled end of the IT job spectrum. It isn’t typical of the work done by the people in short supply – the software developers.

So what motivates these hard-to-get programmers, software architects and team leaders? From the research I’ve done among Computing readers, two things stand out above all others. Love of the work itself, and prestige – being held in high regard by their peers. These count above financial rewards and above security as reasons to stay with a company – or to be more accurate, with a particular project team.

What’s interesting about these key motivators is that both turn out to be highly social. Closely coupled with love of the work itself is the opportunity to learn. And this often means the opportunity to work with and learn from people who are already expert at some new and interesting things. Once you yourself get good at something other people come to look upon you as a resource, and your prestige goes up.

Similar forces are at work in many other professions, but there’s one other wrinkle that makes how they work among IT people distinctive. Truly gifted programmers and software designers are very substantially more productive than their run-of-the mill colleagues. It’s not a matter of 10% or even 50% extra productivity, but often of twice or even ten times greater effectiveness, often coupled with the ability to see ways of doing things that others don’t grasp until they are pointed out. You need to look to fields such as music, mathematics or foreign languages for other examples of variations in performance of such magnitude.

When teams are made up of such disparate talents, information flow has to proceed in a way that doesn’t disrupt the work of the most knowledgeable, most productive members. The exceptional prestige of technical gurus helps protect them from interruptions, and is what allows them to be brusque with requests for help on trivial questions that people could easily solve for themselves.

On the other hand, most technical gurus are also surprisingly generous with their advice, which is what makes the term guru genuinely appropriate in this case. Some observers have been so struck by this that they’ve attempted to explain programming culture in terms of the “gift relationships” studied by anthropologists in some tribal cultures. The most influential exponent of this view is Eric Raymond, a key figure in the Open Source Software movement.

But the simple combination of interest and prestige as motivating factors is also adequate as an explanation. Gurus get back prestige, most obviously from the acolytes at their feet, but sometimes also information. IT knowledge is highly compartmentalised, so although for months at a time the information flow may appear to be going one way, when the topic shifts someone else may get a chance to shine.

Assuming I’ve characterised what’s going on among your IT people accurately, what practical help is this to you? I think the key thing to recognise is the value of the team itself to its techie members. It’s easy for managers to allow effective teams to fall apart. Without intending to, a team can be disrupted when key members move on, interesting work dries up or someone simply moves the desks. So nurture you techies. If they leave, they’ll be expensive to replace.

Further reading: Homesteading the Noosphere, by Eric Raymond. Available free on-line at www.tuxedo.org/~esr/writings. Rebel Code – Linux and the Open Source Revolution, by Glyn Moody (Penguin Press).