DURING THE “MENTORS, MODELS, AND

the Making of Managers” panel at a re-cent software management conference, aparticipant asked, “Do you need to betechnical to manage technical people?”The panelists were united in their an-swer: “No.” I agree, and I would like toexplore the question in a little moredepth. To what extent do technical skillshelp managers? And what other skillshelp managers even more?

Susan manages a team of developerswho are working in C++ on Windows.The last time she programmed, it was inCOBOL on a mini computer. No one inher office even knows the term “minicomputer.” She originally felt out oftouch technically with her people. Butdespite her concerns, she has been suc-cessful in leading her department be-cause she has earned the respect of herdevelopers.

Frank, a highly successful sales man-ager, was promoted to be the vice presi-dent of a software engineering organiza-tion. The executive staff wanted him tobring his gung ho attitude and customerfocus to the development group. Frankeagerly accepted the challenge—then be-gan wondering what he’d gotten himselfinto. But soon he found that the non-traditional skill set he brought to thisposition turned around a flounderingdepartment.

Cheryl manages a team of testersworking on billing software. She does-n’t have much test experience, but shehas more than a decade of experienceworking with billing systems. She wasconcerned that her lack of test experi-ence would make it difficult for her tomanage and guide her testers; however,her domain expertise gave her a differ-ent perspective on the problem and

made her a very effective manager.Susan, Frank, and Cheryl had a com-

mon problem: they didn’t understand theday-to-day details of what their peoplewere doing. They worried that their lackof understanding would undermine theirability to manage.

So what can you do if you’re in a sim-ilar situation to Susan, Frank, or Cheryl?How do you manage technical peoplewhen you’re either not technical or notup to date on current technologies?

Acknowledge What You Don’t KnowThe first thing that Susan, Frank, andCheryl did was admit what they didn’tknow. They understood that misrepre-senting their skills to their staff wouldbackfire.

I once worked with a non-technicalmanager who kept programming bookson his shelf so he’d look more technical.I was fooled for a little while. Then Idiscovered that he didn’t understand ba-sic programming constructs like loopsand case statements. He was trying tobluff, and I lost all respect for him. Hewould have been better off admittingthat he didn’t know how to program.Instead, I began wondering what else hehad hidden.

Use What You Do KnowFrank knew how to motivate people.Managing sales people is a motivation-intensive position. He didn’t know amacro from a make file, but he knewwhat the customers needed and how tomotivate the developers to give it tothem. The developers much preferredworking for Frank rather than for hispredecessor, a process-oriented formerdeveloper who spent most of his time de-veloping waterfall-like process models in-stead of talking with his people. Frankhelped them understand what the cus-tomers needed and improved the rela-tionship between sales and development.

Susan knew a lot about how to buildsoftware. She knew how to manage risk

and had good instincts about when to de-lay a release and when to ship. She alsoused her past experience as a developerin negotiating with the executives to getthe engineering organization bettersalaries, more space, and better equip-ment. She didn’t have to know muchabout the current technology to be agood advocate for her group.

Cheryl knew just about everythingthere was to know about billing systems.She used her knowledge in prioritizingtesting tasks and assessing risk. Her do-main expertise was more valuable to herthan a broad background in testingwould have been.

Any job has numerous facets. If youare a non-technical manager in charge oftechnical people, don’t despair. Youachieved your position because of yourstrengths, not in spite of your weakness-es. Your task is to figure out how you canuse your strengths in managing yourgroup.

As an employee and a consultant, I’veworked with more than a hundred man-agers. All of them achieved their posi-tions by demonstrating their capabilitiesin a variety of areas. The ones who suc-ceeded in their positions did so by beinghonest about what they knew, using theirskills to the full extent of their abilities,and actively seeking to grow their skillsin new directions. Not understanding thedetails of the technology doesn’t get inthe way if you use your strengths well.

Ask QuestionsIf you’re too busy hiding your lack ofknowledge, you won’t feel comfortableasking questions. You’ll think you shouldalready know the answers. Let me tellyou a secret: no one knows all the an-swers. No one. Not knowing the answersisn’t a sign of weakness—not askingquestions is.

Frank was particularly adept at ask-ing questions on unfamiliar topics. Hisfavorite phrases seemed to be “Help meunderstand…” and “Explain this tome.” His technique worked. He didn’t

58 STQE MAY/JUNE 2002 www.stqemagazine.com

