Future of Work
The new Tech Lead’s survival guide

The new Tech Lead’s survival guide

November 26, 2022

The new Tech Lead’s survival guide
Photo by 

Moving into a Tech Lead role is an exciting opportunity! Camille Fournier wrote in The Manager’s Path that a Tech Lead also plays the role of a Systems Architect, Business Analyst, Project Planner, Team Leader, and, of course, Software Engineer. Which means it’s a great way to learn a whole new set of skills. As a Tech Lead you’ll also have more autonomy and influence over your team’s direction than you had as an Individual Contributor. And because it’s relatively easy to move back-and-forth between IC and Tech Lead it’s a great way to learn what you like, and don’t like, about management and test the waters of the Management track.


Unfortunately, most Engineers don’t get much (if any) formal training on this new role before they begin. That’s why we’re offering this guide.

Based on the three major roles-with-a-role, this guide will dig into what being a great Tech Lead entails and offer tips for performing well. First up, let’s talk about the project planner role of the Tech Lead.

Project Planner

Project management is a much bigger part of a Tech Lead role compared with the individual contributor. Now you’ve got to think about things like how to prioritize work, who should be working on what, and how to maximize the work your team can do in parallel. Business strategy and stakeholder management are now essential parts of your job.

“Many tech decisions are business decisions,” Daniel de Castro Ruivo, Founder at, wrote, explaining why entrepreneurs need to know basic tech concepts. The inverse is also true. Because many tech decisions are business decisions, a tech expert needs to know the basic concepts of business.

Part of project management is explaining what’s going on with Engineering to other parts of the organization, and explaining what’s going on with other teams to your team. Stakeholders may include product managers, project managers, designers, and others with varying levels of tech savvy. So the ability to break down highly technical information concerning your team’s status and challenges is essential. You also need to be able to gather business goals and requirements from these outside teams. The more you know about the business, the less time they’ll have to spend explaining.

Lastly, a good Tech Lead is more comfortable with ambiguity and able to accept sub-optimal solutions than an individual contributor. When to accept good enough and when to push for better is ultimately a judgment call. So you’ve got to be good at making them when you don’t have a clear-cut, data-informed answer.

How to prepare

Find and follow Engineering leaders who are good at project management and learn from them. For example, Jon Thornton, Engineering Manager at Squarespace, wrote recently about how he prioritizes the major parts of a big project. Good sources for high-quality advice on Engineering management, including project management, include First Round Review, Chelsea Troy, and (shameless plug), the Clockwise Blog.

Internal research is also your friend. Find out where the strategy documentation lives. Find out which internal leaders you need to get up to speed with. And find out who the stakeholders you need to know more about are and get to know them better.

It also helps to be prepared to contribute meaningfully to discussions with stakeholders around architecture. For example, you may want to have input on the cost–benefit analysis of a homegrown vs purchased component. And as a Team Lead, you might want to influence how systems are partitioned and assigned.

It’s a good idea to spend some time familiarizing yourself with operationally defined system requirements before these discussions happen. At the same time, no one should expect you to come in knowing everything about your architecture. So don’t be afraid to ask “stupid” questions.


The Tech Lead role requires a lot more communication than you had to do as an individual contributor. Now influencing, persuading, coaching, advising are a big part of your job. You’ll likely oversee and review other developers’ code. You’ve got to provide correction and feedback while keeping morale and motivation high. You help set the direction for the team. “A tech lead requires skills that include coaching, influencing, facilitating, motivation and delegating,” wrote Ben Rossi, Editorial Director at Information Age.

Then you’ve got to help sell everyone on major technical decisions, making sure they understand, buy into, and follow them.

Paweł Ledwoń, CTO at Pusher, writes that Tech Leads are responsible for answering questions with high impact on the team’s productivity and morale. These include:

  • Are our services reliable enough?
  • How can we improve performance?
  • Which database is the best choice at this stage of the product development?
  • Can we afford more technical debt?

You’ll also need to help referee and break stalemates when fellow coders argue. The Tech Lead “should act as a tiebreaker when the team is stuck between two similar solutions, and they should keep the team from thrashing by keeping the team from continually re-opening decisions that have been made,” Principal Consultant and Developer Jeff Norris wrote.

While you’re trying to become proficient with people, your tech skills will likely stall. Which is precisely when a junior upstart will join the team and show you up. That’s what happened to Peter Gillard-Moss, Head of Technology for Thoughtworks' Technical Operations, when he became Team Lead. “As the tech lead, I felt that I had to prove myself as the most technically capable,” Gillard-Moss wrote. “I’d feel insecure every time they demonstrated their ability to others (especially my managers), concerned that they’d view them as more suitable for my role than I was.” This can be tough, but there are workarounds.

How to prepare

When it comes to working with people, empathy is your friend and ego is your enemy. Be open to verbal and non-verbal feedback on your communication style. Try to put yourself in others’ shoes when communicating. Ask stupid questions. Over-explain. And let go of the idea that you need to be the person who knows the most about the technology. Your focus needs to switch to motivating your team, running productive meetings, and delegating work.

