How to be perfect (hint: just re-define 'perfect')

I was assigned to work closely with a very capable technical leader. I looked forward to my first meeting with him when I would have the chance to go through my usual on-boarding process. That normally consists of finding out what a new team member's goals and ambitions are, where they think they fit in to the organization and what they want from me as their manager. Sometimes these discussions are simple and sometimes they can be very complex, dragging out over a period of weeks. Regardless, they are always useful and productive.

This particular leader was clearly seen by others in the department and by the entire regional office as a respected expert. He had experience to match that respect; he knew our products and industry well. But in our ramp-up discussions, he raised the issue of emerging as a full-fledged personnel manager. He was tired of his limited technical role and wanted more. He was tired of never having the last word in broad meetings where technical issues were just part of the problem.

We discussed the ins-and-outs of the management role and my perception of what might limit his success. He pledged to work on those areas and our discussions continued. At first he continued to do a great job as a technical lead, exceeding my expectations for his ability to adapt toward better interpersonal communication and teamwork.

When we began to discuss his first management role, he embraced it enthusiastically. Everything seemed aligned so we formed a small team for him and kicked off a project. Nearly immediately, however, things started to unravel. Two people from his team approached me to escalate concerns about their assignments and the plan their new leader had set out for them. The new leader himself began working extreme hours and still could not keep up. He also began complaining about some parts of the management role which he felt were beneath his skills. He requested that a project manager be assigned to his team so he could delegate work to them.

My style is to be very direct with management issues but he was imploding faster than I could schedule feedback discussions. The situation was caustic as he blamed me for the issues and wanted more time, but I needed to take swift action in order to avert an employee and project disaster. He proposed a solution that brought the situation into perspective. Basically, he felt that his responsibility for non-technical issues was a bad use of his time, but that as technical leader, he had previously not had enough responsibility. So I should make him the leader over the entire department, with delegate resources to handle the areas where he fell short personally. In essence, if the role were perfect for him, he would be perfect for the role.

Faced with a tough technical problem, he would never have tried to re-define the constraints just to make his life easier. But that's exactly what he was doing in his first leadership role. It is meaningless to say that you perform well in a role so long as it is a role that you perform well. The whole point of the leader is to bring the team together, filling-in the gaps between them; that is not possible when the leader's role is stiffly defined in a hierarchical dominant fashion for others to align around.

Thanks for reading this Management Use Case. I'm the co-author of a new book on software development leadership entitled You.next() that features dozens of other use cases for leadership. Please see more at www.youdotnext.com.