Two Lessons You’ll Learn in Your First Year as a Tech Lead
I’ve been a tech lead for about a year now and I’m not dead yet.
That’s not a lot of time in the grand scheme of a working life, but since tech lead years are like dog years I’ve got a battle scar or two. These are some of lessons they’ve taught me.
The following points are based on my own experience. Since I’m still new to the role and the responsibilities of being a tech lead differ from company to company, you might disagree with them. That’s great! Leave a comment about it.
1. Saying no is the hardest skill to learn. But also one of the most important.
As a tech lead, you likely got the role by saying yes a lot. When a new initiative came up, you leapt on the bandwagon and drove it through. When a stakeholder approached the team with questions, you took the time to sit down with them until they were satisfied. You spoke up on an issue of engineering standards or volunteered to give a presentation to the rest of the business. Whatever it was, yes was the answer.
That worked to become a tech lead. But being a tech lead? Saying yes all the time is a recipe for disaster.
The activities you used to volunteer for are now daily expectations as part of your role. Which means your time is now more precious. And you are a bigger target for questions, problems and interruptions from the rest of the business.
One thing you learn quickly is that everything is urgent to somebody. On a given day, you might find someone needs the answer to a question at the same time someone else needs this report updated, someone’s found a bug that needs to be fixed immediately, you need to look at someone’s pull request, your product manager needs this project to be finished early and doesn’t want to waste time on a change that another stakeholder needs to be in there. All this while you’ve got a meeting in 10 minutes that you need to be in. And look, just before you’re about to figure out what to do, someone’s dropped by your desk with a conversation they apparently need to have right now.
When you first start in the role, this can be overwhelming. And it will be forever until you learn the magic two-letter word: No.
Now it’s unfortunately not as simple as grabbing the face of the petitioner, staring them dead in the eyes and whispering ‘Nooooo’. You do this tactfully. But saying no is never as hard you think it’ll be. The only difficult thing is deciding to say no in the first place.
It requires you to swallow your habit of saying yes, bottle up your instinct to jump over to help out the first person who asks, and stay your hand from pitching in on all shiny new initiatives you hear about.
Because tech leads are often people-pleasers, this can be difficult. It’s tempting to pile up the tasks and just deal with them by working more. But this is about way more than reducing your workload. It’s about doing your job effectively.
If you or your team take on any random task that comes your way, you’re probably doing a bunch of low-priority work. And this comes at the opportunity cost of the high-priority work that will make your team succeed. It’s not uncommon to see super-busy people spinning their wheels, constantly doing things but not having a lot of impact.
Learn to prioritise
Okay, we’re now super excited about saying no. But how do we actually decide what to say no to? Unfortunately, there’s no hard and fast rule. Each person will ultimately need to figure it out themselves. Stepping away from individual contributor work means operating in an environment of uncertainty, so there’s never going to be a clear right or wrong answer.
I personally find something called the Eisenhower Matrix helpful. It looks like it comes straight from a wanky business textbook, but I like it regardless. It was born from a quote from Dwight Eisenhower: “I have two kinds of problems, the urgent and the important. The urgent are not important, and the important are never urgent.”
Since winning a war against Nazis is probably more difficult than delivering a three-month software project (probably, you can’t be sure), I’m willing to give it a go.
The idea is to rank each problem by how important it is and how urgent it is. If you ever come across something both important and urgent (production is down!), you obviously should do it. No brainer.
Yet if a problem arises that is important but not urgent, you don’t need to drop everything to work on it. Instead, decide when you are going to do it. If you need time to write up an architecture doc, schedule it in your workweek. If a stakeholder needs to be brought along on a journey, schedule a meeting for them. If there’s a bug that can wait but should still be fixed, put it on a Jira ticket and decide when to play it.
If a problem is urgent but not important, delegate it. I don’t really like the word delegate here, since a tech lead is not a position of authority. You can’t say (and hopefully wouldn’t want to) “Jensen! Get your ass over here right now and fix this bug!”. Instead, you ask politely.
I personally find this one the hardest, because I have a natural inclination to shield the team from random interruptions. If a bug appears in your team’s jurisdiction, it seems like the obvious choice to let them continue with their deep focus work while you dig around looking for the cause. But your team is a team. Everyone has joint responsibility for the quality of the software you produce and the success of the team, so spread these interruptions around. Ask if others can look into to it if you have a lot on your plate.
The last quadrant is my favourite. If you stumble on a problem that is neither urgent or important, then why the hell are you wasting your time on it? For these problems, give yourself the freedom to give them the boot.
This can be difficult if it means turning an individual down. Perhaps someone is lobbying you to get the team to do a bit of extra work that you can see really isn’t important to either your team or the business. Saying no in this situation is difficult, both in figuring how to do it tactfully and also how uncomfortable it will feel. Your insides will squirm a little bit when you tell them ‘sorry, that’s not a priority for our team right now’. But when they walk away and you’re free to focus on what is truly important, you’ll feel liberated.
2. You can’t tell people how to do something.
Or rather, you can tell people how to do something. They just won’t do it very well. Plus they’ll probably think you’re a dickhead.
If you become a tech lead, you’re probably a little bit switched-on. You can solve things well in your technical domain or belt out some new fancy architecture before brunch.
That’s great. That’s why you’re a tech lead. You’re here to solve all these hard technical problems. Which means the first time a hard technical problem comes up, you should race to solve it the best you can, right? I mean, that’s why you’re there. Why would a business pay a person good at solving hard technical problems and expect them to sit on their arse?
It comes down to motivation. You can honestly say this in a million different ways: people want autonomy, they don’t want a micromanager, they will work better if they’re brought along on the journey, they need buy-in, they want to solve problems themselves, they want freedom. Et cetera. You get the gist.
The point is, your team will be more effective and motivated if everyone comes up with the solution together. I could babble on about pop psychology and make all kinds of claims about human nature, but the explanation just needs a bit of introspection. Do you like being told what to do? Personally, I hate it. It sucks. So why would anyone else in your team like it?
There are two situations where I’ve found this to be especially important.
Technical meetings
The most important place to keep your mouth closed is in technical meetings with your team. Whether you’re designing the architecture of a whole new feature or just deciding how to implement a user story, it needs to be in the forefront of your mind.
In these situations, your role is to be an opinionated facilitator. Get a collaborative vibe going. Make sure everyone is aware of the context and is at the same place in terms of their understanding. It’s important that everyone feels safe to contribute.
This means toning down your instinct to race ahead and solve the problem as quickly as possible. Now you’re a tech lead, it’s no longer about getting the right answer. It’s about getting everyone bought in to the right answer. So keep it slow and keep up the good vibes. The majority of the time the team will come up with a better solution than you would on your own anyway. Which shouldn’t surprise you. Bringing people with different experiences and perspectives together creates better outcomes.
There is a caveat, however. You are, at the end of the day, the tech lead. Which makes you responsible for the quality of the architecture you design as a team. That’s why, for particularly important architecture meetings, it’s a good idea to spend some time beforehand thinking about what architecture you would personally arrive at.
That way during the meeting you can subtly guide the team in that direction. It’s definitely an art. Too heavy-handed and you’ll be telling people how to do things. Too light-handed and the meeting might lose focus or arrive at an architecture you don’t agree with.
The important thing is to stay humble. If, during the meeting, the team decides to go in a different direction to what you planned, stop and consider. Is there a genuine reason your architecture is better? If not, it’s better to go with the one you decided on as a group.
Everyday problems
There’s a second situation where this mistake is frequently made — those small everyday problems the team run into. Good examples are bugs or disputes on implementation details.
These are definitely more subtle and a lot easier to get wrong. It’s instinctual when a problem arises to leap towards the probable cause and propose a solution. Worse still, to delegate it afterwards.
Imagine two responses to this common scenario: a mysterious bug appears in production and is assigned to your team. Based on the description, you’ve got a fairly good idea what the problem is.
In the first imaginary response you take a 10 minute look at the problem, figure out the issue and the best solution. You describe the solution to the newest member of the team and ask them to implement it. They do so in an hour.
In the second imaginary response you ask the newest member of your team to look into it. With occasional guidance from teammates who are more knowledgeable about that area of the codebase, they manage to figure out the cause, triage it and then solve it in three hours.
Which has the best outcome? If you were to ask the reporter of the bug, your PM, or any external stakeholder, it’d be the first way for sure. It took a third of the time and the solution was optimal.
What about the team itself and the newest member? Which had the greatest learning potential? Which built confidence and set up the team to succeed the next time a similar bug arises, or if you aren’t there?
The second, of course.
It seems like an obvious choice on paper, but in the heat of the moment when you’re stressed and stakeholders want things done now rather than later, it’s easy to dictate solutions rather than engage your team. But the discipline to take it slow is vital to helping the team improve.
That’s it. Two of the lessons I’ve learned the hard way over the past year. If you’ve got your own lessons you’ve learned, I’d love to hear them.
