What Are The Most Helpful Things You Do For Your Engineering Team?

Transcript is auto-generated and may contain errors.

Hey folks, I'm just headed to CrossFit here. We're going to go to Reddit for a question this morning. This one's from experience devs. Um, this one will be a bit more of a kind of like a brainstorm, I guess, cuz the question is pretty open-ended and it's uh essentially like what are the most helpful things that you do for your team? So, uh, thought this would be kind of fun to talk through. I'm going to talk try to see if I can talk about it from a couple different angles. Um, one being of course as an engineering manager like what are things that I do that I have had feedback on that seem to resonate really well with the team?

And then like I want to talk about it from the perspective of like like again if you're not an EM are there still things that like I recommend you do because I see that they they help uh kind of uh you know the entire team and maybe I'll start with that because I I honestly think that's where more of the value is going to be because I think the the stuff that maybe I do as an EM might just be like I don't know might not resonate as much. So, I'm probably going to be thinking of more stuff as I get talking, which is kind of the goal. Uh, but I I think the first thing that comes to mind is like uh as much as you can balance it being able to jump into things like like activities where you're unblocking people.

So that could be uh code reviews, that could be uh getting on like to reviewing design documents or anything else like if you are one of the gatekeepers or you know the the something on the team has to get crowdsourced because it's being gatekeeped. I think a code review or a pull request is uh one of the best examples of this. um being able to to try and get that stuff out of the way I think is is one of the most helpful things. And I I realize that like I can't just say, you know, as soon as you see a notification for one, like drop everything you're doing and go do the pull request or code review. Like that's kind of not realistic. But um I think as much as possible without derailing all of your own work. And if if everyone on a team can do this, I think it helps tremendously.

And that's really just like trying to to get through code reviews and pull requests uh or get to them as quickly as possible. I shouldn't say get through them because I'm not trying to suggest like you just like rush them and like don't actually get any value out of them. I just mean the fact that and you probably have experienced this, right? Like you put up code to get reviewed and then like you know like 3 days later you're like guys come on like can you please review my code? Uh so trying to do something for your team culture to to help improve that, right? I think a lot of the time, you know, a lot of code review systems will have notifications that go out, they email people, right? and then kind of like it just becomes a little bit like noise. So you're like, "Oh yeah, like I saw it and then you were busy and you forgot to go back." And it's a pretty common thing.

So you know, if you can have on your team culture, part of your team culture where it's normalized to remind people, you know, uh email goes out a few hours later, no one's touched it. Cool. Like ping people in the chat or maybe you do both. if you ping in the chat right away when the notification goes out cuz maybe some people like I know for myself personally I get so many emails that if someone needs me to go look at a poll request I would much rather that they like they tag me in chat cuz then I know like it's it's more serious I guess. So just something to think about. Um but I think that's a huge one in terms of helping an entire team out. It seems like a little thing, but like if you could imagine yourself every time that you were blocked on a poll request, imagine if like that amount of time was always just really low.

You would probably feel a lot more productive cuz you're not waiting or context switching as much. Um, so something to think about finding ways to make that effective but still not overwhelming you with like, you know, all of your flow state is gone. So that's one. I think next is um some some type of documentation and I I feel like this is evolving more with with AI tools. Uh so I I don't know if I have like a a fully sort of like refreshed or refined answer in my mind. My god. Oh my goodness. Talking too much first thing in the morning. I'm not breathing enough. Um, so what's going through my mind is like onboarding documentation but also um like TSGs or like things for helping on call engineers and kind of uh clubbing these things together because I think onboarding documentation's really helpful really you know you should have something like that.

Uh but if you're like, "Okay, Nick, yeah, but we're not onboarding people every day." So like, you know, it makes sense why onboarding documentation goes stale because we onboard someone like once a year. And sure, when we're doing it, like we we want to make sure the documentation's good, but it just doesn't happen that often. So like it's kind of does it kind of feels like we want it, but the effort to maintain it like is just too great. And I get that. But the reason I'm clubbing it together with like on call help is because at least on a team like mine, uh, our greater team is responsible for the on call health of the entire set of functionality that we have in the team. And this was the same on the previous team I was on.

