Being a technical leader can involve a number of challenges. Between outside forces, long- and short-term pressures, legacy systems, and complex problems an architect, lead developer, or development manager has a lot on his plate.
Many of the most skilled programmers are comfortable with those kinds of challenges. For a lot of technical people that's the only kind of problem with which you are comfortable. Whether, like me, you are arrogant and demanding or, like many others, you are shy and reserved, there is a decent chance that you don't count people skills among your strongest.
Yet the technical challenges only represent half of the problems facing a technical leader. To be truly effective, you have to be a leader of people in addition to a setter of technical direction. That is, unless you want to do everything yourself.
I'm not saying that every kind of management problem necessarily rests on the shoulders of a technical leader. I do believe, however, that empowering the people you work with to make better technical decisions on their own will have an enormous impact on your effectiveness as a technical leader.
For instance, I recently wrote an article for InformIT that touches on the subject, entitled Five Ways to Optimize Encapsulation in Your Software Architecture. In most scenarios, every single step requires someone to not just be a leader in the area of design and architecture but also a leader of men.
For me, this is the biggest kind of challenge available in the software world. It's hard and rewarding. Sure, there are things that are harder - like trying to maintain really terrible legacy code - but those things aren't as rewarding because so little is accomplished in exchange for so much energy. There are areas where I have more success - like maintaining code that was written the modern way - but that's not as rewarding because so little energy was exchanged for the benefit obtained.
Building up people's skills, guiding them, helping them grow, and influencing their decision making meets all my challenge criteria. At least, it does now that I've become interested in that level of challenge. It requires patience, understanding, and a close approximation of empathy - things that don't come easily to me. On the other hand, in exchange for the enormous effort involved, you get enormous value.
The worst likely case is that you fail and nothing happens. In the software industry, that's actually a pretty good bad scenario. Once you develop your mentoring and leadership skills, the most likely case is that you will permanently modify how effective someone is as a programmer, building up a portfolio of recurring dividends over time. Sometimes, you will help someone else become a true technical leader, improving the rate at which dividends are increased.
The rate of return on this kind of effort is very, very high. For most of us, there's nothing more rewarding than hard work with a high rate of return. So, the next time you're considering your position as a technical leader, try to think about how much time you spend leading people not just products.
