Impact from Helping Others - How and Why for Software Engineers

Transcript is auto-generated and may contain errors.

Hey folks, I'm just leaving the office. It's like 7:30. It's It's a late one. Um, which sucks, but uh it was good to be at the office today. Had really good discussions. Um like uh kind of stuff that I I think like as teams it's like really good to talk through. It's like not always easy, but like I think I think good conversations and I hope others see like value and and that kind of stuff. So, um I that's why it's late, right? Like meetings kept going. We kept discussing and I think that it was just uh overall like good to be to be having conversations like that. So, I got to go to experienced devs subreddit for a question today. And um this topic is on how you can use helping others in terms of your performance reviews or like career conversations and stuff like that.

like you know um you will hear that there's expectations of you for being able to mentor more junior people, being able to help other people grow and just helping out in general on the team. Different places will look at this in different ways. Um and you know for many places becomes an expectation that you're doing this. So how do you go about actually calling it out? So that's going to be the topic for today on the drive home. um because it's so late since it's only going to be 30 minutes, which means we can probably do it faster. And uh if you're new to the channel, a reminder for you that this channel is all based on questions that you have, so you can leave them in the comments below if you'd like to ask anything about software engineering or career development. Happy to try and answer.

When I don't have questions, I go to uh usually experienced devs or CS career questions on Reddit to pick a topic. Um, and then if you're not comfortable leaving stuff in the comments below, you can look for Dev Leader on social media, that's my main YouTube channel. And I have like, you know, C tutorials. I have a podcast there. Uh there's a live stream every Monday at 7:00 p.m. on topics like this. And there's also a resume review uh option there. So, you can check out the playlist and you can submit your resume to me and I can review it for free. So, with that said, um let's talk about this. I think this is an interesting one. Uh I'm going to I want to give like a disclaimer at the beginning of this that this is absolutely going to be one of those things that's subjective.

You might have a manager that cares more or less about this. You might have companies that value it more or less. So, I'm going to be talking about it primarily from the perspective of this is a valuable thing. This is an expectation that I have of engineers. Um I I think that it's very helpful, but I want to talk about how this looks across different levels and how we can try to balance it out a little bit. So that's the the idea, but I I wanted to share the sort of the caveat with you because, you know, if you are new in your career and you're like, well, this guy on the internet with no hair and uh says a boot cuz he's from Canada, uh he said that I should do it this way and like I it's backfiring. Like everything's going to be situational.

I can't speak for every manager, every company, that kind of thing. So sorry, that's how it is. But this is my take on it. So I do think that it's very important for engineers to be doing this. I think that you can be doing this essentially at every level, but the expectation of it changes at different levels and probably your effectiveness and and ways that you can demonstrate this changes across levels. So one sec, let me make this turn. Yeah. Okay. Um and that means that probably how you want to approach this can look differently, right? So I would say especially if we start at more junior levels, right? a lot less of an expectation on you to be helping other people. Because especially at junior levels, one of the more important things is that you're able to start demonstrating that you have autonomy, that you can start being productive, you can get in the groove of things.

When I say being autonomous here, I don't mean like you just ignore the team and don't talk to the team or you go rogue and do whatever you want. What I mean though is that you don't need the more senior engineers to be like to be holding your hand through everything in the beginning. Absolutely expected, right? You're brand new, you know, early in your career, junior engineer. Cool. It's totally expected. There's going to be some handholding. I don't even mean that in like a negative way. You're learning, right? People have to onboard you, ramp you up. But to make progress, there is this expectation that you require the training wheels coming off, right? You're able to do things more on your own. You're seeking guidance as you need it, but you don't have someone that's giving you uh like the prescription for how to go do everything.

Okay? But because that is an expectation in general for more junior engineers, it's great if you can be helping others. Of course, like if there's more junior people or you happen to be building more experience in an area than someone more senior that hasn't had to touch that part of the code, that product, that service, maybe you're helping more experienced engineers on different teams understand what parts you're working on in your product or service, it can look different, right? Um, if you're able to demonstrate that kind of thing, that's awesome. Like that's a that's a huge huge win. But in my opinion, it's not an expectation. Like if I'm trying to promote someone from you know being a junior level to the next level I'm not like oh they better have done this I expected that but if they have done it like that's a

