You’re a Tech Lead. What now?

Expect more questions; but don’t answer all of them

Before, if there was something you didn’t know, you’d go to your TL for clarification. Now the TL is you, and others will ask the questions to you now.

Chances are, you’ve been nominated to become TL because you already could answer a lot of questions. But this does not mean you now need to answer all the questions. It’s not expected that you know everything.

So expect to say “I don’t know” more often. That is also OK. That said, saying “I don’t know” is not the end of your task. When you don’t know something, others will now also expect you to know someone else who knows the answer.

And this is one of the often under-appreciated complexities of transitioning into a TL role.

Prior, you would strive to learn more and more, to be able to answer more and more questions.

In your new role, you should strive to understand the wider knowledge community in your organization, and create a mental map of “who knows what”, both within your team and around it. And you’ll be routing knowledge around and away from you a lot more than before.

Expect more demands on your time; but don’t become interrupt-driven

Before, the folk most likely to reach out to you would be your manager (weekly) and your teammates working on a common project (perhaps once a day). You could plan your work a milestone ahead, with week-to-week flexibility about how to organize your time. You knew that a gap in your schedule meant you could concentrate.

As a TL, this will change in two ways.

For one, more folk will want to talk with you: your PM will ask for your feedback on roadmapping; other TLs will want to synchronize on cross-team projects; engineering managers (EMs) may reach to you to ask about what staffing is best for this or that project.

Then it’s also likely all these folk will want to talk with you more often. Your manager may now send you questions through the week, instead of just during your weekly meeting. Engineers in your team will reach out to you more frequently to ask questions about their project.

So more folk want to talk to you, more often. That’s a lot of talking! How to manage this?

There are two things to keep in mind.

The most important is time management. If you let yourself be interrupted incessantly, your productivity will plummet, and you might not even be able to do a good TL job for your team. So take care of your mental energy first and foremost. Maybe you enjoy the diversity of conversation, and it energizes you? Still, be careful about the overhead of switching tasks when multi-tasking. Or perhaps, to the contrary, multi-tasking fatigues you. Then work with your team, PMs and EMs to lean on asynchronous communication (e.g. shared docs) instead of interrupt-driven chats and meetings.

The other thing to keep in mind is the difference in dynamics. From your perspective, you’re interacting with a lot of folk in a week. Each conversation, relatively to the whole week, is only a small portion of the work. But from the other side of your conversation, they may be talking to you only (especially your teammates). So it’s likely your conversation partners will “feel more special” about the interactions than you do. They will feel your impact more than you will feel theirs. Be respectful, and be gentle.

Expect more anxiety about decisions; how to manage anxiety?

Before, if there was something you weren’t sure about, you’d go to your TL to make a call. Now the TL is you, and others will ask you to arbitrate more decisions.

Chances are, you’ve been nominated to become TL because you had good intuitions about decisions before. But this does not mean you now need to take all the decisions. It’s not expected that you should decide everything.

That said, there will be more pressure from the organization around you (and not just your team) to arbitrate, make choices, select strategies and take action. Such requests will come from support cases, customers, product managers, or engineering managers. And with a wider understanding of your team’s impact, you will also start to predict the potential consequences of “bad” choices.

Your ability to understand the consequences of certain choices, combined with the uncertainty of how to make decisions, can be anxiety-inducing.

And this is one of the often under-appreciated complexities of transitioning into a TL role.

Prior, you would simply dissipate your anxiety by pushing the responsibility for complex choices to a TL or an EM.

In your new role, you’re tasked with dissipating anxiety for other folk in your team. And since you now see the future more clearly, you may experience more anxiety, and it’s also your role not to show it to your team too much (because anxiety is contagious).

So what to do?

There are two things that can help.

For one, it’s useful to step back and understand what anxiety is truly about. Anxiety is a biological response to stress, and is meant to prepare your body to react to adverse physical circumstances. In a tech company, this biological response is not useful. Yes, there can be uncertainty and certain choices have undesirable consequences, but it’s not in your advantage to translate this into an adverse physiological response. Instead, consider lifestyle support to dissipate and sublimate your experience of anxiety. Some folk choose exercise; some others invest into creative hobbies; yet others invest into meditation. There is no one right way, but you should strive for finding ways to keep yourself centered around your values and let the pressure of work “slide” around you, without affecting your well-being. And it’s also quite important and useful to talk about your experience with your peers, your friends and/or your manager, for as much as your relationship with them allows it.

Another thing that can help is to understand that your organization also has guardrails around you. In practice, as long as you are transparent about the work you do (i.e. other folk around you know what you are doing, especially the nearest EM and PM), and you explain the complexity you face along the way, there cannot be ill will against you, should one of your choices bring an unfortunate outcome. Share your progress and struggles, e.g. via Milestone documents. It will be heard, and you will receive support. You will be trusted, but you can also trust in return: if things don’t turn out well, it’s a collective effect and not your personal failure.

