What Is A Tech Lead?
Before getting into what a "good" tech lead is lets talk about the role itself. In general a tech lead is a member of the software development team who helps to coordinate the team's efforts. They help to insure that the team's momentum is of the forward variety. Among other things they are also responsible for communicating up and outside of the team with various other project members, including the project manager, delivery lead, product owners, architects, etc. As the name suggests tech leads are expected to have a high degree of technical competency, and to be able to more than hold their own in a technical conversation on the project. They should be able to make technical decisions about the project, and have a high degree of domain knowledge to make sure the decisions are well-informed.This is a pretty cut and dry explanation of the role, making it easy to identify who should fill the role, right? Riiight. Let's give it a little more nuance, shall we?
What A Tech Lead Isn't
Tech lead isn't just a title. It turns out you can't just point to a random developer on the team and appoint them to be the tech lead. Someone either is or is not a a tech lead, based on their personality and the behavior they exhibit. The tech lead on the team is the individual other developers go to when there is a problem that they can't solve themselves, regardless of whether that person actually fills that role in an official capacity. They're also the one who willingly takes on extra responsibilities in the interest of helping the team to complete the project.A tech lead is not simply the strongest technical member of the team. A lot (most?) of developers are perfectly happy to be heads-down and working on the code which is right in front of them. They'd rather not deal with anything outside of their immediate codebase, much less deal with the politics of the project. This is actually a very good thing, as having strong developers on the team who only have to focus on implementing features and fixing bugs keeps the project rolling. Moreover, taking a strong developer and putting them into the tech lead role based solely on the fact that they can crank out user story after user story is a great way to kill their motivation. A tech lead may be strong technically, but they'll have the ability to communicate and demonstrate a willingness to put up with the additional hassles of being a lead.
A tech lead is also not a manager. If the "tech lead" is spending all of their time in meetings coordinating "resources" and zero time with their hands in the code with the rest of the team then guess what, that person is not the tech lead. They're a manager, or well on their way to becoming one.
Having gotten all things Not Tech Lead-y out of the way lets move on to what a good tech lead.
Personality Traits
There are a number of personality traits that a good tech lead should exhibit (this isn't a comprehensive list):
- Decisiveness - My all-time favorite quote is "He who hesitates is lost." Above all a tech lead should be able to make a decision when no one else can. In essence they should lead. This doesn't mean charging in blindly when there isn't enough information, but it does mean that for given a situation the tech lead should find a way forward for the team.
- Impatience - A good tech should be impatient to solve the business' problems. They should be chomping at the bit to tackle the technical challenge. Moreover they should be impatient to remove blockers for the team, and intolerant of processes and practices which slow or stop the team's ability to deliver business value.
- Bravery - A good tech lead should be brave enough to challenge the status quo and to push for continuous improvement. If existing processes are a hindrance to delivering value than the tech lead should be brave enough to step up and point out their flaws and suggest improvements. They should also be brave enough to speak painful truths if they need to be heard, both within and without the team.
- Humility - By the nature of the role they are in very little that the tech lead accomplishes is actually directly attributable to them. In fact, it is the team itself that achieves the goals of the project. A good tech lead should recognize this. The tech lead might help to coordinate the work, and may even have some excellent technical insight to share, but at the end of the day they are just another member of the team (or should be!).
- Can-Do Mindset - When given a difficult project, or a particularly complex technical problem to solve the tech lead should be approach these issues with the mindset that they are problems that can be be solved, and they should encourage the team to approach the problem in the same way. They should be the one to point out that a two meter exhaust port can in fact be hit with a proton torpedo (After all, they used to bullseye Wamp Rats back home with their T-16, and they weren't much bigger than two meters!).
Exhibited Behaviors
Beyond personality traits there are also certain behaviors that a good tech lead should be exhibiting. Again, this isn't a comprehensive list by any means.
- Technically Excellent - Tech leads should more than just competent developers. They should be technically adept in the project tech stack, and should be able to quickly learn new new technology and adapt to new techniques and practices.
- Delegates to the Team - A good tech lead doesn't try to tackle every problem themselves. They can let go and trust the team to do their jobs and complete the work. The tech lead should not be the hero who saves the day. If they are then they're not doing their job to grow the team.
- Knows the Strengths and Weaknesses of Their Team - Every team is made of different personalities, and developers all have their own individual strengths and weaknesses. A good tech lead should understand what each developer's strengths are (to be played on), their weaknesses (to be nurtured into strengths), and what makes each member of the team tick.
- Aggressively Defends the Team - This is important. There will be times when unreasonable demands may be made of member of the team, such as requests to do work that is not related to the project, or to stay late for an arbitrary reason. There may also be times in which outside entities come into conflict with the team for one reason or another. It is the good tech lead's job to defend the team from these unreasonable demands for their time, and to intervene between the outside entity and the rest of the team in order to keep them focused on the project work.
- In the Business of Building People Up - Another big one. A good tech builds his or her people up. Not just for the project, but for the team members themselves. A good tech lead encourages their teammates to continue to learn and grow, and supports them in these activities. More selfishly the tech lead should also be looking for a replacement, someone who will eventually take their place. After all, as tech lead you don't want to stay on the same project forever do you?
- Able to Occupy the Nether Realm Between Technical and Non-Technical Communication - A good tech lead is capable of not just speaking the tech lingo, but also of speaking the business lingo. They should be able to communicate with non-technical individuals who have a stake in the project. A good tech lead is able to explain technical issues in non-technical terms when the times call for it.
As a tech lead myself I've had to learn the hard way how to be effective in the role. I've been fortunate to have a lot of good role models, as well as a number of not so great role models to learn from. I've made plenty of mistakes, but I try to learn from them whenever that happens. I don't believe anyone can simply jump into the tech lead role and instantly be good at it. It is a role that demands that you attend the school of hard knocks, no shortcuts allowed. The trick is finding someone who doesn't mind that kind of higher education, and who can thrive in adverse situations and come out the better for it, all the while keeping the team together and advancing forward in their goals.
I hope these insights are useful to anyone looking to find a tech lead, or who might be interested in becoming one themselves some day. Thanks for your time, and if you have any of your own insights to share please leave them in the comment section.
I've never been a tech lead and would be miserable as a tech lead, undoubtedly in both senses of the phrase. But I've served under a lot of tech leads, enough to observe a thing or two.
ReplyDeleteHere's one, for example, that's not surprising. When the success of the project rests on a technology in which the tech lead is not an expert, that success is in danger. If there _is_ an expert in that technology on the team, the tech leadership will begin to shift from the politically-recognized position holder to the expert, which will cause political problems. If there _isn't_ an expert on the team, velocity will circle the drain as the team hacks away at the technology, fails, and blindly comes up with a way around it.
I remember one project years ago (back when Maven was new) where the business misguidedly insisted on the use of Maven for the project, but nobody on the team knew Maven. After weeks of thrashing, during which we figured out where Maven wanted its files, we came up with a tiny pom.xml file and an extensive network of Ant scripts that copied all our source code into a temporary directory tree that looked the way Maven wanted to see it, and then did a Maven build.
Here's one that may be more surprising. Whenever I've had a really good tech lead, he's always been constantly bellyaching about the tiny amount of time he gets to spend coding, because he's always in meetings or writing documents or shuffling story cards or something. And whenever I've had a tech lead who has been diligent about spending a nontrivial amount of time coding, he's always been bush-league at best, intolerable at worst.
Given the astonishingly small amount of time it takes for coding skill to first roughen, then rust, then evaporate, this would seem to argue for an arrangement where a selected developer is sentenced to a short term as tech lead (a few months at most), then quickly returned to the coding pool to bang the rust off and replaced with another unlucky shlimazl. Otherwise, our tech leads will gradually turn into managers who used to be technical.
Hi Dan, thanks for your comment!
ReplyDeleteI fully agree that the tech lead should be an expert in the tech stack for the project to be a success.
I also know the pain that comes from being a tech lead and trying to balance non-code-related activities (meetings, backlog grooming, etc) with actual hands-on development time. It's a balancing act that is easy to overturn one way or the other.
I've had varying degrees of success with this, and it seems like one way to achieve a balance is to delegate as much of the non-coding-related activities as makes sense to the rest of the team. This in itself is a balancing act.
On the one hand it can generate a lot of learning experiences for the team. You want the rest of the team to get good at things like writing stories, grooming the backlog, contributing to design meetings, etc, because you want to team to be autonomous as much as possible. In the ideal team the tech lead is something akin to a fifth wheel. The team will be self-sufficient, and won't have a need for a single individual who has to coordinate the effort.
On the other hand there is a pressure from the business to have a single individual that they can point to who will take responsibility (and blame!) for the project. If you delegate to the team too much as tech lead you run the risk of becoming too disconnected from the pulse of the project at a high level. You also miss out on the little details that end up becoming very important to staying sharp technically and in the project domain. This can lead to disaster (as I'm sure you know well) when it comes time to make decisions about the project and you don't all the facts (or even incorrect information).
I like your idea to rotate the tech lead role, but again I think the team might have to contend with the business' need to have a single point of contact. I've recently experienced another angle on this, which is having two leads on the team. Now, this was a team which was far to large to begin with (but that's a topic for another post), and it made sense to have two leads as there was no way that one person could be effective with such an unwieldy team. Again, this had its own issues, but in this way each tech lead could still be writing code and still function as a lead.