you know that's a huge plus but as you progress I think that ex like that becomes an expectation right so as you approach midle towards senior like especially at senior I really think that you do need to be for like again my my opinion on this places I've worked value this. So that's reinforced. But I think there's a tremendous amount of value in in uh you know more senior engineers being able to help uh mentor and help grow the other people on the team. So being able to help others. Oh, come on buddy. You're going to ruin this. You're going to ruin it. Zipper merge. There you go. You can do it. My goodness. Um there is this expectation that as you're more senior that you are you know doing this with other members of the team and I would say like for me at Microsoft I have only had people up to I am at principal level at Microsoft and I've had principal engineers reporting to me.

I've had the way that the leveling works. There's like a a like a ro title like principal engineer, but there's levels within that as well. And usually there's a couple of levels. Uh I think in principle there might be three like 65, 66. I think 67's still principal. I don't know. But um I've only like I'm a level 65 at Microsoft, which is the first level of principal. And I've had, you know, 65s reporting to I've had 66es reporting to me. At the principal level, there's absolutely an expectation that you're enabling other people on the team to be more effective. But when I talk about this kind of stuff in general, like expectations across roles, the level of impact, that guy's flying, man. Holy. Um, the level of impact is expected to to be greater. The surface area is expected to be greater. And the same thing when you're helping others, right?

It's like at principal level, you should be finding ways to help make the entire team more effective. That doesn't mean you can't help individuals or something like that. But the expectation is like the scale of that impact is greater and it doesn't mean every day you have to be doing that. But there should be some things that you are demonstrating that look like that. So the the root of the question was really around like hey if I'm doing this like how do I how do I talk about it and the reason I wanted to go through sort of like a level progression around this stuff is because the expectation around it I think looks different at different levels and that means that if the expectation is changing um in all of these cases I'm talking about helping other people because that expectation is changing depending

on your level you may want to talk about it in different ways right so just to give you an example okay I'm going to do like two extremes if you're a junior developer and you are able to claim look I helped the entire team by doing X I enabled everyone in the team to be more effective I was able to help them learn about this like basic basically helped others but across a large audience. That's going to be like really really awesome. That's a huge standout thing at principal level. So the other end of the spectrum in this example is that like that becomes an expectation of you. It's no longer oh my god that's so amazing. It's more like good you're doing that because we expect that of you, right? The the marker, the bar that's used to gauge you in your role moves. As you become more senior, that bar is raised.

Um now the other thing that I want to mention very briefly though just on the bar being raised is like because there's many facets to software engineering I would say that as you increase the bar across all of these facets I personally feel like it becomes impossible for you know at a at a very high level that you have all of these things maxed out. There's going to be some things that, you know, you've definitely done like an amazing job across, like super great, and a couple others that are like still really good, but they're not like, you know, totally above and beyond. But for the most part, you shouldn't have anything that's like lagging behind. Okay? So, it's when you're more junior, it's probably, you know, you're probably able to demonstrate more consistently across all of these facets that you are doing a good job.

But the more senior it starts to have a little bit more variation I would say. I'm just generalizing trying to make a point. So because these things look different at different levels, how you want to convey them will look differently as well. So if you're going into, you know, senior, you're a senior level trying to be having career conversations about going to principal just as an example. If you're saying things like I, you know, I helped mentor people on the team. I would say yes, good, that's expected. Does that mean that you might, you know, you're consistently showing that you're doing a good job of it? Does that mean that if you're also doing a good job across the board for everything else and like from a performance reward perspective, you might you might be doing better? Yeah, perhaps.

like basic you know obviously I'm just making a super generalized uh example here but you know at senior if you were like hey I've been able to demonstrate that I've had large impact across the team uh in terms of mentoring and helping and and whatever else like that is sort of next level expectations that is good so when we go to talk about this stuff I think that that's really important now I want to walk through what some examples of that look like because I think it's probably there's there's going to be situations. I think the example that was put into the Reddit post is like a pretty common thing where someone's thinking about it very tactically.

So, what I mean by that is their their example from this Reddit thread was essentially like, "Look, I want to be able to talk about how my how I'm helping others and like I want to be able to demonstrate the impact because it looks like I'm spending a lot of time like answering questions like on Slack or something." And I think that at a at a more junior level, and I'm not saying like the most junior, I just mean more junior in general, that that could be great, right? That could be something you you talk about with your manager in terms of like, you know, what kind of impact are you having in that facet of software engineering? I want I want to want to ah I don't want to forget about something. So, I'm going to come back to it in a second, but how do you go to talk about that impact?

Well, you should be able to say, "Hey, look, like on a pretty consistent basis, I've been working with engineers from from the team or different teams, whatever, and answering questions on these types of areas that I have, you know, been building up some expertise in." Great. All right. Like that's how I would talk about that because at at a more junior level that might be the type of impact that you're striving to demonstrate. I think where the the danger in that framing comes in is that the more senior you get, if your framing is constantly like I spend so much time in Slack just like helping people. Then there's more of like a question around like, well, how are you helping people? This is going to sound kind of funny, but are you helping people because they come to you and ask a question and you give them the answer?

