I burned myself out in my first six months as a tech lead. It had always been a goal of mine to be a tech lead, but after accomplishing that goal, I spent some time regretting my decision.
I was putting in a lot more hours as a tech lead during the day and catching up on my ticket work at night. I wasn't sure what the role entailed, so I just did what I saw the previous tech lead do. I was totally unprepared for it.
That was five years ago, and in that time, I've served as a tech lead and engineering manager for three teams. With time, the experience became easier, and the expectations of a tech lead became clearer. There's no reason for new tech leaders to figure it all out on their own — here's my advice on how to be a better tech leader.
First, what exactly is a Tech Lead?
At different companies, the term "tech lead" can mean slightly different things. A team lead is a type of tech lead in which you are responsible for the day-to-day operations and delivery of a quality product from a development team but have no hiring/firing power.
The second type of tech lead is an engineering manager, in which you are a manager with hiring and firing authority as well as people management responsibilities such as regular performance reviews. These can sometimes be combined into a single role. I've also seen it as two distinct roles.
The third type of tech lead is the lead engineer, who is a senior member of the team who occasionally leads smaller projects but primarily in a technical capacity such as doing code reviews, developing a data model for a new project, or architecting the project.
This blog will concentrate on the first type of tech lead, also known as the team lead. Now that that's out of the way, here are some principles to guide your tech leadership.
- Make Yourself a Shield for Your Team
Handle anything that may disrupt the team, such as responding to Slack users who may have questions about your team or upcoming projects, collaborating with internal support teams on escalated issues, and representing the team's interests in meetings as needed.
This saves the team's time by preventing other people (such as upper management) from making requests directly to your team's developers. This can cause them to become distracted and divert their attention away from important planned work. So your goal is to determine if this is occurring and to communicate clearly to those individuals that such requests must first go through the proper channels.
A lot of this work is really just triaging the issue or question at hand and directing to the appropriate resource.
- Maintaining Knowledge of What Other Teams Are Working On
Meetings are one of those necessary evils that we like to complain about, but every now and then, some of those meetings contain useful information. In an ideal world, I'd get a five-minute recap of every meeting in which I'm not actively participating, but that's not going to happen.
They provide an opportunity to learn about what's going on in other teams, whether they're teams you work directly with or teams that are more distant from the work you're doing. You may overhear that a team is developing a new service, which gives you the opportunity to say, "Hey! My team is working on a similar project. Let's have a discussion about it!" Every now and then, that interaction saves you a quarter's worth of money.
- Discussions with the team should be facilitated.
Have you ever been in a team meeting where most of the time is spent in silence, waiting for someone to speak up (especially in a remote setting)? "Should we explore this library?" someone might ask, to which crickets might respond. People are sometimes unsure of how to respond and are afraid of appearing stupid. It is your responsibility as a tech lead to facilitate the discussion with the team so that the team can own — and make — the decision. Assist people in gathering as much information as possible to aid in decision-making. You can request clarification or ask dumb questions.
Half of the time, other people have the same questions but are too shy to ask them because they don't want to be the one who asks a stupid question. You may need to rely on your developers in the early stages of your role. You won't know everything about the codebase, but you must be able to answer questions like "Is feature X possible?" We have the information in system Z." If you've been on the team for a while, you'll be aware of who has access to which parts of the codebase. They'll be the ones to point you in the right direction if you're new.
If you don't have enough information to make a decision, say so and let whoever needs the decision know when you'll be able to make it.
- Maintain high standards and set a good example.
Don't waste time pointing out stylistic differences. Add a linter and/or a formatter to the project and direct the discussion to the tool. It's one thing for another developer to leave 15 nitpicky comments; it's quite another to ask if we should add a new linter rule.
Where possible, require code changes to be accompanied by unit tests, and track unit test coverage. 70 percent coverage is sufficient for me across the entire project.
Some scenarios are more difficult to cover with unit tests, but these are the exceptions. Unit tests are required for any business logic or unusually specific behaviour; this is the only way to prevent other developers from accidentally breaking code by removing code that they believe is no longer required.
- Concentrate on the Big Picture
You have to pick your battles, and there are some minor decisions that aren't worth your time. I'd bite my tongue and move on if a developer implemented something in a procedural pattern when you wanted it to be more object-oriented.
These kinds of decisions don't really matter in the long run. What matters is that your team does not push broken changes into production. A few procedural snippets here and there will not derail production.
That is not to say that you should not provide feedback. Instead of the tech lead's personal preferences, it's sometimes more helpful to ask questions to ensure that their proposed solution meets the needs of the problem, such as "Did you consider X or Y?"
You should not instruct your developers on how to carry out their change (unless they are specifically asking for that feedback). If you do this too frequently, they may begin to feel more like code monkeys simply doing what the tech lead says.
By asking the right questions, you can sometimes coach them into a different solution, allowing them to own the idea and implementation more than you saying, "Build it this way." Sometimes you can't because their solution also meets all of the needs equally, and choosing between the two approaches is a matter of personal preference. In that case, don't sweat the small stuff and get on with your life.
Conclusion
As a developer, you won't often need these skills, but they will come in handy. As a result, new tech leaders typically face a learning curve as they figure out the people’s side of leading a team while balancing their own responsibilities. So, if you want to be a better tech leader in 2022, pay attention to the following:
- Being a bulwark for your team Keeping track of what other teams are working on Facilitating discussions within your team
- Maintain high standards and set a good example.
- Consider the big picture.
If you have any questions about the above topic, please do not hesitate to contact us. Your digital partner will be Airo Global Software.
E-mail id: [email protected]
Author - Johnson Augustine
Chief Technical Director and Programmer
Founder: Airo Global Software Inc
LinkedIn Profile: www.linkedin.com/in/johnsontaugustine/