Leadership in software development allows people of different backgrounds and levels of experience to work together efficiently. Strong and careful guidance can pull a group of individuals together into a cohesive and effective team.
I have experience in leadership roles including work as lead engineer and application architect. My skills in leadership include:
I think that leading people includes offering them a vision, a big picture of where they are going. If we can communicate the "why" of the project--the business goals, the technical goals--people are more likely to join in. It's a bit like the analogy of building a cathedral: craftsmen worked harder, and with more dedication, knowing that their work on a small part of the building was part of the larger goal of building a great cathedral. A good leader offers a vision that inspires the group and gives them a common goal, a goal outside of themselves, to focus on. And in focusing on that goal, people are more willing to set aside their differences and work together.
At the same time, every individual on a project has some right to see their own personal aims achieved. A good leader will find opportunities to allow each person to find means for growth within the project as a whole. A leader seeks to have the individual serve the larger goal, while finding their own fulfillment and growth. As the developer works towards their own goals, they will work harder towards the project's aims as well: they will give more of themselves. So finding this balance, between the needs of the project and the needs of the individual, is part of the task of leadership.
I've worked as a team lead on several projects where we had a range of skills amongst team members. Some groups included CS students fresh out of college along with 20-year programming veterans. What I've found is that, borrowing the terms of a programmer/teacher I knew, every programmer has an area of comfort, and an edge. The trick is always to have assignments that fall within the area of comfort, and rub up against the edge.
Our "area of comfort" includes those tasks where we feel strongly capable of succeeding. We can tackle those tasks with confidence, and be pretty certain of a positive outcome. Within our area of comfort, we feel empowered in facing problems, and satisfaction on completion, at showing once again that we can handle them.
Outside our area of comfort is the "edge", those problems which we may be aware of, may have touched on, but which we feel challenged and perhaps uncertain. The edge is not completely outside of our domain, it's just the most difficult part, which we have the least experience with.
When leading a project, I think one has to assign tasks both within a programmer's area of comfort, and also at their edge. That way, programmers will feel empowered, capable, strong--and proud at contributing value to the group's effort. At their edge, programmers will feel challenged, engaged, interested--and trusted by their lead to take on something new.
I find that publicly praising people for their successes is a good idea. If an assignment fails in a big way, I find it's usually better to re-assign it with little fanfare, or to bring more experienced help to the task, than to air the problem out in public. When necessary, it's better to talk about problems with someone's work in private rather than in public. On the other hand, if team members are disrespecting each other, that should be called out and spoken against publicly, to set a strong message that it's inappropriate.
It's part of our job as leads to encourage polite behavior. It creates a better, more pleasant atmosphere to work in.