.svg)
.png)
Curious about the nuances of being a Tech Lead? In this blog post, we reveal the dynamics of being a “person in charge”, straight from the source. We've gathered insights from three seasoned developers, each with their own unique experiences and stories, to paint a comprehensive picture of what it means to lead in tech.
Part 1: Defining the Tech Lead Role
Mateusz: For me, the term "Tech lead" is synonymous with "Tech enthusiast." I can't imagine any tech lead who doesn't feel a healthy excitement when a new JS framework lands. Such a drive to explore and use new technologies benefits the daily job.
Once one has seen and played with many different technologies, great intuition can be developed. In most cases, when someone from the tech lead's team has some architectural/conceptual problem, the tech lead has likely been there and found a solution (or not, and it's not a good way to go).
I remember the times when I was a junior dev, and my tech leader was more like a fortuneteller to me. He just knew that something was not performant or scalable. Luckily, instead of relying on beliefs, he always had good arguments or examples to prove his point.
Moreover, in my opinion, tech leads benefit from their soft skills. Haggling better than the vegetable seller at the local market is more than desirable when you are on sprint planning and the PM ignores another batch of bugs to fix in favor of a new feature. Additionally, there is a "lead" in tech lead, so a good candidate has to know how to deal with people, which is not a common skill in the IT world.
Part 2: Nurturing Growth and Fostering Team Dynamics
Kuba: I believe that the best way to mentor team members is to work directly with them, to create an atmosphere where curiosity and questioning are welcomed, and to answer all the concerns and questions of the team as substantively and clearly as possible. If there is a fear of asking so-called “silly questions,” there is no room for improvement for both the team and the team leader, who has to rely on his formal role and authority, rather than experience and knowledge.
Fortunately, I haven't had any major conflicts in teams I have led, so I believe mutual respect and using a merit-based approach are good ways to prevent them. Probably, there are cases when this might not be good enough, but I haven't experienced them yet in my career.
The best way to be an advocate for the team's needs is to explain the trade-offs of particular approaches, especially when business-oriented people insist on delivering a quick solution. In that case, I try to explain in simple terms how this could backfire in the future and ask if the client is ready for this potential cost.
Part 3: The Project Pathfinder
Rafał: Is the technical leader also one who works on reducing team distractions that could come from stakeholders? Taking unrelated-to-sprint-goal requests, preparing the technical backlog, and scoping epics are only a few examples of what we're struggling with daily. Many factors define the need to contribute as a technical lead in a given project. I enjoy working in a configuration where I can directly impact teammates' growth by pair programming, brainstorming, mentoring, or just solving difficult problems together. My hands-on coding is usually limited to the less comfortable tasks for my teammates or building proof of concepts that we later improve together.
In terms of project management, it is crucial to think about the project from a long perspective. The tech lead's scope is much wider than the usual development team. To avoid drowning in current affairs, there must be time blocked or meetings planned with clear goals. Strength is in a team, and arguing backlog, ideally with the CTO or other leads, is one of the best things that can be done while building the roadmap.
Collecting and prioritizing project requirements from day one should help build the technical aspects of the project vision. When I see people joining, I’d love to see them challenging the status quo. Working for a long time on a single project might make us blurry on simple issues. Another important step is to iterate and verify if our project state is on a good track to the vision or our roadmap. Previously defined technical vision, non-functional requirements, and a carefully crafted development process would help us mitigate most of the typical issues.
Part 4: A Day in the Life of a Tech Lead
Mateusz: In my (unpopular) opinion, you can't define a regular day in the same way you can't define a Tech lead as some generic IT dude. Yet still, tech leads I know (including me) are often overloaded with work. When it's a case, good time management is key to, well, survive. To do so, I implemented a few rules to maximize my usability as a tech lead:
- Use pomodoro. Multitasking is a myth, and anyone who tries to multitask knows that. Working in short periods followed by breaks allows you to do tasks quicker and minimize context shift costs.
- Define rules of cooperation. For example, tell people to remind you. There are days when 4 people want "something," and it's easy to miss some tasks if you already have plenty to do. Luckily, you can turn on a reminder that oddly resembles your angry co-worker. If you establish proper rules, people know what to expect and can react accordingly.
- Follow the gradient of productiveness. In my opinion, the derivative of your prioritization equals the productiveness of your team. If there is a task that blocks your co-worker, it's a good candidate for a high-priority task. Even at the cost of refactoring, you always wanted to do.
Kuba: My key daily tasks are the same as for a regular developer, plus some additional ones. I especially need to address any blockers that other developers experience in their work and help them as much as I can, either with advice or pair programming sessions. There is also more emphasis placed on doing code reviews, planning and analysis of business requirements, as well as coordination of work between developers and teams. Apart from tasks specific to the team leader role, the TL must do a normal development job because otherwise, he would lose connection with problems that his team members experience.
Rafał: We all already know (yes, the paragraph above) that multitasking is one of the worst things you can do to yourself during the working day. I will share with you a couple of pieces of advice that helped me stay focused and more performant in the long run. Some of them relate already to the time management paragraph from Mateusz:
- Split the day into blocks and make sure to work only on related stuff. I distinguish focus time, meeting time, and code review time. The focus slot is something you should probably discover by yourself; for me, the most productive time is 7:00-10:00 when I have a fresh mind and there is not much happening in the project. Meetings are not something you can always impact, but at least ask your teammates to keep them in the block with appropriate breaks. Code review block is also quite important to me to make sure I don't miss contributing to merge requests.
- Be proactive instead of reactive. You don't need to respond to most of the requests and resolve everything that you were asked for immediately. I'm building teams where as a leader I'm not a bottleneck, so I let people make their own decisions so they don't bring simple problems to me.
- Turn off all notifications, and ask for private messages on urgent stuff only. You should have full control over your notifications. Don't ignore messages, just get back to them when you are ready to do it. You will realize that most of the things you didn't need to know.
- Plan and reserve time for periodic tasks, like 1-1 meetings, reviewing the technical backlog, reviewing project state, metrics, or any other agreements. The to-do list is also something I use frequently. At some points, I verify those tasks and create tickets to address changes to appropriate areas.
I believe building healthy habits would help you to be better organized and perform well in any role, but probably everyone needs to discover their own best practices. There are a bunch of books and techniques, but for me, probably the best reading position was Getting Things Done by David Allen.
Part 5: Challenges and Rewards
Mateusz: The main new challenge is leaving the warm basement and starting to talk with people. It's somehow rewarding if you like to discuss things with clients and co-workers, but you can't avoid confrontations or tough decisions for which, since you are a tech leader, you are responsible. Maintaining such a position teaches a lot; each day allows you to develop your risk management skills (should I use this brand new framework?), and you get better at conversations (how to explain to a newbie dev that fetching an entire database might not be a good idea without discouraging him?). In the end, I think that the most rewarding part in my case is to see people benefit from my experience and become better than me so I can learn from them as well.
Kuba: As a team leader, seeing suggested good practices, advice, and decisions that are adopted by team members and multiplied by their talent leads to a successful project, which is very satisfying. It means that you can foresee the long-term consequences of design decisions, as well as see the bigger picture of the project as a whole, not as a series of separated tasks that only the assigned developer takes responsibility for. On the other hand, this can be extra stressful when we encounter some serious bugs or don’t deliver sprint goals because this is my responsibility to avoid such situations.
Rafał: The same as considering every person is different, there are a bunch of leadership styles that differ from actual leaders. Things that are building us are the environment and experience. Take care of your environment, and search for people from whom you can learn. Ask questions and be curious about what story is behind them. I learned a lot from badly managed projects and bad decisions; I also made bad decisions myself, but I saved a lot thanks to the experience of many people I met on my path.
Leadership is not a skill that you can learn. If you have a leading attitude, you are probably recognized by your supervisor or your team already. This is something you probably feel and it should not be considered an opportunity itself or be pushed for. I believe that in healthy development environments, all you need to do is just work hard on things you're good at. Just stay focused, give more than others, and you will be rewarded.
Final Thoughts: Beyond Code, Embracing Leadership
Bringing together the insights from our three developers, it's clear that the role of a Tech Lead is as complex as it is vital. They are the guardians of a project's technical integrity, the champions of their team, and the navigators of the project roadmap. The Tech Lead role is not a static one; it adapts and grows with each challenge faced, offering an opportunity for continuous learning and leadership. Through the shared experiences of our seasoned developers, we hope to have illuminated the multifaceted nature of being a Tech Lead and the indelible impact they have on the tech world.
