Managers vs. technical contributors. Respect for process and schedules vs. the cult of creativity.

One of the most challenging aspects of being a manager in a technical organization is reconciling our viewpoints with those of the technical contributors. It has become very popular to malign management and managers-a la Dilbert-as non-value added functionaries in the more important world of technical achievement. Management tools and talk (especially for project management) can leave engineers bored, resistant, or outright rebellious-it's overhead, not valuable work. I have encountered this attitude many times in my career. Although two-thirds of technical professionals eventually spend much of their careers doing some kind of management, you wouldn't suspect it from their lack of interest in the subject.

Managers need to bring management theory and practice out to technical professionals, to integrate it into the mainstream of their work to have the best shot at successful projects. We have to be able to do our jobs with full team member cooperation. They need to see management and development processes as tools that will enable their best, most productive, and most enjoyable technical work. The fact is, all successful technical endeavors actually exhibit an effective integration of good development practices, astute technical decisions, and value-added use of project and functional management techniques.

How to solve our buy-in problems? I believe that the key to effective management of technical teams is to make them partners in the big picture and bring their technical concerns to the forefront. Then show them how integrated, effective management can eliminate the things they hate worst on projects and make their technical work and their careers successful.

• First, we need to identify the management language and perception issues at the root of the trouble. For instance, do we talk to our teams only about work breakdown structures or detailed procedures ("bureaucracy"), without explaining and selling the value of our tools? Their job is to produce technically-sound designs and implementations that meet requirements. Of course we know that good management facilitates all that. But they think management is just scheduling, formal status meetings, budget machinations--constraining and time-consuming overhead. They don't necessarily see the value.
  
  
• Next, especially if we're project managers, we have to ask if we're doing our jobs with the appropriate technical orientation. Do we come across as managers who drive unrealistic schedules without understanding the complexity or risks of their technical work? Do they see us as instrumental obstacle-removers, or as lackeys managing schedules and reporting status? Do they feel respected for their contributions?

Then we have to do the following with the technical team members:

• Involve them in the big picture of the business and the project, so they'll understand and participate properly in higher-level decisions that affect their technical work. They shouldn't be handed a schedule; they should participate in making design tradeoff decisions and planning the entire project.
  
  
• Talk to them and work with them primarily from the viewpoint of their technical work, in the language of their design processes. Status meetings and schedules should be directly, crisply, obviously relevant to their daily work and how it fits into the big picture.
  
  
• Deal with anything that is causing them to see management as ineffective or inefficient, and adapt our management style and techniques to fit the situation. Does your company require documentation that isn't useful, or bureaucratic signoff processes that take up time and add no value? Change it.
  
  
• Sell them on how good management will ultimately benefit to their careers. The better this project goes, the sooner they can go on to the next one. How can we better involve them in contributing to the project's success?

You may have to do a number of things to actually get your managers and technical contributors more aligned to ultimately make your projects more successful, such as modeling the behavior you want; getting supporters of the changes you want to make; investing in some education; prioritizing to take on the most important improvements first and being flexible about their implementation; and doing some individual selling.

The challenges are not insurmountable. The journey toward relevant management is highly gratifying. A technical team that understands the value of management is a delight. A lot of the work and responsibility for making this a reality in your organization is yours. Don't miss this opportunity to align your work more closely with their technical world-and enjoy your job a lot more in the process.