Tech Lead in a Broken Team? What You Need to Do First

Transcript is auto-generated and may contain errors.

Hey folks, we're going to go to the experienced dev subreddit for this topic. This one is really long in terms of the post, which I think is awesome because they have so much detail in it. Um, but because I'm driving, I can't keep going back and referring to it to to pull out the nuances and the specifics. So, I apologize for that, but it's about um someone who's been moved into a tech lead position and uh they're looking for some guidance on what seems like a a challenging setup in terms of the engineers like I mean there's a lot going on, but like uh engineering capacity is like kind of over the top right now. Uh there's kind of like on a regular repeated cycle like they got a lot of manual testing that has to happen. There's regressions that come back from prior releases.

Like there's just a whole bunch of stuff that's like uh what I would kind of uh I don't know attribute to, you know, scaling up teams, trying to do a lot and like uh not not pumping the brakes uh enough. along the way. And what I mean by that is like, you know, uh especially for smaller companies or things that are scaling up, just like we got to ship more, we got to do more with less. And while I mean that's an interesting efficiency goal to have, at some point it doesn't uh it doesn't scale the same way. You can't just keep doing the same thing and like keep squeezing more out of less uh without making like fundamental changes. And I think what this person's kind of walking into is is perhaps some of that, like where do we need to start having changes? So I think they're trying to figure out what's actually expected of them in the tech lead position.

What's the status of like what's going on with this project? Because they're coming in new to it. So I think they're doing you know I think they're doing the right thing in terms of like learn about it try to understand it don't come in and say you know day one or just making changes because like if you don't know you don't know like you have to kind of learn and observe first. So I think that's you know on the right track. Um they're trying to figure out this working relationship. I mean there's a lot going on. So, uh, like I was saying, like a lot of detail in the post. So, kudos to them for actually doing that. I think if I were to say like, you know, for people that want to submit questions and stuff to the channel for me to to answer, like the amount of detail they put into that, I'm like, that's that's awesome.

Like, that's what I would need to do a a good job. Um, and that's a reminder that if you have questions you want answered, add them in the comments or go to code.com. And uh, you can submit anonymously that way. What's going on with these lights? It's green now. Okay. Sorry, the emergency vehicle made the lights go all funky. So, like, where do we even start with this person? Right. They're trying to figure out how to navigate this. Um, I think if I had all the the points pulled up and I were trying to go through them, I'd probably have different parts to address because I don't have them pulled up. I think I'll just try my best to talk about the different aspects. Um, and they'll be more generalized because of that. So, I think number one, uh, let's kind of take a step back from the specific project.

They're they're new to this role, right, as a tech lead, and they're trying to figure out, I mean, how to navigate this in terms of the expectations that are on them. And I think the first thing uh not I'm not saying they haven't done it but like the first thing that I would recommend to people is like get this clarification with your manager get it regularly um like try to as you're like exploring and encountering new things as part of their role and you're like I don't know man if I'm supposed to be like am I supposed to be pushing back on this? I think they had a bit of guidance in that regard that yes they should. Um, so I think they've been hinted at least like you have some um I don't know like authority is the wrong word. You have I don't know like you have a say in this, right?

You're not just like a do as you're told kind of uh situation like this is something where you should have input. You should be able to push back. So they're they're getting some of that. But I think if they're still not clear or they're not sure, like um I'm just trying to think if I had an employee coming to me like this, um I wouldn't be like, "What the hell, man?" Like, "Why aren't you just pushing back?" I would try to remind them like, "Hey, like no, that's that's expected. I encourage you to do it." Uh supporting them if you're if they're like, "I don't know how to navigate pushing back in this scenario." Like, cool. Let let me walk you through like what you're thinking, what you could try. um like are there steps you want to try taking after this conversation? Are there points where you want me to jump into to help facilitate that kind of thing?

So, um I think that there's a lot that can be done in terms of clarifying the expectations and it's not a one-time thing either. In fact, I I definitely think for a role like this where you're you're going into something where there's a little bit more leadership, a little bit more uh in terms of like the level of responsibility and accountability, but the role is starting to shift, right? Um this like tech leads and team leads look different at different companies. Um but in general I would say there's a what's common is like this higher expectation around uh like leading of projects and I guess with team leads sometimes that ends up looking like uh people um it's I think a lot closer to like a people management kind of split but a lot of the time it's a hybrid of these things. It's uh it's kind of like a I mean you're getting a lot of pieces of of management kind of uh falling into that which is which is an interesting step.