So even though like I have three feature crews within my greater team and there's even more feature crews beyond that that don't report to me, every single person when they're on call has some responsibility at least to be able to mitigate issues across the entire platform. Okay. So when I think when I'm saying like documentation for onboarding I'm and clubbing it together with like on call type of documentation the whole point is that someone else in the team to some capacity should be able to jump in to help like understand functionality mitigate issues and and like if there was zero documentation and there was an issue going on with your platform or service like that experience is going to be terrible, right?

And I don't know, like some of you listening to this may have may have lived through stuff like that where there's like an alert firing or you have a partner service that's like, "Hi, like all this shit's busted." And you're like, "Okay." And you start investigating it and you're like, "Oh, it's related to feature X or you know, area X part of our our service or our product." And then you're like, I know like Jimmy worked on that and same with Susie, but like it's 8:00 p.m. or 900 p.m. They're not online and like I can't seem to find like like anything about about it. So you're like your documentation is the source code, which I mean that's the most real thing there is. But sometimes when there's a fire to put out, what you don't want to do is try learning how something works just directly from the source code for the very first time.

So I think that there's a lot to be said about when you're building features and functionality. Um it's a good opportunity if you're like hey that's going to be something that when people are onboarding to the team like we should touch on that like yeah like remind yourself maybe you should go update the onboarding documentation but furthermore you know if that's something that an on call engineer is going to potentially have to help support where's the documentation for that like is there if there's not maybe you should consider your features not done until someone who has to support the the service or their product has a little bit of guidance for what to do. And of course, like you can't predict every single scenario, or else you'd probably have written automation to prevent those things from happening. But the point is that, you know, if people are getting involved in an on call incident, you want something to uh to help them out.

Okay. Um, and I've like, you know, I can give kudos to one of the the sub teams. Uh, I think I have one feature crew in particular that does a really good job of writing documentation, but couple of weeks ago, I was on call for almost two months straight. And um, there's one of the sub teams, they have they've done a really good job with updating their documentation. And I rarely like when I'm on call I feel like issues I don't know I'm not saying they have no issues kind of thing but uh I I find like it's less frequent that I'm dealing with that stuff or it's automated a lot or there's questions uh from partners and it's less like something's on fire. But if something does go on fire I don't know that area very well. It's just like I don't spend a lot of my own time there.

Like I have three other areas that I need to spend significantly more time on, but their documentation's really good. So when an like a an alert comes up, they actually have like quite good guidance around how to go like troubleshoot it, investigate it, and and resolve it. So like I really appreciate that. That's a really helpful thing for me as in this case someone acting as an on call engineer. So, um I I would say like you know documenting the important things I would say is uh you know my my second one on my list. Um, I think another one, this is going to maybe sound a little fluffy, I guess, but like it's actually apparently really hard for people to do and I understand, but like being honest with feedback and um and doing it early I think is is really important. I know that I know it's like difficult for people to give like critical feedback or to give feedback that's not just like hey great job pat on the back.

Um but both of these are important like giving critical feedback and the pat on the back kind of thing. And it's like it's kind of crazy. We don't we don't do either a lot and it makes a really big difference in especially for people that are more junior or newer to the team. Um like everyone can benefit from a little bit more more confidence in the work they're doing, right? Even people that like sometimes seem overly confident, they might be uh not actually confident and they're uh they're trying to compensate for it. But I think, you know, people either getting feedback about how to do things better next time or being told like, "Hey, great work. Like, you did an awesome job on that." When that comes from your peers, like I I don't think people recognize the the kind of impact that kind of stuff can have.

It's it's tremendous. And uh we don't do it a lot. So my recommendation to to anyone listening is like you know it takes you don't have to do this for like every single thing that someone does but like you know in a week you know set a goal for you know once a week to start things off like try to make sure that by the time Friday rolls around every week you've tried to give one person just one person on the team like a hey good job on something they did. Hey, saw, you know, saw how you were handling those comments on that poll request and like and you can do this two like two ways here. Like you were giving really good feedback to someone on that poll request and I just wanted to, you know, I just wanted to acknowledge that I thought that was awesome and like you gave helpful comments or the other way like hey like really good job on that poll request.

