It’s no secret that many talented software engineers are supremely confident in their own technical abilities. Successful companies exploit this fact and constructively leverage the peer pressure to inspire creative innovation. At the various engineering management levels (manager, director, VP) we encounter professionals with a technical background who previously worked as hands-on engineers. So how does technical egotism factor into the role of management? Should someone’s technical opinion count for more, solely because he/she now has a management title? Major project decisions that factor in solely technical issues are rare since software development is a juggling act involving not only technical innovation but also resource constraints and target date pressures.
A good situation exists when technical managers at all levels stay on top of software technology as it continues to evolve. Often a first line manager is the technology expert among the group; many times a director or VP needs to be technically astute, knowledgeable and sharp, able to ask the right questions, assess the answers and drive decisions when no obvious conclusion exists.
Bad problems occur when people in an engineering management role don’t allocate time and energy to stay appropriately knowledgeable. The overall team needs to have confidence that not only can the leader positively influence the product development effort but he/she must be able to successfully represent the engineering team in cross-functional discussions and status reporting to senior management.
Ugly consequences result when the engineering manager (director or VP) insists on clearly and constantly establishing that he/she is the technical expert for the group and competes with the engineers to prove technical supremacy. It’s good to constructively challenge the engineering smarts of the group. It can be very destructive for the head of the group to consistently belittle technical ideas proposed by individual contributors. Brain-storming sessions should be creative discussions where half-baked ideas can be casually tossed out; many of these ideas won’t have merit but the group slicing and dicing of the concepts can be very productive, ultimately resulting in better products developed in a timely fashion.
Ideally a person now wearing an engineering management hat will have enough rapport with his/her team so that he/she can freely participate in nitty gritty technical discussions. All his/her ideas should not be taken seriously because of the management role but neither should they be summarily dismissed because of his/her management title. Either of these extremes occurring consistently is problematic and does not bode well for the success of the team.
______________________
Jane Divinski has, since 1994, provided software engineering management expertise on a temporary basis, leading Silicon Valley teams as interim VPE, director or program/project manager. For more background please see www.jadski.com.
No comments:
Post a Comment