Most engineers are faced with the choice to switch to management at some point in their careers. Changing to Engineering Management (EM) or sticking with an Individual Contributor (IC) role feels like a black-and-white decision, and people often feel pressure to pick one or the other. Instead, there is a less well-known hybrid role at many companies: the Tech Lead Manager (TLM) role.¹

Responsibilities

The responsibilities of the TLM role can be fuzzy and include a mix of people management, technical leadership, and individual contributions. Let’s take a look at common EM and IC responsibilities:

The TLM role is usually a hybrid of all of the above EM and IC responsibilities.

In my experience, the TLM role is a great option for experienced Engineering Managers who want to retain their ability to set direction and write code. However, quite often ICs who are switching to management for the first time find themselves in a TLM role by accident and they end up disliking their time as an EM because of it. Much is written about the TLM role being challenging.

Switching from writing code to people management is extremely hard and requires an entirely different skill set. It’s easy to fall back to coding when things get tough or when a first-time manager runs out of “management” tasks to do.

Let’s look at whether the TLM role is a good fit for you first before exploring how to get good at this role:

Is the TLM role a good fit for me?

If half or more of these behaviors resonate with you, you might enjoy the TLM role:

• You are a highly specialized and/or highly-productive IC who is comfortable dialing back coding to help people grow.
• You genuinely enjoy a multitude of responsibilities across people management, hiring, coding, leading, setting direction, and product management.
• You really really care about the technology or product your team is working on. You are not just nodding along when your superiors come up with something many people think is silly, you truly believe in the product and the technology.
• There is nobody on the team who can take over technical leadership in the next one or two years, even if you hire technical leaders. This is rare and applies to people who either have a deep understanding of internal company infrastructure or are industry leaders in their area.
• You are excited to solve the most technically challenging problems, yet you are happy to hand those exciting problems to people reporting to you.
• You want to keep managing a small team and are motivated by technical challenges over growing a larger organization.

I’ve seen the TLM role more often in infrastructure teams than product teams. At big tech companies, the TLM role might be well defined and I suggest looking for internal documentation on the concrete expectations.

At startups or smaller companies, most of the managers might end up being TLMs rather than people managers, despite the label being “Engineering Manager”. If you feel like expectations for your role don’t match up with your title, I suggest having a conversation with your manager to clarify your responsibilities (or your title).

The TLM role is hard. It’s easy to end up feeling like you are expected to do 200% of the work and be 100% EM and 100% IC at the same time which is not sustainable, and it doesn’t have to be this way. Let me share what has worked well for me in the past to become really good at being a TLM:

People Management First, Engineering Second

People management is challenging. Managing multiple people, their career expectations, the company’s and the organization’s goals and managing yourself is a never-ending game of Tetris. At the same time, people grow and change slowly so “gratification” as a manager might take months to materialize. It is much easier to show up at work on Monday at 9 am, dive into your text editor, write code and deploy a new feature by 5 pm. You check out of work on Friday afternoon feeling great. In the meantime, the team is struggling: They complain about being blocked, there is some conflict between people you are unaware of that stifles collaboration, and they don’t get enough time with you.

When I was in a TLM role, I started every week focusing on people first, and technical impact second. Depending on team size I would front-load all the 1:1s with team members and cross-functional teams to get alignment in the first half of the week and free up my calendar for technical contributions in the second half. I also usually check in async with people who I haven’t been interacting with as much.

This makes people feel taken care of and it leaves ample buffer to deal with fires, dramas and conflict. Some weeks you’ll do no technical work up until Friday afternoon, and you have to be ok with that. You can only be successful if you help your team be successful, and they always take priority.

Develop Your Direction Setting Superpowers

As an established leader in your organization, people want to hear about direction from you. TLMs are domain experts, and your technical input carries a lot of weight inside and outside of your team – use it to your advantage! I recommend sharing your thoughts with your team often. For example, I quite like summarizing what’s on top of my mind, stuff affecting the team, and even how I feel every two or three weeks. It’s a great way to lead with transparency, increase visibility to the rest of the team, and invite discussion on topics related to what the team is doing. It’s also a great way to plant the seeds for changes that might be coming because people hate surprises.

However, as a TLM you also need to develop superpowers for direction setting outside of your team. A lot of EMs are great people managers but they lack the technical context of what people on their team are really doing.² TLMs have the unique ability to merge project management skills expected of EMs with the technical ability they retain by being involved in the day-to-day engineering work. This usually leads to more informed and technically sound decision-making. If you are doing this right, you’ll be sought after by other EMs for your technical input, and you’ll be able to influence the direction of larger groups or even the whole company.

Scaling Yourself through Delegation

Strong TLMs will not only set direction, they also need the people skills to successfully delegate projects of increasing scope to people reporting to them. This requires the ability to mentor people, and a real interest in helping people grow their careers. More importantly, a TLM must delegate in order not to become overwhelmed.