(Of course, you only have access to this effect if you are transparent along the way. If others don’t know what you are doing… then it’s on you. Be transparent.)

Issue triaging becomes an instrument instead of a chore

Before, you knew that triaging incoming issues/requests/bugs was something that “needed to happen”, and you mostly were happy when it wasn’t you doing it. Or perhaps you were OK doing triaging work to help your team, in a sense of collective duty. It was probably still a chore.

Chances are, you were nominated to become TL because you are good at triage, or you don’t mind it much.

Now, as a TL, the task to triage incoming work might fall largely on you (NB: this is team-dependent). This is a somewhat large responsibility. As long as you consider it a chore, that could perhaps feel like a load of unpleasant work.

Yet… this is one of the often under-appreciated changes that happen when you transition into a TL role.

For one, you can share this burden with your team. Your PM can help a little, and often you can delegate some of the work to other team members (e.g. via a rotation).

But don’t seek to delegate right away! You will soon understand that triaging incoming work is really a discovery instrument that makes the TL job easier. By triaging incoming work, you learn about what other parts of the organization expect from your team. You learn which areas seem to encounter more issues, and may need some investment. You learn about who in your team and the organization is more knowledgeable about which area of the product.

Without triaging, you would be mostly blind to “who knows what” and “what is most important”. By participating in triage work, you learn things and develop an intuition that other folk in the org miss. It will make your job of making decisions easier and less stressful. It will make it easier to understand about what is important to do short-, medium- and longer term. It will also reduce the amount of “roadmap surprises” you encounter over time.

Also, by doing it more often, you will start to develop reflexes and automation to make the task easier, so that the amount of time done triaging will reduce overall.

You’ll need to know your team better; but don’t micro-manage

Before, your team was something that “happened to you”; chances are you joined a team that already existed before you, and folk joined and left without much input from you.

Chances are, you were nominated to become TL because you had built a mental map of the composition of your team.

Now, as a TL, you will start using that map of your team to drive decisions and run projects. Your EM may ask you about who should work on a project. Your PM may ask you how long something is going to take. All this means you need to predict how folk in your team are going to react to the work. So you will need to start continuously maintaining an up-to-date understanding of who your teammates are, and what they are up to.

And here there’s an under-appreciated challenge faced by TLs.

You will start noticing that individual team members expect that you know what they are doing, what interests them, what are their strengths and weaknesses, but without telling you. This is a known psychological bias, where folk are somewhat likely to mistake leadership for omniscience.

How to reconcile the two?

In an ideal world, you could perhaps expect the EM to track this for you. But sometimes (often!) the EM is busy or a bit further from the day-to-day, and sometimes it really will help your work to track this yourself.

So you will need to start paying attention to the group’s dynamics. Maybe you will notice how differently often your teammates ask questions. Through your more active participation in code reviews, you will learn more about their programming and discussion styles. You might get an intuition about how more proactively or reactively they tend to relate to their work. Or you could simply… ask them directly about how they’d like you to work with them. Hopefully, over time you should develop an intuition of what would happen when you approach any team member to work on a new project, or when collecting their input on progress.

In any case, remember what you found important as a non-TL. Most engineers value their agency. Most engineers enjoy and need periodic feedback. Most engineers expect a TL who is available and willing to share knowledge, but without being overbearing. Don’t micro-manage, and foster trust instead.

Now your team’s PM is your friend (or at least your ally)

Before, you were probably not thinking about PMs very often. If at all. Or perhaps you had this abstract understanding that PMs are responsible for “deciding the direction of the product” and you were merely expecting surprises (or dreading them) during roadmap reviews and definitions.

Chances are, you were nominated to become TL because you had a working relationship with some PM(s), and started to engage with them at their level of abstraction: putting customers first.

Now, as a TL, part of your responsibility is to ensure there is a connection between what your team does and the product roadmap at all times. This could feel uncomfortable at first. What if the business objectives make some project more difficult? What of the technical debt that doesn’t directly connect to business objectives? What of plain R&D?

And this is when you’ll discover one of the often under-appreciated changes that happen when you transition into a TL role.

Your PM will start sharing with you that they actually care about the well being of the team, about the technical debt, about the R&D. They do understand that reaching roadmap objectives cannot happen if the team feels unhappy or poorly engaged. You will soon discover that the PM is in fact shielding your team from the hurricane of uncertainties and conflicting requirements. But the PM is also just a person. Their job is hard. The PM will deeply appreciate your help when you can point out how to make their job easier. Perhaps you can teach them something about the product, or about why one project is more complex than another when it’s all the same for the end result. You can also ask them how you can help them.

In exchange for your help, your PM will care to listen to you about your team’s needs. For example, if you think some infrastructure needs an investment, you can ask your PM to help you relieve the roadmap pressure in exchange. If your team hits a snag in a project, you can ask your PM for help about how to communicate this effectively, and redirect other teams that may depend on it.

This partnership will make both their job and yours easier over time. Use it!