Norris recommends having “water cooler conversations” with your project’s stakeholders and your teammates. Go beyond work to ask about their kids or favorite restaurants. These kinds of conversations can be essential for building the kind of rapport you need to get stakeholders to give you bad news, offer timely, relevant feedback, and get you involved earlier in the process. “Those relationships are important,” Norris wrote. “You can’t retroactively create a relationship, but you can proactively build one.”

Software Engineer

Unlike an Engineering Manager, who may not do any more coding, a Tech Lead still has to code. How much depends on the organization and its needs. There are only so many hours in the day. So if you get a slew of new responsibilities, it stands to reason that you’re going to have to carve out time for them from your current responsibilities.

On Reddit, user william_fontaine wrote that when he was working as a lead he was only getting to code about five hours per week. The rest of his time was divided among non-project meetings (20-25 hours), reviewing other developers' work and design (5-10 hours each), “and a few hours of looking for a new job where I wouldn't be a lead anymore.” Ouch.

Principal Consultant and Developer Jeff Norris has to balance his individual contributions with the overall productivity of the team when he’s Tech Lead. “It usually ends up being more important to focus on the team’s productivity,” Norris wrote. “It no longer matters whether I get any stories done or not; what matters is whether we as a team are successful. I might go through a week and not commit a line of code, because I am bouncing around removing roadblocks so that the team can be effective.”

In the The Geek’s Guide to Leading Teams presentation, Engineering Management consultant Pat Kua wrote that Technical Leaders should spend about 30% of their time coding.

The problem is that when you do sit down to code, you’ll get interrupted a lot more often. “It is very difficult to get into the groove of writing code if you’re interrupted every hour by a meeting,” Camille Fournier wrote in The Manager’s Path.

Due to a phenomenon called “attention residue,” it takes around 20 minutes to get fully focused on the task at hand. Which means your productivity falls as your number of interruptions increases. So not only do you get less time to code, but you’ll get less code written in that time.

Since code is easier to measure than your new responsibilities, it’s easy to get down on yourself about what feels like a decrease in productivity.

Another hurdle is that now that you have more responsibility for the team’s code, including tech debt examples, you may be tempted to go in and fix errors yourself. This is a mistake, though. First, because it’s a sure path to overwork and burnout. Second, because it will disempower your teammates. And third, because it shortchanges them of the opportunity to learn and grow. And as a Tech Lead one of your goals is to help your team get better at their jobs, not do their jobs for them.

How to prepare

A good Tech Lead cannot code as much as they did when they were an Individual Contributor. And for people who love to code, that can be tough. Step one is to stop evaluating yourself based on how much code you write, how good your code is, or how well you know the technology. That’s a recipe for unhappiness. Instead, focus on getting good at the tasks now under your purview. Does your team understand what’s going on in the company? Have you set a roadmap and are you sticking to it? Can you identify underperforming teammates and flag that to your manager? Are you aware of any skill gaps on your team and have you flagged that to your manager? While not all of it will apply, How to evaluate Engineering Managers can help you better understand the KPIs of your new role.

Rather than mourn your loss of Focus Time, work on opening up more of it for your team. "It's important to get your team into a schedule that allows them to be focused on development for long stretches of time, because they will need to focus for several days on coding problems,” Fournier wrote. “Part of your leadership is helping the other stakeholders, such as your boss and the product manager, respect the team's focus and set up meeting calendars that are not overwhelming for individual contributors." Fournier also warned that “The worst scheduling mistake is allowing yourself to get pulled randomly into meetings.”

Luckily there's a free tool that can automatically create more Focus Time for you and your team.

Going forward

So, what is a Tech Lead? A Tech Lead is a talented Engineer who has an interest in honing their communication, project management, and coaching skills. As many of these skills are essential for management, trying out a Tech Lead role is often a good way to see whether management is for you. And being promoted to Tech Lead is a good way to gain greater influence on your team’s priorities and overall direction.

But the role isn’t without its challenges, including having to step back from writing as much code as you used to, having to switch contexts far more often, having to spend more time doing things that you’re not good at yet, and spending a much larger percentage of your day working with people.

The faster you let go of needing to know everything already, the faster you’ll learn everything you need to know. And the better time you’ll have along the way. Imposter syndrome is rampant here, and the way to head it off at the pass is to recognize that you weren’t promoted because your manager thought you were good at all this already. They promoted you because you showed an interest in and aptitude for learning it. So ask questions. Lots of questions. Stupid questions. Embarrassing questions. Take classes. Find a mentor.

And, of course, if you haven't, try Clockwise. We make it easier to make time for what matters and kill it in whatever role you choose.

About the author

Cathy Reisenwitz

Cathy Reisenwitz is the former Head of Content at Clockwise. She has covered business software for six years and has been published in Newsweek, Forbes, the Daily Beast, VICE Motherboard, Reason magazine, Talking Points Memo and other publications.

Make your schedule work for you

More from Clockwise