Key traits of a software leader - Dedication, Love for Mentoring, Balance and Perspective

• Dedication

Leaders and senior developers often know what to do, without the need for external direction. Of course you must do what your manager asks of  you, but once you start on it, you should usually be able to complete the task without requiring management oversight. Are the requirements clear and complete? If not, find out who to talk to get them clear and complete. If you can't get clear requirements from the prodouct owner for this task, come up with your own clear and complete requirements (written or in the form of tests) and then give these to the product manager or manager as a starting point. Hold a meeting with the stakeholders and leave with the requirements clarified. Take a similar approach for every other aspect of the delivery. Push for answers you need, make proposals along the way, always get buyin from others of the team, and don't be afraid to hold meetings when email, issue tracking systems, or other communication mechanisms fail you. Ensure that requirements end up in a written form that is signed off on by all stakeholders.
Whether it's the near-term objectives of a sprint or longer-term objectives, a leader is strongly invested both in his/her own commitments and in the teams' commitments. Are others on the team in need of your help? How can you ensure the success of the entire team? Like everyone on the team, leaders will put in extra hours during legitimate "crunch" times to meet important milestones. This does not mean that you should be expected to work 80 hour weeks ad infinitum. Learn when it is truly important to put in the extra hours and when it is unreasonable. If you are like many developers, you enjoy your work enough to want to put in longer hours. Instead of putting in an 80 hour week for your current sprint, consider spending time learning on your own and/or playing around with new technologies if not in a crunch period. This is also important to the team, as you can bring what you learn to the table to help in design of future corporate initiatives.

• Love for Mentoring

One of the most rewarding aspects of working on a development team can be the opportunity to help with the growth and learning of others on your team and teams you work with. There are many aspects to mentoring. Consistent application of the traits described in this blog series on leadership alone is a good way. From an early age on, people emulate the behavior of people they respect. Find other ways to personally connect with individuals on the team. Choose one or two on the team who are most engaged with you and work closely together. Often this will be more junior people on the team, often you will select people who show the most promise, but neither of these is a requirement. Remember that anyone with more experience in any one area can act as a mentor for anyone else in that area. You could easily end up helping someone older or with more overall experience, but less in one or more specific areas. Lastly, there are always opportunities to find others to help mentor you. Nobody is ever done learning and there are always people to learn from, whether on your team or externally. Try to spend as much time finding people whom you respect in an area you would like to grow in as you do in trying to find others who can learn from you.

• Balance and Perspective - Understanding of when and how much technical debt to accept

In constant conflict with your goal of delivering personal excellence will be the organization's need to deliver software in a timely fashion. A true leader will understand enough of the market dynamics to know when it is appropriate to "rush a solution" and when the constraints are artificial.
Organizations tend to constantly apply time pressure. You should understand when there is a true market force for a rush and when it is self-imposed by the organization. A clear-cut example of a true market need is delivery of software to a hardware product timeline owned by another organization or company. If there is a true market need, often you will be forced to create some "technical debt" and deliver software that is not as well written as you would like. In these situations, a leader will still strive for quality and test coverage in the solution, and sacrifice architectural and/or design integrity. In other situations, the time pressure may be internally-driven. You should act as the code-base custodian. Make sure that management understands the trade-offs of technical debt for this decision and weighs its long-term supportabilty costs. Importantly, a code-base custodian looks for appropriate times when external pressures are not as high to lobby for an investment in paying down technical debt from previous "rush jobs".