Today on the show, we welcome special guest, Kelly Wu. Kelly is a software consultant and as a consultant has worked with many different tech leads and teams throughout her career. Most engineering teams will have a tech lead and have experience either working with a tech lead or actually being one. Being a tech lead is not an easy job. They have so many hats to wear and are faced with many different scenarios, dynamics and people on a day-to-day basis. That being said, it’s almost inevitable that a tech lead is going to slip up and make a couple of mistakes on the job. Kelly joins us today to talk with us about the common mistakes that tech leads make. In addition, this episode is also offers some valuable tips on how to be an effective tech lead and guide a healthy team toward the ultimate goal of kickass code.
Key Points From This Episode:
Transcript for Episode 248. Common Mistakes Tech Leads Make with Kelly Wu
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast in fantabulous Chelsey Manhattan. I’m your host, Michael Nunez. Our co-hosts today.
[0:00:09.8] DA: Dave Anderson.
[0:00:10.8] MN: Our producer.
[0:00:12.0] WJ: William Jeffries.
[0:00:12.8] MN: Today, we’ll be talking about common mistakes tech leads make. Things happen all the time, at work and a tech lead may run into and slip up and have a couple of mistakes on the job.
[0:00:23.5] DA: It’s not an easy job, it’s not an easy job, you got a lot of hats to wear.
[0:00:25.8] MN: Yeah, and tech lead is pretty difficult. Before we begin, we have a special guest today. We have Kelly Wu. Hey Kelly, how’s it going?
[0:00:33.2] KW: Good.
[0:00:33.7] MN: Tell us a little bit about yourself?
[0:00:35.5] KW: Sure. Well, I am a software consultant and as a consultant, I work with very many different tech leads on all sorts of different teams, shapes and sizes, also been a tech lead on very many different teams, shapes and sizes. I think this is a really great topic as most engineering teams will have a tech lead and have experience either working with a tech lead or actually being one.
[0:01:00.3] DA: Yeah, I guess even if you don’t have a tech lead like somebody’s going to be leading in some shape or form, like you may not have the official title but you know, it may have some of the responsibilities, some of the hats.
[0:01:12.3] KW: Yeah, that’s a really great point for teams that I’ve seen that don’t have an official tech lead, either someone unofficially has it or that type of responsibility is distributed across multiple people.
[0:01:26.2] DA: I recently felt this responsibility, this weight on my shoulders as our team’s tech lead went on vacation. I had to take up his responsibility and it was like, “Okay, I get it, you got to do some meetings.” Yeah.
[0:01:41.8] MN: Some, yeah.
[0:01:41.9] DA: You’re not really writing some code.
[0:01:44.9] MN: Yeah, let’s dive right into some of the mistakes that happen. I think Dave just mentioned the idea of like, having a lot of meetings but sometimes the inverse can happen, and a tech lead may fall into the trap of writing code all the time.
[0:02:00.1] DA: Yeah, I mean, I guess if you’re a tech lead, you might feel like you have something to prove – you’ve got to be the best coder on the team.
[0:02:09.9] WJ: Yeah, I think there’s also sort of a super hero syndrome that can kick in where you want to rescue the project when you feel like it’s not going well and your way to do that is by doing the thing that made you successful in your previous role, which was an individual contributor and that’s just writing code. You just do more of that and you like, work the whole weekend, you implement the whole thing and then you go in on Monday and for some reason, everybody’s mad.
Like, “Wait a minute, I did this great thing.” Well yes, but it was somebody else’s ticket and they had already started on it and they were having a hard time and like now you just gone and done it for them. Okay, we’re going to hit the deadline but was that really worth it?
[0:02:58.6] KW: In a book called Talking With Tech Leads, where they interviewed a bunch of first time tech leads, one of the most common mistakes was the tech lead writing too much code. I think that’s a big shift that people have to make, from shifting from an individual contributor to being a tech lead.
[0:03:17.4] DA: Yeah, especially if there are like organizational kind of pressures that push you into doing that. You may have like a big deadline or some other responsibilities that you have like a lot of context on and it can be hard to step away from that.
[0:03:33.5] KW: Yeah, I think that’s one of the interesting things about the tech industry is that often times, let’s say there’s a very high performing individual contributor, those are typically the people being pushed into leadership roles but the responsibilities for the leadership roles, that they’re being pushed to is so different from the responsibilities that an individual contributor has.
[0:03:59.3] WJ: It’s the Peter Principle. When people are promoted to the level at which they are incompetent and unable to be promoted further.
[0:04:07.2] MN: Gosh.
[0:04:07.9] WJ: Results in a company where everyone is incompetent.
[0:04:12.1] DA: Who is it named after?
[0:04:13.5] MN: Poor guy, right?
[0:04:14.1] WJ: I feel really bad for that guy.
[0:04:18.0] DA: It’s like naming an illness after someone.
[0:04:21.7] KW: I’m curious, seriously, who is Peter?
[0:04:24.1] MN: I don’t know.
[0:04:25.6] WJ: Let’s Google it.
[0:04:25.6] MN: Yeah, we’d have to definitely check out who Peter is. I think like, even the word, like tech lead, some people may take that as like, I am you know, the top most engineer in the team when it’s like, the leadership aspect of knowing the technical knowledge, you should be able to lead other individuals to also be amazing in the code base.
[0:04:52.3] DA: I did just Google it; I was very curious about who Peter was.
[0:04:55.3] MN: Yeah, who’s Peter?
[0:04:56.0] DA: There was a book in the 60’s, 69, called The Peter Principle who was written by Laurence J. Peter.
[0:05:05.9] MN: So he brought it out? Not that he was incompetent but he might have thought, okay.
[0:05:09.9] DA: But he named it after himself and he named the book after himself too.
[0:05:13.3] MN: I see.
[0:05:15.7] KW: That’s funny. He came up with the principle but now the naming of it makes people think he was the incompetent one.
[0:05:23.3] MN: Good job.
[0:05:23.9] DA: Yes, oops.
[0:05:25.0] KW: One could argue that he was pretty incompetent in naming.
[0:05:28.8] DA: It’s rough. Yeah, what are some other problems that could come up?
[0:05:32.5] KW: I think the flip side also occurs which is not coding enough because as tech lead, these tech leads might be pulled into a lot of different meetings and white boarding sessions and they just get too far removed from the code.
[0:05:47.3] DA: Yeah. I guess also from the team. If you can’t spend any time getting context about what people are doing and you know, what things are going on around, it can be hard to stay in touch with how the pace is going to be and how happy people are going to be.
I think we talked before on the podcast about a common thread among like, people who leave companies is they’re not really leaving the company, they’re leaving the manager. Got to spend that time.
[0:06:15.7] MN: Yeah, try to find opportunities to code some, not all the time and being able to lead your team across the code bases, like the ideal tech lead.
[0:06:26.6] DA: I guess kind of like in a similar vein of coding all the time or not enough, kind of feeling the responsibility that you need to make all the technical decisions, that could definitely be a challenge if it leads to bottlenecks where people are just waiting for you to decide which sorting library to use. You have to like really weigh all the tradeoffs very carefully and no one else is trusted to do it.
[0:06:52.6] WJ: The problem there is that you have to become okay with the wrong decision being made. That’s what makes that difficult is that when you delegate the responsibility, there are going to be times when somebody makes the decision that you vehemently disagree with and you missed it and you’re not going to have time to go back and fix it.
[0:07:10.9] KW: Yeah, I think that’s a really good point. I think one of the things tech leads also struggle with is yeah, making the wrong decision because as an IC, like, you get to dive in super deep and you know at the end of the day, your technical decisions were either your choice or something that you worked at with a team. As a good tech lead, you shouldn’t be making all the technical decisions and trust that you know, the team comes up – this is more important that the team is moving forward on a technical decision and corrects that technical decision when it’s needed versus putting the team to a stop, trying to figure out the best solution.
[0:07:51.3] DA: I guess like, when the team does make that decision to do the wrong thing, if you have to go back and redo it, then it should be like a collective team decision. Like yeah, “Hey, this thing is actually causing us a lot of pain and we all see and understand why we might want to take a different path and refactor or choose a different sorting algorithm library.
[0:08:13.6] KW: Yeah. I think that’s totally okay, that’s the right thing to do. I once was on a project where two people couldn’t agree on the technical direction of a project and what ended up happening was they were at a standstill for two weeks when one of the technical, going with one way or another would have taken probably half a week.
Let’s say they went with one way, it was the wrong way, the go with other way, that would have bene one week versus two weeks of a standstill.
[0:08:43.3] DA: Mexican Standoff.
[0:08:45.8] WJ: Yeah, I think the issue is, you have to think meta to the problem at hand like the issue isn’t that the wrong technical decision was made, the issue is that by going back and and vetoing someone’s decision after they’ve done a bunch of implementation is far more detrimental to the team that the original bad architecture.
[0:09:09.8] KW: That’s an interesting point. Though, don’t you think that on a healthy team, people are unattached to code? They understand that it’s okay to go back like just delete everything they’ve written to move forward on something better?
[0:09:26.9] MN: Yeah, understanding the changing nature of code. I guess, ideally on a healthy team like it would not be a top down decision to delete that code, like the manager wouldn’t come over and just delete your code for you.
[0:09:42.7] KW: Yes, that is true too.
[0:09:44.7] MN: Backspace.
[0:09:48.6] WJ: Cyber consent involved there. Certainly, on a healthy team, one would hope that the individual contributor who wrote the original code would be open to and excited about help with refactoring. But, in the event that they are convinced that their architectural decision is correct and the team lead disagrees –
Going back and forcing the tech leads will, upon the group, I think causes more harm than even if they’re right, a better architectural decision would help.
[0:10:21.4] KW: Right, yeah, absolutely. In fact, I don’t think there’s ever a moment where it’s correct for a tech lead to force their sole opinion upon a team. I think the tech lead’s role would be leading the team to come up with a new solution with consensus of the team.
[0:10:38.5] DA: Maybe to their point, like that could indicate that your team lead is making mistakes or you yourself as a team leader making mistakes is that you feel like kind of that you are the top dog with technology and that means that you are the best person to be leading the team.
An example I saw in a really great article I saw from some folks at Thought Works, talking about how you know, you need to be open to mentoring new team members who may surpass you technically and that doesn’t really necessarily mean that you are not the one who should be leading the team even if you need to defer others.
[0:11:21.0] MN: Or, you could be the Java Script/J-query expert but some younger individual may know the hotness in React and can then kind of lead forward in that regard. In the React code base.
[0:11:35.3] WJ: If you’ve ever tried to be a team lead on a team that you are relatively new to, I think it becomes pretty painfully clear pretty quickly that the people who have worked in that code base for you know, a full year are going to be a lot more effective than you even if that is the only year of software development experience they have.
In the beginning, your lack of context is devastating.
[0:12:00.0] MN: Right. I think as new code gets built, the tech lead can then help out in that front and then be more effective in that regard.
[0:12:08.7] WJ: You don’t have to be the expert in order to be effective as a team lead. The lead is a role, there are certain responsibilities that come with it and like we were just saying, not about being the person who makes all the architectural decisions.
[0:12:22.2] DA: Yeah, right. Maybe that’s a mistake in itself. You know, being too focused on the technical things and not thinking about the broader picture of like the skills that you should be building up and weaving together as part of that role.
[0:12:38.8] KW: Yeah, one way I like to think about it is like, kind of view a tech lead as like a quarterback on a football team. They’re definitely not – quarterback’s definitely not the best person for every position on the field but what they do know is who is the best position on fo certain types of plays.
[0:12:58.9] MN: They could make the call when the play happens depending on what’s happening at that point in time. I’m talking like I know football, I don’t know much about it.
[0:13:09.2] KW: Actually yeah, me neither.
[0:13:11.7] DA: A Beautiful Man.
[0:13:12.9] MN: Gosh. All the Tom Brady fans out there, shout out to y’all. Yeah, like the quarterback can then, and like the tech lead knows, “I can give this responsibility to this person or I can put that person to the test in this particular problem so they can learn some new functionality in the code base that we’re dealing with.”
The quarter back isn’t the one always running to the goal, right? They have to delegate that to other individuals.
[0:13:39.3] KW: Yeah, totally.
[0:13:41.2] DA: Yeah, I guess they are in the field. We can just keep going with sports metaphor.
[0:13:45.3] MN: Yeah, let’s do it.
[0:13:46.0] DA: They’re in the field with the team members so they have the big picture, they’re figured out and they’re saying some cryptic things to each other.
[0:13:57.7] WJ: They’re contributing, they’re like holding the ball or throwing the ball or whatever you do with a ball.
[0:14:02.1] DA: Yeah, sometimes they’re doing the hits.
[0:14:04.4] WJ: Sometimes they get hit.
[0:14:06.5] MN: Yeah. If you guys sat in your development job, then you might want to call HR again. Don’t get tackled at work, please, don’t.
[0:14:15.9] DA: That is part of the team lead job. If things aren’t going well, you do kind of have to run interference.
[0:14:24.7] KW: Yeah, one thing I also think is important for tech leads to know is to also know their weaknesses. How will we play this into this football analogy?
[0:14:35.5] DA: This is just the rest of the episode people, you know?
[0:14:40.4] WJ: If you know you have a bad right angle, go left.
[0:14:43.8] MN: I don’t know all that. What do you mean by playing – so the tech lead knowing another individual’s weakness?
[0:14:50.6] KW: Their own weaknesses.
[0:14:51.8] MN: I see.
[0:14:52.6] KW: To give an example, let’s say, I probably sway a little bit stronger on the project planning side and then there might be a certain technology on the project where you have to have deep intimate knowledge on. Typically, those are the areas where I’d be a little bit weaker on.
[0:15:12.3] MN: Right, and you knowing that that is something that you are weaker on, you know to delegate that to individuals who may shine in that particular role?
[0:15:22.0] KW: Yes, exactly. Delegate it if I already know someone has that expertise or find someone who is excited about going super deep on a certain technology that might be required for the project.
[0:15:36.3] MN: Right. We’ve been talking about some mistakes that tech leads make and what you should do about those mistakes and how to fix them. What are some good things that a tech lead should do intentionally?
[0:15:49.3] WJ: I think that being a lead of really anything is about servant leadership. The reason for the leader isn’t because you are the best or because you’ve been around the longest or even because other people want you to fill that role. The reason is because the team needs someone to do that role.
At the end of the day, you need someone who is going to be the buck stops with me guy or girl and the person who is going to have their coding work flow interrupted to go meet with the product manager, to go do that white boarding session and to talk to people about their – about what they’re working on and if they need help and be the point person who can say like, “Well, I know that you wanted more exposure to the front end.”
We’re going to give you this ticket even though it’s going to slow things down and I’m going to explain to the PM why that’s worthwhile.” That’s often a thankless job, it’s often a painful job, it’s often a job that you feel like you didn’t sign up for when you got into software development but it’s an incredibly valuable service that you are providing for your team.
If you go into it with that mindset, “This is not something that I’m entitled to, this is not a special privilege, this is not a thing that I’m doing so that I can brag to my parents or my friends about it.” This is a thing that I’m doing as a service to my team and in the event that I am no longer the best person to perform this service, I will happily hand it over to someone else, then you will be much more successful as a teach lead.
[0:17:32.3] MN: I think, with that in mind, you level up all the individuals of the team by being se servant leader to the job at hand. By helping other people, they can then, you know, one day be able to help lead other people in the future and you set a good example by doing that.
[0:17:51.8] KW: Yeah, William, I think you basically hit the nail on the head there which is if you fully embody that mindset, being a good tech lead naturally follows. I think most people who go into the role thinking that it means you get more power or control are the ones who ultimately fail as tech lead.
On that vein, another great tip for being a tech lead is being a gate opener, not closer, basically giving people more opportunities to make choices, not hutting, not putting things to a halt because you as a tech lead want to review all code or you as a tech lead wants to be involved in all decisions.
But really embodying the mindset that you’re really there to help support other people when they need to so that you can move things along faster.
[0:18:44.5] DA: Interesting. I mean, the phrasing kind of implies that you are still the gatekeeper but your role is like more towards facilitation than like being imposing and standing in people’s way.
[0:18:56.4] KW: Yeah, that’s true. Maybe there could be a better phrasing than the word gate in there.
[0:19:04.5] DA: I don’t know. I think it works pretty well and there is a responsibility, right? And I think we talked a lot about some of the other good things that you can do which is having that broader perspective and finding the balance between coding and other non-technical responsibilities and being there to protect the team from thrashing in the business and the larger organization as a whole.
[0:19:32.6] WJ: Another thing I think effective team leads do is adapt the leadership team as their first team. So probably as a tech lead you are going to have a non-technical counterpart like a product manager or a project manager. Maybe that includes QA or design, somebody from some other department who you need to collaborate with in order to move the team forward. I think that it is important to be willing to accept them as your first team.
Because there is a temptation to stay in your old click and say, “Well you know I am an engineer. I am with the engineers. I am here to represent the engineers. They are my first team and I am just a delegate here that has been sent to you to interface with the rest of the organization,” and the problem with that is, it ends up creating inter-departmental politics. “Well, I want engineers to have this. I want engineers to have that. I need for our department to get this much money or this much head count.”
Or “We need to push back on these things because that’s what’s best for engineers,” and when you do that, when you take that attitude, the product has to take that attitude to design, it has to take that to all the other departments to take the same attitude and it becomes competitive within the organization. If you adopt that team as your first team and you say, “Hey I’m an engineer but I am here on a team with you from design and you from QA and you from product.”
Like, “We are going to come together and I am going to explain to you what the engineering team can do for you and I will be clear about what our limitations are and there are some things that I can’t commit to but if we need to reduce our headcount or our budget or put our priorities further back on the roadmap for the success of the group, then I am willing to do that and I will even go back and sell it to the engineers.”
[0:21:32.3] KW: I think that is a very good point, what are some things that you guys do to build that trust with that first team and then also on the same thing, make sure that the engineers know that you also have their best interests in mind as well. I think that is a very fine balance between working with the counterparts and your own engineering team and making sure that both teams know that they have, I guess equal power? I am not sure if that is the right word but equal voice.
[0:22:08.3] DA: Right. Yeah, I mean I think like having a good whole team mentality and encouraging team members to talk to design and product when they have questions rather than filtering them through yourself is a good way to keep a broader perspective. I guess also delegate some of that responsibility off of your shoulders for being that ambassador to that broader organization. I guess like probably one of the things that you are thinking about was like the larger people.
Besides the immediate product people and you know, being a representative and reaching out to those higher up or different product people or different teams.
[0:22:54.8] KW: Yeah, I’ve definitely been on teams where tech lead almost gets upset if a team member reaches out directly to say someone outside the department. But a good tech lead will empower their teams to be speaking with all parts of the business.
[0:23:11.3] WJ: Yeah, that is toxic for the tech lead to become and information bottleneck that everyone has to communicate through. That’s just going to slow things down.
[0:23:21.4] MN: Yeah by not empowering your team to talk amongst different departments, you know what happens if we take bus fact into consideration or this person takes a vacation then your team can’t or doesn’t have the ability or don’t know how to communicate with another department and then features may not be released on time and stuff like that, due to that bottleneck that the tech lead had imposed on the team in the first place.
[0:23:48.1] WJ: Yeah by adopting the leadership team as your first team, I definitely don’t mean it like you are the only person to interface with any of the other departments. It is just like, if there is a leadership counterpart in the other department that you need to collaborate with then you need to treat them as your collaborator.
[0:24:08.2] KW: I mean their team as well, is that right?
[0:24:11.1] WJ: You need to treat them as part of your first team.
[0:24:13.4] MN: Yeah.
[0:24:13.9] KW: Yup.
[0:24:14.0] DA: Right, cool. Does anyone have any war stories or any challenges they have faced as being team leads that you want to share?
[0:24:23.4] MN: I know for me one of the things that I have, I think we had the conversation before of just trying to get as much code in as possible. As a tech lead you may end up with a lot of meetings and architecture meetings and stuff like that and that takes up a lot of your time and you get back to your seat and it is 6:00, you’re like, “Oh man I really want to nail this code down” and then it’s 8:30 and you are still coding because you had meetings the entire day and it is a quick recipe for burnout.
I would suggest, regardless of your day, if it is filled with meetings or with code, every minute of that time is valuable and don’t burn yourself out by making sure you do X amount of time coding and Y amount of time of meetings. Your responsibilities in the meeting is just as important as the code that you have to create.
[0:25:11.5] DA: Yeah, I definitely found that to be the case last week as well for me and even if it wasn’t meetings, I was just helping to unblock people really quickly and kind of leaving my own poor story like neglected. I think that something that I probably wish that I had done better was to make sure that there was more shared context about what the work was that I was working on. So that way I could better delegate it but unfortunately, the person with the most contacts had left on vacation so.
[0:25:45.7] MN: It happens.
[0:25:47.7] WJ: I think one of the worst things I ever did as a tech lead was to consistently cover for a member of my team who was having a hard time pulling their weight. I just covered and covered and covered and then I went on a vacation and when I was not around to cover, it came out and the person had gotten too deep and the problem had gone on for too long and it was too late to put in proper remediation.
[0:26:20.8] DA: Oh dang.
[0:26:22.5] MN: That’s tough. So allowing the other person to jump in and code as well and not too much coverage would have been more helpful at the end.
[0:26:31.6] WJ: It would have been better to let the person fail and learn from failure early on and to give them the tough feedback but I thought it was just easier to just cover.
[0:26:42.2] DA: Yeah and I guess also like letting them fail is going to save space like when you’re there and you can control the reaction and guide them towards a better solution.
[0:26:55.9] KW: I think for me one of the things that I find myself doing every now and is just getting a little tied to a certain technical solution and just reminding myself that I have to take a step back, that as tech lead my role isn’t necessarily to push certain technical solutions as to drive forward a technical solution.
[0:27:20.2] DA: In the general sense not the specific sense. Not a specific sense, not your technical solution but a technical solution.
[0:27:26.3] KW: Correct, yes.
[0:27:28.9] DA: But your technical solution is so good.
[0:27:33.1] KW: In those moments I think so, yeah.
[0:27:36.5] DA: Yeah, I totally know what you mean like there’s, “Oh man this is so good!”
[0:27:41.0] KW: Got to do it.
[0:27:42.3] MN: Let’s do it and then ship it.
[0:27:43.8] DA: You just got to trust in it.
[0:27:45.9] MN: Yeah, give the trust to your team and make sure that in the end the solution that is chosen is the best one at the time. If worst comes to worst, it’s not, everyone learns from that and you build upon that and make sure that everything with that you can build the best code ever and that is your goal. Build the best code. Yeah, you’ve got to build the best code ever. What are you doing if you’re not building the best code? You failed and you fix it up. You fix it up some more.
[0:28:17.5] DA: What is the best code, yeah, might be.
[0:28:20.4] MN: Yeah, there you go. That is better. It is the best code yet, there you go.
[0:28:23.2] KW: So I once worked with a tech lead that had very strong opinions on how to do certain things and I found that we are often shut down, like the developers were shut down with what they wanted to do. From that I learned a very good tip which is to allow people to explore because if you don’t allow them to explore they will always be resentful of not having that opportunity but then you also have to be mindful of projects getting delivered on time.
So, the tip is to basically allow people to explore under time box constrains. People could spend, you know, people could shut down an idea or tech leads can shut down an idea and move the project forward, but you will have a resentful developer. Or they could take that 30 minutes, an hour a day, I don’t know how long depending on the task and just say, “Time box it, explore it”. Best case scenario is they come up with something that actually was really good. Worst case scenario is that the team “Loses a day” but can move on happily from there.
[0:29:32.3] MN: Right and you can probably learn something in that one day about the solution that you are diving into.
[0:29:37.6] KW: Yeah and that is why I say like “Waste of the day” because I don’t even consider that a waste of time.
[0:29:43.8] DA: Yeah and then I guess that spikes are pretty grateful like just sharing knowledge with everybody and bringing some broader knowledge from the outside instead of just keeping your head down and coding.
[0:29:55.8] MN: Kelly, thank you so much for coming on down to The Rabbit Hole, really appreciate it.
[0:29:59.5] KW: Thank you for having me.
[0:30:00.7] MN: Follow us now on Twitter @radiofreerabbit so keep the conversation going. Like what you hear? Give us a five-star review. It helps developers just like you find their way into The Rabbit Hole and never miss an episode, subscribe now however you listen to your favorite podcast.
On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
Links and Resources:
