My experience as a Tech Leader
Versão em português aqui.
Not too long ago I had (or earned) the opportunity to be the technical leader of my team, and I wanted to tell you how it was. But first allow me some context.
It was a team that was starting the creation of a super-important product for the customer, but this team already existed for about a year. At first, we had a technical leader, and after he left, we had no one to wear that hat for about 7 months.
After inception[1] the discussion about this role on the team came back to the table. Would that really be necessary? So the team found itself in this questioning, and even a bit tough on the subject. After all, we want less hierarchy, right?!?
And remembering these conversations was the motivation for me to write this article a few months later. Telling you how this experience was and how these questions made me more efficient in this so relativized role.
My goal wasn’t to make the best deliver. My goal was to give people all the support so they could make the best deliver.
I had already participated assiduously in the creation of a product with the same tech stack a year ago, so the technical context I had. And that didn’t mean stories were being finished faster because I was in them. Quite the opposite, I avoided doing those stories because I knew people’s learning would be more valuable than delivering the feature.
The team is not what I am. The team is what the team is.
The team will not reflect my knowledge. I am not responsible for everybody’s deliver. I can not guarantee that the best decisions will be made because it is not up to me. The only thing I can guarantee is that I will try my best to bring different perspectives to my knowledge, put them on the table and then people will have more inputs about a certain decision.
It doesn’t matter if you use a semicolon or not.
Even though I did not make decisions for the team, the effort to influence them was high. But as a technical leader, I should not “stress my image” in decisions that are not relevant to our delivery. That’s because a lot of times I’m going to need people to listen to me in decisions that really matter.
In our software developing team, we also look for developing people. And in these cases, the team’s speed will be the slowest person’s speed.
Speed is not necessarily connected with knowledge, but being radical to prove a point, the point here is that in this role I had to make sure that all people were learning, and so knowledge was not focused on one person, which is a big and applicant issue.
I didn’t have to do everything. My job was to make visible everything that had to be done.
I have seen a lot of technical leader working extra hours, balancing a thousand of technical tasks, doing it without pairing because “this is supposed to be delivered fast”
It is not enough to have a business analyst with a technical background.
In the same way, they do not have the same context of the actual code, and because of that my efforts were very useful on business analysis with the technical perspective.
Delegating not only makes my job easier, it also helps developing people.
I was in the position of setting goals. Something had to be done, so I’d choose the closest person to an answer and say: this has to be done! And the secret was not thinking about “how”. If I think about how a problem should be solved, I am not delegating, I am directing. And there are two negative points about that. The first is that the problem will be solved under my perspective, and the second is that the person chosen to solve it will not learn how to do it this time.
These were some of the learning that I thought would be relevant to be shared. Of course, everything changes according to the context of each project, people and team, but even with these nuances, consider these ideas in case you take this position in the future.
Interested in working with us? We’re always looking for people passionate about technology to join our crew! You can check out our openings here.
