(This is an article that originally appeared on the IT Manager’s site. Since the site has shut down, I’m reprinting the article here to give it a more permanent home)
Books about management techniques rarely mention how to lead computer programmers. The few that do sooner or later reach for a cliché and compare the effort to herding cats — J. Hank Rainwater, for instance, uses the phrase as his title. Partly, the comparison reflects how much the topic is outside the corporate mainstream. However, the comparison also reflects the conflicting nature of the job. The typical IT department represents a separate culture within a company, and a successful manager must both understand that culture and stand between it and the rest of the company, trying to explain each to the other.
I’ve seen dozens of managers — including me — approach this conflict, each with varying degrees of success. My observations here summarize what I believe are the basic facts that managers needs to know to manage programmers. They apply to any programmers, but especially those involved in free and open source software (FOSS), many of whom develop typical programmer attitudes to an extreme. Although some of the points seem obvious to those familiar with programmers, let me assure you: To outsiders, if their mistakes are any indication, the points still need to be emphasized.
You’re in a meritocracy. Prove yourself.
Management gurus usually focus on the characteristics of natural leaders and how you can imitate them. They give ambitious managers heroic images of themselves as samurai warriors, Antarctic explorers, or Henry V. However, neither the discussion nor the image is much use when you manage geeks, because developers, regardless of whether they are involved with FOSS or not, are more concerned with results than any real or artificially generated charisma. Before you can even start to lead a group of geeks effectively, you have to prove yourself to them — either by showing your competence in their area of expertise or by demonstrating that you have useful expertise that they lack. To become truly effective, you need to go further and prove that your expertise helps the group and everyone in it towards their goals, and that you have at least a high-level understanding of what everyone else is doing.
Until you prove yourself, you can expect to be tested, even if you’re a former programmer yourself. The probing can be aggravating, but the good news is that, if you prove yourself, you can quickly become accepted. At one company where I worked, the CTO had an impressive programming background, but it was some years in his past. The developers questioned his decisions constantly, right up to the time that he started delivering tough but accurate critiques of their code. The questioning stopped overnight.
Just because you’re in charge doesn’t mean you’re better
Watch how people spend their free time with family and friends, and you’ll soon notice a preference for informal structures. Given anything resembling a choice, people choose not to be in formal hierarchies, especially if they’re near the bottom of it. A hierarchy may be efficient, but, by being its local representative, you automatically become the focus of resentment.
This natural anarchism is stronger in developers than in most people. If you think for a moment, a meritocracy implies a constant shifting of status that depends on who has done what recently. Add this political instability to a widespread feeling of being different and misunderstood, and the resentment of leaders becomes stronger still. Moreover, in FOSS, where status is still one of the main coins with which programmers are paid for their efforts, these attitudes may be taken to a further extreme.
Neither being in a position of authority nor being older — as managers often are — is going to command automatic respect in the IT department. You might assume that your position reflects some superior qualities such as intelligence or ambition, but the development team probably doesn’t. Management consultant Tim Bryce insists that most programmers are no smarter than anyone else in a company, but that’s not what they believe.
Rather than relying on any natural or structural authority, IT managers need to see themselves as coordinators or problem solvers, working within the culture of their department whenever possible rather than against it. Nobody has ever shown the causality, but there’s probably a connection between the fact the era in which the corporate hierarchy has flattened corresponds to the rise of the IT industry. Because of the economic important of the computer industry, its values are spreading through the rest of the business world.
What motivates you doesn’t motivate your staff
A few management books, such as Beverly L. Kaye and Sharon Jordan-Evans’ Love ‘Em or Lose ‘Em
emphasize that one management style doesn’t fit everybody. However, many gurus and the managers who listen to them continue to assume that what motivates them — promotion, money, perks — also motivates programmers. For those unfamiliar with programmers’ culture, the process of realizing they are wrong can be disconcerting.
“Leading programmers is different from leading most employees,” career expert Tag Goulet says. “At one of my previous jobs at a startup, I was the vice-president of production, and led a team of three programmers. One of the guys posted Dilbert cartoons by his desk that poked fun at Dilbert’s pointy-haired boss and were quite possibly references to me. I’d never seen cartoons like that in more corporate workplaces. Instead, everyone was always careful to have political decor that implied that they were all team players.” In fact, such cartoons, like the popular Demotivator posters that satirize inspirational corporate art, are often the first indicators that many programmers are skeptical, even dismissive of the values that many managers take for granted.
The trouble is, managers usually have backgrounds in business or marketing, and are outgoing people who prefer to work with others. By contrast, most programmers are the academics of the business world, inwardly focused and preferring to work with inanimate objects. If they’re FOSS-oriented, they may also have a strong streak of anti-corporate sentiment. While they won’t turn down money, for them job satisfaction is more likely to lie in greater challenges or responsibilities, and, especially for those involved in FOSS, credit for their efforts.
Impromptu bowling in the hall may motivate your sales force and marketers, but, chances are that programmers will only feel like they’re being spirited away into a nightmare of frivolity. A weekly pizza night or an evening at a night club to celebrate the successful completion of a project might be satisfying to a human resources team, but your programmers will either resist being dragged away from their projects or, if they’ve just come off a coding spree, resent losing time they could spend with their families. Instead of being events to anticipate, such efforts are more apt to be seen as annoying obligations.
Instead of trying to make such by-the-book motivators work for programmers, think about you can implement the intrinsic awards that actually mean something to them. Reward those who meet their deadlines with greater autonomy in a project, or by giving them the chance to become project leaders or to telecommute so long as they meet their responsibilities. Let FOSS participants have time to work on free projects once they’ve met their deadlines; even if the projects have no immediate use to the company, they may become useful later, and, meanwhile, your sponsorship gives the company a good reputation among potential future employees.
Credit is the most important motivators, especially for FOSS participants, but don’t forget the cultural differences. Most developers are only going to be embarrassed by being singled out for praise or an employee-of-the-month award at a meeting. Instead, let people know that you’ve noticed their efforts and given them credit elsewhere in the company.
Learn when to keep hands-off
Shortly after I became a product manager, I discovered a major bug in a commercial product that was just at the plant and ready to be assembled. Put in charge of disaster recovery, I asked the team to assemble every hour so I could report to the company officers on the state of their efforts. After the disaster had passed, I found that I had left resentment in my wake. Not only did the programmers dislike meetings, but, by keeping such a close eye on events, I was questioning their competence and taking responsibility away from them. The emergency was real, but I was hampering their efforts to resolve it, not helping.
This kind of situation can’t always be avoided, but experienced managers will give all members of a programming teams as much autonomy as they have proven themselves capable of using responsibly. Partly, that means mediating between programmers and the demands of executives, but it also means only making an appearance among the cubicles when absolutely necessary. Instead of calling everyone together, I would have done better to send email requests or appoint a programmer to provide status checks. Better yet, I could have asked the team for a firm deadline and not interrupted anyone until that deadline while explaining to the company officers that the solution was being worked on — which was all they wanted to know anyway.
Minimize meetings
For managers, meetings are times when work gets done. For programmers, however, attending a meeting usually means time away from their work. Sometimes, especially at the start of a project or at a crisis, a meeting is unavoidable, but managers need to accept that programmers are likely to resent meetings and become more impatient with every minute that passes in the board room. The fewer and shorter the meetings, the more easily the developers will accept them.
Beware of fads in programming languages
Every couple of years, programmers become excited by a new programming language such as Java, .NET and Mono, or Ruby. Inevitably, whenever a project begins, some of your team will argue strenuously that it needs to be done in the latest fashionable language. Sometimes, this argument may be justified, but it is more likely to represent intellectual curiosity than sound design practice.
Almost always, the argument is a recipe for chaos. At one company where I worked, so many different languages were represented in its product suite that individual modules only communicated with difficulty. Several attempts to rewrite the suite in a single language only added to the complexity because they were never completed, and legacy support remained an issue. This trap is easier to avoid if you have a programming background yourself, but any manager should be wary of adding another language to the stack.
Learn when corporate values have to take precedence over geek values
Not being interested in business, many developers tend to ignore necessities like deadlines. Many become skilled at dodging them. The problem isn’t that most developers can’t be trusted to work responsibly by themselves, so much as the fact that they can be almost guaranteed to tinker as much as the schedule allows. In such cases, for all that successful management of geeks means understanding their culture, it also means recognizing when moving to achieve corporate goals are more important. At times, understanding needs to take second place to necessity, even at the cost of resentment. Skilled managers minimize conflicts with their staff, but they also recognize that some conflicts are unavoidable.
Conclusion
Managing programmers — especially FOSS ones — is an extreme version of the balancing act that any manager must do. On the one hand, managers need to understand the culture of their departments and how to work within them. On the other hand, they also need to act as intermediaries between that culture and the rest of the company. Combining these goals means adjusting your concept of management to the department. Sometimes, it means interpreting programmers to non-programmers,or shielding programmers from the misunderstanding of executives in order to achieve corporate goals. At other times, it means awakening programmers to the larger goals of the company. It’s a precarious balance, but knowing what to expect as you go into the position can leave you with more time to handle the challenges that arise without being distracted by cleaning up your mistakes or a lack of cooperation from your team.
Read Full Post »
Off the Wall 