Honing your technical skills as a team leader

There are two distinct aspects of your job now, each with its own set of responsibilities: technical and managerial aspects. And both aspects are important – if you try ignoring one over the other, you will cause problems. A team leader who focuses only on the managerial aspect of the job will have a hard time understanding what their team is working on. The opposite is maybe even worse: those who focus only on the technical side of things could compromise the stability of the whole team. This problem is something that many people in leadership positions are facing. 

And, while this article focuses on how to address this problem from the perspective of a software engineer, it should be noted that the problem itself is not exclusive to the IT industry – it can be found in many different professions. 

So, it’s obvious that the key to success is balancing these two aspects. Their ratio will fluctuate over time depending on priorities (and some other factors as well), so you need to stay flexible and pay attention to how you spend your time. However, software development as an industry keeps changing and developing all the time, so you must still stay in touch with technology. You should not remove yourself completely from the process of making software, but once you become a team leader you will have less time to do it. This is exactly why you must maintain an engineering mindset. 

Keep in mind that having an engineering mindset is a bit different from just coding. Coding is just one part of the equation – one of the activities that will help you in maintaining an engineering mindset. There are several other tools at your disposal, and we will provide several suggestions with the descriptions below.

Write some code

Let’s start with the most obvious approach. As we already stated, due to the nature of your work, you will write a lot less code, but you should still write some code. Because of that, the nature of the tasks that you work on must change. You should not work on the most critical and the most interesting tasks. Leave them to your team members (unless there is no other way). Your other responsibilities can (and will) get in the way if you start working on something complex. And if it’s also a high-priority task, it will make the situation even worse. Not to mention stealing the spotlight and learning opportunities from your team members by choosing the most interesting things for yourself. 

The solution to this is to work on smaller, non-critical tasks (and try to do so regularly). This will have several positive effects: your skills will not deteriorate, and your team will see that you don’t shy away from doing the work (which is very important).

Code reviews

Besides writing code, reading other people’s code can be another good way to “stay in shape”. Code review is not only about providing feedback on someone else’s work – it’s also about you learning how others work. By participating in code reviews, you will be exposed to new ways of doing things (like different approaches to solving certain problems), usage of new language features, libraries or frameworks. 

However, you will also be able to observe the work habits of your team members and the way they approach designing software. For example, you might notice that many pull requests are large and complex, or that your team members repeatedly don’t follow best practices or the coding style. Then, you can react and, together with your team, make some adjustments.

Participating in technical discussions

There will be many technical discussions between your team members. You probably don’t need to participate in every single one of them because you simply don’t have time. Also, you want to trust your team members so that they can solve a lot of issues on their own. However, there are some discussions that you should be a part of. For example, if your team is designing a new service, making some major architectural change, trying to address some serious performance issues, or doing anything that can have system-wide impact – you should participate. 

Sometimes, you might need to change the course of the discussion if the team strays too far, or you could be the person with the most experience in the specific domain and you can provide some very helpful feedback. However, the most important thing is that you want to observe how your team is approaching designing things and participate in the process yourself. Remember what we stated at the beginning of this article: you should not remove yourself from the process of making software. Technical discussions are an integral part of that process, so don’t ignore them.

Writing documentation

Writing documentation is one part of the software development process that is often neglected, for various reasons (usually, due to not having enough time to write documentation). However, good documentation can help your team in multiple ways; likewise, the lack of documentation can hurt your team. This is exactly an area where you, as a team leader who must carefully balance multiple responsibilities, can help (and at the same time, still maintain an engineering mindset). 

Because writing documentation can quickly spiral out of control if you are not careful, try to figure out what is the absolute minimum. Here is a list of ideas:

• Add a brief description of each service to its corresponding repository, together with a list of important interactions/use cases or remote systems it communicates to.
• Create manuals for building and deploying your applications (so anyone in the team can do it). Document all activities that are critical for your software development lifecycle. There are things that everyone in the team should know about – so make those things visible.
• Cover the most important configuration settings for each environment and instructions on how to access important tools/services.
• Create documents that describe what to do in case of an incident (for example, how to restore database from a backup)

By writing documentation, you will have to do some research or talk to people who are knowledgeable about the chosen topic (possibly both), which in turn will expose you to various types of technical information.

Doing research

As a team leader, you will have to pay attention to what your team will be working on next and plan accordingly. Sometimes, that could mean doing some research (for example, to discover the best approach to building a new feature). 

Research tasks are one of my favourite suggestions on this list. They are giving you the best of both worlds. On one hand, you will be working on something interesting and using your technical skills. On the other, you are also laying down the groundwork for something that your team will have to focus on soon. They can take many shapes and forms: reading various sources, investigating integration with the new API, trying out a new library or framework, designing a new service, etc. 

This means that there are many opportunities for learning new technologies or for working on something interesting (that is very different from the type of tasks that your team usually works on). Also, once you complete the research, it could serve as a great starting point for a technical discussion with your team.

Being involved in system monitoring

If you work in an environment that has an on-call management strategy, this could be a great option. Yes, on-call might be stressful – no one likes being woken up at 3AM because there are production issues. It also means you’ll have to familiarise yourself with tools that are used for monitoring, logging and alerting. However, if engineers in your team are expected to be part of the on-call rotation, then you simply must participate, because not doing something but expecting your team members to do so is a sign of very bad leadership. 

But once you look past the inconvenience, this will be a great opportunity to learn a lot about the system and how it works (because you won’t be able to help with resolving production issues and outages otherwise). Not only that, but you will have the opportunity to work on improving monitoring, alerting and overall system stability – and your team will benefit greatly from this. This hands-on approach will (likely) require you to learn about incident management, which is an important skill for anyone in a leadership position. 

Conclusion

Keep in mind that you should look at this list as a list of ideas – not as a rule of law, set in stone or written in blood. There are also other approaches that we didn’t cover here; we focused only on the most common ones or the most impactful ones. 

When it comes to maintaining an engineering mindset, it is important to understand that there are multiple tools at your disposal. Depending on your responsibilities and the time that you have, you might be able to participate in each of the listed activities, which is great. However, often, you won’t be able to do that – instead, you’ll have to choose the approach that is the best for you at that time. Sometimes, you’ll write some code; at other times you could be doing research or participating in system monitoring. 

Regardless of the number of things you do, the most important thing to remember is that you must do something and be consistent with it – because all those things you do will contribute to one goal: expanding your technical knowledge and skills further.

---

Author

Miroslav Lazovic is an experienced software engineer from Belgrade. Over the past 15 years, he worked on many different projects of every size – from small applications to mission-critical services that are used by hundreds of thousands of users on a daily basis, both as a consultant or part of the development team.

Since 2016, he is focused on building and managing high-performing teams and helping people do their best work. He likes discussing various important engineering and management topics – and that’s the main reason for this blog. Besides that, Miroslav has quite a few war-stories to tell and probably far too many books and hobbies. There are also rumors of him being a proficient illustrator, but the origin of these rumours remains a mystery.

– Backend TL@Neon and Dev. Advocate @Holycode