By Bob Hueston on Feb 05, 2007
To be a good leader of engineers, one has to take on the roles of a good engineering leader. One has to be willing to surrender their own behaviors, and adopt the behaviors of a good leader. Like an actor, the engineering leader plays a role, and often the role changes from scene to scene. I'm not suggesting that an engineering leader learn to act, to pretend, to be a leader; instead, they must learn how to act like a leader.
Three Roles of an Engineering Leader
In his book From Sage to Artisan: The Nine Roles of the Value-Driven Leader, Stuart Wells identifies nine roles for a leader, but I can never remember all nine. Instead I've identified three primary roles that the engineering leader assumes, and yes, I've come up with cute names so they'll be easy to remember:
- beekeeper: system-oriented.
- shepherd: team-oriented.
- cowboy: goal-oriented.
Why three roles, and not one? There is nothing quite like leading a team of engineers, and as a result, there is no single analog that reflects the engineering leader. Also, a leader's behavior has to adapt, based on the people and situation. At any given moment, the leader will be exhibiting one or more of the roles.
Studying Leadership Roles
Why should we study the behaviors of a leader -- aren't you either a good leader or not? No. Some people may take on the roles of a good leader instinctively, but the rest of us can learn the roles as well.
When I graduated from college I was a shy, introverted young engineer with little or no leadership abilities; only a desire to be an engineering leader. Over time I learned to act like a leader by watching the good engineering leaders around me. I learned how to give good presentations despite my abject fear of public speaking (and today some people even think I love an audience). I learned to approach strangers and get them to help when my nature is to avoid unknown situations. I learned how to motivate others, and how to motivate myself. I learned how to touch the human side of my teammates, and how to allow them to touch me. I learned that even though my gut might be telling me to keep my head down low in the foxhole, someone must stand up and lead the charge, and that someone was me.
I think any person, even with no natural leadership abilities, can grow into a good engineering leader. And a person like me who has gone through the transformation is probably in a good position to talk about the roles and behaviors a good leader must learn.
In addition to the three roles for a good leader, there are also dozens (perhaps hundreds) of other roles that we all play in our normal lives. As a leader, we can't always play the role we want to play; we have to decide to act differently in order to ensure our people and projects are successful. When another project leader calls up and says they can't deliver some dependency on their promised date, we might want to employ the angry, indignant customer role who yells some derogatory epithet and slams down the phone, but we need to play the beekeeper role. When we have a passive-aggressive engineer who won't follow the plan, we could play the wounded child role and go back to our office and cry, or the cowboy role and push them to complete their tasks. If we have a set of roles that we can use in these tough situations, we can stop, think about the correct role, and then move forward to resolve the situation in a constructive manner.
Roles in Action
As a negative example, consider the person -- we all know one -- who consistently plays the same, predictable role. My favorite I call the "grenadier;" he's the guy who figuratively throws a grenade into a crowded room (for example, he emphatically says, "This will never work!"), then when the smoke clears, he walks in to see who's left standing (he sees if anyone is able to defend their original position). It's a role that has limited usefulness, but the real problem is when a person plays the same role in all situations. I can imagine when this person gets home from work: He yells in the front door, "Dinner smells terrible!", then walks in, kisses his mother on the cheek and asks her what she's been cooking.
As a more positive example, consider a project I led a few years ago. Our software needed to interface with the software from another department, and my senior engineer had a proposed interface, call it option A. She met with the senior engineer from the other group, and he was very negative on her proposal -- it was overly complex, it would never work, and "everyone else" was using another approach, call it option B. My engineer didn't think option B was that great, and there appeared to be technical holes in the approach, but she went back to the drawing board and in a week or two we modified our design based on option B and got his personal OK (in writing via email). Then we held a formal review with multiple groups. When we reviewed this portion of the design, many people criticized the interface, pointing out the deficiencies in option B, and recommended a different approach, almost identical to our original option A. The engineer from the other group joined the choir, saying, "I told them this wasn't a good idea, and I think they should have used option A." My senior engineer seethed, but I encouraged her to refrain from commenting. We took an action item to investigate the two approaches.
Back at my office, my senior engineer let loose. She still had the email from him telling us to abandon option A and use option B. She wanted to send the email to his boss in order to point out his incompetence. I did too, but I realized that running with my emotions would have only served to initiate a finger-pointing argument, which could sour the relationship with the other group and hinder forward progress. More importantly, we needed the OK from this other engineer, and making him look bad, especially in front of his manager, was not going to help achieve our goal. Instead, I took a deep breath, and playing the role of the beekeeper, I drafted an email response to our action item saying that upon further review, we agreed that option A was superior, and thanked the members of the design review for catching this problem, all of which was true -- we did believe option A was superior and we were glad the reviewers helped finalize the design. I just chose not say anything further. This approach got us what we wanted: Approval to use option A (which is what we wanted all along), an official OK from the other group (which we needed to finish our product), and left us on good terms with the other engineer, with whom we often would have to deal in the future.
The story does have a happy ending, well, as happy an ending as a story about design reviews and software interfaces can be. The other engineer sent a private email to my senior engineer saying that he realized that he might have been the one to lead us down the wrong path, and he apologized for any inconvenience that might have caused. He was basically admitting, privately, that he had screwed up, something he could not do publicly for whatever reason.
Roles are a set of behaviors that we use when dealing with others. There are roles we play naturally, from instinct. We can also learn roles, roles that are constructive, supportive, and motivating in order to lead our projects and achieve our goals. When we understand the roles available to us, we are able to intelligently select a role that best suits the situation.