Career Development

Managing Technical People (When You’re No Techie)by Elisabeth Hendrickson

Q U I C K L O O K■ Ways to work around your technical

shortcomings■ Building on your strengths

This article is provided courtesy of STQE, the software testing and quality engineering magazine.

always understand the answers to hisquestions, but he kept asking questionsuntil he got the answers in terms hecould understand.

When asking questions, it’s importantto ensure that you are genuinely asking aquestion and not simply phrasing a state-ment in an inquisitive way. Just because aphrase sounds like a question doesn’tmean it is. The phrase “What do youmean, we’re going to be late?” isn’t aquestion. That’s a statement that means,“You idiot. We can’t be late.” Frank nev-er asked rhetorical questions. When ask-ing questions he accepted the informa-tion he got whether or not he liked it.That’s why Frank’s staff never balked atanswering his questions; Frank queriedthem in a way that indicated he reallywanted to know the answers.

Asking questions helps you under-stand what your staff does on a day-to-day basis. It also enables you to gaugethe effort your staff put into solving agiven problem. Finally, asking questionscauses your staff to question their ownassumptions—and that helps them im-prove their own work.

Focus on the PeopleNo matter what the technology, peopleare at the heart of software development.That means that as a manager, your abil-ity to work with people is far more im-portant than your ability to sling code.As Jerry Weinberg says, “Every problemis a people problem.” If you’re a non-technical manager, you may have strongpeople skills that your technical counter-parts do not. Play to your strengths; fo-cus on the people.

Both Susan and Frank focused ontheir people. Susan worked hard to gether best developers rewards they hadn’tpreviously received. Frank encouragedcommunication and strengthened the re-

lationship between development and oth-er departments. Your people skills canhelp you lead and manage, and can alsopoint out potential problems.

Without understanding the content ofa technical discussion, you may be able tospot technical risks by listening to the tonein meetings and watching postures. Youcan tell a lot by watching people interact.Perhaps your lead programmer is an intel-lectual bully or your best tester hasstopped sharing information. If you werefocusing on the technical details of the dis-cussion, you might miss the subtle bodylanguage or masked hostility that couldwarn you of communication problems.

Learn Something about the WorkCheryl made a point of taking testingclasses and reading books on softwaretesting. If you’re truly non-technical andfind yourself in charge of a technical or-ganization, it’s a good idea to learn some-thing about the work your people do.You don’t need to become so proficientat it that you could take over for yourpeople. You just need to understand theins and outs of the job well enough thatyou can anticipate what your peopleneed and understand the importance ofwhat they’re saying.

So where do you get technical experi-ence?

First, decide what technology wouldbe most beneficial for you to learn. Youmight start with programming, testing,system administration, databases, net-working, or a variety of other technicalskills. If you’re unsure what to learn first,consider asking your people, “I’d like tobecome more technical. Where do yousuggest I start?”

Consider finding a class in the techni-cal skill of your choice. Community col-leges and university extension programs

offer a wide variety of such courses. Youcan also find online courses throughcompanies like Digital Think (www.digitalthink.com). Although you couldtry to learn to program from a book, I’vefound that formal classes are often betterfor beginners. You can ask questions in aclass. Further, the interaction with otherstudents can help speed your learning.

ConclusionThere’s a lot more to managing than un-derstanding the technology. Do youknow how to elicit requirements fromusers? Do you work well with manage-ment? Do you have a knack for askingthe right questions at the right time? Notknowing where to put the semicolons ina line of code isn’t a big deal. Knowinghow to lead people, now that’s a big deal.

You don’t have to become a supergeek to succeed in an engineering organi-zation. You do need to bring your ownunique talents and skills to the table andcontinue to add to the value you bring.Whatever your personal strengths are,they will serve you well in your role. It’sup to you to figure out how. STQE

Elisabeth Hendrickson (esh@qualitytree.com) is an independent consultant spe-cializing in software quality assuranceand management, with twelve years ofexperience working with leading soft-ware companies. An award-winning au-thor, Elisabeth is a frequent speaker atmajor conferences on software qualityand management. You can read moreabout her ideas on quality and testing atwww.qualitytree.com.

www.stqemagazine.com MAY/JUNE 2002 STQE 59

Career Development

STQE magazine is produced by STQE Publishing, a division ofSoftware Quality Engineering.

This article is provided courtesy of STQE, the software testing and quality engineering magazine.