Good Tech Lead/Bad Tech Lead
Below is something that I worked on recently at accuRx to try and clarify expectations of our Tech Leads internally since I realised this was clear in my mind but I’d never written it down.
I’ve published in full below and thought it may be interesting to others. Thanks to Ben, Benji and all our Tech Leads for their helpful and constructive feedback. Comments welcome and would love to hear from others about how they view this role!
Preamble
For now, being a tech lead at accuRx does not have a Job description in the same way that being a Product Manager does. It’s not a promotion (or demotion!) but one of the hats that a senior engineer can wear — albeit a rather time consuming hat! It’s hard to put an exact percentage on it, but somewhere between 50–75% feels right. People should be able to move into and out of being a Tech Lead so long as they have a strong technical background and the people skills to co-lead the team with a PM.
Given it is a large percentage of someone’s time, and an important role, we decided to write down some behaviours of what a good tech lead and bad tech lead would look like at accuRx. This will definitely be different to Tech Leads in other companies — it’s supposed to be tailored to our vision of this role and our culture. We were inspired by Ben Horowitz’s good PM/bad PM, which you can read here.
To try and make this easier to digest, we’ve grouped the behaviours into 5 key areas. I’ll also use “TL” instead of Tech Lead for brevity.
Leadership
Good TLs are as invested in the product vision as the PM. Bad TLs expect the PM to define the vision and see their role as just the “execution” of this vision. Good TLs tailor their processes and tools to suit the needs of the team. Bad TLs are dogmatic, enforcing their own preferences for system design, tooling and processes. Good TLs don’t say “that just isn’t the accuRx way” but invite creativity into the solution.
Coaching
Good TLs give candid feedback to people in their team to help them improve. Bad TLs complain about problems in their team without chatting to those involved. Good TLs spot when others have strengths in areas that they themselves are weak, and play to this strength. Bad TLs assume that years of experience are correlated with strength across the board. Good TLs help people learn how to solve their own problems. Bad TLs tell people the answer.
Ownership
Good TLs create an environment where everyone feels ownership over monitoring and bug fixing whilst knowing they are the final backstop. Bad TLs shield others from this completely, or blame the team when things go wrong. Good TLs champion effective code reviews as a way of teaching others, and ensuring consistency and quality of the software. Good TLs use pairing, when appropriate, as a great way of teaching, relationship building and breaking down problems together.
Relationships
Good TLs believe in teams, so they meet with them 1:1 regularly*. They invest heavily in the TL-PM relationship. Bad TLs give different answers to the PM when asked the same question. Good TLs build trust so they can understand how people in their team “tick” and have their finger on the pulse when it comes to team health. Bad TLs don’t see “people” as a part of their role.
Delivery
Good TLs facilitate excellent task breakdown, creating space for engineers to explore different technical solutions and giving others a chance at the most complex work. Bad TLs ignore scoping, or see it as the PMs responsibility alone. Bad TLs take all the complex work themselves, robbing others of a chance to improve. However, good TLs know when to push and can trade off team growth vs. delivery deadlines. Good TLs consider opportunity cost with every feature, often using the 80:20 rule to deliver value quickly.
*We would expect all TLs to do at least two 1:1s with people in their team during a 6 week cycle. Weekly meetings with the PM are encouraged. This is only a rough guide though, we’d expect TLs to meet more regularly with new team members and they may find they want more 1:1s in particular with engineers. However, all relationships are vital. Why? Not only should TLs have a grasp of team health but building trust and psychological safety will allow others in the wider team to challenge decisions. It’s very hard for a junior user researcher to contest a decision from a TL without a relationship existing.
