Who is (not) a Tech Leader
Things I should know when I started leading the team
It’s 4 years now when I have been leading mobile department at Azimo. Formerly as a Head of Mobile, and now as a Tech Lead. My background is purely technical and I started my leadership like many others — as the next step in my software engineering career.
More than once I was looking for the answers for what does it mean to be a leader for engineering teams. And what a good leader does.
I’m writing the message to myself, 3–4 years ago. Beginner team leader, who tried hard to be at his best, yet who made so many mistakes affecting great people working f̶o̶r̶̵ with him.
Do I know now what does it mean to be a great leader? Probably not fully yet. I hope to learn it in the coming years of my professional career.
But today at least I can answer who the great leader is not.
Not technical expert of everything
Leading a tech team doesn’t mean that you know everything about technologies that you and your team are using. Very often it means that you know enough to move the development forward. The more versatile your team is, the more often you will work with experts who know much more than you do. My team consists of software and QA engineers for both, Android and iOS. And I know how to code Swift, but I still lose myself deciding what is the most optimal and error resistant way of unwrapping optionals. I have a couple of favorite RxJava functions, but my Merge Requests are constantly rejected because of something more optimal and easier to use, with 2x less code. I know XCtests and Espresso, but I’m not sure if I get the Page Objects approach correctly, especially when building it in the code.
I do know how to write code, add new features to our product, build a new test for QA and automate new steps for our CI/CD. But at the same time, I’m sure my team is very often better in those. And I am happy to admit that. Because we deliver as a team, not as individuals.
Not a boss
You don’t tell people what to do. You figure out solutions with them. You ask questions, challenge decisions, draw a big picture so everyone can understand it better. You can propose your way of solving a particular problem, like everyone on the team. But it can be rejected like anything coming from anyone.
While giving orders, we very often forget about describing the context of them. If we are lucky, they are in line with team members’ vision or their personal development. But there are also stupid or pointless tasks to do. Like something that needs to be done quickly, as a workaround, or as a lite version of a solution which cannot be developed in your team’s or company’s scale.
And your role is to explain that. When you do this right and honest, very often stupid decisions become just another problem, which we tackle together, as a team. When you have more people knowing the reason, who knows, maybe a better idea will come to workaround this or that, without making a big technical debt or any other mess in the project. Or at least there is a bigger chance you will have more people on the same page.
In my career, there were dozens of pointless tasks that became really smart solutions when the team and I honestly talked about them.
Not a judge
Everyone deserves praise, and we shouldn’t underestimate this. But there is a big difference between appreciation and assessment. Very often team leaders assume that their role is to tell their colleagues how they are doing. Were they good enough? Did they meet your or company’s expectations?
It took me some time to understand it is a horrible way of working with the team. Let’s think about it. What is your intention when you usually come to work? Do you think “ok, I’ll do bad today”? Of course not! For most of your time, you do things as good as you can. So the same with the people around you. That’s why your role is to provide a framework that is showing what does it mean to do a good job. You should talk about goals, expectations, possible ways of development. And let the team members do self-assessment. And of course, you should have your point of view, and your comments. But first — listen.
Not the most important person in a team
There is not such a person. Everyone is equally important. “But the team cannot operate without a good leader” you can say. First, this is not always true, because if your team cannot do their job without you being involved, maybe it’s you doing something wrong? Also, a leader cannot exist without the team — who is more important then?
You face challenges, deliver features, fix problems and celebrate as a team. And a team is the most important thing. The individuals’ power is essential, but the real strength comes up from the composition of unique skills and experiences.
“None of us is as smart as all of us.”
Not a next step in software engineer career path
Leadership isn’t always the next step after a senior software engineer role. It’s more like an alternative branch, one of many to choose from.
It happens that good developers aren’t good leaders and vice versa. And they don’t have to be. Leading a team is a very different role than building software. When leading, you focus on unleashing the power of your team. Software engineer does the same, but with the technology. When you, as a developer call communication, lack of specs and requirements or human nature problems, for the technical leader they are challenges to face. So If you, software engineer, were offered a promotion to technical leader position, give you some time to think about it. This isn’t the next level in software engineering. This is a very new path built on the foundations of your technical skills.
Not a full-time coder (anymore)
I still do a lot of code, what I am glad of. But when you’re leading a team, the hierarchy of priorities is much different. First — your team. Are there any obstacles slowing down the delivery? Maybe open questions to answer? It’s all on you.
And then, when a team can move forward, there are individuals. Are all team members happy? Do they know what to do? And what does it mean to do a great job? Great, so what about long-term planning? Even if product roadmap is already there, do you have plans for technical debt? What about monitoring, performance or lowering project’s entry level for newcomers? Do you have all of them?
Great, now you can do code.
Is technical lead, a team lead?
It all depends, as always. For me it is. I see Tech Lead as a team leader role for technology projects. But It doesn’t have to be the same in your company. The reality (hierarchy, processes) will be different in company hiring 100+, 1000+ and very different in 5000+ people. But in the end, at least one goal is the same everywhere. As a (tech/team) leader, you care about people. And then you all together care about the product you build.