What does a tech lead do?

A friend of mine worked as an investment banker right after college. As he described it to me, in i-banking you essentially have a very fixed career that comes with well defined roles. You start as a summer intern and (usually) from there you get an offer to come work at graduation as an analyst. From analyst you progress through associate, vice president, director and then managing director.

Many tech companies have a similar career path for both individual contributors (ICs) and engineering managers (EMs). In startup land, if you even have titles, roles are very rarely as well defined. By the far the least understood or defined role is the Technical Lead. The tech lead role is so hard to define that at my last company I actually ended up using the term “Team Lead” instead (in most cases) because it came with less baggage.

The tech lead is usually a senior engineer who has shown ability in technical execution, organization of work, communication with their peers and strategic thinking in their domain. The tech lead keeps a foot in the IC track but also stretches into areas that overlap with an EM. Since every team is different the following responsibilities aren’t universal but should be used as a rough approximation if you’re trying to understand what you might be doing as a tech lead or if you’re already a tech lead then some thoughts on how to level up. A tech lead role can lead to a people management role but not enough engineers realize that it can be its own discipline. A good tech lead is invaluable to a team and very hard to hire.

Quick disclaimer

As with all roles, a tech lead is just a hat you wear and not an expression of seniority in itself. Senior engineers are senior because of the way they carry themselves and their constant dedication to best practices, high performance and self-improvement. If you need a title to convey your abilities or authority (this word makes me feel gross) then you probably aren’t at the level you think you are.

And here’s where you call me a hypocrite for displaying my titles on linkedin. So why do we use titles? Besides getting your next job, titles are helpful in quickly setting expectations about what someone’s responsibilities and capabilities should be. But usually within a few minutes it’s easy to tell someone’s abilities (or lack thereof) outside of the title. That’s true of a VP of engineering as it is with a summer intern. Keep that in mind when you ask for your next title change.

Delivery and Execution

By the far the most important part of being a tech lead is helping your team get sh*t done. Most tech leads are part of a team composed of other engineers. Some may be more junior and some may be more senior but the tech lead must be able to aid in everyone’s work. That doesn’t mean literally being able to do another person’s work (especially for very specialized engineers) but it does mean that as a tech lead you might have some tools for helping others deliver their work on-time, within budget and with a high degree of quality. Some examples might be removing roadblocks for others or helping facilitate an engineer thinking through a design decision. The tech lead should be spending a healthy portion of their time keeping a pulse on the various projects in the sprint so they can quickly react when necessary to help out with work that is struggling along before it goes off the rails.

In fact, if it seems like your tech lead doesn’t often intervene but projects seem to be going really smoothly, that could be a sign that your tech lead is very good at subtle, discreet and effective assistance (or your team is just really really good and doesn't need any help.. It’s very case specific). Tech lead is definitely not a job for glory seekers and you will rarely get credit from anyone other than your manager (if she's good at her job) for the sprint running smoothly. It's only when things go very wrong do you get recognition and not always in a good way.

As a tech lead myself, I was often responsible for the delivery of work that I personally could not have completed with the same quality as an engineer on my team. For example, I’m not the strongest frontend engineer so helping someone else code a mobile responsive page is a losing battle for me. But what I can do is help them think through their work and use universal strategies like testing, chunking work into smaller problems, finding other folks on the team or outside the team to advise or being a rubber ducky when they get stuck. With a higher view of the organization I can also help find other examples where someone may have already completed similar work or may be facing a similar challenge. If the work is taking too long or is too difficult, I can advise and facilitate changes to the requirements or make recommendations on scope to cut.

It’s important to distinguish between helping and gate-keeping here. For example, “a tech lead should review as much as code as possible” is a good example of helping but “a tech lead should review all changes before merging” is gate-keeping and counter productive to the team. The tech lead should also avoid becoming a bus count of one for any process (this also for your own sanity because at some point you’ll want to go on vacation). The tech lead shouldn’t be the only admin for a service or only contact for a vendor. The tech lead should also not be making all of the decisions directly but creating a space for decisions to be made by the team.

Ultimately the tech lead is responsible for work being completed but delegation is not only acceptable but highly encouraged and almost always a smart decision. The main driver should always be setting up others for success counter-balanced with keeping the team running smoothly. A really good tech lead will know when they need to do the research themselves or when they can delegate to someone else.

