Engineering Leadership: Reducing Chaos For Development Teams

Transcript is auto-generated and may contain errors.

Hey folks, I'm just leaving the gas station after CrossFit. I keep forgetting that if I ever have to come to this gas station. It's insanely slow to pump gas. It took me uh five like actually 6 minutes to pump two gallons and I have to leave because I can't sit here and pump any more gas. Uh it's gonna be a shorter drive just because I'm getting home and then I have a drive to the office. So, have a longer video. Uh, I'm just going to kind of catch up on on things since I've been back at work. Um, after my little vacation. Um, like something that's top of mind for me is like uh I don't want this to be like a rant. So, I just want to be careful about how I talk. Sometimes like if something's top of mind, I passionate about it, I don't want it to come across like a rant.

It's just something I want to talk about. And um I don't it's hard to like not uh because I'm not conversing with any other person like to to not just rant right. So um I want to talk about sort of the role as a middle manager in uh in software engineering and sort of some of the the ongoing challenges that we kind of have to deal with. Um, one sec. There's like a The ramp is metered to get on the highway. Come on, man. Person in front of me is not going. You got to go. Come on. Talked about this before. If you're trying to get onto a highway, you have to be going the speed of the cars on the highway. You can't merge in going slower. Um, okay. So, middle management's kind of a weird spot.

Uh I think that sometimes people perceive it as like oh I like be so easy to be a manager cuz you just get to tell people what to do and like I would say if that's the philosophy around it then that's like if that's what you observe is like being a middle manager as and I'm really sorry that you've been experiencing like really shitty middle managers. Um, being able to delegate things is of course part of it, but uh I I see this happen with middle managers. I see this happen with uh with tech leads where people are just like, "Oh, so and so do this, so and so do this." It's not um it's not just as easy as like picking people and then just like throwing work at them. So if this is your sort of perspective on it, then I I'm sorry that that's kind of what you've been exposed to.

Uh is a little bit more involved than that. But um between like delegating work and uh ensuring that people can do work effectively, uh there's a lot of stuff that kind of comes up. And I think that the one thing I wanted to talk about is like uh reducing chaos, right? It sounds kind of funny, I guess, but um Okay, sorry. I just got clear. Speaking of reducing chaos, um I just got some some chaos reduced, which is nice. Uh one of the things that we have to do as managers is like you get you kind of get from all directions. Right? So, you have stuff that comes from organizational leadership that may or may not be what you agree with. You have stuff that comes from your own direct management that may or may not be what you agree with.

Uh, and then you also I I believe personally if you're I believe if you're doing a good job as a middle manager, then you also need to make sure that you're hearing the team, right? like so things have to flow upwards as well and then literally as a middle manager you are in the middle of all of this. So you get stuff from all different directions and I would say that like we have a responsibility as middle managers to to reduce chaos for teams. So what I what I mean by this is like in other conversations other contexts you'll hear about like oh like managers are keeping stuff from us or we need to have a transparent culture where everything's shared and you know different sort of perspectives or takes on this and personally I agree in having as transparent as a culture as as possible.

I want to promote transparency. I want to promote information sharing. Um, but one of the one of the consequences of this is like without any filtering, it can become overwhelming. And if you don't agree, if you're not a middle manager and you're like, "Well, no, we should hear everything that's happening." I I I mean this like if I as a middle manager am being overwhelmed with information coming from all sorts of different directions, it would not be in my best interest to try and then pass it on to every single member of the team directly because it will absolutely overwhelm them. It is it's introducing chaos when there's too much information that's not necessarily relevant. it becomes chaos. If there are distractions like that are coming to me and someone's looking to me to try and go get that work done, I should not blindly just like cover my eyes and start doing the delegation thing where like, okay, so and so, you're up next.

What is this? I don't know, but go do it. It's got to get done apparently. Um, this is it's chaos. We need to be able to prioritize things that are coming through and that involves both like tasks or things that have to get done and information. Now, on the information front, that doesn't mean that I sit there and I go, "Oh, this is top secret. I should not tell the team." Um, or you know, I need to withhold this from soand so because I want to keep it a secret. Um, it's not It's not about that. It's about like if you lead by putting too much information out to people, they don't know what to do with it and it becomes distracting. Right. I had this um use an example the project that I was working on for for five months. I had one of my sub teams I kind of sheltered from the project they were doing security work and that's highest priority for Microsoft.

