Do a search for “managing programmers” on the Internet, and you will find a number of sites that lead to the following observation: Managing programmers is like herding cats. The prevailing belief is that programmers are such an independent and rebellious bunch that they resist conventional management practices. Nonsense. The only similarity I see between programmers and cats is that both become attentive when food is present. A more honest and accountable appraisal might be that programmers, by and large, are an intelligent and creative group and thus are not resigned to suffer poor management in silence. Besides, I see no reason to malign cats.

The difficulty in managing programmers lies in the unique requirements of their vocation. The best programmers must be both linear and orbital thinkers. That is, they must be capable of sustained logical reasoning, coupled with bursts of creativity and cleverness. Programmers are both left- and right-brain thinkers, logical and intuitive, scientist and artist. Most managers would agree that overseeing a group of methodical scientists requires a different style than managing a bunch of unruly artists, but what do you do when both aspects are strongly present in the same people?

Equally daunting for managers is a mistaken notion programmers fervently harbor, namely that they work alone. They don’t, of course. Lighthouse keepers work alone. Typically, programmers are members of a team, and that team, directly and indirectly, interacts with numerous people who are part of a software development project. Yet, many programmers see themselves as digital cowboys who, armed with mouse and Cheetos, ride out alone to tame the wilds of cyberspace. Or conversely, programmers may revel in being “black hats” capable of hacking into any system, unlocking any secret, unrestrained by rules or security provisions designed to obstruct mere mortals. Both are romantic and self- aggrandizing notions, and, as a manager, you will not be popular for dissuading people of their fantasies.

These challenges are complicated by the fact that programming managers often come from the ranks of software engineers with scant experience as administrators. While technically brilliant, these engineers may be thoroughly unprepared to submit budgets, negotiate schedules, analyze requirements, and manage projects and people. Alternately, managers may be talented outsiders with general management skills and a solid

understanding of IT functions, but short on technical expertise, unable to fluently speak the alien language common to the software development community.

Either scenario presents unique challenges. Managing yesterday’s peers requires the ability to differentiate respectfully from the pack and to let go of the control enjoyed as a coder. Wanting to examine every code segment will only alienate the programming staff and exhaust the manager. The challenge for the newly promoted manager is to assign, trust, and test. Outsiders will have to earn the respect of the team by becoming knowledgeable about the software environment and by listening very attentively to input from the group.

Given the complexities of technology, the multidimensional personality of programmers, and the multifaceted demands placed on software development managers, I offer the Top Ten Considerations for Managing Programmers:

Drum roll, please!

10. Start with yourself—As a manager of whatever origin or experience, the most courageous and fruitful place to start is with yourself. Do an honest assessment of your strengths and weaknesses. Some managers are better technicians, others have more refined people skills, still others excel at administrative tasks. The reality is that the people you are managing are very bright, and you will not fool them. Find your area of learning and share your findings with your staff. They already know your weaknesses anyway, and honest disclosure builds trust. Delegate where you can and seek training where necessary.

9. Everybody learns—Having led by example, ask your staff to do a similar assessment of their own skills and training needs. Develop personalized training programs based on their responses. Ensure that your staff has the tools and knowledge to do the job. If, for example, you are developing an accounting system, it will be helpful for your staff to have a rudimentary understanding of accounting principles before designing the new system.

8. Be aware of learning styles—Understanding learning styles will assist you in communicating with people who are both left- and right-brain thinkers. Typically, you communicate in the style in which you are most comfortable. When that style clashes with the listener’s, you repeat your message louder in the hope that she or he will eventually get it. Usually, they won’t. It is much more effective to modify your communication to suit the listener. There are three primary learning modalities: auditory, visual, and kinesthetic. Each modality has a preferred way of receiving and processing information. Programmers are predominantly visual learners. Those who are principally left-brain visually oriented (the ones who typically work on linear systems such as accounting or manufacturing) want information presented logically and sequentially. These programmers have to see in order to listen. They need to have the why questions answered. They like information presented in manuals, on video, or on computer screens. They become overloaded with too many words. They need physical distance from the speaker to create mental pictures. They are often cautious and want time to reflect before deciding.

Right-brain, visually oriented programmers (the ones who gravitate toward games or highly graphical applications) are fast thinkers with subtle reactions. These programmers like new toys, new acronyms, and the latest technology. They get bored easily. They want to know what will occur before you begin. They make commitments that last, but they want control.

