On being effective tech lead

Tech Lead / Lead Developer / (Whatever it is called in your company) is a very interesting role that combines technical work and leadership.

I’ve been in that role at a few different companies and I’d like to share my thoughts on what you can do to be effective in that role.

Equally, this article may also help you to decide if you want to try the role.

Your main goal is to enable your team

Your first and foremost goal as a tech lead is to enable your team. Your team’s success is your success.

Yes, it was partly your technical chops that brought you into this role, but a tech lead is not the person who writes the best code on the team (at least not just).

But it is the person who enables the entire team. And that means doing whatever it takes to help your team to succeed - whether it’s mentoring them technically or buying coffee - you have to do it.

Generally though you work on two fronts - product and technical.

Product

Yes, it is a role of a product manager to define a product vision, build a roadmap, and write user stories. But if user stories are missing details or the team does not know what they’ll be coding next week, it is your responsibility to step and help the team. Sometimes it means you’ll fill the gaps yourself and tell the team about what you’ve heard in that long product meeting last Thursday.

Or sometimes you have to guide the product team on how to better translate their ideas into something developers can work with.

Shortly, you need to make sure that your team knows not only how to build software, but what to build.

Technical

And speaking of the question of how to build, this is where your technical expertise comes in.

You need to make sure that your team knows how to build those fancy features and fix pesky bugs.

So if someone has not worked on a certain part of the codebase, sit with them and walk them through it.

If someone does not know which environment to deploy and where the API keys are, help them with that.

If someone is stuck, drop whatever you’re doing and unblock them.

But... delegate and help your teammates grow

Although you’re there to protect your team and help them focus on writing code, you shouldn’t take away all non-coding activities from them.

You don’t have to be the only person who onboards new team members, defines architecture, and fleshes out user stories with product managers.

If you do that, you’ll soon end up being a bottleneck for your team. Moreover, you’ll prevent your team members from growing professionally.

Instead, identify activities which your teammates are interested in and let them run with that.

If you happen to be their line manager, it’s double as important to do that, as it’ll help them with their career growth. And if you’re not line managing your team, you may pair up with their manager and find out what career aspirations your colleagues have and give them a chance to go in that direction.

Communicate to provide clarity

It’s your job as a tech lead to communicate and provide clarity. The product team may need to know how long some features will take - and you will have to tell a Product Manager that feature XYZ will take longer because the team needs to do essential refactoring.

Equally, your team needs to know that there might be a change in a product direction in two months, hence it is worthwhile to invest time in bringing framework ABC.

Partner with product

I have already mentioned working closely with product managers a few times. Here I want to stress why it is important and a few usual things you have to do.

First of all, you're the main point of contact for all things technical to the product and other departments (if you are working on B2B software you may also have to interact with sales and professional services). So do expect a lot of questions from them about timelines and feasibility of their ambitious ideas.

But working with the product team is more than just answering their questions, it is also about being proactive. It is up to you to help them to build a roadmap. It is up to you to say that certain features are not possible without doing an essential technical work. It is up to you to say that all feature work should stop and you have to move to a different framework.

Equally, it is for you to say that some features are less complex than they thought before and that you can do them now.

But... then again help your fellow engineers engage with product

Yes, you should protect engineers’ time, so don’t invite them to all the meetings.

But every software engineer is still interested to know which features they’ll be coding in six months' time. Every software engineer has great ideas on how to improve the product.

So make that happen - make sure that the product team talks to engineers about product plans and that they all sit together to flesh out user stories.

Trust your team

A tech lead should trust their team to make the best decisions. If someone wants to introduce a 3rd party library XYZ for doing ABC, then let them do it. If your colleague proposes re-designing a part of the system, let them do it, too.

But... be prepared to ask question in a helpful way

Whether it’s choosing a 3rd party library or deciding on architecture, make sure your colleagues have considered alternatives and impact on maintainability, project timelines, performance, security, etc. Feel free to ask questions about that.

Equally be prepared to step in and guide your fellow developers. For instance, if you notice that some tasks are taking much longer than expected, do speak to engineers who are working on them. They may be busy trying to consider every possible edge case that may never happen or do refactoring that should be a separate task. Help your team to avoid such rabbit holes.

Be strategic and stay technical

As a technical lead you should look ahead and be strategic. More specifically, you should:

  • Collaboratively establish architecture and coding standards
  • Prioritise working on technical debt
  • Look into newer version of the tools you use and make sure that you keep your codebase up to date
  • See what other technologies are available and how they can help your team

And that is impossible without you staying on the bleeding edge of technology. Remember, technical lead does have ‘Technical’ in it.

Yes, it’s a people intensive role, but it is also about technology. And on that note...

Be clear on how much time you can spend coding

A technical lead is expected to code. But how much can vary significantly week by week. Sometimes, you’ll have the luxury of spending 80% of your time coding away new features. Sometimes, it’ll be only 20% of your time.

What is important is to set expectations with your colleagues. No-one would mind if you say that next week you’ll be able to only commit 30% of your time to writing code. But they will certainly be less happy if you forget to mention that. And that includes both other engineers, who may wait for you to redesign an API endpoint, or product managers who expect you to finish that feature that all users want to see.

Work with engineering managers (if you’re not line managing your team)

Often as a tech lead you don’t have line management responsibilities, but it is often you who knows your teammates the best and it is you who can help them to get a promotion, salary increase, bonus, more equity, etc.

So do spend some time with their line manager and pass on feedback. Plus, their line manager can also tell you where you can help your colleagues in their career. You may even want to establish a pattern that you speak to their line manager and pass feedback on before their 1:2:1’s.

Finally

Tech lead is a great role. It allows you to write code and gain exposure to leadership, people, and product. But remember it’s not about you, but about helping you team to succeed!

Related posts

Mike Borozdin (Twitter)
16 January 2021

The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way. My personal thoughts tend to change, hence the articles in this blog might not provide an accurate reflection of my present standpoint.

© Mike Borozdin