Tech leads are overwhelmed. Here’s how to take back control

Estimated reading time: 8 minutes

Key takeaways:

• As a busy tech lead, focus on what matters. Log, triage, and delegate.
• Lead with clarity: set priorities and make tradeoffs explicit.
• Protect capacity! Guard code time and flag overload early.

---

The role of a technical lead can be challenging. It’s perfectly natural, and often unavoidable, to feel overwhelmed and struggle with the quantity of things that need your attention.

You are expected to balance business priorities and questions from cross functional teams, mentor and help your team members grow, and are responsible for the technical implementation of large features, often with deadlines that necessitate reprioritizing and juggling multiple tasks at once.

Let’s explore some techniques you can use to reduce this feeling of overwhelm and help you stay calm, focused and, most importantly, in control.

We’ll talk about how to ruthlessly prioritize, balance your focus, and manage expectations to ensure everyone knows where they stand.

Triage and delegate

As a tech lead, there is a near constant flow of information coming to you:

• Questions about feature complexity or estimates from product managers.
• Design docs and code changes for review from your team.
• Bug reports and feature requests for the product you are working on.
• Deadlines for work that you need to implement.
• Questions from other business functions about privacy and security as you work to launch your feature.

When I first made the move into technical leadership, I made the mistake of wanting to do it all. I felt solely responsible for everything my team and I did. I made two mistakes:

1. I thought everything was of equal importance and tried to do it all.
2. I didn’t lean on my team to delegate work to them.

Now I have a system that works much more efficiently to cut through the noise and focus on the tasks that are most pressing, and the ones that are best done by me.

• I log everything I’m asked to do into a to-do list application. My preferred choice is our internal bug tracker, but pick whatever app you like best. If someone pings me on chat and needs a detailed reply, I log it. If I get an email with some questions, I log it. I do not use unread chat messages or inbox items as my list because I’ll inevitably forget or let something slip through the cracks.
• Now I have my list, at the start of each day I triage them and ask:

1. Is this important? I want to make sure I’m focusing on the highest priority work.
2. Can I delegate it? If it’s important, does it have to be me who does it, or could I ask someone on my team to take a look?
3. Does it align with our priorities? At any time, our team has a set of focuses which we set every six months. If the request doesn’t align with those, then I’m far less likely to do it.

• Once I’ve done this, I have a list that is prioritized and full of items that I am best placed to solve. 
• I’ve also had to come to terms with not being able to do everything. You have limited time available to you, and not everything can be done. Be content with the fact that you will sometimes have to say no, or push some work back by many months.

Communicate clearly without broadcasting panic

Imagine you are on a team working to deliver some features and your tech lead says: “wow, we have loads to do this month. I’m not sure how we will get it all done, but let’s try our best.”

Compared to: “I’m aware there’s a lot on everyone’s plate right now. Let’s make sure we prioritize the work on the new checkout flow as that’s most important. Please talk to me if you need any guidance on where to focus.”

The first approach communicates your feeling of stress and overwhelms the team. It also implicitly suggests that all the work has to be done, and it builds pressure on people to deliver.

It also gives people no space to reach out to you or ask for help, or to push back if they feel overwhelmed by the workload themselves.

The second approach is much more productive. It acknowledges the heavy workload, provides clear guidance on what to prioritize, and leaves your door open for people to come and talk to you if they need a hand.

Saying no and making it tradeable

As a tech lead, you will be the first person that stakeholders and senior leadership get in touch with when they have an idea or something that has suddenly become urgent and needs fixing.

The problem is that you’re going to get more of these requests than you can reasonably deal with. In my experience, everyone thinks their problem is urgent, but few problems people perceive as urgent actually are.

If you allow all these requests to be actioned you undermine your team’s planning process and list of priorities, causing routine disruption.

The challenge is that it’s very hard to actually say no, particularly to senior management. In these scenarios, the power balance can be unclear and it’s difficult to know where you stand.

