I recently started thinking about the role of techlead, after all today I occupy this role and I would like to share here some of my reflections on what it means to be a techlead.
I read an article on quora quora which really caught my attention, and was the reason I decided to write about it and I will take the opportunity to quote part of the text:
A Tech Lead is by definition, someone who is too good to be “just” a programmer, but not good enough to be more than a programmer. Once, you get there, you are parked in this halfway house of being part manager who isn’t management, and part architect who isn’t the architect. You stay there, until you build your skills far enough to move to what you are really good at.
I found this definition interesting, as did the entire article, and I would also like to leave my comment on the issue.
What is a techlead
The definition certainly can and will vary from company to company, as each company can adopt this position in the way that suits them best. In my opinion, being a techlead is not having the role of techlead, but rather having the title of techlead, something like being a knight, you know (a beautiful comparison).
As it is not a position but a title, there is no differentiation between a specialist and a techlead in salary matters, but that is where the big deal lies. Because it is a title it means that if we are not consistent this title can and will be taken from you. But so far we haven’t reached the responsibilities of a techlead.
A TL is someone who is very technically competent, but also has a very interesting personal profile and a certain group of soft skills. These skills allow techleads to help the manager to micromanage the teams, but not in a bad way. I say bad, because micromanagement is often harmful, and we end up feeling as if there was a nanny managing us all the time, but that’s not the point. This micro management actually allows the TLs who are part of the squads to monitor and check possible personal problems in these squads. Sometimes, some members are having personal problems, or relationship problems between team members that go beyond the technical scope, but that should be managed normally by the manager, however the manager cannot manage so many people at the same time (admit it, it is impossible manage a group of 40 people knowing exactly what is happening to each one) and that’s where TLs come in. We monitor our squads and identify deviant behavior, and we act accordingly, calling that colleague for an informal conversation in a cafe, first identifying what is happening.
This is very important, because as we are his colleagues, his peers, we can more easily understand any difficulties, and sometimes it becomes easier for him to open up to you than to his manager. As soon as we identify what is causing the disturbance, we try to act, as far as possible by advising and guiding these colleagues. This autonomy is granted to us by managers because they trust us and know that we are capable of managing this type of crisis. If the situation is beyond our limits, we then pass the situation on to the manager who has the power to act and assist our colleague.
Note that it is important to be aware of your environment at all times, which ends up consuming part of our time with this management, but without being managers per se.
Of course, it is also our role to help the members of our squad and our entire team in any technical difficulty. We serve as strengths and sources of knowledge, and sometimes (mostly) we don’t have the knowledge to solve the problem, but we usually end up having methodologies that help us understand the scope of the problem, evaluate and give feedback on how to solve the problem. , or at least how to research a solution in a more applied way. Obviously, we must always be aware of what is new so that we can help our companions when necessary.
Dealing with people
People are the most complex assets, and also the most valuable in a company, and the TL role ends up being extremely important for the company. Another point that I think is very important to highlight is that TLs get together to exchange experiences and share cases to always be up to date with the team’s needs. It is important to remember that TLs are technically competent people, but they are not infinite sources of knowledge and for this reason it is important to maintain a network of colleagues ready to help you, however much of the time I found myself managing people and exercising soft skills and in I only had to consult my technical knowledge base for a few moments.
The road to follow
It is obvious that at some point we will have to migrate to an architecture or management position, and during this period in which I became a TL, I was able to evolve a lot in a short time. Now I need to choose which path I want to follow, and TL’s experience was of great help, as it helped me understand which path I should follow. And it is this path that you will end up having to choose too.
I hope this short article helped you see a little more about what it means to be a TL and the importance of a TL in a team.
