Some people simply don't have the natural proclivities necessary to be good Technical Leads. It's not enough to have good technical knowledge. You must be able to communicate that knowledge to others, as well as translate it into a simpler form that your management can understand.
You also need good organizational skills. Coordinating the efforts of multiple people to produce a functionally consistent outcome is not easy, and demands a methodical and detail-oriented approach to planning and scheduling. If you can't plan ahead successfully, you will find yourself constantly in reactive mode, which is both stressful and inefficient.
If you don't have these qualities naturally, you may be able to develop them to some extent, through training and deliberate effort. But it may ultimately be necessary for you to lean on others in your team to support you, should they have strengths in areas in which you have weaknesses.
Mistake #9: Failing to represent the best interests of your team
Perhaps the most nauseating mistake a Technical Lead can make is to become a puppet of the management above them. As the interface between management and technicians, it is the Technical Lead's role to go into bat with their management to represent the best interests of their team. This means standing up to the imposition of unreasonable deadlines, fighting for decent tools and resources, and preventing the prevarications of management from disturbing the rhythm of the project. A weak-willed or easily manipulated Technical Lead will incur the disrespect of his team.
Unfortunately, such spineless behavior is quite common amongst the ranks of the ambitious, and you don't have to look far to find obsequious Technical Leads who will gladly promise the impossible and impose hardship on their team, in the interests of creating a "can do" image for themselves.
Mistake #10: Failing to anticipate
An essential part of the Technical Lead's role is keeping an eye on the "big picture" - the system-wide concerns that are easily forgotten by programmers whose attention is consumed by the coding problem they currently face.
These "big picture" issues include those non-functional requirements sometimes called "-ilities" - maintainability, reliability, usability, testability and so on. If you don't make a conscious effort to track your progress against these requirements, there is a high probability of them slipping through the cracks and being forgotten about until they later emerge as crises.
If you don't have a dedicated project manager, it may also fall to you to handle the scheduling, tracking and assignment of tasks. It isn't uncommon for Technical Leads to find themselves playing dual roles in this manner. You may not be very fond of such "administrative" duties, but their efficient performance is critical to the smooth running of the project, and for the developers to know where they are and where they're going. Don't make the mistake of ignoring or devaluing these tasks simply because they are non-technical in nature.
Mistake #11: Repeat mistakes others have already made
It is common for developers to dismiss the experience reports of others as having no relevance to their own situation. Indeed, it is wise to approach all anecdotal evidence with skepticism. But it is unwise to completely disregard the advice of others, particularly when it is accompanied by sound reasoning, or can be independently verified. Ignoring good advice can be very expensive; it is said that "Experience keeps a dear school but fools will learn in no other."
The unwillingness of developers to learn from the mistakes of others, and the ease with which you can encounter software project horror stories in the literature and recognize your own projects in them, is evidence suggesting that the software industry as a whole is not getting any wiser.2 You need not contribute to that collective stupidity.
Mistake #12: Using the project to pursue your own technical interests
Remarkably, developers can reach quite senior levels in their organization without having learnt to appreciate the difference between work and play. Many are attracted to programming to begin with because, as hobbyists, they enjoyed fooling around with the latest and greatest technologies. Somehow they carry this tendency to "play" with technologies into their working lives, and it becomes the aspect of their jobs that they value most. From their perspective, the purpose of a development effort is not to create something of value to the business, but to create an opportunity to experiment with new technologies and pad their CV with some new acronyms.
Their technology selection is based upon whatever looks "cool". But a rational approach to technology selection may yield quite a different result to one guided by technical enthusiasm or a fascination with novelty. New technologies are often riskier choices, as the development community has not had much time to apply the technology in varying circumstances and thereby discover its weaknesses and shortcomings. Putting an immature technology on a project's critical path is especially risky. So an older, tried and true technology may be a more rational choice than a new, unproven one.
Mistake #13: Not maintaining technical involvement
In order to fully appreciate the current status of the project as well as the difficulties your team is facing, it is vital that you maintain a coding-level involvement in the project. If you're not cutting code, it is too easy to become divorced from the effects of your own decision making, and to be seen by other developers as being out of touch with the technical realities of the project.
Contd...
No comments:
Post a Comment