I thought that you know you had a lot of uh there was a lot of different opinions showing up in the comments and I think that you did a really good job navigating that. Right. Awesome job on the design, Doc. I think you touched on a lot of really important things and I just wanted to acknowledge that like I thought your analysis was done really well. It was very clear. Awesome job keeping that meeting on point and like not running over time and uh it seemed like really clear goals in the beginning and uh and by the time we finish like there was some clear action items. So, just wanted to give you kudos for that. It's it's not hard to do because it takes such little effort, but for some reason in practice it seems like it's quite hard to do or else we would do more of it, right?

It's like a I want to say like it's simple. It's very simple, but it seems to not be easy. And that's just like on the positive stuff. So truly I think that you know if you can set a goal for once a week by the time Friday rolls around try giving some you know some positive feedback to folks like one person try it right that should be very doable to do one person I need to do a better job of it and I'm an engineering manager that's a that's a part of my role and then I would say the the inverse right and I understand that this one is significantly more difficult because it's like, okay, how do I bring this up? How do I navigate this stuff? But I'm not going to suggest like once a week find someone to go criticize. Not that way.

Um, but I I do think that if you can like maybe a good a good thing to like a thought exercise is if you had to especially for more junior people on your team. Not that you can't give feedback to more senior people. I'm just trying to kind of narrow this down a little. But if you were to think about someone more junior on your team and you're like, I think that there are situations where it would be good if I can give them feedback. If in your mind you're like, ah but like I don't know, they're probably going to get upset or I don't want to bother them or I don't think that they they really value my opinion or um I don't know. Like if you're already kind of throwing yourself off from it, it's going to sound kind of silly, but like why, right?

Like what what are the reasons that you're thinking that way? I'm not I'm not saying that you're wrong for thinking that way, but I want you to go through the thought experiment of like why, right? Like is it because you don't actually interact with them much at all and now you're about to pop out of nowhere and give them some constructive criticism? If so, like that's a that's valid, right? That's very valid. So, what can you do to make that better? Maybe actually engage with them a little bit more, right? Like there's there's something to be said about actually forming like a working relationship with someone where you're not just an absolute stranger that's popping out of nowhere to to criticize them. Like, I have to do this as an engineering manager for building trust and respect, right? Like yes, I might be someone's manager, but I don't just get to command respect and command trust.

Sometimes that comes a little bit with the title, but like I absolutely would not rely on that. And I would say the same thing about senior engineers on the team, right? You you get a little bit of it implicitly, but like you need to work on earning that trust and respect. So how are you doing that? And if the answer is, well, I'm not. And then you're also feeling like you're it's really uncomfortable for you to give feedback. Like I'll give you a counter example. There are individuals that report to me that uh and there's several of them where on different occasions in like 101's they've come and basically they've talked to me about something and they're they'll do this thing where they're like they'll say something like oh I don't know if I should or like this might this might not be okay but

um there there's sort of like a disclaimer before they bring something up and to me that's this like this pause for them uh in their minds like a pause of ackn acknowledging like, wait, I trust this person. I respect this person. And like even though this is uncomfortable for me, I want to talk through this because I know that this person will try to help me. And to me, that's a reminder that I like the time and effort that goes into building trust and respect is working. So that means if I do have to give them critical feedback that might be hard to deliver, I can do the same me mental exercise where I'm like, you know what, this person knows that I'm coming from a good place that if I have to give them difficult news or difficult feedback, like they know that I'm here to help because they've leaned on me multiple times in different situations and that's like they've literally said it.

So then I can feel more comfortable doing it. So genuinely if you're like, "Oh, I don't know. Like this person might not value it." Like ask why. And if the honest answer is because like you don't ever talk to them or you're never like working together on things and whatever it happens to be, like maybe invest some time and effort into that. And then when you have to give feedback, it's less awkward and terrible. But if you can, please try to do it early. Try to do it like when it's relevant. Not not waiting for some issue to to grow and get out of control because then at that point it's a lot more difficult to give feedback cuz you're like, "Hey, that thing that you've been doing for 6 months sucks. Don't do it." Um, but yeah, I think that's all the ideas I got.

I didn't get to even the manager stuff because I guess the drive was shorter than I thought. But if you got questions, leave them below in the comments or go to code.com. You can submit your questions anonymously and then check out the other Dev Leader channels. I got to get into CrossFit, so I'm not going to spend time on that, but there's three of them. Devleer for programming, Devleer Path to Tech for resume reviews, and the Dev Leader podcast for interviews and a live stream every Monday at 7. I'll see you next time. Take care.