Mistake #14: Playing the game rather than focusing on the target
In some organizations, being a Technical Lead is a politically sensitive position. Technology choices, work assignments and project outcomes are all just tools to be used in the pursuit of personal agendas. To some, this "game" of political influence is both fascinating and addictive. They play it in the hope of gaining some advantage for themselves, and do so to the detriment of the project and the individuals upon it. When they don't have their eye on the ball like this, devoting more energy to Machiavellian maneuverings than to the technical difficulties of the project, then the project inevitably suffers.
Mistake #15: Avoiding conflict
Many people find interpersonal conflict distasteful. Some dislike it so much that they will do practically anything to avoid it, including giving up in technical disputes. Such people are prone to being walked over by those more aggressive and forthright.
This is bad enough for the individual, but worse if that person is meant to be representing the best interests of a team. A meek Technical Lead can be a real liability to a development team, who will find themselves buffeted about by external forces that they should have been shielded from, and burdened by demands and goals that are not informed by the project's reality.
With such a disposition, a Technical Lead may be unable to even deal effectively with unruly behavior or inadequate performance from members of their own team.
Mistake #16: Putting the project before the people
It's one thing to be focused on the project's goals, but quite another to adopt a "succeed at all costs" attitude. Ambitious Technical Leads, concerned with the image they project to their management, sometimes accept impossible goals or unreasonable demands, because they lack the courage or integrity to say "no." These goals then become the development team's burden to shoulder, leading to increased stress, higher defect injection rates, longer working hours and lower morale. There is a tendency to be so focused on the end goal that the effects of the project on the developers gets overlooked. It is not uncommon for successful delivery on a high pressure project to be followed by the resignations of several disgruntled team members, making the project's triumph a pyrrhic victory indeed.
Given the costs of hiring and training staff, treating developers as expendable resources makes no financial sense, quite aside from the ethical implications of such treatment. A wise Technical Lead will know that putting the well-being of the developers first also produces the best results for the project and the business. Project success should leave the participants satisfied with their achievement, not burnt out and demoralized.
Mistake #17: Expecting everyone to think and act like you
Being a Technical Lead may be the first time you are exposed so frequently and directly to the problem solving styles and low-level work habits of others. Programming is traditionally an individual activity. Programmers are often able to face the technical difficulties of their work in isolation, emerging sometime later with the completed solution. But as a Technical Lead you will frequently be called on to help those who are stuck part way through the problem-solving process, unable to proceed. Seeing a solution that is "under construction" might be a bit of a shock to you at first, as you may find your colleagues approach to problem solving dramatically different to your own. Some people work "outside in", others "inside out", others jump all over the place, some work quickly with lots of trial and error, others slowly and methodically. It is tempting to stand in judgment of approaches and methods that don't gel for you, pronouncing them somehow inferior. Avoid the temptation. Learn to accept the varieties of cognitive styles on your team, and recognize that this cognitive diversity may actually be an asset, for the variety of perspective it brings.
Mistake #18: Failing to demonstrate compassion
Although I've put this last, it is in some ways the most important of all the mistakes listed here. Always remember that your team members are people first and programmers second. You can expect them to be temperamental, inconsistent, proud, undisciplined and cynical - perhaps all in the same day. Which is to say they are flawed and imperfect, just like you and everyone else. So cut them some slack. Everyone has good and bad days, strengths and weaknesses; so tolerance is the order of the day.
If someone breaks the build, it's no big deal. If a regression is introduced, learn something by finding out how it got there, but don't get upset over it or attempt to assign blame. If a deadline is missed, stand back from the immediate situation and appreciate that in the grand scheme of things, it really doesn't matter. Mistakes happen and you should expect your colleagues to make many, as you will surely make many yourself.
References
- Becoming A Technical Leader - G. M. Weinberg, Dorset House, 1986
- Facts And Fallacies of Software Engineering - Robert L. Glass, Addison-Wesley, 2003
No comments:
Post a Comment