So, I I do think that when you're transitioning into something like this, like keep asking the questions, keep getting the clarity. You got to find your footing. Um, and you know, like as I'm saying all of this, what I'm trying to call out to is like it's going to look different at different places. So, it's like it's one thing if you're trying to read about all this stuff online or like watch videos like this one, but like the best way to get that clarity is to ask about it. So that's part one is like obviously the theme of this channel is always like you know clarify expectations align on them but then I would say too um like you have different relationships with stakeholders now and in this particular person's case that's one of their PMs that they're working with who seems to be um from what I read on the post a bit of a point of friction.

They're kind of like I think a lot of the challenges are driven by this particular PM doing a lot of this forceful driving. So, um like hey, I think it's a good opportunity to start building that working relationship, right? Um especially if in the beginning you're like kind of seeing some trends and you're like, oh, I think you know I can start pointing a lot of these things to this root cause which I think is this person. like instead of starting that working relationship off like where you're probably going to start building resentment by being like hm I have all of these problems and they seem to all be coming from one place. Um you know like get a head start and like try to figure out how to work effectively with this person because uh surprise you're going to be working with them. So figure like what are what are they hoping to get from you?

um can you start clarifying with them and let this be something that evolves, right? Like what are you hoping to get from them? Like how do you support each other, right? It sounds like uh what this person was writing about was that they did have at least some initial conversations with this person. Um they were walking through clearing up some of the like pain points they're observing or some ideas and it seems like the response they got was like, "Yep, like that sounds interesting. That seems like we can try some things out." Um, and we'll kind of touch on this in a little bit, but then this this tech lead saying like, "Hey, like nothing happened, so clearly this PM doesn't give a shit." So, I want to come back to that. Um, but it sounds like they were at least trying to have some of these initial conversations.

Um, sorry, I'm technically back up on call. So, when I have notifications on my phone, I'm going to keep glancing down to make sure my primary is not asking for support. I'm back up for two shifts in the day, which is fun. So, it's 12 hours of backup for the week. Oops. That's okay. Um, so they're they're doing some of that, but I think you know the getting the clarification of expectations and starting that networking with the PM early key. And if you're thinking about this for your situation or you know want to reflect on this for the future, one of the things that I would say is like it's not just about oh the the networking relationship with this PM. It's like who are your Holy crap, buddy, don't be pulling out. It's about like your you're going to be working with different stakeholders and like that's going to change and evolve over time.

So like how are you building those relationships up? will give you a very you know as an engineering manager I'm I'm doing this like I work with a few PMs that are in my uh greater team and like we've had a little bit of change uh temporarily just with people's uh working hours and things like that where I have to work more closely with a different PM and it's not like I don't know him or we never talk but we don't work on the same projects together and so like now we're going to need to so I need to make sure that I carve out time with him. Um, and it's a mutual thing, right? Like I know that he can do a tremendous job supporting me and I have to do a better job supporting him. So like we have to get together. We have to talk through these things like hey as these things grow and evolve because it is a difference right now.

How do we do a better job of this? And it's not a blame thing. It's not you're not do like what have you done for me lately? It's just like I'm fully admitting like there's more I could and should be doing um to support him in this sort of new working relationship. So, I'm just calling this out as an example. Like this kind of stuff is always changing and it's not a one-time thing. Okay. So, expectations, networking, these are things that are kind of like not specific to the project but like more specific to the role transition. So, that's part one of this. Now, maybe we can talk through some of the stuff that I recall that he was was mentioning um like in his post about things that seem like they're challenges, right? I'm going to do my best to try and recap them uh and hopefully we get through them.

But the list that I'm recalling right now had to do with like I said a little bit earlier, manual testing. So they he said like four to six hours of manual testing per release. I don't know what their release cadence is, but let's assume it's not like daily because that would be nuts. Uh let's assume it's like monthly releases, whatever, right? But there's a the point is that if you want to ship software, it takes 4 to 6 hours of manual testing. To me already something's not right about that. Um and this person's kind of calling that out. I'm saying this as someone who has literally no insight into what this project is like, but there's something I don't like about four to six hours of manual testing before you can ship something. So, I'm seeing that as a bit of a flag. Um that they were talking about, you know, uh during that testing the there's bugs that are being found that are literally some that have been closed from from prior releases.

So, like there's just regressions coming up. So, what's going on with that? Um, it seems like uh from some of their proposals that they wrote down, they were talking about doing a little bit more uh proactive tech debt. So, I'm assuming that there's not enough uh at least maybe from the engineering side, uh not enough around like how do we make sure that our our code is like not eroding over time, not enough focus on that. I think there's I made a video about this recently. I think there's always going to be um sort of a healthy debate that needs to happen because I exaggerated. I think that's actually the live stream that I'm doing tonight. Um so sorry. Uh I was like, why is this so familiar? Uh it's because I just wrote about it and it's the live stream that's tonight. But um the the idea is that if you take the extremes of like product management, it's like ship features, ship features, ship value.