So I let them or let them and like made sure that they could continue on that with priority but that meant that the other project that was going on they're aware of it. And it's not a secret. The whole the rest of the team is working on it, but I'm sheltering them from like they're not pulled into all the meetings for it. They're not like they're just not part of all of the conversations around it. Unless it's like a teamwide update, right? Few minutes here and there. But some of those individuals would say, "Hey, like how is how's that project going?" Right? So, they're curious. They're asking about it. And I'm not going to go, "Oh, like don't worry. You don't have to think about that. No, if they're curious, I'm going to talk to them about it, but I'm not going to sort of like force feed them information where they're like, "What do you want me to do with it?" Because it it's distracting from the work they're doing.

Is the information available? Absolutely. If they ask about it, will I share? Absolutely. But if it's going to distract them from what they're doing, I'm personally not going to prioritize going out of my way to share that. Now on that's like the information front. Lots to discuss there. But I think even on or arguably more importantly is on the task front. Um there is only so much time and so many people to get things done and there is seemingly an infinite amount of work that we need to get through all the time, every direction. The the reality is that not every bit of work is a priority. And when we have many channels to bring that kind of work in front of the team, it becomes absolutely chaotic. And I want to give an example of this from way before Microsoft when I was at a startup.

We used to try and do agile software development and like and and we we meant it, right? Like we were a startup. Did we know what we were doing? Absolutely not. But we said, "Hey, like we want to try putting some of these things in place to help guide us." So like was it, you know, perfect scrum or perfect camb or like absolutely not. But um we like one of the things that we agreed was that we can only get through so much work in a sprint. Okay? We can only get through so much work in a sprint. So, if someone's trying to introduce more work to the sprint, we don't want to say, "Oh, no, no, you're not allowed to. Uh, you found a really critical bug. Too bad. You have to wait 2 weeks." No. Like, if something comes up and it's truly a priority, we'll adjust, but we need to make sure that we can pull something out, right?

Like, there's only so much capacity. So we had this kind of philosophy early on and I think you know I still agree with this today. There's only so much capacity but what would happen is that if you didn't go through normal channels so like if you weren't coming to the engineering managers or going directly to the product owner ultimately the product owner and sometimes that was the engineering manager sometimes it was a direct product manager. If you weren't going to one of these individuals so that they could help coordinate the work within the team, like things would start to fall apart. And what I mean is like we would have uh sometimes we'd have sales people coming over and talking to the developers and being like, "Hey, like can you can you go do this for me? Can you get this done?" And the developers wanting to do the right thing, like I don't blame them.

They're like, "Well, yeah, like I could I could do that for you." Like you're making it sound very urgent and a priority. Yeah. Like let me do that for you. And then what would happen is like they would do whatever and then the sprint commitments would get missed and we'd be like, "Well, what the hell?" Like this thing that we've been planning to do is just not getting done because because why? Oh, well, you know, so and so asked me to do this. And it's like, well, what? Like, when did that come up, right? Um, and that that's not a priority. And then they're like, well, I they said it was. And it's like, yeah, because everyone has their own top priority. So, we would have salespeople injecting things. We'd have, you know, and I I've talked about him before. I love him to death, even though we don't work together.

the CTO would come over to developers and say, "Hey, like go do this for me." And then, of course, it's the CTO. He's the founder of the company. Obviously, they're going to go do the work for him, right? And then what would happen? Oh, we missed sprint commitments. Well, I had to do this for him. And it's like, I I get it, but it's introducing chaos. And then I even talked about uh uh one developer in particular in a video yesterday or something. Um sorry, it wasn't yesterday. I was re-watching at the clip shorts, one of the ones I posted recently. Um, and there's been many developers like this, but they they go kind of go off the rails and they'll either go refactor or go build other things that aren't part of the sprint commitments and then we miss our sprint commitments. They've introduced chaos into the development process.

So, I'm just giving a bunch of different examples of like chaos being introduced. It's not that it's unrealistic in my opinion that we completely eliminate chaos, right? Chaos, it's going to come up. There's going to be stuff we don't plan for. There's going to be, you know, not everything follows a rule perfectly. I'm not I'm not saying get it to zero and like that's realistic. I'm just saying we want to minimize that. As engineering managers, I believe it's our responsibility to minimize the chaos with our engineering team so that they can do their priorities effectively. So both information in terms of chaos and and work streams in terms of chaos. But what that means, I want to tie this back to delegation, is that it's not it is absolutely insufficient and I would just argue uh lazy to say here is a big list of stuff and I'm just going to keep like you keep adding stuff to this list.

I'm just going to keep delegating it to people. It's in my opinion that's just absolutely crazy lazy and kind of like a just a approach. Like it's it's not helpful. In my opinion, it introduces chaos because there is no prioritization that goes into it. If you're just constantly piling up work and it's not getting prioritized, there's things that need to be cut. Right? If you if you have a backlog of things to get done, you either cut things out that truly aren't important or you have a prioritization system that allows them to drop all the way to the bottom where the unimportant things go. But constantly uh piling on things and trying to uh create urgency around them I do not think is a strategy that works. And I feel like it's the role of of managers to be able to help with that. Like that's my responsibility.