cuz yes that's help but that's like a a more uh I don't know what the right word is a more junior way of helping people is just giving them answers right the the more sort of long-term better investment type of approach is like you guide people for how they can get the answers right you teach them. You don't just say, "Oh, the answer is X." You say, "Oh, I you're so you're trying to get to this answer. Okay, like here's some tools you can go use and I'll point you in the right direction." Right? Maybe you give them a starting point and then you enable them to go find the answer, right? Give them some guidance so they can go figure that out. Now, you've and might take a couple times. This is the thing, right? It's not it's not necessarily easier to do. Often it's more difficult which sucks because you're trying to help people.

You want to give them the shortcut but you have to give them a more difficult path but the reality is they end up learning more this way. And what ends up happening is that you start enabling people to be more effective. Now this is still a onetoone type of thing. It's also something that doesn't scale super well. It scales better than giving every individual an answer. That scales real poorly. That's like a negative scaling factor because other people don't get better and you spend all your time doing that. The next version of that is like teaching other people. The next version of that is a combination of teaching other people and then putting either documentation or tooling and systems in place that kind of push people into the pit of success, right? You can e you potentially avoid classes of problems. You can avoid people having to to have to question and go diagnose things because the information is readily available.

That's more of like a system level view. of being able to drive impact at a broader scope even though it's related to just like helping other people, right? So, how you want to go communicate this stuff, you have to think about the level that you're at and the expectations of your level and the expectations of the next level. The thing that I wanted to come back to, I've already forgot, but I knew I wanted to come back to it. Did you remember that I said I wanted to go back to something? Uh, if I could rewind my brain. Um, I think the thing I wanted to talk about was like the when we're talking about the expectations at your level for being able to help others and what that looks like in terms of, you know, progression and stuff, you should seek clarity with your manager on this.

This is my one of Nick's go-to things that he has to say on every vlog is like talk to your manager. Um, but I mean it. I always mean it. The uh idea being that you like if you're talking about career development, promotion, stuff like that, your manager is the one that has the influence over that. If you if you have different expectations than your manager on that, you might feel friction. you might feel like you're doing the right things and then like being disappointed that that's not coming through. Um I feel like there's a pickup truck that's trying to race me. Like it's it's weird. They uh they keep trying to like match my speed. Very weird. Um the uh the point of that though, right, is like in in organizations that I've worked in Oh, police. Are we safe? Let's see. Are we safe?

No cherries. That pickup truck just wanted to pass. I passed them back. The uh organizations I've worked in have done a good job in trying to like have um like written down expectations, right? So at Microsoft, we have a talent guide or like a career guide talks about the expectations at different levels. This kind of information is documented there. When I worked at Magnet Forensics, I was part of putting together this type of thing. Um, there were revisions and stuff to it. Obviously, it needed to happen. We're a startup. It's not going to be there's going to be some gaps. So, but this is the kind of thing we talk about at different levels like what is expected of you? How do we how do you get graded in terms of performance so that there aren't surprises so they have consistency across managers and levels and stuff?

So, if you're like, I don't even know if we have that, have a conversation about that, right? I'm hopeful that more and more places have this kind of thing so that people aren't guessing and that more and more people talk to their manager about this kind of thing so they're not left guessing because some places genuinely I don't know why but some places genuinely might be like look we value helping other people less I'm just making this up we value helping other people less because we expect that people are going to be more self-sufficient And we need people to drive their own progress. And those are our beliefs. We value helping other people less because it's a it's more of a distraction and people should be more enabled to solve their problems. We would rather put systems in place to help people solve their own problems.

And that's our philosophy. And then you go to that org and you know in your career so far you've been like man I know that I've always been able to you know be compensated well because one of the things I do so good is I help other people and like that's awesome and then you go to this place and they're like you suck because you spend all your time helping other people. It's just it's like different expectations right? So that's why I wanted to clarify at the beginning in my career in my experience as an engineering manager and even in my like my as an engineering manager managing other people and as someone who is being managed it's always been um a key component for engineers and myself as an engineering manager to be helping others but that's why I was stressing how you go do that.