If you take the extreme of the engineering side, it's like how do we how do we architect? How do we make code better? Obviously, I'm exaggerating, but there's got to be a healthy balance between these things. So, it sounds like there's not enough. Uh, one of the things this person called out was that he said it seems like there is I'm saying he I don't know if it's a he or she. Sorry. Um, they're saying that it seems like deliverables are tied to dates and not to engineering effort required. And I want to touch on this one a little bit more, but I think that's a very fair like thing to bring up and be like, hm, what are we going to do about this? So, um I'll put a pin in that and hopefully I don't forget to come back to it. And what else?

Um I think there's this general feeling of like he was trying to capture around like there's there's too much there's just like too much going on. And um I think that I can't remember exactly how they said it, but along the lines of like there's um there's basically just not enough uh he said something like if the PM doesn't change things like the expectations are basically that like you know the engineers are are having to work overtime or or something to that effect, right? Like there's there's just too much being asked for. Um, so maybe we'll we'll keep it at that list and kind of go through them. Um, on the manual, let's start with the manual testing stuff. Uh, I realize that all software is different. Um, you could have websites, you could have live services, a combination of the two. You could have mobile apps, a combination of an app with a a backend server.

Um, and so like if you have a mobile app, it's like technically it's a live service. It's just that you have this app to go with it. It could be a game. It could be like there's software and everything, right? I don't know what they're building, but when I see something like 4 to 6 hours of manual testing um per, you know, being able to release or ship something, huge red flag for me. Um, and I think there's probably a vicious cycle going on which is like, hey, if we don't do this, we don't catch these defects. Like, and we're clearly showing that doing this is important because it literally is catching these bugs, right? So, if we stop doing it, you're just telling me that we're going to start shipping because clearly we're catching it, right? Like, it's a it's a vicious cycle. I'm just realizing now there's someone in this lane that's going below the speed limit.

Come on, guys. I'm You can't see my speedometer. I'm still going 58 in the fast lane that I'm paying money for. So, um, very nice. There's no there's no one in front of these two cars. They're just not going the speed. So, um, this is a it seems like a chicken and the egg problem, but it's one of those slow down to speed up kind of things. Um, this kind of thing happens primarily, I would say, because people aren't taking the time to like add in proper regression tests. And it's probably not necessarily because engineers don't want to or no one sees value in it. It's probably because of one of the other things this this tech lead said which is like there probably just isn't enough time. They're being told like more more and it's like well the only thing that you're not going to see or like these tests we have to write like we have to start cutting scope from somewhere.

So I think that's probably what's happening and I think this person really has to uh push back on like hey stuff's not done until until there's regression tests in place whatever that looks like. And I'm not trying to claim that, you know, um, all software can be have automation tests that cover everything. Um, I think that would be a claim for me to say. As much as I like automated tests, I'm still going below the speed limit, by the way. This is insane. Um, and I can't switch lanes until there's an opening cuz it's illegal. Should be illegal for this person to be going this slow, though. Um, as much as I love automated testing, I don't want to claim that all software like can get away with uh without any manual testing, but I think for an overwhelming majority of it, you probably can move more towards automation.

If you have to be manually clicking through stuff at release time, my perspective is you're probably not doing it right andor there's probably a huge missed opportunity. Here we go. absolutely not putting up with that Um so again like if there's no time to do it then people will continue to keep paying this tax and um I I think yeah this person really has to be able to to make a case to this to this PM uh around that. And I think this is the perfect thing to push back on. I think it's uh a matter of saying like, hey, like we're, you know, we're putting work into this sprint or whatever they're doing. We're not calling this work done until we have what we're calling sufficient tests in place. And that doesn't mean, for what it's worth, that doesn't mean that from day one you're like, screw this PM, like we're going to add 400 tests per feature.

Like we don't have to get absolutely crazy here, but features should not be going in unless you have tests, right? Like it it you should have something and there's, you know, something to be discovered here about are you writing good tests on this stuff, right? Are you just adding tests and you get the code coverage um percentages and you're like cool, we hit, you know, some number so like good enough, right? that we must be safe. Are you doing that or is it like over time you're like, "Hey, good. We're adding tests, but they're still not they're still not stellar. Like, we should figure out ways to improve this." So, let that evolve over time. Um, I think that going from nothing to to some is already a huge improvement. Same thing with bug fixes. You fix a bug like uh red green test, right? Make sure you have the test in place that catches or proves the bug, you fix it, goes green.

