Tech leads oversee and lead challenging projects, meaning they regularly take on work that may span multiple months, or even years. These projects are complex due to technical requirements, additional hurdles of managing workloads, conflicting priorities, and the inevitable need to flex plans based on unforeseen circumstances.

How to avoid the key issues of being a tech lead 

A key part of any tech lead’s responsibility is to plan projects and consider how the work relates to other tasks the team is doing in parallel. Spending time identifying any potential hurdles upfront will help you jump over them, before they occur.

The below techniques may be useful in mitigating these risks.   

Allow breathing room in estimating and workload management

Things always take longer than we expect. People can be ill and work can uncover a ticking technical timebomb. It is because of these sorts of bumps in the road that it is always best to assume there will be “slower” periods where the project doesn’t run so smoothly. 

For instance, if your team is small even one person taking vacation for a short period can impact your velocity. If you decide a project will take six weeks, that should include allowances for vacation, illness, and technical challenges that increase the scope of the work. If everything goes perfectly, you’ll be done early – which is a great feeling!

Include a pessimistic worst-case scenario 

In our kick-off meetings, we include a “pessimistic worse case” section where we sit and list all the things that could go wrong. This might seem negative, but it is a way to generate a checklist of items that you can investigate ahead of time to see if any are going to cause you additional headaches or workloads. Perhaps someone realizes your project might interact with another team – maybe you can check in with that team ahead of time to flag this project and see if they have any concerns, or even capacity to assist you.

Be transparent 

Be clear with your leadership team and stakeholders on how this project will impact and relate to other projects. Is future work dependent on this being complete? Will other work be possible while this project is underway?

Technical migrations in particular can often grind feature work to a halt as no one wants to build features using old, technical architecture while migrating to a new architecture. You should aim to avoid this scenario if you can, but if the migration is required, make sure leadership knows how it will impact any feature work they may prioritize.

Think about the rollout

Think about how this project can be rolled out incrementally. Frequent, small changes are easier for engineers to work on and far less risky to your users.

Gradual launches also enable you to focus on other work if necessary without leaving things in an incomplete state. This approach is sometimes referred to as the “scout rule” i.e., leaving the campsite [code] in better condition than you found it. Think of projects as a series of incremental improvements, rather than single, large ones makes them easier to plan and implement.

Tips for when the project’s underway 

Make sure to maintain the momentum gained in the planning stage once the project is underway. 

Checking in

One of the biggest challenges with a long-running project is making sure you have regular, constructive check-ins with your team about how the work is going. 

If we’re not careful, it’s easy to get trapped in a false sense of security during project updates and then suddenly realize the project has gone over its initial time frame with no idea of when it will wrap up. 

During the team meetings, syncs, or check-ins discussing these themes, try to questions that get more specific on the status:

• “Do you anticipate any issues this week with what you are working on?”
• “Has anything you’ve done so far been harder than expected?”
• “Do you think our initial estimation of [X] weeks is still accurate?”
• “Is there anything I can do to unblock you here?”

Check-ins allow you to pinpoint and discuss elements of the project your teammates own, serving as a platform to keep projects on track. Caution is advised here, as you have to be careful to not stray towards micromanagement, making sure it’s clear where your role stops and your teammates’ begins. This can be a difficult balance to maintain – there are no hard rules so it depends on the individuals in the team. Some approaches I’ve used in the past include:

• Asking people how they prefer to work with a tech lead – Some prefer regular catch-ups so they can update me, others prefer a fortnightly sync, reaching out proactively with questions or updates in between meetings. Others much prefer async emails or chat messages, with video calls kept to a minimum.
• Clarify responsibilities – Early on in the project clarify what your expectations are of your team and what pieces of work they should be owning. A good way of doing this is to have people create design documents that describe the steps they plan to take. You can review this and sign off on it before leaving them to get into the details.
• Learn to let go – Watching your team or product grow can be hard as you have to accept that you can no longer own and control every last line. Trust your teammates and let them take on work to free you up to think about the bigger picture.

Finally, make sure you drive a team culture where people do not fear giving you bad news. It is important that you have team members who feel comfortable asking you for help or admitting that they are stuck. Empower your team to come to you with concerns. Weathering unexpected technical complexities and changes to timelines are part of a tech lead’s role and it is on you to unblock and work with them.

Accept that plans change

Every single team and every single tech lead, however experienced, will need to change plans at some point, for reasons both in and out of their control. No matter the circumstance, it is important to maintain a positive attitude and not allow (perfectly reasonable) frustrations to impede your work.

If the plan has to change because something has overrun and a deadline is likely to be missed, or previous work has not gone as intended, it is important to hold a blameless discussion about this. Could this have been anticipated ahead of time? Or did we just get unlucky? 

If the plan has changed because of a shift in priorities or direction from leadership, it is best to accept it and embrace the new reality regardless of whether you agree or disagree with the decision. But make sure you clearly and calmly communicate back the impact of this change to your team.

In my experience, many people will ask you to squeeze some extra work in i.e., “Does your team have capacity to quickly provide X by next week?” In this situation, make it clear that the request can be fulfilled, but at the cost of other planned work. Your team has finite capacity and if additional work comes in, it has to be at the expense of something else.

Wrapping things up

It is part of the role of a technical lead to embrace and accept that time-consuming, complex projects will occasionally hit roadblocks. It is important to stay flexible while embracing that a stumble is not a reflection of your own or your team’s abilities.

As a tech lead you have to walk a fine line. Planning ahead is important, but cannot be the approach for everything, as there will always be unknowns. Learn from the unexpected unknowns and scrutinize them to see if you could have caught them earlier – how you react to them is most important. This may seem obvious in hindsight, but planning as a tech lead has an element of diminishing returns. Sometimes you have to dive in and accept the challenge.