My first year as a Lead Developer was quite the ride. I have made some mistakes, but I have also gotten many things right. In this article, I will share some of the dos and don'ts of being a lead developer based on my experiences this past year.
Your shiny new role
It is easy to get caught up with the added responsibility and especially with the shiny new title of "Lead Developer". That was me at the beginning of my journey. I carried an immense sense of pride and my ego was inflated. I guess this is human and will happen to most people. However, you can stay mindful of your behaviour and identify situations in which you acted or are about to act egotistical.
Luckily, after some time the "shininess" of the role will fade away and you will in the best case become more level-headed. The speed of this process depends on the overall culture of the company you work for I would say.
Taking on this new role is intimidating in the beginning. You look at other lead developers and see high-performing leaders who seem to never get anything wrong. And then there is you who has just started this role. In the beginning, you might feel small, not cut out for the role, or like you never will be as good as other lead devs. This problem is very common in the software engineering space, even for regular developers. This is a hard pill to swallow, but yes, there will most of the time be someone better than you. What is important is to focus on your journey, steadily improve, and do the best job you can, because if you do that no one can hold anything against you.
Don't worry your confidence will slowly increase over time. For me, it came in waves for most of the year but in the end, my confidence solidified and I now feel up to the task.
I have briefly explained this concept in my blog post about onboarding. There is a time and place for criticism, but going overboard with it can have detrimental side effects. You can single-handedly destroy your team's spirit and make yourself an unpopular leader very fast.
As a leader, you must be able to admit to your shortcomings and always have an open ear for criticism. This will enable you to grow exponentially in your role. It can be hard at first since there is pressure on you to get things right and some things rely on your performance.
Some people may use humility and humbleness synonymously. But you don't have to be humble. Be confident and have pride in your role! I know this sounds contradicting to the first section of this article. However, the crucial thing here is to still have humility, because it gives you the ability to grow and learn.
This cuts into the next point.
Taking one for the team
In the same way, you have to show humility for your errors, you also have to take responsibility for your team's shortcomings. I think this is one of the hardest and most uncomfortable parts of being a leader. But you want to lift as much pressure off your team as possible, so it performs better, but subsequently put the pressure on yourself. Because of this, you must have high resilience and stress resistance for this job.
This also goes for asking management for "wishes" on behalf of the team or individual team members. Be the one who takes the initiative for your team.
Additionally, you face an interesting challenge as a lead developer. On the one hand, you have to lead a team of developers and on the other hand, you also have to perform as a developer yourself, especially regarding finding new ways of doing things, prototyping, etc. This will truly show if you are cut out for the role. Because if you neglect either one of the mentioned challenges, you are not doing the job properly in my opinion.
What you can do however is prioritize one or the other for periods. Let us say you have a very important release coming up. In that case, you would prioritize making your team as productive as possible, but also code yourself, the latter of the two probably taking a big part of your resources. As you can see, in this scenario none of your responsibilities is truly neglected, the software development part is just prioritized. This works the other way around as well. Say there is a period when not much is going on. Instead of relaxing like some of your team members might do, you focus on self-reflection, finding new ways of doing things and fixing bottlenecks in the development process. Here most of your development resources go into prototyping and you fulfil your leadership responsibilities by looking for new ways of doing things.
So in conclusion, be the hardest working in the team, initiator, and take those Ls.
Praise, Inspire, Motivate
As development lead, you should set the tone. Your team should be able to learn from you and be inspired by you to perform at their optimum. I overlooked this fact for a long time. If I check my phone every ten minutes while working, what example do I really set? If you want your team to perform at its best, you have to strive to perform at your best first and show them how it is done. I think this is a really cool aspect of being lead.
Next to "passively" inspiring your team, you should also do it actively. Shower them with praise for their efforts and show them that you are proud of their achievements. If you lead a scrum team the sprint review/demo is the perfect opportunity to lift individual team members up and proudly present what they have worked on in the last sprint.
Lastly, you should also be the one who keeps motivation in the team high. You can achieve this by repeating why you are working towards a certain goal. Make it clear what the long-term implications are if you are planning on implementing a change that requires a lot of effort on the team's end such as writing documentation.
Naturally, you have to make moves as development lead. A critical view of the development process and other processes, even when things are running smoothly, is a valuable asset for the company and crucial for long-term success. Proactively look for improvements and work on a plan to implement said improvement. This can be done with prototypes or a demo for a new tool. What has really helped me with this is a "Just do it" attitude for prototyping and utilising new tools, no matter the outcome, because you will have a much easier time selling the adjustment you want to make to your team and upper management if you have already built something that works.
Learn from others
I will keep it brief for the last "do". Learn, learn, learn. Read books on leadership and communication and keep up to date with the tech sector. For leadership, I can highly recommend reading and listening to Simon Sinek's work.
To be a lead developer, you have to be great in many different disciplines and be resilient. Many things can go wrong. Nevertheless, as intimidating as the role sounds, it is a worthwhile and fun step up from being a regular developer. I can only recommend it if you have the opportunity.
Did you find this article valuable?
Support Diego Schleis by becoming a sponsor. Any amount is appreciated!