Friday, April 06, 2007

Everything I Needed to Know About Being a Dev Lead...

… I learned from my Hubbs.

He is by no means a household name like Hanselman or Esposito. He has yet to receive his MVP or his MCSD or a lucrative contract offer from Google. He doesn’t speak around the globe nor author best-selling development bibles.

And yet, he is arguably as good a team lead (if not better) than anyone who would fit one of those categories described above.

What I have learned from Hubbs, I have gleaned from his speech, his actions, and his thoughts. I have observed the way that his peers and his team respond to him, and I have watched him grow and reflect and improve with each day that he is in a position of leadership over others.

And this is what I have learned: to be a successful development team lead means to be effective on three fronts –beliefs, speech, and actions. In each of these areas, an effective lead is consistent and committed to the values that they profess.

I think that for the next few days, I would like to share what I've learned in each of these areas, with you. Thank you for indulging me in this rather thoughtful, more technical journey.


Beliefs

Effective leaders do not assume superiority over their team.

There are many paths that lead one to take on the position of a team lead. Being in such a role, then, does not necessarily correlate to having greater development abilities than those who are not team leads. Hubbs is a great developer, and innovative, and eloquent in his code. He would be foolish, however, to think that he is somehow a better developer than his teammates simply because he is the lead and they are not. His effectiveness comes from having the humility to recognize that he has much to learn as a developer himself, and to be willing to recognize that his abilities may in fact be far inferior to some with whom he works.

Effective leaders do not see their team members as threats to their position, but as measures of their own success in leading.

Though I cannot profess to know what motivates people to see their peers as threats, this is not uncommon at all in the development industry. I have heard, as I am certain many of you have also heard, some ugly tales of developers and project managers who have uttered mean-spirited, passive-aggressive remarks about the developers who have worked with them, or who have made decisions in order to keep certain teammates or subordinates from advancing in their careers. This has undoubtedly led to some very disastrous working relationships, many of which likely ended in burned bridges and hard feelings.

Being a successful team lead, however, requires the very opposite attitude. It requires a spirit of genuine camaraderie and collaboration, and a belief that the success of an individual brings success to all. This has been one of Hubbs’ finest qualities as a person and as a dev lead; he has always celebrated the individual successes of his team members, and has never looked at another’s professional accomplishments as a challenge to his own. I have never heard him speak ill of another developer or even contemplate a decision that might jeopardize the well-being of another developer’s career in order to secure his own role as lead or prevent others from advancing positions. If anything, Hubbs has worked hard to help bring about the advancement of others in their career. To him, their success is hardly a threat but rather, a tribute to their own skills and to his effort in helping every person on his team maximize their potential as developers.

Effective leaders believe that every person on the team has something valuable to offer to the project.

Every developer is uniquely talented and an expert in some area in which they have worked for a long time; this may not be expertise in the newest technology or the most cutting-edge applications, but a valuable skill set nonetheless. The role of the effective team lead is to recognize the inherent value of each of their team members, to discover the individual gifting of each member, and to help everyone work to their strengths and improve in their weaker areas.

Hubbs has long been an advocate of the “underdogs” in the office. Some of his closest friends and most loyal allies in the industry are people who had been written off by others because of their background or their unfamiliarity with newer technologies. What Hubbs has been able to do is to see where the passion lies in each of these developers, and to help them cultivate their interests and skills so that they can become productive, contributing members of the team. Had he written off members of his team due to their perceived inexperience or incompetence, he would not have the circle of colleagues and teammates that he now calls friends.


(...to be continued tomorrow)


0 comments: