By George N. Andrew
Many at NASA believe the myth that good engineers make good project managers. My twenty-eight years of experience in engineering and management have taught me that engineers are often poorly equipped to manage projects, but it isn’t always their fault.
Good engineers know a lot. They know how and when to multitask; they can focus on details as well as the big picture; they interpret requirements and make good judgments about which are necessary and which are merely desirable; they make educated decisions about risk; they are team players and listen to others’ opinions; they brainstorm, whittle down to viable options, and make decisions; they empower, mentor, and teach others; and they take and give constructive criticism. Many of these qualities are also essential for being a good project manager. So why don’t all good engineers become good managers?
A Difficult Transition
When I made the move from engineer to manager, upper management expected me to handle all project issues and concerns and report back plans to correct them. Trying to do that on my own, with no formal training, I ran the risk of becoming a micromanager and a stranger to my family. I eventually realized I needed help from my whole team. Sharing the load meant the project could be successful, and I could leave work at a reasonable time and have a family life. I also believe that letting my team know that I couldn’t do it all myself encouraged them to come to me when they, too, needed help on a particular task. No one ever told or showed me that this was something I should do as a manager—and must do to become a successful manager—and learning the lesson was painful.
I made mistakes and couldn’t avoid all the pitfalls that come with moving from a specialist role to a managerial one. During unfavorable (not constructive) feedback, I learned I was doing a poor job of managing my budget and schedule and that my team was filing complaints about me. That was tough to hear, but it told me what type of manager I had become. In some areas I was a “micromanager” and in others I was a “hands-off manager.”
One of my early projects as a manager involved a guidance system for a launch vehicle, which I let the contractor handle completely because, at the time, I had little guidance system expertise. At the critical design review, it became clear that the contractor had accidentally designed for a suborbital launch trajectory, which meant the vehicle would come back to bury itself in the earth, rather than an orbital trajectory. Had I taken time to familiarize myself with the system along the way, I could have caught the problem early on. I was paying too much attention to the areas with which I was most comfortable and familiar and avoiding the unfamiliar because it was uncomfortable, and I had a greater chance of messing it up. A tight schedule and low budget compounded the problem. At this point, I had two choices: proceed on my current path and more than likely continue to be unsuccessful, or acknowledge my error and get some help.
Instead of falling deeper into fear and ignoring the tough feedback, I asked the company vice president, who had been a project manager, why I was perceived as doing poorly in some areas. I found a mentor and sought training outside the firm to help recognize my faults and failures. I also set aside time in regular staff meetings to ask my team how I could help them do a better job and what I could do to be a better manager. Taking that risk was frightening and overwhelming. I was fairly sure that raising those questions would strengthen their impression that I was less than capable of doing the job. Instead, I began to regain the team’s trust, and we began to work better together.
Finding a mentor and training to improve my people management skills were the most important steps in turning my failure into success. I learned not only how to work with people better but also how to recognize the fear of failure that was sabotaging my ability to succeed.
Making the Change
So perhaps the question should not be does a good engineer make a good project manager, but rather how can we help a good engineer become a good project manager?
Good systems engineers have experience seeing the big picture and multitasking. Good detail design engineers are well versed in managing details. These strengths can also be pitfalls. A systems engineer may fall into the role of a hands-off manager by losing sight of the details, while detail design engineers run the risk of becoming micromanagers. Both should aspire to become empowering managers who have natural leadership skills and can balance a project’s demands with their team’s abilities. Recognizing an engineer’s strengths and limitations should be the first step in making the change from engineer to project manager.
What both types of engineers need most is training in how to work successfully with a team. Supporting and leading a team requires a different skill set than supporting a system. Good engineers need training in how to become good managers, no matter how talented they are. Thinking that they will be good managers because they are good engineers only perpetuates the myth and sets them up for failure.
I am not a perfect project manager, nor a perfect engineer for that matter. I have learned how to ask for help, empower my team, give credit where and when it is due, continuously work with a mentor (seeking a new mentor when I am without one), take bad news and issues up the chain, and develop (with my team) a recovery and implementation plan. We managers need to prepare our high-performing engineers better for the new responsibilities they will face as project managers. The first step is recognizing that technical ability alone and even technical ability combined with natural leadership skills are not enough to make the transition successful.
This article is based on a presentation from NASA’s 2006 PM Challenge. The original presentation may be found online at http://pmchallenge.gsfc.nasa.gov/Docs/2006attendee-presentations/2006presentationsCD-attendee/George.Andrew.pdf.
This article mentions different managerial archetypes. Below are qualities I have observed or experienced from each type.
THE MICROMANAGER
The micromanager seems never to delegate; always has to do things himself; doesn’t plan (and wonders why there is always a problem); looks to blame instead of encourage results; performs crisis management; believes whatever is done isn’t done well enough; thinks there is never enough time to get anything done; seems to always claim the fame; rarely rewards subordinates; and is motivated by fear.
THE HANDS-OFF MANAGER
The hands-off manager seems to always delegate; never does things herself; asks others to do the planning; reviews very little work from her subordinates; approves everything either without reviewing it or asking questions about it; doesn’t understand why or what decisions are made, as she doesn’t make the decisions; seems to work in the shadows of others; may or may not reward subordinates; may or may not claim the fame; and is motivated by fear.
THE EMPOWERING MANAGER
The empowering manager delegates with an observant eye; shares in the work; works with others in planning; always looks ahead; empowers those that work for him; reviews work and suggests improvements; pushes those who work for him to step forward; encourages creativity; looks to solve the issues and not place blame; looks to do the right thing; manages time; and is motivated by confidence and trust.
About the Author
 |
George N. Andrew is an independent consultant with twenty-eight years of experience with spacecraft and launch vehicles, including fifteen years in project management. He has developed and presented numerous tutorials and authored several articles on systems engineering in spacecraft and launch vehicles. He is currently working as a program systems engineer on the NOAA GOES-R series weather satellites at Goddard Space Flight Center. |