I expect that of my managers. If they don't have context, then we should talk about that. If I don't have context, I need to go ask more engineers about that or other stakeholders. But if I have someone that comes to me and says, "We need your team to do this." I don't just go, "Yep, roger that." And then top of the list and whoever's next in line, go do it. I need to be able to balance those priorities against other things we have. And that might mean telling someone, "Hey, sorry. I understand that you have this request, but it's not happening for for weeks. It's not happening for months." Like, we need to be able to do that. It's not just a matter of Yep. and then like telling people yes and then hoping that there's enough capacity on the team to do it.

It's a lot more involved than just simply slapping someone's name beside it and hoping and I talking about this because we have a lot of things currently going on that I need to personally sit down and go through and say like look this is not important. No, we should not do this. Someone wrote this 2 years ago and said it was important and we've gone 2 years without it. Is it important? So, I need to be able to have those tough conversations. But like the reason I'm talking about this is like a couple things, right? I think I want to sort of expose that like being in a situation where you're getting information from multiple angles and asks from multiple angles, it's not it's not trivial. but also just that there's like there's more that goes into prioritizing work than just putting someone's name beside it.

You need to be able to, in my opinion, the word I like using is ruthless. You need to be able to ruthlessly prioritize things because if it's not happening, you will be focused on not the most impactful work. Like I'll say it a different way that's probably more straightforward. It's not like being an effective engineering manager is not about keeping people busy. It's about getting people working effectively on the highest priority items and then you can break down effectiveness as some some formula for like delivering business value but also helping focus people on career growth as well. Uh, I I think that these things need to be considered because um you can't just have people working on like sustained highest priority business stuff if it has uh basically like super low engagement value for them. You can for a little bit, but if it's sustained and they're not engaged, like it all falls apart.

So, So, this is sort of a I wanted to talk about this because it's top of mind for me. I basically have to have start having hard conversations to be like, "No, like I understand you want this done, but no." or you want this done, no problem. But which of these other things do you not want done? Because that's the trade you're making. This is a strategy I had to use. I mentioned the CTO where I used to work. Um, and you could like, like I said, I'm not talking ill about him. I love him to death. Um, I I always remind people like I invited him to my wedding. like we don't work together, but um you know, someone that I'll always uh really really look up to and we'd have to have this hard conversation where he's like, "We really we should really do this." And he is he is the customer, right?

Like he was a police officer. We were a digital forensics company. Um he really understands like from the user perspective. So it's hard to tell him no. But what we'd have to do is say instead of just being like, "No, we're not doing that. No, we're not doing that." We'd say, "Look, we trust you. We trust that you think this is the highest priority." Right? So, let me put these other things in front of you. If what you're saying is true, and you think that X is the highest priority, I just want to confirm with you. You're okay with not having Y or Z or A or B, right? Which one of these do you not want? at least in the short term. And sometimes that conversation would be like, "Oh, I didn't realize that we were doing those things." Like, now that I see them all laid out, yeah, those are the most important.

Or sometimes it would be like a very obvious decision for him where he's like, "Oh, well, no, we don't have to go work on that. We should put this in instead." And this is like, sorry, lost my train of thought. This is uh like being able to have that exercise I think is really valuable because in my opinion, it's it's ruthlessly prioritizing. You have to say like something's getting cut. It's not just, oh, one one more thing, one more thing. It's no, like it's out. You want us to follow with it? Sure, no problem. But like that could be uh when we were doing sprints, that could be next sprint. That could be next release. It's not going to make it in this month's release. We did monthly releases then, right? But you have to make hard decisions. It's not just piling in more work. And I think sometimes when you have those options stacked up in front of each other side by side makes it a little bit more apparent.

Um it's like I said it's lazy to be able to sit back and just say oh one more thing comes up here you go do it. So and so knows the space you go do it. Uh just because work is in a particular space and similar people are are working in it because they're subject matter experts doesn't mean that it doesn't become randomizing. If there's no theme to the work and it's just like seemingly random stuff in that space, like in my opinion, that becomes very randomizing even though it's related. Oh, buddy. Oh my goodness. This kid c I'm Thank God I look where I drive. this kid. I just watched him walk across the street slowly with his head down looking at his phone. Anyway, I'm at home. Uh that's the mini rant for this morning. Meta points are engineering managers need to drive clarity and reduce chaos and delegation.

It can be done in a lazy way, but I think that just introduces chaos. So, thanks for watching. See you next time.