If you’ve been working as a software developer for a few years, chances are you’ve filled the role of tech lead at some point. Perhaps not officially, but most of us have, at one time or another, called the shots on important pieces of work or been the go-to person on a particular project.
In my experience, most true tech-leads are “de facto” tech leads: leaders in all senses of the word, but without the fancy title. Other teams contain several people who fulfill different aspects of the tech lead role, with one person excelling at organization and vision, another at execution and day-to-day engineering, and another at architecture, teaching, or getting stuff deployed.
In short, I believe that being a tech lead is less a formal title and more about occupying a leadership role in your team. You may occupy this role temporarily (during a particular crisis or while working on a particular project), or more permanently. Several people may step into this role at the same time, while at other times in your team’s history the role may be vacant, causing a leadership void. Sometimes this leadership void can be present even when your team has a designated leader or manager... as too many of us know.
As you’re likely to occupy the tech lead role sooner rather than later, it’s important to do the best you can in the role. These eight tips are born from some of my own mistakes and learnings in the role of tech lead, as well as the learnings of colleagues who’ve occupied the role on various projects and teams, and lived to tell the tale.
1. Know that anyone can be a tech lead, but nobody should be the tech lead all the time, in all situations.
As I mentioned earlier, it’s important to separate the concept of technical leadership from job titles. This kind of thinking causes managers to become gatekeepers, and some people with the Tech Lead title to micromanage every aspect of their team’s functioning. Depending on the situation, even a very junior member of the team can be the tech lead for a particular piece of work. I believe it’s an anti-pattern for one person to fill the tech lead role all the time. Software is sufficiently complex that no single person can, or should, be the tech lead for every single story or card.
In the best teams I’ve worked in, the tech lead role is a little like an invisible conch shell that gets passed around between team members throughout the hours, days, and weeks. One person often holds this conch shell most of the time, but other people also get the chance to hold the conch when it is appropriate. If you find yourself in the tech lead role, don’t be possessive of it. Recognize when it is time to pass the role to someone else, and when it is time to take the role back.
In the best teams, no single person is the tech lead all the time. The role should be flexible, able to be assumed by other team members as needed. Photo by Biel Morro.
In Talking With Tech Leads by Pat Kua, the author interviews dozens of tech leads about their experiences. He asks each tech lead interviewed about the mistakes they made when first assuming role. The most common mistake is continuing to code just as much as before. The second most common mistake is no longer coding enough! It’s clear that newly minted tech leads struggle to find the right balance when it comes to coding.
People often become tech leads because they are a productive member of the team, able to churn out good quality code exceptionally quickly. The tendency is to operate in the same manner in the role of tech lead, not realizing that you may be maximizing your individual productivity at the expense of your team’s productivity.
As you can see from the above circles (source), the tech lead role sits at the intersection of many different responsibilities. Before becoming a tech lead, the focus was on doing everything in the ‘Developer’ sphere. As a tech lead, responsibilities balloon out to include everything in both the ‘Architect’ and ‘Leadership’ spheres as you take responsibility for the technical path of your project as well as the functioning of your team. Development is one third of this picture, so if you’re spending all of your time doing software engineering, it’s impossible to adequately perform the other demands of your role.
In contrast, an almost equally common mistake is quickly becoming post-technical in the tech lead role, with your time almost fully consumed by meetings, people management, grooming the backlog, and other organizational tasks. Usually, this is very well-intentioned: the tech lead believes that this path will help everyone else on the team be productive. However, if you’re not coding as a tech lead, how can you know if the solutions suggested by your team are appropriate? How can you know if your project architecture is taking shape? How can you help your team-members when they get stuck? It’s almost impossible to gain adequate context on all but the simplest problems in a few minutes spent peering over someone’s shoulder.
Pat Kua suggests tech leads follow the 30 percent rule: people in the tech lead role should continue to code at least 30 percent of the time. In my experience, the sweet spot lies somewhere between 30 percent and 70 percent of the time, leaving at least 30 percent of your time to take care of other responsibilities. This translates to 12 hours a week in a 40 hour week, approximately 2.5 hours per day.
A common mistake new tech leads make is to unintentionally become yet another gatekeeper. If any of the following statements are true, this can indicate unnecessary gatekeeping:
- The tech lead must review every change to the codebase.
- The tech lead must have the final say on all decisions, and be involved in every technical discussion.
- The tech lead is generally involved in the creation, assignment, and completion of every work item.
- The tech lead is the only person who can access critical services.
- The tech lead is the only person who knows how to maintain or change certain areas of the code base, or the only person who knows how to debug certain parts of the system.
Each of these situations can cause a team, or individual team members, to slow down and become less productive. At worst, team members feel micromanaged and disempowered.
These situations usually arise when well-meaning tech leads feel it is their responsibility to be the decision maker on everything. The idea that leadership involves making all of the decisions for a team is a fallacy, and is akin to acting like a parent rather than as a leader of skilled adults. As the tech lead, you will usually be involved in critical or tough decisions, but you shouldn’t be involved in every decision, no matter how small. A good tech lead empowers team members to make decisions that the tech lead respects and understands, even if it is not exactly what they would have chosen themselves.
Tech leads, when they are formally elevated to the role, are often elevated partly because they are good at knowing when it is, and isn’t, appropriate to use highly technical language. In my career as a developer, I’ve noticed that many conversations between software engineers and non-technical business people end with both sides feeling alienated: the business person feels confused, and the developer feels like they were not understood.
Software engineers who can speak about projects in universal terms that everyone understands, including the business, often find themselves elevated to the tech lead role. However, this can contribute to the development of an anti-pattern: the tech lead becomes the sole messenger between the team and the business. The business sees the tech lead as the only person who can speak “their” language, while the team see the tech lead as the only person who can communicate effectively with “the business.”
While this kind of shielding of the team can be necessary in the short-term, such as when the team is battling against a tight deadline, its use long-term ultimately leads to a disconnect between the team and the business. In addition, when the tech lead is sick or goes on vacation, all communication with the business (and from the business) stops.
The best tech leads aim to lead by example in communicating with the business. They’ll take other software engineers along with them to (some) meetings, invite them along to conversations with stakeholders, and ensure that each team member is integrated with the business. At the same time, the best tech leads advocate for their team within the business, ensuring that their team has the time, facilities, and resources to be happy and effective at work.
This is a little easier if you’re officially recognized as your team’s tech lead. If being a tech lead in your organization means also being a manager, then have weekly or bi-weekly one-on-one time with everyone in your team. If your team has a manager who’s already doing one on ones, then this may not be possible. Instead, try to take each person on your team out for an informal coffee or tea once a month.
The traditional one-on-one meeting consists of you and your team member, seated opposite each other, in a small meeting room. This gets boring and routine after a while. Try to mix it up a little bit. Sometimes, go for a walk, or maybe just play a game together (ideally a game that the team member likes, but you aren’t familiar with or good at). This could be a board-game, pool, table tennis, or darts. This gives the team member an opportunity to teach you something, and can be extremely refreshing for more junior members of the team who may feel like they have nothing to teach you.
It’s extremely difficult to be a good tech lead if you don’t understand the mental state, priorities, and concerns of everyone on your team. Very few people will share all of these things in group settings. One-on-one time together is almost always required to draw these things out.
One of the things that changes in the role of tech lead vs. software engineer is your zoom level. As a software engineer, you can afford to be laser-focused on your current task, or the specific feature you’re working on. You need to have some awareness of how your work connects to the larger system, but you’re generally zoomed in pretty close.
One of the responsibilities of a good tech lead is to zoom out. You need to have a broader overview of the system than any of your individual team members — enough to see how everyone’s work fits into the larger picture. This will often involve being aware of what other teams are working on and how they’re building their systems so that you can steer your team away from decisions that will make integration difficult in the future.
If your team members are like sailors on a boat, focused on hauling rope, managing the sails, and maintaining the vessel, the tech lead should spend some time up in the crow’s nest, spotting potential hazards on the horizon, and ensuring that the ship is maintaining a correct course in the context of the islands and other boats around it.
Throughout your day, ask yourself: what zoom level am I at right now?
Photo by Adam Kring.
One of the biggest challenges faced by new managers and leaders is learning to delegate. It’s understandable that this is a struggle: we’ve often worked as peers alongside our team members, to the point where asking a team member to do your work for you (“Hey, can you write tests for the feature I just shipped?”) would be considered quite rude. But when formally leading a team, delegating tasks is necessary: there’s simply too much for you to do on your own. Failure to delegate will mean that, at best, you’ll become overwhelmed, and at worst, you’ll become a bottleneck that slows the team down.
People often think of delegating as telling others what to do, but that’s overly simplistic. Delegating is the deliberate sharing of responsibilities. Since assuming new responsibilities is generally the means by which people develop their skills and seniority, delegating tasks to team members is an opportunity to empower them.
Here are a few tips on how to delegate effectively:
- Delegate more than feels comfortable. Tech leads delegate too little far more often than they delegate too much.
- Ask for volunteers. If you’re delegating a task, allow people to nominate themselves to undertake the task. This helps protect you from bias, real or perceived, in your nominations. Team members can take responsibility for tasks they enjoy, or stretch to take on responsibilities that will challenge them, but that they’d like to develop skills in. Nobody has the opportunity to feel resentment over being given a task they hate doing. Some team members will be overly timid about taking on tasks that are outside their comfort zone, in which case some extra encouragement and support may be needed.
- Ensure that the same people don’t do certain tasks all the time (e.g. running retrospectives). Otherwise you quickly run into the situation where if that person is sick or busy or on vacation, the task will simply not get done.
- If there are some tasks nobody likes doing, create publicly visible rotating rosters for those tasks so that everyone on the team shares the burden equally.
If being a software engineer is challenging, assuming the role of tech lead is even more difficult. When your team is humming along, performing well, and enjoying work, being a tech lead feels incredibly rewarding. But when a seemingly impossible deadline looms, or technical debt seems overwhelming, being a tech lead can be really tough.
Tech leads must wrestle with double complexity: the complexity of software systems and the complexity of groups of people working together. Because of this, software engineering teams often feel “messy.” Work gets done, and value is generated, but the process seems slightly loose and chaotic. I spent a large chunk of energy in my career as a software engineer fighting against this sense of team entropy and imperfection. But I’ve come to realize that some degree of messiness and imperfection is inevitable for groups of people working together to solve challenging problems.
So, go easy on yourself. As long as things are good most of the time, you’re probably doing quite well. Gather feedback from your team about your performance, encourage openness and honesty, and always try to get better.
Self-reflection and feedback x thoughtful behavior modifications x time = getting better at being a tech lead.
And if you’ve read this far, you probably care enough about doing well in the role of tech lead that you have a natural aptitude for being one. I believe the best tech leads are people who have adequate technical skills and high levels of empathy.
If you’ve ever (unofficially or officially) been in the role of tech lead, what tips would you add to this list? We’d love to hear from you in the comments on this article.