However, you have a responsibility to your team to ensure you are focusing on the most important things. What I’ve learned is that you can say no in a way that is productive, opens the floor for negotiation, and is less blunt. Here are some examples:

• I’m afraid we can’t get to that for a few weeks, but I can ensure it’s prioritized for the next sprint. Is that OK?
• Sure, we can take on that extra work, but it means we’ll probably not ship the new checkout flow until next month. Are you happy with that tradeoff?
• I don’t think we have capacity to take on all that work, but we might be able to do parts of it now and complete it next month. Let’s sync to see if that works?
• My initial instinct is that this work is a lower priority than the work already in our backlog. Can you help me understand why it needs to happen now and can’t be deferred for a few months?

In all of these replies, you are either saying no, or you are making it clear to the requester what the consequences will be and what work will have to be dropped.

This is a really effective way to make people realize that their work is not as important as they thought, but now you’ve managed to not overload your team, and have made the tradeoffs clear.

Keepi your hands in the code

The role of a tech lead involves a permanent balancing act between strategic thinking, cross functional communication, and technical expertise.

While you will be expected to spend less time heads down in the code implementing features, it’s still an important part of your job. You are solely responsible for the delivery of features on your product and, in particular, maintaining a codebase which enables your team to build features efficiently and robustly.

If you are not aware of the codebase and what it takes to build a feature, you cannot empathize with your team when challenges occur or proactively take steps to reduce friction.

It is very easy to become a tech lead and get swamped by incoming feature requests, bug reports, and strategy meetings. Before you know it, it’s been weeks since you landed a change. Or you spend your week jumping from meeting to meeting with only brief 30-minute slots to code, which is never enough to get deep into a technical problem.

The best approach to this is to make the time non-negotiable and deliberate:

• Try, when possible, to group your meetings together. I have all 1-1s with my team on one afternoon in the week. It’s an intense afternoon, but it means I have large chunks of time with no meetings to balance it out.
• Take some of those empty chunks of time and block them in your calendar. Make it clear that you will not (barring urgent exceptions) take meetings during these blocks. Don’t go overboard; if you schedule four hours every single day, people will ignore them because it’s impossible to meet with you. Find a balance that works for you and your team.

Don’t forget that a large part of the technical lead role is to be present for your team and ensure they can make progress. It’s not a role where you can disappear offline for the majority of the week, but don’t be afraid to guard some time.

After all, most people who are in a tech lead role are there because they are good at and enjoy implementing features. Make sure you get some time to do it!

Recognize when things might be broken

While we’ve focused on techniques to process and deal with a large workload and the pressures of running a team, it’s important to be aware of problems that might be outside of your control.

If you are feeling overwhelmed and unable to shake the feeling, raise this proactively with your manager. Make sure you are both aligned on your team’s priorities and their expectations match yours. 

Foster an environment with your manager where you can be honest. Some of the most productive 1-1s I’ve had have come from me saying “I honestly don’t see how we can deliver this feature by that date. How do you see it?”

By asking for their opinion you can surface places where the two of you are misaligned or have different perspectives. This can either help you realize you misunderstood – perhaps the scope isn’t as large as you expected – or help your manager recognize that there are technical circumstances they hadn’t seen that mean you might need an extra pair of hands.

It is important that you have a system to try to avoid becoming overwhelmed, but that doesn’t mean you shouldn’t push back or raise concerns when you have them.

Find your rhythm as a tech lead

The tech lead role is fundamentally difficult because you are asked to remain a technical expert with deep knowledge but also to be a mentor, contribute to strategic planning, and deal with a constant stream of incoming requests.

Never be afraid to take a breath, take stock of everything around you, and process things one step at a time. Protect your team and maintain an honest but clear dialog with leadership about priorities and your team’s capacity.

If you can prioritize effectively, be honest about capacity. and communicate clearly with your team, you’ll be an impactful, empowering, and respected technical lead.