You’re arriving here because you’ve been nominated for a Technical Leadership (TL) role in some team. Or perhaps you’re considering applying for one.
The following document is about the experience of being a TL, and that of evolving into the TL role. It does not detail what will be your TL tasks and responsibilities.
Neither are you expected to know all the tasks and expectations at the beginning! You will learn them incrementally, as a side effect of requests and projects. You should also periodically check in with your engineering manager and product manager about how your role interfaces with theirs.
What changes? Expect more questions, but don’t answer all of them. Your role is to understand who knows what. Expect more demands on your time; but don’t become interrupt-driven. Take care of your mental energy. Be mindful that others will feel your impact more than you feel theirs. Expect more anxiety about decisions; how to manage anxiety? Find ways to dissipate anxiety. Also, your org has your back: as long as you are transparent and explain your struggles, you won’t be blamed for undesirable outcomes. Issue triaging becomes an instrument instead of a chore; it helps you understand what is going on and helps with decisions. You’ll need to know your team better; but don’t micro-manage. You’ll need to poke around to understand who does what, what works well and what doesn’t. Foster trust. Now your team’s product manager (PM) is your friend (or at least your ally). You’ll help them, they’ll help you. How you’d know you’re doing well? Are you unblocking coworkers? Removing friction? In any case, be proactive about communicating what you do and why, and you’ll receive feedback.
On the day-to-day, life is not so much different from not being a TL. (That is, unless you also become an engineering manager, that is, a “TLM”. We’re not going to discuss that here.)
You are still expected to contribute to our technical roadmap via product contributions, team participation, support rotations, etc. This continues more-or-less unchanged. There will be subtle adjustments over time, but none will creep upon you by surprise.
The main change is that you will soon discover that you won’t have enough time in a day to both deliver the same volume of technical contributions as previously, and also make good on your TL responsibilities. And that’s all right! No-one expects you to. It’s expected that TLs “shift gears” and start investing into their team’s productivity instead, and that can come at the expense of personal productivity.
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.
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.
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.)
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.
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.
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!
Transitioning into a TL role often means that your actions and performance will start diverging from the “simple mold” of a programmer, and so there will be less simple/measurable criteria to measure your progress and provide feedback.
That said, it does not mean that you can’t expect clear objectives and periodic feedback either!
Some of the things that you will naturally “feel” going well (or not) are the rituals around your team’s work: is the backlog under control? If not, does the EM and PM clearly understand what is going on and is there a plan to tackle it? Are you eliminating “blind spots”, reducing cases where your team is unable to take action for something that’s nominally attributed to it? Your progress in these areas will feel like strong wins and will be likely easy to report on in your brag document.
Next to these, there are more subtle markers of success. Things that an EM is likely not able to pick up on their own, so you will need to be very proactive and clear when talking about them.
Think about something that makes your team “hurt” continuously, but where nobody is complaining. Maybe a programming pattern is brittle and causes new hires to make mistakes often when they start, but not later when they’re indoctrinated. This is a productivity tax that your team is paying. Can you remove that and make it easier for newcomers to contribute? Perhaps, there is a component that has complex interactions with others, whereas nobody but the most senior engineers in your team dare perform maintenance on it. Can you break it up and empower your team to make gradual improvements?
More generally, it’s part of the TL role to discover how to make the organization work “more smoothly”, talk about it so others understand the problem (and phrasing the problem, in itself, can be an achievement!) and then perhaps take an initiative to provide a solution. But it’s unlikely folk will notice when you do this unless you explain that you are doing it. So be proactive about communicating what you do and why.
It’s a bit for you to decide, really.
The TL role is not “superior” to a non-TL role. It’s a different focus.
For example, if you care about solving engineering problems, the TL responsibilities will likely hinder your progress. Certain product objectives require extremely deep focus, and it would be hard to dedicate that focus while also keeping an entire team’s worth of work in your head. (And the technical fruits of deep focus tend to be rewarded handsomely.)
It’s actually common for a senior engineer to take on a TL role for a team for a given period, then migrate to another team or project in a non-TL role. This is not a demotion: senior engineers are recognized for their ability to quickly learn and start contributing in a new area that needs help. But that can only happen if their attention is not divided. Moreover, someone arriving in a new team usually does not yet have the instincts that would make them a good TL.
Meanwhile, if you care deeply about mentoring folk, or matching folk to the right projects or teams, you might gravitate towards engineering management.
In any case, you should check in with yourself about your career goals periodically, perhaps once a year. Talk about them! With mentors, your peers, your friends, other TLs, or possibly an engineering manager if your relationship with them allows that.
It’s useful to start exploring how other organizations “do” technical leadership.
Perhaps you’ll care to join online communities of technical leaders. Or attend public events.
There is also a lot of literature about various aspects of leadership. For example, the Harvard Business Review has excellent “top papers” shared on their web site, that are directly applicable in tech organizations.
One interesting feature of the tech industry is the tulip shape of career progression.
At a medium stage of career progression, it feels like one needs to make a far-reaching choice between an IC career track (deep expertise), technical leadership (broad expertise) or management (organizational awareness). This is known as the “trident model” of tech career progression.
However, in reality this choice is not definitive. As you gain more experience on either of these tracks, you will start noticing that the day to day activities become close(er) to that of the other roles. The branches of the trident get back closer to each other at the top, like a tulip 🌷. It’s also possible to move side-ways during organizational changes, or transition into executive roles.
There is no one “right path”. As usual, it will be on you to document yourself, talk to other folk about what they are doing, the challenges they faced, and poll your community about how you can best make a difference—to others, and to yourself.
So what do you think? Did I miss something? Is any part unclear? Leave your comments below.