If both types are represented in your group, expand your communication style to include their preferences. When there is poor communication within a working group, it is often caused by a mismatch in the way people give and receive information. An awareness of learning styles will make you a more flexible communicator.

7. Create a shared vision—Developing a shared vision is the most powerful way to build a team and persuade your digital cowboys to march in lockstep. Create a vision for your

department as well as each individual project. On the project level, this means developing an explicit consensus about the nature of the software you are cocreating. Who are the users? What is their level of comfort with computers? What interfaces are appropriate? These, and the answers to dozens of other questions, will comprise your vision of what the end product should be. World-class teams are not autocratic, but collaborative. Programmers will be much more generative and passionate about a project if they view it as developing a collective work of art, rather than churning out code. Vision provides the roadmap. Take the time to create one.

6. Monitor technology overload—For all their eccentricities, programmers are the creators who breathe life into inert computer stuffings. To do so, they ride a technology roller coaster that never slows. New hardware, new operating systems, new programming languages, and new development tools all come at a dizzying pace. Overnight, today’s experts become tomorrow’s novices. Although the process of vocational death and rebirth is engaging and exciting, it is also ultimately exhausting. If members of your staff are resistant to projects that require learning new skills, they may simply be saturated. If possible, allow overloaded people to rest and regroup by assigning them less demanding tasks. And remember, just because a new technology exists doesn’t mean it’s appropriate for your shop. Assess your team’s interest in the new technology and the real, measurable benefits of deploying it. Before you make a move, evaluate whether the result you want could be achieved with technology your staff is comfortable with.

5. Beware of feature creep—Like the military’s nightmare of mission creep, feature creep can make short projects long and long projects endless. While most projects continue evolving beyond the requirements phase as users begin to fully explore the possible uses of their new system, excessive requests for new features should be handled as change orders, outside the scope of the main project. Feature creep is a schedule buster and the main reason projects drag on into the unproductive terrain of waning interest and dwindling commitment.

4. Protect your staff from political fallout—Any good manager will instinctively do this. Mistakes happen—that is why rigorous testing is a part of any implementation. In spite of best intentions and systemic precautions, some bugs will inevitably survive simply because all possible software usage scenarios cannot be anticipated. Top management may only have a rudimentary understanding of IT and may thus reach unwarranted and unflattering conclusions. A manager’s responsibility includes educating his management team and setting realistic expectations, then assuming full accountability and ownership of the outcome.

3. Develop rigorous standards for specifications—The more clarity and detail you build into the design specifications, the greater the probability of a successful and timely implementation. This becomes doubly important in a distributed environment where distance imposes its own discipline on application design and development. But the degree to which any project relies on continuous direct communication as a remedy for lack of design precision is the degree to which the development process will be frustrating for all concerned. As in manufacturing, the more quality built into the front-end of the process, the less rework required.

2. Remember the big picture—It is easy to get swallowed up by the crisis of the moment and lose perspective. When external pressures mount, programmers are too often sacrificed at the altar of today’s disaster. An indication of myopic focus is when dedicated people are worked to exhaustion, and individual sacrifice becomes the answer to every crisis. Problems occur in context. If your staff is constantly fighting fires, you have a process problem. Employees are not empowered to create or change a process, they simply thrive

or fail within established structures. Only management can change an existing process, but employees are a great source of information about what works and what doesn’t. Ask them.

1. Set realistic schedules—I’ve seldom heard the word schedule in a development context when it wasn’t preceded by the word aggressive. It’s as if it’s somehow an admission of inferiority to advocate for realistic schedules. But, in my experience, the number one reason projects fail, programming managers lose their jobs, programmers quit theirs, and users gripe, is the imposition of unrealistic schedules. Simply stated: Overly aggressive schedules produce shoddy software and burn out employees. Never assign a task to a programmer unless he or she has fully bought into the implementation schedule. It is cruel and counterproductive to force an unrealistic schedule on your team members and then put them in the position of being targets of criticism when the software is delivered full of unanticipated glitches. The exhortation to work harder is often a poorly disguised attempt to compensate for unrealistic expectations created by unreasonable schedules. Individual heroics should not be the substitute of choice for sensible scheduling.

Build a fudge factor into the schedule. A friend of mine who works as a consultant says that building an extra month into the schedule is always a win-win situation. If the project comes in on time, his customers are pleased. If he delivers the software a month ahead of schedule, his customers are delighted. All things not being equal, opt for delight.