Uh, again, let this evolve. Um, I know some people will say, well, it's not that trivial, like don't test the implementation details. I say screw it. Like, test the implementation details to start with. If you can't some other way, right? If your code's too coupled, it's convoluted, and you're like, you know, we'd have to go rewrite this thing to be able to do that, cool. Like, tech. for now. Test the implementation details. Prove it's actually fixed because if this keeps regressing, which surprise, it keeps regressing. We've already been told that. Um then you got something else to do, right? I understand too, by the way. I'm just kind of going in circles on this testing part cuz I know there's always people that are like, "Well, what about Yes, I understand. And if you test the implementation details, you make the code change, you have to change the whole test or something.

I know it's not the sustainable thing. I'm just saying that if you don't get in the habit of trying to get testing as a first class part of your development life cycle, you're screwed. That's it. So figure out what works. Start small, but it has to start and there should be some push back on this. um then I would be pushing back personally on trying to figure out how do we start getting coverage of whatever is manually being tested. Right? So if we're talking about uh percent time in the sprints or tech debt allocation or whatever, what is being manually tested at release time and start burning this down. Get that to zero or as close to zero as physically possible because it's the biggest waste of time ever and it kills your agility. Humans are so much more than manually clicking through things. Do not waste people's time doing this.

It's it's the wrong use of people's time. You're always going to find Like if you go looking you will find I've said this for almost a decade straight when working at a startup when we had people doing these tests right before releasing I would say look if you click through this app and on any given day if you click through this app and you click enough you will find things where you're going to say I think this is a bug whether it's a real big bug or something you don't like you will find a bug. So, why are you doing it right before we release? Because you know what's going to happen? You're going to find a bug and you're going to delay the whole release. The point is that it doesn't matter if you do it the day of, right before the release on some other day.

If you go looking, you will find. You are always going to gate a release because of this So, don't And I'm not, don't misunderstand what I'm saying. I'm not saying that there's, you know, finding bugs is delivering no value or adding no value. It's great you find them, but like it does you no good to find them right before you ship. Find them sooner. Find them all the time. Just it's the wrong It's the wrong time to do it. It's the wrong use of people's time. Whatever people are doing that is right before a release, burn that down to get it automated. And then if you want to have exploratory testing, don't do exploratory testing right before you release. Uh, let me clarify what I'm saying there, too, cuz I realize maybe that's coming across wrong. Don't only do exploratory testing before you release. If that's the only time you're doing it, you're going to explore and be surprised and then always delay.

If you're doing it, if you want to do exploratory testing and you're doing it regularly, you're going to know this baseline of like that's coming up and then it's like less of a it's less of a shock value when it's like, oh wait, you know, Billy found a bug and it's like, well, is it a bug or is that Billy's opinion, right? Like it's just figure out the right split, burn down your tests and release time so they are more uh automated. Um, so I'd push back on that. That needs to be something that gets scheduled in and and chipped away at. And that, um, not only chipped away at, it should only go down. There should be no up. There should be no, oh, add more to it. Never. You want to add more to it. It's it's adding in automated tests somewhere. You might not have the infrastructure for it.

Right? when I went uh when I was working at a startup and we we didn't have any UI tests that were specifically clicking through the UI. We were building them for uh for some other purpose basically so much tech debt that we couldn't um we couldn't even refactor the code without having some behavioral tests on the app. And I, by the way, all that tech debt, big part of that was my fault, so I'm not blaming anyone, but we we needed to have some UI tests to cover so we could go refactor and then write things in a way that could be tested. And then people were like, hey, we can start using this as um like to automate our build verification test that people were clicking through. Awesome. Um, I think people took that a little bit too far in some regards, but if you don't have the infrastructure to be able to do it, carve out time.

You have to slow down to speed up, right? Find incremental ways to get there. You don't have to deliver the most perfect um, you know, automation suite that touches everything end to end before you get any value ads. Start with a thin slice. get something carved out of that manual test. Prove it works. Okay. Um, next part. Um, on the, uh, dates versus engineering effort. Uh, what's the there's the whole triangle thing where it's like you pick two out of three qualities that you can fix and the other one um, how does that work? Sorry, I'm all strung out about testing now. Uh they have like speed, quality, and time. That's speed. I can't remember. Whatever. Um there's there's nothing wrong with either of these sort of delivery mechanisms, right? If you want to do release dates, there's nothing wrong with a release date.

