On Becoming a Tech Lead

Hi, I'm Suez 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 you know, the role is supposed to be 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.

And 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 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.

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. You're usually 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 helping, 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. Force multiplying is the main thing that tech leads do.

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? 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. 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 projects than if you're just the person taking direction and writing code.

And 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 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, you know, 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, like maybe a couple of weeks. That one is really easy. That one is really hard.

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 know, you have a bigger impact and that feels nice. It's an interesting different kind of challenge than just getting a sliced up story that's, you know, if you're doing Agile, you get a sliced up story, it 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 the, 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 the, 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, more good stuff happens. So, you know, kind of 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, you know, 20 years later when it's like, huh, 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 some, when, you know, 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. You know, 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, you know, if you make a stupid suggestion, nobody is 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, what they might think is a stupid idea, but is 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, you know, 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, etc. 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 are 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 be 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 get it and help them get it done. If you try to do the work of an entire team, you will burn out. So 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 know, you're there to help the team be effective, not to do the teams work for them.

So do less, let people struggle, let them fail, let them fall flat on their face. If it's not working, you know, 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, critical, 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 are 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 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. The idea being that you make a plan and you commit to a plan and then when you make these decisions you just hold them in your head. The rest of your team, it should look like you're mostly certain, you should explain your reasoning, you should explain that there are error bars in 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? 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 back end 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. 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 and, 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 a 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 software, and basically into software.

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. But 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. 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, you know, 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 a 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. You know, 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 the whole system should fit together. And, you know, 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 what's coming next, what to do in the future, which parts of the projects can be like swapped. Hey, you know what? This is a lot of work that we don't need to do right now. If we flip the road map around, we're going to get a lot more value ultimately faster, and we're still going to get everything done in the end. And I personally find that a lot more fun than just banging on a keyboard and, you know, and, you know, 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. Well, welcome. How are you today? I'm doing really well. Yes, join our virtual stage. Yeah, it's very comfortable up here. Yes, thank you so much for being here and for that, for sharing your experiences.

I'd love to dig into some questions with you now. First though, I want to discuss the answers to your poll question. So the question, you know, 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'd 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, I agree, for me, solving fuzzy, 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 No, I was gonna say, if you know that joke that when you press, 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 impression. 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, you know, that's okay too. So awesome.

So, all right. So, first question here from, from, from the audience is, says, you know, 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, 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. Usually these days we do both of, both of them kind of paralleling simultaneously. And then if you go into architecting, I think a lot of, where a lot of architects run into problem, into trouble, is that if you become too abstract, you lose the coding part and you start, I think we've, 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 write the first line of code and it all breaks apart because some basic assumption doesn't work.