Planning

My engineers are used to hearing me describe the tech-lead / product manager (PM) relationship as the most important relationship in a startup. That’s because the best effort-to-value ratio in any company is planning. An old manager used to say “weeks of coding will save you hours of planning”. This is both true and unfortunate that not enough teams realize this fact. Coding is very very expensive both in salary and in the opportunity cost of working on a different task. That’s why planning is a very critical component of the tech lead role.

Planning is a big word to describe a few different activities including acting as a partner to the PM to help turn feature ideas into technical specifications that can be worked on by an engineer. The tech lead knows their team’s code, the product itself and the business well enough that they usually can spot opportunities for simplification or risk better than anybody. When I was a tech lead I would sit down with my PM every week and we’d talk through the list of new features, bugs and tactical tasks and see how each one could be communicated to engineers and which seemed not flushed out enough to be worked on. It’s much less expensive to ask a PM to spend another day thinking through a flow than it is to have an engineer start working on a vague card and be blocked by a decision after work has started. Even worse is when that decision causes the task to be delayed or even scrapped (the horror of wasted work!). The tech lead is supposed to do everything in their power to guard against this happening.

The tech lead also knows each team member’s capabilities and can communicate whether the team has the resources in place to work on a feature. For example, if the task calls for integrating the left phalange and the team doesn’t have a phalange expert, the tech lead can recommend that the work go to the team with the expert or see this as an opportunity for someone on the team to get some experience with new technology and recommend training / learning prior to starting the task. This also means the tech lead has the best view on who should be assigned which work based on their abilities, preferences and capacity. Not every tech lead does the actual assigning of work but every tech lead should think of themselves at the very least as an advisor on the sprint.

One interesting dynamic between an EM and the tech lead is career advancement and technical learning. Strictly speaking I advise that a people manager should always be accountable for the advancement of every engineer on their team but the tech lead in their role as assigning work is in a unique place to advise the EM on upcoming projects that can fit the career goals of each engineer and thus the EM should keep the tech lead apprised of what work each engineer is interested in pursuing. For example, the Em can let the tech lead know that Jane is interested in learning about the thingamajig and when there is a task coming up to add a whatsthatthing to the thingamajig, the tech lead can let the EM know.

The last example I’ll add (and this is certainly not an exhaustive list) is technical prioritization. The tech lead is in a role where they can see across different projects to understand what is causing decreased productivity or unhappiness and either suggest prioritization or directly prioritize tech debt projects. In a larger organization with multiple teams, the tech lead can communicate with other engineers outside the team to find patterns and suggest larger technical projects. Often the technical lead will have to balance multiple competing priorities within the team especially as it relates to the trade-off between building for today vs building for months from now. The tech lead must use the information available to distill the technical and business context into the best decision possible.

Communication

We’ve talked about a few different types of communication that a tech lead is either responsible for or is actively a part of. Communication is important for every role but for the tech lead it’s important to be well versed in talking to both technical and non-technical folks. In fact, one of the best qualities for a good tech lead is being a good storyteller. It's very difficult to convey subtle and nuanced technical issues to a PM, business stakeholder or executive without a colorful metaphor or example at hand. Engineers on the team will often look to the tech lead to help them describe a technical problem or sticking point in their work. Bridging that communication gap is one of the core parts of the tech lead’s role and often a big part of how a good tech lead starts to build credibility for themselves and the team with the organization.

That bridge works in both directions. A good tech lead will take the larger product context and paint a picture for their engineers which in turn helps engineers make better tactical decisions within their work. It can also be important to understand whether a certain decision actually matters in the long-run. Sometimes it's important to steer the team away from yak-shaving (engineers love to shave that yak).

The tech lead can also be responsible for the team’s communication ceremonies (often just called the sprint meetings) like estimation, standup and retrospectives. Sometimes the tech lead is also responsible for processes like bug tracking, on-call or rollout communication. There are other important responsibilities that are situation dependent and can vary. One example is the tech lead of a team that is responsible for a database where the tech lead is responsible for reviewing risky migrations. The tech lead should help facilitate meetings (both intra and inter team) where it's necessary to reach consensus on a sticky subject.