Um there's nothing wrong with uh trying to have flexible release states and then scoping things by engineering effort, but uh you can't fix both or else I think that's where the triangle part comes in. You're probably going to be missing quality or having tech debt like crazy. So, if someone's like, "Hey, we need to ship this in a uh I'm gonna make it more obvious. We need to ship it in a week." And it's like, "Well, the engineering effort for that is going to be a month, right? Like, we're way way way over um budget for what we could do there." Okay. So, you either don't do it at all or you try finding ways to break it down into smaller pieces. And that might mean uh from a feature delivery perspective, is there a vertical thin slice of this feature that you can ship end to end?

And I would say a lot of the time there is. It's just that people um people don't love doing that cuz it's like it's more work, right? Well, it's not the full thing and like how is a customer going to use? I'm sure you could probably take many features, thin slice them, deliver a small working piece of it, and if people did this more, you'd probably realize half the ship you ship, like probably doesn't get used or doesn't get used the way that you expect or you you did way too much work up front and it wasn't really the right thing to go build. So, um I would strongly advocate for shipping uh smaller thin slices of verticals, letting people try them, use them, getting the feedback on them. If for some reason you can't, right? Um do you need to have a conscious decision? Whoa, buddy.

That's that's three lanes of a lane change. That's nuts. Very good. Um do you need to have a conscious decision about tech debt? like, hey, the thing we want to go build would take a month, but there's a a hard ship date of 1 week. Cool. Okay. Well, here's the here's the shortcut. We can ship that. And um basically, you know, if we need to touch this feature, so like if you if you want us to iterate on this um like you're basically in debt now, like we have to pay down that debt before we can even iterate on it. This is a slippery slope because if you don't have uh strong engineering to push back on product for this, you keep just getting more and more in debt. Uh which is probably honestly what has happened with this team, right? Just over time like, oh, we got to there's tech debt.

There's no other way to to get this done except to introduce the tech debt. Whether that's gaps in testing, whether that's in uh architecture, whatever it is, right? We'll pay down the debt, but then it never happens. So I think you have to have really strong engineering to push back in a a healthy conflict kind of way. Um, what else I would say too that um, like there while it sounds kind of weird to say like, hey, we're not going to iterate on that. Um, and in your head you're like, well, obviously we're going to have to iterate on that because, you know, they're going to be getting product feedback. That's totally fine. Uh, let them get the product feedback. It doesn't mean that you guys can't be talking about the next uh version of what's going to ship or how the feature needs to evolve and change.

Like literally use that time to be getting feedback and brainstorming what to go build as the basis for that the architecture of the right change like has to go in place. You can do those things in parallel to some degree. Um, but I I would say like, hey, look, like if you need us to rush it, like we're not iterating on it. We can't, right? That's the conscious decision we're making is that iterating on it in this format is going to be a terrible waste. It will not scale. Um, I know I was going to miss one more. I'm just getting to the office now. I got too riled up about testing. I have prior trauma talked about tech debt expectations timing. Oh, uh I think the final thing was that this this person was saying like clearly this PM doesn't care, right? They don't they don't want to see any change.

Um I'll put it this way. They're probably not incentivized to change anything, right? Like I I'll put it this way. Like wouldn't they have been driving the change themselves if they cared about it? It's not to say that it's not adding value. It's not to say that they don't care at all. But like, oh man, there's a spot right here. Nice. But uh this is something that you care more about. you're observing that engineers on the team care about this, right? And so I think that I don't I don't know how this is all, you know, proposed or put in front of the the PM in question here, so I'm not like trying to blame anyone or anything, but cuz I literally don't know, but uh I I think that if this is something you're trying to drive, like accountability is on you, man. um that's part of it's part of the role.

So if you're trying to drive these changes and doing push back, start taking accountability and ownership for that, right? So if these are things you're trying to propose and you're like, well, it seems like this PM doesn't care, they probably not enough to make changes or else they probably would have been. So, don't expect that they're going to, you know, drop everything they're doing to make changes. You have to be the one pushing. It's going to be uncomfortable. Uh, and then take those incremental steps, get those wins, and you'll start seeing that like as you're making positive changes. Momentum starts to build, right? You'll get more support from people on the team, all this kind of stuff. Um, but if you're waiting for someone else to go take action on it, it's not going to happen or else it would have already. So, I think it's sort of like a meta point around all this, but sorry for the rant on testing.

Um, I hope that some of that was at least helpful and it's definitely an interesting role change. So, I wish the best for this person. I think it was a really great question and a lot of awesome context. So, thanks for watching. I will see you in the next one.