"Lead Developer" - now that would look good on a business card.
Most developers I have worked with have all been striving after this title. But, many see the word "Lead" and stop reading there. Based on this, the idea is conjured up that a lead developer will command their team, revolutionize the technology stack and code 75% of the tickets. Meanwhile, others think it's about being a bridge between development and other groups - representing their vision for the company, and communicating their concerns.
Simply put, there is a lot of confusion about who a lead developer is and what exactly he or she does.
Recently some developers have approached me asking what it takes to be a lead developer. In their mind, they are already there. In their mind, they ship quality code, push the team forward and introduce new technology. What more could you want?
Rather than focusing on specific actions that you'll be performing, it's far better to focus on attributes you should develop to be a lead developer. The reason is that actions are difficult to measure their effectiveness. Sure, you may feel your ignored suggestions would transform the company but are you in touch with broader business contexts? When reaching out for a promotion, be mindful about coming from a place where you're already there. You may well not be (and that's ok!).
Build the attributes below, and you'll be promoted in no time.
- Communicate effectively. In the era of remote work, communication is everything. Aside from the obvious, not complicating a topic, sticking to the agenda and choosing clear words, there is another crucial element of good communication. Translation. Not from Hebrew to Maltese but from non-technical teams to technical teams and vice versa. As a lead developer, you play a vital role in helping both teams work together cohesively. A good measure of this is how much one team hates the other - the less, the better! Doing this translation work also comes with being able to listen (yes, communication is both speaking and listening) to stakeholders about wider business concerns and use them to inform technical decisions.
- Take responsibility. As Uncle Ben (spiderman's uncle, not the bloke who sells microwave rice) would say, "with great power comes great responsibility". As the team lead, you are responsible for how well the technical staff under your care perform. It is your responsibility when something goes wrong, even if it's not your fault. Your job is chiefly to make your team look good, not yourself. Building responsibility helps prove that you're ready to shoulder people problems.
- Be principle and process driven. There is no exact playbook for each situation that will arise as a lead developer. But by being principle-driven, you will always know what to do. And processes will form the basis of consistent actions across various decisions. For example, by taking the lead in incident postmortems, you will help develop the principle of transparency and discovery.
- Trust others. You don't know everything, and you can't know everything. And that's good! It makes humans interesting and gives different perspectives. When you don't know something, don't be afraid to empower someone on your team who does. Trust them, and ask questions to learn more about what they know.
- Trust yourself. As a lead developer, there should be a lot of knowledge you do have that your team needs. Don't be afraid to mentor them and teach them everything you know. Rather than reducing your job security, you'll get a better relationship with your team and improve the quality of the team's work.
Lead Dev or Bust?
Junior dev, mid-level, lead developer. Job done. Right?
I used to think so.
But it's really not as simple as that path. Rather than taking "upwards steps" into management, you can take horizontal steps. If you're a web developer, look at DevOps, Security engineering, site reliability engineering and solutions architecture. Because of the complexity of modern-day systems, there are so many technical roles now.
Management might not be for you. It's not for me. I got bored of managing people directly, doing 1-to-1's, and sitting in planning meeting after planning meeting. I wanted to code, write, read about cool tech and create automated tools. It might not be for you, either.
Having said that, we can all use the principles outlined above. Developing them will lead to being better engineers and improve teamwork.