DEV Community

Cover image for Being a Tech Lead
Robert Basic for Trikoder

Posted on

Being a Tech Lead

I’ve been the tech lead of my team at Trikoder for just over a year now (380 days, but who’s counting?) I think this is a good time to look back at what this role means to me, the things I’ve learned, and mistakes I made.

My background

Ever since I started programming back in 2005, I sort of have known that “writing code and solving problems with software” is the thing I’ll do. As I grew older and more experienced, I’ve slowly come to realize that, well, writing software is only one part of the equation and there’s a bit more to it. Turns out the “people stuff” is quite important and necessary, even when dealing with computers all day.

Joining Trikoder

In the summer of 2018, I joined Trikoder as an external contributor on the Njuskalo.hr platform.
As part of the Common Base Technology (CBT) team, I’ve took part in work that enabled us to internationalize the Njuskalo.hr platform and launch bolha.com on the same code, as well as undertook some bigger refactors and rewrites to lessen the burden of technical debt and legacy code on other teams. We still have a lot of work ahead of us as 10 plus years of shipping fast tends to leave a lot of “baggage” behind.

What do I do as a tech lead?

I’ve been the tech lead of this small team for the past year and, mostly through trail and error, I’ve been figuring out what does this role expect from me. I have good support both from my team, my team lead, and from the company in general, so it’s been a great learning experience so far.
A thing I learned over the years is that one of the reasons “legacy code” happens is due to a communication breakdown between the business people that need the software to solve a particular problem, and the software people that write the software. This is why I believe the position of a tech lead is a unique one. We can help the business understand why delivering new features takes as long as it takes, or why is it necessary to do some seemingly unrelated code maintenance. But, communication is a two way street, so we also need to ensure that the developers can understand the business side of things, how it’s not financially viable to halt producing new features for several months to rewrite that ugly piece of code someone else wrote, or how this project might not be the best place to try out the latest and shiniest new technology. I see my main role as a tech lead to be a bridge in the communication between business and development.
Through regular communication with the other teams, I try to understand what parts of the platform should we focus on next when it comes to dealing with technical debt and legacy code. Then, together with the leader of my team, we try to come up with a strategy and goals that will get us buy-in from the business.
Within the team itself, I do my best to guide the team towards good technical and technological choices. To make sure the code we write (and don’t write!) is the best it can be under the current circumstances, that it’s aligned with both the needs of the business as well as with the overall architecture.
While I love nothing more than getting “into the zone” and delivering code, I’ve come to realize that that part of the job is gone. I’ve seen this mistake made by other tech leads, and then, sadly, made it myself. As a tech lead I can’t let myself focus too much on any single problem, because then I don’t see what else is going on in my team. I might miss out on an important decision being made, or someone might decide to not reach out to me for advice as they don’t want to disturb me.
I see myself now as an enabler — my work is to enable the other programmers on my team to shine. Enable them to learn, to grow, to get into the zone, to make an impact. Even enable them to fail.
And this is where I think I’ve come full circle as a programmer. When I was starting out I was always volunteering for the tasks that no one else wanted, the boring tasks, the non important but still have to be done tasks. I’ve started to pick up those tasks again, so that my team can focus on the important things.

Self-retrospectives are weird

Am I doing it right? I think so. It feels right. I’ll probably make a few more mistakes along the way, but that’s how we learn. I’ve been fighting this direction of my career for a long time, as I didn’t want to bother with “management”. Now that I see and understand what the position of a tech lead brings to the table, I’m going all in.

Until next time, take care my friend.

Discussion (0)