Perhaps the most difficult job to do on any software development project is that of Technical Lead. The Technical Lead has overall responsibility for all technical aspects of the project - design, code, technology selection, work assignment, scheduling and architecture are all within his purview. Positioned right at the border of the technical and managerial, they are the proverbial "meat in the sandwich." This means that they have to be able to speak two languages - the high-level language of the project manager to whom they report, and the low-level technical language of their team. In effect, they're the translator between the two dialects.
Observation suggests that there are not that many senior techies who have the skills and personal characteristics necessary to perform the Technical Lead role well. Of those I have seen attempt it, perhaps ten percent did a good job of it, twenty percent just got by, and the remaining seventy percent screwed it up. Therefore most of what I have learnt about being a good Technical Lead has been learnt by counter-example. Each time I see a Technical Lead doing something stupid, I make a mental note to avoid that same behavior or action when I am next in the Technical Lead role.
What follows is the abridged version of the list of mistakes I have assembled in this manner over the last thirteen years of watching Technical Leads get it wrong. It is my contention that if you can just avoid making these mistakes, you are well on your way to doing a good job as a Technical Lead. You might consider it a long-form equivalent of the Hippocratic Oath "First do no harm," although given the self-evident nature of many of these exhortations, it is more like "First do nothing stupid."
Mistake #0: Assuming the team serves you
Perhaps the most damaging mistake a Technical Lead can make is to assume that their seniority somehow gives them an elevated status in their organization. Once their ego gets involved, the door is open to a host of concomitant miseries such as emotional decision making, defensiveness and intra-team conflict.
I can't emphasize enough how important it is to realize that although the Technical Lead role brings with it many additional responsibilities, it does not put you "above" the other team members in any meaningful sense. Rather, you are on an exactly equal footing with them. It's just that your duties are slightly different from theirs.
If anything, it is you that is in service of them, given that it is part of your role to facilitate their work. To put it another way, you are there to make them look good, not the other way around.
Mistake #1: Isolating yourself from the team
In some organizations, having the title of Technical Lead gives you entitlements that the rank and file of your team do not enjoy. Sometimes, the title is considered sufficiently senior to entitle you to an office of your own, or at least a larger workspace if you must still dwell in cubicle land.
It is a mistake to take or accept such perquisites, as they serve to distance you (both physically and organizationally) from the people that you work most closely with. As military leaders know, it creates an artificial and ultimately unhealthy class distinction between soldiers and officers if the latter are afforded special privileges. To truly understand your team's problems and be considered just "one of the guys" (which you are), you need to be in the same circumstances as they are.
Mistake #2: Employing hokey motivation techniques
Different sorts of people are motivated by different sorts of rewards. Programmers and managers certainly have very different natures, yet it is surprising the number of managers and aspiring managers who ignore those differences and try to reward technical staff in the same way they would like to be rewarded themselves.
For example, managers value perception and status, so being presented with an award in front of everyone, or receiving a plaque to display on their wall where everyone can see it, may well be motivating to them. However programmers tend to be focused on the practical and functional, and value things that they can use to some advantage. Programmers regard the sorts of rewards that managers typically receive as superficial and trite. They have a similar view of "team building" activities, motivational speeches and posters and the like.
So if you want to motivate a developer, don't start cheering "Yay team" or force him to wear the team t-shirt you just had printed. Instead, give him something of use. A second monitor for his computer will be well received, as will some extra RAM, a faster CPU, cooler peripherals, or a more comfortable office chair. It's also hard to go wrong with cash or time off.
Developers are also constantly mindful of keeping their skill sets up to date, and so will value any contribution you can make to their technical education. Give them some time during work hours to pursue their own projects or explore new technologies, a substantial voucher from your local technical book store, or leave to attend a training course that interests them - it doesn't have to be something that bears direct relationship to company work, just as long as it has career value to them.
For example, managers value perception and status, so being presented with an award in front of everyone, or receiving a plaque to display on their wall where everyone can see it, may well be motivating to them. However programmers tend to be focused on the practical and functional, and value things that they can use to some advantage. Programmers regard the sorts of rewards that managers typically receive as superficial and trite. They have a similar view of "team building" activities, motivational speeches and posters and the like.
So if you want to motivate a developer, don't start cheering "Yay team" or force him to wear the team t-shirt you just had printed. Instead, give him something of use. A second monitor for his computer will be well received, as will some extra RAM, a faster CPU, cooler peripherals, or a more comfortable office chair. It's also hard to go wrong with cash or time off.
Developers are also constantly mindful of keeping their skill sets up to date, and so will value any contribution you can make to their technical education. Give them some time during work hours to pursue their own projects or explore new technologies, a substantial voucher from your local technical book store, or leave to attend a training course that interests them - it doesn't have to be something that bears direct relationship to company work, just as long as it has career value to them.
Mistake #3: Not providing technical direction and context
A common mode of failure amongst Technical Leads is to focus on their love of the "technical" and forget about their obligation to "lead." Leading means thinking ahead enough that you can make informed and well-considered decisions before the need for that decision becomes an impediment to team progress.
The most obvious form of such leadership is the specification of the software's overall architecture. Before implementation begins, you should have already considered the architectural alternatives available, and have chosen one of them for objective and rationally defensible reasons. You should also have communicated this architecture to the team, so that they can always place the units of work they do in a broader architectural context. This gives their work a direction and promotes confidence that the teams collective efforts will bind together into a successful whole.
A Technical Lead lacking in self-confidence can be a major frustration to their team. They may find themselves waiting on the Lead to make decisions that significantly effect their work, but find that there is some reticence or unwillingness to make a firm decision. Particularly when new in the role, some Technical Leads find it difficult to make decisions in a timely manner, for they are paralyzed by the fear of making that decision incorrectly. Troubled that a bad decision will make them look foolish, they vacillate endlessly between the alternatives, while their team mates are standing by wondering when they are going to be able to move forward. In such cases, one does well to remember that a good enough decision now is often better than a perfect decision later. Sometimes there is no choice amongst technical alternatives that jumps out at you as being clearly better than any other - there are merely different possibilities, each with pros and cons. Don't belabor such decisions indefinitely. In particular, don't hand over such decisions to the team and hope to arrive at some consensus. Such consensus is often impossible to obtain. What is most important is that you make a timely decision that you feel moderately confident in, and then commit to it. If all else fails, look to those industry figures whose opinions you trust, and follow the advice they have to give.
Finally, always be prepared to admit that a decision you've made was incorrect, if information to that effect should come to light. Some of the nastiest technical disasters I've witnessed have originated with a senior techie with an ego investment in a particular decision, who lacks the integrity necessary to admit error, even when their mistake is obvious to all.
Contd....
The most obvious form of such leadership is the specification of the software's overall architecture. Before implementation begins, you should have already considered the architectural alternatives available, and have chosen one of them for objective and rationally defensible reasons. You should also have communicated this architecture to the team, so that they can always place the units of work they do in a broader architectural context. This gives their work a direction and promotes confidence that the teams collective efforts will bind together into a successful whole.
A Technical Lead lacking in self-confidence can be a major frustration to their team. They may find themselves waiting on the Lead to make decisions that significantly effect their work, but find that there is some reticence or unwillingness to make a firm decision. Particularly when new in the role, some Technical Leads find it difficult to make decisions in a timely manner, for they are paralyzed by the fear of making that decision incorrectly. Troubled that a bad decision will make them look foolish, they vacillate endlessly between the alternatives, while their team mates are standing by wondering when they are going to be able to move forward. In such cases, one does well to remember that a good enough decision now is often better than a perfect decision later. Sometimes there is no choice amongst technical alternatives that jumps out at you as being clearly better than any other - there are merely different possibilities, each with pros and cons. Don't belabor such decisions indefinitely. In particular, don't hand over such decisions to the team and hope to arrive at some consensus. Such consensus is often impossible to obtain. What is most important is that you make a timely decision that you feel moderately confident in, and then commit to it. If all else fails, look to those industry figures whose opinions you trust, and follow the advice they have to give.
Finally, always be prepared to admit that a decision you've made was incorrect, if information to that effect should come to light. Some of the nastiest technical disasters I've witnessed have originated with a senior techie with an ego investment in a particular decision, who lacks the integrity necessary to admit error, even when their mistake is obvious to all.
Contd....
No comments:
Post a Comment