Managing Technical People (When You're No Techie)

During the "mentors, models, and the Making of Managers" panel at a recent software management conference, a participant asked, "Do you need to be technical to manage technical people?" The panelists were united in their answer: "No." I agree, and I would like to explore the question in a little more depth. To what extent do technical skills help managers? And what other skills help managers even more?

Susan manages a team of developers who are working in C++ on Windows. The last time she programmed, it was in COBOL on a mini computer. No one in her office even knows the term "mini computer." She originally felt out of touch technically with her people. But despite her concerns, she has been successful in leading her department because she has earned the respect of her developers.

Frank, a highly successful sales manager, was promoted to be the vice president of a software engineering organization. The executive staff wanted him to bring his gung ho attitude and customer focus to the development group. Frank eagerly accepted the challenge—then began wondering what he'd gotten himself into. But soon he found that the nontraditional skill set he brought to this position turned around a floundering department.

Cheryl manages a team of testers working on billing software. She doesn't have much test experience, but she has more than a decade of experience working with billing systems. She was concerned that her lack of test experience would make it difficult for her to manage and guide her testers; however, her domain expertise gave her a different perspective on the problem and made her a very effective manager.

Susan, Frank, and Cheryl had a common problem: they didn't understand the day-to-day details of what their people were doing. They worried that their lack of understanding would undermine their ability to manage.

So what can you do if you're in a similar situation to Susan, Frank, or Cheryl? How do you manage technical people when you're either not technical or not up to date on current technologies?

Acknowledge What You Don't Know
The first thing that Susan, Frank, and Cheryl did was admit what they didn't know. They understood that misrepresenting their skills to their staff would backfire.

I once worked with a non-technical manager who kept programming books on his shelf so he'd look more technical. I was fooled for a little while. Then I discovered that he didn't understand basic programming constructs like loops and case statements. He was trying to bluff, and I lost all respect for him. He would have been better off admitting that he didn't know how to program. Instead, I began wondering what else he had hidden.

Use What You Do Know
Frank knew how to motivate people. Managing sales people is a motivationintensive position. He didn't know a macro from a make file, but he knew what the customers needed and how to motivate the developers to give it to them. The developers much preferred working for Frank rather than for his predecessor, a process-oriented former developer who spent most of his time developing waterfall-like process models instead of talking with his people. Frank helped them understand what the customers needed and improved the relarelationship between sales and development.

Susan knew a lot about how to build software. She knew how to manage risk and had good instincts about when to delay a release and when to ship. She also used her past experience as a developer in negotiating with the executives to get the engineering organization better salaries, more space, and better equipment. She didn't have to know