The Engineering to Leadership Transition - Your Questions Answered

Transcript is auto-generated and may contain errors.

Hey folks, we are just going to an emailed in question. This comes from codeccommute.com. It's left anonymous. Um, this person has a sort of a multi-part question that's effectively around transitioning into a leadership role uh from an engineering role. Um, so they said they have this opportunity they've been nominated for. Um, and what what I like about their question is that it doesn't say how do I become an effective leader or an effective manager. They actually ask a bunch of, you know, very quick questions. It's like, how do I uh suggest pro um process improvements? How do I, you know, uh report on progress in a lightweight way? How do I um like basically they're it seems like they have awareness of a bunch of different things that they want to get right which is awesome because I think a lot of people sometimes are

um like hey here's a promotion into this role and you're like hell yeah like more money you know a different title cool and then you don't realize that like uh surprise like none of us really know how to do this properly and when you're first tossed into it if you don't change how you're approaching things, you're probably not going to do it effectively. So, I do appreciate that they have some awareness. Um, this is going going to be like a all over the place in terms of trying to answer this stuff. Um, because really what this comes down to is like how do I, you know, how do I start being a good manager? And, um, well, do my best here.

So uh first thing that I would like to touch on uh that I feel like addresses a handful of their their concerns or curiosity is around um sort of is it's like leading right so when it comes to you know progress reporting or not micromanaging or uh getting team process changes what I really encourage people to do in these situations is uh you probably heard or seen the movie Inception. I always like using this as an example. If you haven't seen the movie Inception, the premise is really like planting ideas in people's heads, right? And that way, if you go really deep and you get someone to believe that they came up with the idea, then it's like you haven't convinced them of something. It's their belief. And that's very strongly rooted. Um, and so I like the idea of uh inception, but what's cool about this is that it's not about just like making people do what you want.

Um, going through and thinking about it from an inception perspective in my from my point of view is like this actually teaches you more things too. So for example, let's say that you are in charge of a team and you want to drive some uh process improvements because you see some inefficiencies. you as a leader and someone with experience might be in a position where you're like, I have a bunch of good ideas about how to make this better and we could do A, we could do B, we could do C, and it's going to be awesome and people are going to love it. Um, and surprise, like a lot of the time people resist this kind of stuff even if it's a good idea. And I don't know all of the psychology behind this, but I think part of it is like people don't like change and people don't like being told what to do.

But instead, if you have conversations with your team about some inefficiencies or some opportunities for improvement, if you have those conversations, you could have them in combination of like in one-on ones with people so you can get some of their ideas and perspective brought up in team settings. Like you want to do all of these right in team settings so the group can discuss and uh look at opportunities or look at where people are seeing challenges. Are there common like surface areas where people are frustrated with things or they're like, "Yeah, I agree. We should try something like that." Having those types of conversations as a team in one-on- ones and bringing this all together gives you an opportunity to uh maybe some people aren't even aware of some of the challenges. They're not really thinking about it. They're kind of just going about their day-to-day work.

This gives you an opportunity to kind of plant some seeds for people to think about things, right? This is where the inception part comes in. It's like, hey, I'm just making this up. Um, our code review process, like the turnaround time on code reviews is 2 weeks. Like, that's kind of ridiculous. We're a team of four people. There's no reason code reviews should be like going back and forth for for 2 weeks. Like, have you noticed that? And some like you might have obviously this is a very contrived situation. Someone might be like, yes, like totally that pisses me off. You might have someone on the team that's like, "No, I'm never even, you know, not doesn't phase me. Like, I'm kept busy doing my work and like delivering and I don't really notice that." Um, but you plant some of these seeds to get people thinking about some of these opportunities.

Um, you know, for the people that aren't really aware of it or don't really have ideas, you can sort of vet some of your own thoughts and and for the people that are, you know, sharing perspective and stuff. Um, it's a great opportunity to surface that for to you and to the broader team to get more discussion around it. So these types of things I think are super important that you do not um just impose your way because you think it's the best in isolation and that might be difficult for you because you might be looking at it going oh I know I know that this is going to be better. I know this is going to improve things. Please um take a moment to see if you can find ways to get people bought into that. And through that process, it's not just a matter of convincing people and getting your way.

It's a matter of listening because what you observe as the pain point may not be the issue. You might be observing the same symptoms but not understanding the same pain point. To you it might look like code reviews are slow and it's because um people aren't responding to them fast enough and you're like okay there's a new mandatory rule that like every code review goes up you tag people in the chat and everyone has to drop what they're doing to go get the code reviews done and that's how we get code reviews done faster. that might work to get code reviews done faster, but you've made it a shittier situation because that's not the root cause. The root cause is like other people are swamped with other things and like maybe that needs to be addressed. So point is I think one of my meta principles when trying to coach people around this stuff is like um it's not about telling people what to do, it's about listening.

