On Becoming a Tech Lead


Tech lead sounds like a lot of work. And not the fun coding kind either. Why would you ever want that? What does it feel like when you get it?

In this talk Swizec explains why he took the step towards technical leadership, how his priorities changed, and why it means he’s doing more engineering than ever. A whole new world where writing code is the easy part.


Hi, I'm Swiss and I'm going to talk about some lessons learned after becoming a Tech Lead, why you would even want to be a Tech Lead and what is it that Tech Leads even do. So first of all, what is a Tech Lead? The definition or the job description of a Tech Lead kind of varies between different companies. Some companies think of this as one type of a staff engineer, some people think of it as a stepping stone towards becoming a staff engineer. And the role is supposed to be probably one of the first or the most common ways of getting into the technical leadership track, which is sort of a parallel track to the management track where a lot of companies these days have a technical track where you go from junior engineer to mid-level engineer to senior engineer, and there might be multiple levels of a senior engineer. And then it kind of stops. You can be a senior engineer basically for the rest of your life. It's usually considered a terminal title, which means that once you're a senior software engineer, we trust you to do work independently, to successfully follow business objectives and to get your stuff done. Then you can go beyond that either on the technical track, which eventually which goes to staff, principal, distinguished engineers, and all of those people. Or you can go on the management track, which is engineering manager, VP, CTO, and that sort of thing. Like, I don't know the exact steps. Usually there's a bunch of them between different companies. And where it really gets tricky is this fork in the road where you go from being just a senior engineer or being a senior engineer towards something more. What is the next step? Often tech lead is the first next step that people take. And if you look at it as a fork in the road, it's usually tech lead is usually more on the side of the technical leadership track, staff, principal, et cetera. And team lead is the first step towards the management track. Some companies mix those two, but that's how it usually works. And the idea of a technical leadership track is that you are not responsible for managing people, at least not directly. You're more responsible for managing the technical direction of a team, especially as a tech lead. You are focused on a specific team. And you are, so you're focused on a specific team, which means that while you're sort of still an individual contributor, your output is now being judged by what the team does as a whole, except that unlike a team lead or a manager, you're not dealing with the people management responsibilities. You don't have any direct authority. It's more about soft influence and directing people and basically helping the team make good technical decisions to make sure that projects flow smoothly, that you're working with your product owner and kind of force multiplying the team. I would say that force multiplying is probably the main thing that tech leads do. And no, what was I going to say? Yeah, so force multiplying is the main thing that tech leads do. And the question that a lot of people ask is why would you even become a tech lead? What is it that makes somebody want to become a tech lead? And honestly, it varies between individuals. But for me, the main reason I decided to become a tech lead was that after doing this for many years, coding kind of became the easy part and I started looking for more interesting things to do than just banging out code. And one thing I realized while working on a team in a hyper growth startup is that there is a lot more you can get done if you're not the person banging your hands against the keyboard. You can have a much higher impact, a much bigger contribution if you're helping the entire team get more stuff done and work on the right project than if you're just the person taking direction and writing code. And one way of getting all of that, one way of having more of that impact is that as a tech lead, you get to quote unquote be in the room where the bigger decisions are made, where product owners and other technical leadership is deciding what is it that this team is going to work on next, what is it that we're going to decide is important, what we're going to focus on. If you're in that room, you can help shape the roadmap and you can help with simple things like hey, we have these five ideas, which of these is actually achievable within a certain amount of time? And if you're in that room as a tech lead, you can say hey, that would take, I don't know, maybe a couple of weeks, that one is really easy, that one is really hard, and this other idea we probably shouldn't even try because it's just going to be a ridiculous amount of work and it doesn't look like the most important thing right now. So when you get to shape that roadmap, you get to help the entire team and the whole company as a result be more effective and get more done and make sure that you're working on the important things, which means that you have a bigger impact and that feels nice. And it's an interesting different kind of challenge than just getting a sliced up story that, if you're doing agile, you get a sliced up story, tells you exactly what you need to do and you go and you get it done. If you're a tech lead, you get to be there way before those stories are even sliced, sometimes before even anyone knows what the stories are going to be, you get to be in the room and help people decide what the stories should be, what the projects should be, and then help your team work on those. And I think what I'm trying to say basically is that it doesn't really matter how productive you are or how much code you can write if you are working on the wrong kind of project. And what I would say here is that I think the best kind of tech leads are the sort of engineers who will even get into leadership if that means that more of the right work gets done and more good stuff happens. So at least I personally take a reluctant leadership approach and some of the best managers I've worked with were always people who didn't see leadership and being a tech lead or a manager or those higher positions as, oh yes, that's the next step in my career, I got to do it to grow. The best people I've seen who take on that role are the people who will even do that if it means that everything is going to go better for the company and the project. So what are some lessons that I've learned while doing this role? Keep in mind, these are early lessons. I'm a fairly new tech lead. So the nice thing about these lessons is that they still come from a perspective of remembering what it's like not to be a tech lead rather than 20 years later when it's like, oh, what was it actually that felt new about being a tech lead? So the first lesson that I learned is that usually the person who becomes a tech lead is the strongest engineer on the team or at least usually they're a very, very strong engineer. So what you can do as a tech lead to kind of help the rest of the team and empower them is to be the clown. When the manager or the product owner is asking for ideas, one of my favorite things to say is, well, okay, so we need immutable data, but let's not use the blockchain. Funny joke, ha ha. But it's also setting the floor for what a dumb idea looks like. Because you're a tech lead, you have a lot of so-called reputation that you can burn or karma points. So if you make a stupid suggestion, nobody's going to think that you're stupid, but it frees up everyone else on the team to give their ideas because they know that they can't say anything stupider than what you just said, which then brings out a lot of their ideas, makes it easier to collaborate and make sure that nobody feels afraid about sharing what they might think is a stupid idea, but it's actually a really, really good idea and a great solution for whatever problem you're solving. So being the clown works really, really well. Another one is that engineers who get to being a tech lead, they're strong engineers, they take a lot of ownership, feel a lot of responsibility. I actually remember reading a study that said that feeling responsible and feeling sort of guilt, I've also heard it called tech lead's guilt, is that if you feel a certain kind of guilt towards not getting stuff done, that actually means you are great tech lead potential and staff engineer, et cetera, potential, because you take a lot of pride and a lot of ownership and you try to make sure that you get a lot done. But that is also a trap because once you're a tech lead, you become sort of quote unquote responsible for the output of the entire team. So it's very easy to get lulled into the role of trying to be the hero and being like, oh shit, that didn't get done, I'll just do it. Oh, that other thing didn't get done, I'll do it. Oh crap, this project is going poorly, I'll do it. Oh no, that engineer is struggling, I'm going to jump on a Zoom with them and help them get it done. If you try to do the work of an entire team, you will burn out. And I've seen this with a lot of my friends when they were early managers, they were like, okay, cool, I'm managing a team of five people and they were just doing the work of five people instead of delegating. So really important is to focus and think about doing less and letting your team do the work. You're there to help the team be effective, not to do the team's work for them. So do less, let people struggle, let them fail, let them fall flat on their face. If it's not working, after a day or two days, let them be, and then be like, hey, do you need some help? And then jump in. But you don't have to, you really, you have to consciously avoid trying to do everyone's work and give away your Legos and let other people shine, because I promise you it's going to be fine. Even if they don't do it the way that you would do it, it's going to be good. Focus on the outcome, not on how the work is done. And the next thing that comes out of this, I mentioned earlier is, you know, working on roadmaps and future looking things. It gets really, really confusing once you are beyond the senior engineer stage. Companies, it turns out, and I think this is true across the board with anyone I've talked to who was in a leadership position, nobody knows what the hell they're doing. It's like, oh my God, we have so many priorities, we have so many big, critically important projects. If we don't do that thing, the company is going to fail. If we don't do that other thing, the system is going to explode. If we don't make this customer happy, they're going to leave. And there's just so many critical, urgent things that feel like they should be the next thing you work on. But when you're presenting the team, you have to show leadership and yeah, so basically it's confusing up there. But what you have to do for the team is to have that sense of leadership and kind of almost play act or present a front of certainty. Even though you're not sure if you made the right decision or if you're not sure you're working on the right next thing, once it gets to the rest of the team, once people start working on it, you have to show some level of certainty. You have to, even if deep inside you're not sure you're doing the right thing or you're not sure about the technical decisions that you've made, you kind of just got to go with it and be like, and commit to a path. You look at different possibilities. Ideally when you're making plans for a specific story, you get everyone involved. So the whole team is coming up with ideas. And then when you have competing ideas, your job as the tech lead is to say, okay, that one is 60% bad. That other one is only 50% bad. Let's go with the 50% option and then reassess if it's not working out in the next couple of hours or in the next couple of days, depending on what your story cycles are like. So the idea being that you make a plan and you commit to a plan. And then when you make these decisions, you kind of just hold them in your head or in like, you know, the rest of your team, it should look like you're mostly certain. You can explain your reason, you should explain your reasoning. You should explain that there are error bars on your decisions. But once a decision has been made, commit to it, don't try to flip flop every couple of seconds or every time they come into a meeting and they ask you, hey, how should we do this? You know, don't change your decision or change your entire approach. But also really important when you are making a plan with your team is to leave enough room for the team to have autonomy and for everyone to feel like, not just feel like, for everyone to have space to contribute. Don't say, okay, for that button, you have to go to that file, change it to purple, go there to change it, to change where it shows up. You don't have to give them all of those details. You don't have to, and you shouldn't give all of the details to your team for what they're doing because then you might as well just do it yourself. It's more like, okay, you take care of the button, make sure it's in the right place. This is the place that we want it to be. You go take care of the API, build the backend API for this. You go work on the middle layer where the button is talking to the API. And then when we get it all together, we're going to figure out how to assemble it. Kind of make a plan more based on how the different moving pieces are going to talk to each other rather than what the actual moving pieces are going to be. And then let your team focus on the insides of each individual moving piece and figure out how to build the implementation itself. Which brings me to my next point, which is that as a tech lead, what you get to do is a lot more engineering and a lot less coding. And this is one of those things that it took me a really long time to realize the difference between coding and engineering. And the best way I have of explaining the difference is that when you're engineering, you can work with a whiteboard or a virtual whiteboard or even Post-it notes. And you can just draw circles, squares, arrows, and stuff like that on a whiteboard of some sort or on Post-it notes and figure out what the moving pieces are, how they should interact, how you should, you know, a lot of this is domain modeling, how you should break down a problem. What are the steps that it will take us to go from an initial valuable working solution to the full solution? So like, how do you get from a skateboard to a car, which is an analogy for a moving vehicle that, or a people transporter. You start with a skateboard, you end with a car, and what are the steps that get you there? What are even all of the steps in a business process that people are doing and how can you turn those into code and software? So it's a lot more, the tech lead's role is to do a lot of that breaking down and less of the actual final implementation and coding. It's important that you still stay in the code and that you do the work and that you're hands-on with the team. What you're focusing on day-to-day is a lot more engineering and then letting the rest of your team figure out the idly coding details where they build the actual implementation. This is one of those things where it's really hard to explain until you've tried it, but once it clicks, it feels very freeing, because at least to me personally, after I've been coding now for 25, 26 years, it's been a really long time, and what I realized is that the more of these systems you build, the more you see the philosophy and the structure behind the actual code, and then you can kind of, in your head or on a whiteboard or with your team, just move pieces around and figure out what they should be and how they fit together without even knowing or caring about the final implementation of those, because then the senior engineers and the mid-levels and the juniors and everyone else can work on the actual implementation after the overall engineering piece has been done. And also, it's really fun to code, so I personally still jump into a lot of the moving pieces, but I find that I'm much more effective and I have much bigger impact, and it's much more helpful to my team if I focus on the engineering parts and help them reason through the engineering parts. Sometimes it can just be asking good questions. When you have really strong senior engineers that are really good, that just need some guidance, you can ask them pointed questions to guide them into a certain direction and help them figure out how this whole system should fit together. And overall, I would totally recommend going for a technical leadership position and going on that track. It's honestly been the most fun I've had with coding and software engineering in a long time. It feels a little abstract sometimes, and it feels like you're far removed from the implementation, but on the other hand, you also don't have to do the parts that feel boring anymore. It's really nice to just work on interesting new challenges and focusing more on the higher-level things and figuring out what's coming next, what to do in the future, which parts of the projects can be swapped. Hey, you know what? This is a lot of work that we don't need to do right now. If we flip the roadmap around, we're going to get a lot more value ultimately faster, and we're still going to get everything done in the end. I personally find that a lot more fun than just banging on a keyboard and arguing on the internet about the best way to write a for loop in JavaScript. So yeah, if you get a chance, try it out. It's definitely interesting, and it opens up a whole new world of possibilities and a new world of software engineering that as a senior engineer maybe you didn't even realize was there. Thank you. Wow. Welcome. How are you today? It's a good way to turn the stage. I'm doing really well. Yes, you're in our virtual stage. It's very comfortable up here. Yes, thank you so much for being here and for sharing your experiences. Love to dig into some questions with you now. First though, I want to discuss the answers to your poll question. So the question, what's your most interesting fun part of software engineering? 60% said beating fuzzy problems into concrete solutions. 24% were, hmm, that's weird. Why did it do that? That was my pick personally. 16% said writing code. And I'm actually, I'm personally surprised that 0% said debating tabs versus spaces, semicolons versus not, Vim versus Emacs, considering how many tweets I see about those topics. But what do you think of these results? Do they surprise you? Yeah, they're a bit surprising. Okay, there we go. We got somebody responding that they like the tabs versus spaces debates. There we go. But yeah, I agree. For me, solving fuzzy problems is also the most fun part. So I'm happy that other people agree as well. Nice. And I'm glad that there is also still some love for debugging and figuring out how things work and why something went wrong if it did. So awesome. So we do actually have quite a bit of questions coming through. Oh, go ahead. Sorry. No, I was going to say, if you know that joke that when a non-engineer presses a button and it electrocutes them, they say, oh shit, I'm not going to do that again. When an engineer presses that button, they say, I wonder if it electrocutes me every time and presses it again. Exactly. Yeah, we're like taking things apart and seeing how they work and then hopefully being able to put them back together. But if not, that's okay too. Awesome. So, all right. So first question here from the audience is, says, you make an interesting point about engineering versus coding. And then they use the term architecting specifically. What do you consider the differences between engineering and architecting to be? So I think the difference between engineering and coding is primarily that when you're engineering, you're mostly dealing with solving the fuzzy problems and creating their solutions. Coding is like the implementation part of the engineering process. We these days, we do both of them kind of simultaneously. And then if you go into architecting, I think where a lot of architects run into trouble is that if you become too abstract, you lose the coding part and you start, I think we've probably all experienced so-called architecture astronauts that have a really great solution on paper, great diagrams, great schematics. Now just somebody has to go and implement it and you've read the first line of code and it all breaks apart because some basic assumption doesn't work. So I think engineering is like the sweet spot between those where you're doing just enough architecting to be thinking about solutions in a slightly more abstract way, but you're still doing enough of the coding part so that you actually get your hands dirty and implement those solutions and can see how they work and can adapt them in real time.
25 min
09 Mar, 2023

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Workshops on related topic