Finally the tech lead can often be accountable for the technical documentation of the team. Documentation is due its own large conversation but in a quick summary, documentation can often come down to the culture of the team. The tech lead should consider themself responsible for pushing the team to be better at documenting new and changing features, preserving decisions and formalizing proposals in writing. This can take the shape of design docs, implementation details, diagrams and any other important artifact that helps a future engineer. A good tech lead is encouraging and not prescriptive about documentation. I would often not only publicly praise an engineer for great documentation but take the time to comment and share it more widely and do my best to loudly refer back to that documentation in the future to show its value.

Contributing Code

There’s a reason I saved this for last and it's because it’s the hardest to get right as a tech lead. Universally a tech lead is expected to contribute code in some way. Many teams differ on whether the tech lead should be in the critical path. I won’t get into whether a tech lead should be coding 30% of their time or 80% of the time. That greatly depends on context, team size, company maturity and the skillset of the tech lead. Some tech leads are great at context switching and can jump in and out of code all day between meetings. Some find it much more difficult. What’s more important than how much code they contribute is what they contribute. A tech lead should always always embody the best practices of the team. There is no wiggle room here. If your tech lead takes shortcuts or takes a “do what I say, not what I do” approach to coding then there is a serious problem. Whether that’s focusing on design patterns, writing tests, refactoring code or adopting tools into your process, it’s critically important that the tech lead is (as much as possible) above reproach for cutting corners.

A few helpful tools for a tech lead to gain more leverage for their limited hours coding are code reviews, technical documentation, demos and pair programming. Code reviews allow the tech lead to spread best practices between the team and quickly (and kindly) nip bad practices before they make it past that team member. Technical documentation, especially guides and tips, can help engineers get up to speed and scales well asynchronously. Demos are a great way to showcase what’s possible and facilitate discussions on the team. In fact, sometimes I’ll just do a half-assed demo (aka a modified version of the McDonalds’ approach) just to start a conversation on a topic without directly specifying that the goal of the demo is actually a consensus meeting.

Finally pair programming can serve several purposes. You can use it as a tool to teach or learn quickly. You can use it to encourage an engineer towards best practices. For example, I’ve often commented on someone’s code that they really should add a certain type of test and gotten pushback that it was “too hard”, that the code is “time sensitive” or that they’ll “add it in the next branch”. I can use pairing as a way to help them add the test together so it seems less scary and can get done quickly without just doing it myself. Pairing is also a great way to see if an engineer is using the latest and greatest tools, has an efficient coding process or to surface complaints about the dev environment that you might not otherwise hear.

Challenges

We’ve talked about all the things a tech lead should do but one last very important challenge is aimed towards the tech leads who are already extremely capable. Tech leads sometimes fall into a trap where they are so experienced, so senior, so knowledgeable (hear the sarcasm in my voice) that they struggle with junior engineers who are not as capable. The tech lead then adopts a “I’ll do it myself attitude” and takes over a project, a pairing session, a meeting, etc. It’s important to remember that you were also once that junior. And even if you weren’t (ha!) you have to accept other engineers’ capabilities. I’m not talking about situations where an engineer should be let go for performance but engineers who are good at some things and need to improve in other things. Your frontend engineer might be able to work magic when coding but maybe doesn’t run a meeting very well. Your backend engineer might be a great planner but has a hard time explaining the technical plan to the PM.

You need to augment and amplify their voices, not steamroll them. I’ve seen too many tech leads just run roughshod over their team to get work done. It’s not scalable and will lead to resentment and long-term issues on the team. It’ll happen sometimes. It always does. But the trick here is to constantly be evaluating yourself so you can do better next time and obviously point it out and apologize to the person you hurt.

Keep Going

This isn’t meant to be an exhaustive list or try to capture everyone’s experience. I took a hard look at what worked for me and some of the best qualities of the tech leads I’ve managed and tried to turn that into a small set of roles. Your own tech lead experience must differ widely. I mentioned at the beginning of this (rather longer than I expected) post that a senior engineer is concerned with self-improvement. There are many great resources out there to read further but I highly encourage The Manager’s Path which was given to me by my former manager when I started to think about leadership. It will not only dive deeper into what a tech lead is but will put it into context within other roles in the organization.