And I think you know an overwhelming majority of the time having the team come up with the ideas and have a space where you can experiment I think is critical right so let's take you know this hypothetical example we've been kind of uh toying with around like code reviews and stuff like that. um pitch the idea and if it's yours that you're going to try or a teammates's whatever, it doesn't matter whose idea it is, right? That's the other key point here is it's not whose idea. It's just like the team's going to try something and pitch it like an experiment. We're going to try this for the next, you know, week, 2, 3, 4 weeks, whatever it is based on your experiment. We're going to try it and then we're going to have a conversation about how it's going because if it sucks, then we'll stop.

If it's going pretty good and might need a little bit of tweaking, cool. Let's iterate on it. And if it's just awesome, great. Like, let's talk about where the other pain points are now. And treat things like this sort of evolving thing that you can do. Okay. So that's like in a nutshell when I talk about leading teams in terms of the software development life cycle. That's my my go-to is like I want people to be um feeling like they are in a place where they can help drive the changes on the team. You're facilitating that. You're giving them that space. And then of course if there needs to be tie breakers or you need to veto things or whatever it happens to be, step in to do so. But you have to look at things as like it's not you just like being an overlord of a team.

It's you supporting the team through growth and change. Okay. Um let's talk about progress uh status and reporting and stuff like that. Uh this is going to be highly dependent on your stakeholders and your team. I'll give you an example a couple so that we can look and contrast these things. I once managed a team that was doing mobile uh digital forensics and um some of the work that we did was like very much research and the kind of stuff that like there is you can't search for it online and get answers but we have a hunch that something's technically feasible. We have no idea how we're going to do it but it should be technically feasible. And so some of the work streams we had I'd have an engineer on for months at a time. Months, right? Right. And like we don't know if it's even physically possible, but we believe that there's a possibility.

And so for you know for that engineer working on that stuff, we would just routinely have conversations with our team with our product manager who is our product owner. We talk about this um you know with uh like beyond our product owner into like engineering leadership and and because if we're going to communicate like big advances and we need marketing for that like we're just making sure that everyone is kept in the loop of the progress and being very transparent that like we can't commit to like an exact time right and like for some of those things you know if all the stakeholders are bought into understanding that that's just the way it is. They can make demands and say like well we need to know and we're like well we can't tell you so like that means assume it's not going to be ready for ready for the you know this marketing launch.

assume it's not because we can't guarantee that. And then maybe we get it done like a week or two after whatever it happens to be. And then from there it's like, okay, well, if we're going to release in the next month, then maybe we feature flag it off and then when we release in the next month, we go turn it on for people, right? So like we can we can work with stakeholders this way. uh other things on that team we might do very much like on a you know sprint-by-sprint basis where we're landing stuff within the sprint. We can communicate that with marketing with stakeholders you know um hey like we we need to do a hot fix and while we're doing that we might as well turn on this feature great like let's go do it. But that's one example of a team that had both like iterative feature development bug fixes and then some really longunning research things.

Uh some of my teams at Microsoft, we have features that uh are you know uh enhancements for our platform, right? Some of those are you know uh we get the work done in a week and then to go deploy it across the entire surface of the service is going to be more weeks. And sometimes the way that things deploy out and how things are tied together, maybe we uh you know deployments are slowed down for some from some reason outside of our control. Got to get over one more. Um and so like we need to be able to communicate that, right? Like I think the at the end of the day you need to understand your stakeholders what they're trying to do because they have to communicate to other people too, right? A lot of the time when you have people that that are micromanaging what's happening and I mean this is different in all cases but when people are like what's the update?

What's the update? What's the update? It's because they're getting pressure to go provide an update and they're just not doing a good job of like meeting you in the middle on that. And I think if more people work towards meeting in the middle on communicating ideas, a lot of that progress reporting and status update stuff gets way better, right? So, for example, if you have someone that's constantly like, "Hey, you know, what's the update on this? What's the update on this?" You're probably like, "Man, this sucks and it's really annoying." So, if you instead of just like every time they ask, give them the answer because they're getting what they need. say, "Hey, can we come up with a better cadence for this?" Like, you know, um, when you're asking for this information, how can I help you do this more effectively? Uh, so that you don't need to reach out to me every 5 minutes asking for an update, right?

And then have that conversation. So, you as a leader of that team are going to need to think about this with other stakeholders. This is going to happen on a per project basis with different um, you know, different teams you're collaborating with, different customers depending on the scenario. But like it's very situational and I don't think like ultimately uh yes you should help lead and drive what that looks like but you want to make sure that your team can also do some of this right the more junior engineers are probably going to have a you know generally speaking have more challenges with this because they're not used to it but they need to learn and same with you know mid and senior and beyond engineers. the more experience they have, the more likely it is that they've encountered this kind of stuff, communicating things with stakeholders.