So I think that's in my opinion the most important part about how you sort of demonstrate the impact is think about what kind of impact you need to be demonstrating. And just to quickly revisit that um at more junior levels if you're able to show any oh come on man it's a red light but you can turn right should have went um at junior levels is it expected of you? Not necessarily, but if you can do it, that's great. The more you get to mid-level and senior, the more there's an expectation that you're able to help other individuals, especially at senior. And then I would say beyond senior. By the way, I'm using like principal, like you can put staff in here however you want. I don't know, we don't have staff at Microsoft.

Um at principal level it's more of like minimally it's expected that you're you're mentoring other people and helping them but uh having like a teamwide impact in that case is like sort of what you need to be demonstrating at least that just becomes the expectation. The bar is is changed. So how do you document this? Again, um I would try not to cuz you could probably use language in terms of how you talk about this or document it in a way that even if you're helping things people more individually where you're showing like holistically, I'm addressing this class of this category of issue that's coming up. So yeah, I was helping Joe and Sally and Bob and Frank and like, yeah, that was individual, but as a side effect of that, um, I actually had, you know, Frank go and create the documentation on this

and Sally actually ran because I was helping Sally, she actually ran a presentation on it and was helping even more people, but like I was kind of driving all of that. So you could talk about the impact that you had even with individuals and how they went beyond and had like a larger impact. It's a possibility. But like is that something you talk about with your manager? I would say so. I don't know what kind of tooling or systems you have at your organization to document your progress. At Microsoft we have I have Deion on Happens when I'm talking too much and not breathing. Um, at Microsoft we have things called connects twice a year. It's a great opportunity to document this kind of stuff. So, um, other places have like, I don't know, like different types of performance review documents and things like that. If you don't have anything, I would say do try to take some notes.

Do try to bring those up in conversations with your manager. I think it's important. But I think that's probably it. I have crazy heartburn right now. Oh, came out of nowhere. It's like I yawned and then I had heartburn. There's another yawn. My goodness. Long day. Um yeah, I think that's it. I'm going to just remind folks um the video I recorded this morning, which in theory should be the previous video posted before this one, is sort of my admission that my live stream on Dev Leader that I just did, I don't feel very proud about it. So, just want to call some attention that I'm going to be re-recording it on my main channel, Dev Leader, and I'm just going to I'm not going to do it live, but I'm going to build the thing that I set out to build. And that's going to be the code commute landing page, which will be cool.

We're doing it. Woo. Um, it's a game time decision to go through that intersection. Um the landing page is ideally going to be set up so that um when you want to submit questions to the channel, you can either just comment um and instead of trying to find a social media account for me, which it's been working well, people find them. Uh which is cool news. Uh I will also suggest you can just go to code.com and submit your question anonymously. So I'll build that. I'm going to record the video of me vibe coding it with AI agents because it failed. miserably on the live stream, but uh I don't think I took enough responsibility and that's the part I feel uh dissatisfied about. I feel like kind of guilty that um I just don't think I did a good job. It's not the standard I want to hold myself to.

So, uh I'll record it when it's done. I will mention it a few more times on the channel and it's there's probably going to be a gap between when it's coded and when it's actually deployed and live and usable. So, the intros and outros to these videos will change and I will be saying go to codemute.com and submit your question. Doesn't that sound cool? That's way better than the other 25 to 60 seconds I say go look for me on social media and blah. but it's going to be built in Aspire and Blazer. So, it's going to be a netbased setup. If you're not familiar with those things, they're cool tech. So, Aspire's to help orchestrate resources for cloud deployment. So, you don't have to set up your YAML files anymore. It's all like you write C first and super cool. um kind of learned that it will do Docker um resources.

So like you write some code when you go to run it locally, it's not a cloud deployment, it will go pull a Docker image and run Docker for you. Like it's badass. And um then it will call your app and start it up and everything. Service discovery, it's got an awesome dashboard. But Blazer is going to be the actual uh framework that I use for um the landing page and that is Microsoft's um offering for being able to create web frontends in C and Razer pages. So um I am not the person that loves front-end webdev. So like JavaScript, TypeScript, React, Nex.js, I hate all of it. I don't like using it. Um, can I be productive? Sure. But not my not my first choice. It's funny.

Brand Ghost, which is the product and uh service I build on the side for my content creation and to help other content creators that has a Nex.js JS and Typescript front end because the other guys on the team are more effective at using using that to be Oh, is my wife behind me? I think my wife's behind me. Let's see if she puts her signal on. That's the wife for sure. She's got to wait her turn to get in the driveway. She's probably like, "Oh, he's so dumb recording his stupid videos." Oh, yeah. I'm so popular on the YouTubes. You know, you could never be this popular. You want to see my wife? There she is. Oh, no. You'll never see her. She's real. I promise. Anyway, I'll see you next time.