Like many other people, I fell into a lead developer role, mainly because I found myself part of a team that had no leader. The idea of self-organising teams makes a lot of sense to me, but I think that people need, or at least want, leadership, and that social dynamics generally tend towards a leader emerging within most groups. Lately my Twitter feed has seemed to contain lots of people talking about what defines a senior developer and their role, and it got me wanting to figure out my own thoughts on the subject.
As I’ve previously written, job titles are a curious thing, but there’s something particularly odd about the word “senior”. It’s certainly true that it makes a difference to the way that people perceive you and your employability. This isn’t just true for developers - a designer colleague reported a significant increase in LinkedIn spam from recruiters immediately after including the s-word in her job title.
There are different types of leaders, and I’ve been lucky to have worked with some excellent ones in my career so far. I’ve also worked with some less inspiring leaders, but that’s another story…
Some of the lead developers I’ve worked with have been technical experts who knew their stuff inside and out. Others have been more like project managers, making sure that the team is keeping on top of the backlog. Some are like sports captains, motivating the team through exhortation or example.
Here are some of the qualities that I think make an effective lead developer.
Confidence
Sometimes the team needs someone to say “yes we can do this”, to help them believe in their own abilities. Other times, they need someone to say no, to protect the team from unreasonable requests. Either way, the leader needs to have the strength of character to stand up and make a statement; to say that something will happen, and have the commitment to see it through.
Honesty
Perhaps this isn’t specific to leaders, and it may be obvious, but teams work better when there’s trust and openness.
Humility
Everyone gets it wrong sometimes. How a person reacts when they realise they’ve made a mistake is an important measure of their character. Chris Hartjes recently put it well on Twitter when he talked about the importance of “learning to let go of the desire to always appear right”.
Supportiveness
Something that goes along with humility is the ability to not try to be a hero. Leaders should share knowledge and help other members of the team to build their skills. Especially if the team includes more inexperienced members, it’s enormously valuable for a lead developer to be willing to spend time helping colleagues to learn. Part of that is often about giving team members enough space to do the work themselves - it’s important that leaders let their team-mates gain their own experience. Leaders shouldn’t micromanage, and they shouldn’t be backseat drivers.
Experience
It may seem facile to say it, but there is a lot of value in having been there and done that, and not being fazed by whatever might be thrown at you next.
Calmness
As Rudyard Kipling famously put it, you should try to keep your head, even if others are losing theirs. At the risk of repeating my previous point, it’s important for a leader not to panic. If a team is struggling, and the politicians are jumping up and down and talking about escalating issues, the lead developer needs to remember that it takes much longer to fix the mistakes that will be caused by rushing than it does to do slow down and do the job properly. Trouble is, sometimes it takes longer to explain that point to a project manager who’s getting grief from all sides.
Big Picture Thinking
All too often, developers plough their own furrow, getting on with the job without considering the tasks in the wider context of the business goals that they relate to. Too few developers value the ability (and desire) to think about the why as well as the how of the project. Similarly, it’s all too easy for a developer to start building things without adequate consideration of edge cases and exceptions - an effective lead developer will look at a project from a lot of different angles.
Common sense
It’s important to know what the team is capable of, and to make sure that targets are sensible. Too many people in the tech industry talk about impostor syndrome and its inverse twin Dunning-Kruger, but clichés arise because everyone notices the same truths. Having a realistic awareness of the team’s strengths and weaknesses goes a long way.
Political nous
Many developers like to think of themselves as somehow above all the nonsense, that they are purely engineers who don’t need to sully themselves with the messy realities of human interaction in a corporate environment. But messages need to be told in a certain way if they’re going to be heard. Especially when the only way to get the stakeholders to pay attention is by getting them in a meeting together. Yes, some meetings are toxic, but sometimes they are necessary, and when you’re in them, you need to behave in a way that means people will listen to you.
Leadership
Again, it may seem facile, but there is something of an X factor when it comes to being able to motivate a team to get the thing done. In short, a good leader is a good leader - someone whose leadership is accepted and supported by the team, and who helps the team to succeed.
All of the attributes I’ve mentioned go to making an effective leader of development teams, but I’m sure that there are other important qualities I’ve left out, both interpersonal and technical. Please share your thoughts in the comments.