So, I think ultimately you can't police this for your team and like be the single point of failure for all communication for progress status reporting and stuff like that. Um, but you need to make sure that you give guidance to team members how this works. You support them through it as they need help. Um, but they kind of have to be taught and practice doing this. So again, like listen to where they're having challenge challenges with it. Do they need support on it? What does that look like? Are there commonalities? Like um, you know, is there a common theme where other partner teams are are constantly like interjecting and demanding things of your team? Like you might need to step in and work with the team like, hey, do we need a process around triaging some of this stuff? Like what does that look like? This goes back to point number one.

Work with your team on it. Um, where else do we want to go on this? I need some water. Uh, micromanaging. This is what one of the first things on the list. Um, this kind of goes back to status updates and stuff. I think very situationally, and I've kind of even in more recent years learned this the hard way, I hate micromanagement. Um, it is the number one thing that disengages me as an employee. So, when I have someone that's like asking for details about things uh in a way where I'm like it it seems like they're trying to do the work or telling me specifically how it's supposed to be done, I feel completely devalued as in like, you know, if you're inserting yourself so much into this, you it seems like you don't actually need me. That's how it feels, right? Usually what's happening is that this person is not getting information in a way that's helpful for them and they're unfortunately not finding an effective way to communicate that with me.

So, I like, you know, need to to sulk about it less and be like, "Hey, when I feel like that's happening, how do I more proactively be like instead of just like, wow, I hate this person doing this." Being like, "Okay, I see it happening. This probably means that they need information or they don't have visibility into something. How do I how do I work with them to make that more effective?" Okay, but I I personally hate micromanagement. It means that my management style shifts automatically to the exact opposite direction. I try to make sure that I have a lot of trust with my employees. They know that I'm trusting that they're doing work. Uh they know that if I do get into a mode where I'm asking for more regular status updates, I communicate with them like, hey, you know, security issue or something, we have to make sure we're more actively communicating on this kind of stuff or uh there's a critical issue with the partner team.

So, they're going to be asking, I'm going to be getting those updates from you. So just a heads up, but it's like that's the I try to make that the the rare case and people seem to understand this. Um, but what that means is that for more junior employees around like work items and progress and expectations around delivering things, what I've had to learn and relearn over the past few years is I actually need to heir more on the side of micromanagement for the more junior people. And that might sound kind of like, well, what the hell are you talking about, man? Like, don't do that. Um what I mean is like setting more clear expectations for timelines with my more senior people.

um you know I feel like they have an understanding of like the rate at which they can work their work capacity and I have these open conversations with them where I'm like hey look like based on our deployment velocity um because we have to roll changes out across the planet um and we do it slower on purpose um based on what that looks like you probably need to juggle a few work items that might mean you have a design going on you have some code up for you you have another change that's rolling out and you're evaluating it. So, you're you're juggling a couple of things and I just make sure that people feel a good balance by having conversations with them. That means if I'm like, "Hey, if you're ready for more, I'm not trying to overload you, but I don't want you to be bored either.

I want to give you interesting work, so let's have a conversation." Um, and this has worked really well for me where people like you might think, "Hey, if there's nothing to do, I can just sit back and do nothing." No, like if we find interesting work, I I will have people that are like, "Yep, I'm ready for more. Like, what's next?" And, you know, we get people engaged that way. But with the more junior employees, if they don't have a concept of how long something takes, I can't remember. There's like a I might butcher this, it's like Parkinson's law or something. And it's like if you give an amount of time, people will fill the time with the work, right? So if I set some milestones for people on their deliveries, at least they have an expectation around like, okay, I should try for this. And I tell people it's not carved in stone, but here's some guidelines for it, right?

And and I find the more junior developers have been thankful for that. They want that because they haven't yet formed an expectation of how long things should take. Some of them it's their first job like ever. So they're like, I just don't know what's expected of me. And then once you kind of set that up and you build some cadence and rhythm with them, it's it's required less. But anyway, point is that for some people it's uh especially needed in the beginning. So, I need to be care like you can't I guess what I'm saying is you can't just completely swing the one direction where you're like I'm never going to micromanage and then like you're too lax where people are like look I need some I need a bit more clear guidance and like I said I've kind of relearned that. Um anyway, that's a bunch of thoughts.

Uh, I will share this video and for the individual that submitted this, um, I can't email you back because it's anonymous, but if there's still more questions you have on this and you want to dive more into some specifics, please just let me know. You can send in another thing on code commute uh, on the submission page, happy to to answer more, but it's a pretty generic open-ended question, so we kind of have to give some some generic answers. So, um, feel free to submit again. um and we can dive into more pieces of it. So for those of you that aren't familiar, just leave a comment below if you have a question on anything about career development, software engineering, happy to try and answer. Or you can go to codecommute.com and submit questions anonymously that way. Or just send a message to me. It's devleader or code commute on any social media platform.

And I'm happy to try and make a video for you. See you next time. Take care.