What I Learnt Becoming a Tech Lead

I transitioned into a tech lead role around 9 months ago and I didn’t quite know what to expect. I thought I would share some of the things that I have learnt since then in case it helps anyone else looking at that role. The tech lead role is varied and these learnings come from the particular flavour of role that I am in, so mileage will certainly vary¹. Furthermore, it would be remiss of me not to acknowledge that as a white male I will undoubtedly face fewer challenges moving along this path than people with different genders, ethnicities and abilities.

Don’t write code on the critical path

The most stressful times I have experienced in the role so far is when I have tried to contribute code on the critical path (i.e. the release is blocked until I finish the code I am writing). Moving to a tech lead role has meant that my schedule has shifted towards manager’s time so I have fewer blocks of uninterrupted time for programming. Trying to deliver code alongside all the other responsibilities of the role mean that I have either ended up working long hours or we miss the deadline - neither of which feel great.

If it is unavoidable then I try to pair with another developer so they can take the reins if when I get pulled into meetings.

You’ll write less code than you think

On the above, the amount of code I write day to day is way less than I thought it would be. I scratch the coding itch largely from fixing up technical debt or poking into bugs.

Defending your calendar is a crucial art

This is perhaps less particular to being a tech-lead, but I have found that the art of defensive calendar scheduling is crucial in making sure I have time to focus. I schedule blocks of time as an Out of Office in Google Calendar (it appears as a tab when you schedule a new event). If meetings are scheduled in that block they are automatically declined.

While we are talking calendars here are some related calendar tips I use to reduce cognitive overhead when handling my calendar²:

• Go into calendar settings a turn on the setting to dim past events. It makes it easier to focus on current and upcoming events.
• Go into calendar settings and turn on the setting to hide declined meetings. It reduces visual noise.
• You cannot be in two places at once, so decline meetings you aren’t attending. Don’t let them just overlap.
• Color code your calendar, so you can tell at a glance what type of meetings you have coming up

It’s not necessary to be in every conversation

It is not necessary to be in every conversation - if I am bringing context my team doesn’t already have then it seems like a bit of a smell. I try and give people the right information and parameters to have good conversations and make good decisions. A system of working out loud in the team also helps here, as I can see decisions as they get made and step in where necessary.

This is also relevant.

Transitioning in your existing team can be hard

As tech lead, I am accountable for the technical output of the team I am in. This can mean that sometimes I have to push the team to do something that they might not want to do. Moving from being a peer to a position of leadership can be challenging as your relationships and relative priorities shift.

I found that over time as new people came into the team and I spent longer in the role, the relationships re-established themselves along new lines, but the transition is hard.

It is useful to have a vision

It is really useful to have a clear technical vision of where the team are heading towards. The team and I need to make decisions every day that will impact the future state of the system. Knowing what we want that future state to look like can help us make those decisions and ensure we are heading in the right direction.

You don’t have to be the most experienced engineer in the team

I am not the most experienced engineer in my team. This can seem initially challenging.

However, in a lot of cases you have become a tech lead not because you are necessarily the best engineer in the room but because of the other skills you can bring. You are not expected to solve all the hard problems yourself.

I am finding that it is often more important to bring wider context (“Ah, that would align with the work that Team Scooby are working on.") and ask the right questions (“How are we going to roll back if this fails?"), allowing the engineers (more experienced than you or not) to do their best work.

Clarity of expectations is important

I highly value clarity. One thing I have learnt is the importance of communicating clear expectations.

Often, when you ask someone to perform a task, you have an expectation of what the output of that task will look like. Making sure that you communicate that expectation clearly means that they are set up for success and that you get the outcome you anticipated.

Communicate impact

When giving updates to stakeholders such as product managers, project managers or engineering directors, tell them the impact of that decision upfront.

We have decided to spend some extra time refactoring the Goose Protocol. The impact of this is that we will have to push the release out a week, but it will save us time when we implement the Duck and Chicken protocols next quarter.

Clearly communicating impact ensures that you and your stakeholders are aligned and they are not left trying to read between the lines. This helps you as they can then clearly commiunicate on your behalf in the meetings you aren’t in.