I’ve written about increasing the scope for people on your team through delegation previously in my management starter pack. The best way to do this is by identifying the right opportunity and matching it up with someone ready to take on more responsibility. This is a great way to help people grow and it also helps you scale yourself.

Being so close to the technical work, I’ve found that it allowed me to mentor people more closely, and the relationships I built with people reporting to me were more rewarding as a result.

Skipping 1:1s and Other Meetings

In most tech companies, you are expected to meet each person reporting to you at least once a week. Dropping 1:1s is a cardinal sin. However, as a TLM you have to be extremely guarded with your time. If you look at monthly or quarterly horizons, it’s ok to deliberately cancel all 1:1s every five to six weeks or so while still making people feel supported.

Make sure to set the right expectations with people, check in with everyone async over Slack/Teams/Chat during the week, and let them know you’ll make time for in-person meetings if they need you. Chances are you’ll be more responsive because your calendar is blocked off for focus time.

While most people are ok with canceling 1:1s once in a while, some folks might be way more sensitive about it. Be mindful of this, learn about the needs of each person on your team, and avoid canceling 1:1s with people who find checking in with you invaluable.

In general, people should be more aggressive towards declining and canceling meetings. Few things are more frustrating than an organization bogged down with countless meetings in which no progress is made. People need free time for deep work, and it applies to EMs as much as it does to ICs.

Reduce Coding Deadlines

As a TLM you’ll have weeks that won’t go according to plans and you might end up not making any progress on your technical contributions. I suggest limiting any negative effects your lack of technical contributions might have on your team’s roadmap. Don’t be on the critical path for engineering work and instead find ways to make your team more effective or take on work you are uniquely situated to solve.

The worst-case scenario is to commit to engineering work in the critical path of your team’s focus. This can lead to a failure state when you need to pull back from engineering work to prioritize management tasks which creates stress for your reports. You can do high-impact work if you make sure nobody is waiting for your feature to be finished right now. I’m not saying you should never set deadlines or only work on low-priority projects, just making you aware that you should be extremely intentional about the commitments you are making, and good time management is crucial.

This is another reason why the TLM role tends to work better for infrastructure roles in my experience. If your team’s customers are other engineers at your company, they will often be ok waiting a bit longer for something to be ready.

Avoid Pressuring Your Reports

As a TLM you are both managing a team and at the same time part of the team as an individual contributor. On any given day you might have a question, require a code review or be blocked by one of your reports.

Even if you do your best to be mindful there are power dynamics at play and some people might drop whatever they are doing to please their manager, and then fall behind on more important work. Worse, they might feel pressure to approve code that is not up to the standards of the team, because their manager was just trying to ship something quickly in the little time they had to write code on a Friday evening. In the worst case, you might end up causing an incident while you are in meetings for the rest of the day and your team is left to deal with the remediations.

As a TLM you must set clear expectations with the team that technical contributions from their manager should be viewed the same as those of their peers and should be held to the same (or higher) standards. TLMs are role models and they have to be mindful of the impact their actions might have on the rest of the team. This goes both ways: People emulate their leaders, and a TLM should lead by example. They can set exemplary technical standards, write tests, and be on top of any incident they might cause.

Managing Up

When your team is in a healthy state, you can experiment with dialing back the time spent on people management and test how far you can pull back without compromising the people and the team.

It’s a balancing act because the amount of support people need constantly changes. You might spend one performance cycle getting great upward feedback from your reports and feel less technically fulfilled, and cycles in which you feel technically fulfilled but get feedback that you could spend more time with your team. This might be intentional depending on your needs, but you need to communicate this intention to your manager so they know how to put feedback for you in context.

Give it 1 Year

Give yourself at least a year to go through various performance cycles and see the outcomes of your support for people. However, if you discover that you don’t enjoy people management at all, you should shift back. An IC with prior management experience can provide extremely valuable insights, and you’ll be able to choose to continue doing the EM responsibilities you enjoy.

In my experience, the TLM role is challenging but extremely rewarding. You can be an Engineering Manager while still keeping your feet on the ground and solving challenging technical problems together with your team.

I’ve found that people trusted me more to make the right decisions. I knew how the technology stack actually worked because I built a large part of it. It’s frustrating and demoralizing to report to a pure people manager who is unable to understand what people are building, and which problems they are facing, regardless of how much time you spend explaining it to them. Stepping into the TLM role is a good way to counter that, and reporting to a TLM is often deeply rewarding because they tend to care about people and technology in the right way to get amazing things done.

Finally, I hope this post helps you navigate the role much better! TLMs tend to feel overwhelmed due to the many responsibilities they have. It’s ok to feel this way, and hopefully, you are oscillating between personal happiness and happy people reporting to you.

Thanks to Tim Yung for supporting me when I used to be in a TLM role and for providing many suggestions for this post.