Measuring Developer Performance as a New Software Engineering Manager

Transcript is auto-generated and may contain errors.

Hey folks, I am headed to CrossFit. I'm uh taking Monday off today from work for my on call day off. So just going in a little bit later. Usually it's I guess now that it's basically summer. It does get light. So that would be wrong for me to say it's usually dark, but historically it's been dark because it's always overcast and crappy and it's been winter. So, um, but that's not the case today. It's nice and sunny. So, I got a topic. I'm going to go back to this email that was sent in with a ton of, uh, engineering management questions. And um if you're not an engineering manager, I still feel like a lot of this stuff is relevant because if like if you watch my other videos, I often talk about uh you know being aligned with your manager I think is like incredibly important in your career.

Um so finding ways that you can make that work or if you're basically in a situation where you've been kind of avoiding it, I don't know, for whatever reason, like just uncomfortable talking to your manager, you don't see the purpose kind of thing. Like a lot of my beliefs as a software engineering manager are like, you know, if you have a crappy manager where you can't get on the same page and stuff, maybe that's a bad spot to be, but when you have someone that you can work with, it should be like a beneficial working relationship. So, I just always encourage people to to kind of see it that way. Um, so this question that comes from this individual in the next part of their email was around measuring performance, and they didn't just want to lump that into the last video. Um, I was talking about collaboration and stuff like that.

Uh, I wanted to talk about this more um, specifically I guess and this is like a, you know, as an engineering manager that has never done this before, this can get kind of weird because you're like, well, what what is the way that we measure the software engineers? And I think that this ends up being like this balance between sort of like the things that that you value. Sorry, there's a a school bus that's stopped here, so I have to Okay, we're good. Um, between the things that you value and then like as you're building this up in your career, it's not just what you value though, right? where you're working like they should be setting the expectations for the software engineers in terms of like being more uniform at levels and different bands and stuff like that. But what you'll notice is that there are things that you find that you value in software engineers and ideally that's aligned with where you're working because when it's not that becomes really um challenging, right?

I'll give you just a very brief example of what I mean. One of the things that I value most in software engineers um and especially as they become more senior is that I value almost more than anything else the ability to help other software engineers on the team. Um the reason I value that is because I think that is the best way to have a multiplier effect and bring up the entire organization. So um I and if you want to challenge that thought with like well you know level appropriate kind of focus. My point is that it's not necessarily you have the most senior engineers on the team helping the most juniors but having this cascading effect where you know the more senior people can help the people maybe a level or two below them kind of thing and so on and so forth. Not that you can't help the junior people, but basically having a cascading effect where you can help other people get better um and enable them to be more effective.

In my opinion, it's like one of the things that I value above all else. And um that's just like that isn't the case everywhere, right? Like at Microsoft, that's not the case. If you were a principal engineer and all you did was work within your team or even cross team just to help other people be more effective, um it's not really going to work. you need to be able to demonstrate that you're having a um a more concrete business impact that's at an organizational level at that point. And what I just described would be more almost like looking inward like it's still having an effect but it's not going to land with um with the people that ultimately make the decision which is not the engineering manager. So these things will be in conflict over time and you need to have alignment with where you're working because that is going to be setting the standard.

Now this individual is at a startup. So this could be a little weird because if I recall my time at a startup, we didn't even have levels. We introduced a senior software engineering level because we were like, we're pretty sure we need to start doing this. Um, but the thing that we were most cautious about was just introducing more levels without having it figured out because it's much easier to introduce a level than it is to have people in levels or even in rolls and then like try to take them away because you're trying to recalibrate things. So, it's it's challenging, right? So, we had to do that at a startup for this individual. I don't know um you know if they have a bunch of different levels and stuff. What I would highly recommend is making sure that I don't know how many engineering managers there are there or like what the whole hierarchy looks like.

I think it from what I understand it's relatively small. Um but I would make sure that there is level set expectations across the organization for different levels. Uh, I would highly recommend coming up with something that's like a rubric to measure the core competencies that people expect at different levels and and iterate on it. It's not going to be right the first time. Um, whatever you do the first time will be better than zero because if there's nothing, how the hell is anyone measuring uh effectively, right? So like the company needs to decide in terms of values that they want like what do you want demonstrated that needs to be established that's uh you'll have input on that as an engineering manager of course but like the other engineering managers should too um different people in leadership should and then I would highly recommend coming

up with uh the best way that I would call it is just a rubric and then be willing to acknowledge it's not going to It's not going to be, you know, perfect the first time. It's probably not going to be perfect for a while. U I would recommend using that rubric with people on a regular basis and especially in the beginning when it's being created. I would highly recommend pulling in um I don't know how you do this in practice. I know for us, we kind of uh did a little bit of vetting with some of the engineers on the team just to make sure that like not that they get to dictate how they're measured, but more about like the clarity in what's being said. Like if we're saying that these are things we value, so you know, demonstration, I'm just making things up, right?

So, uh, being able to demonstrate your your technical abilities and at different levels how that's measured. Um, is the clarity there I just spat everywhere. Is the clarity there in the rubric that we have? Um, because if it's not, like that needs to be refined because if you go to have conversations with people or if you put this rubric in front of people and they don't understand what's going on, then like it's not going to be a good time when you're trying to have conversations about it. So, I think maybe some people listening to this might say, "Well, a rubric feels kind of ridiculous. Like, I'm an adult. I don't need a rubric to go by." Um, it's a it's a tool that works in multi like multiple different directions, right? Um, I have so I'm at Microsoft right now. We have in Microsoft 365 there is a career guide or a talent guide.

It is a big rubric. Um, I use this regularly with my team, with my previous team. They love it. They absolutely love it because number one, I have to use this kind of information when it comes to having people conversations for rewards and promotions. And number two, what really helps is being able to align the work that people are doing and demonstrating to the engineers like this project you're on or these scenarios that you were navigating, these are examples of these things. So you work on it together to be able to call out the examples, right? You help work with the engineer. So you help the engineer work with you to basically over time build a case for promotion. You just collect evidence that aligns with this rubric. It's a great way to talk around things too because you're saying it's in writing like these are the expectations and you get to talk to the engineer about how you're evaluating them against that.

Now, you might not always agree or be on the same page, which is fine. Like, that's what you have conversations about. If they're like, "Hey, like just to give you an example, like, hey, I see in the rubric it says X and I, you know, the other day I had a conversation with a person on a different team, so therefore I've accomplished thing X." Right? You might say, "Actually, that's not how I observe that." Right? Like doing that one time. Yes, that was an example of it, but you're a senior software engineer. We need to be able to see that kind of interaction happening regularly. So, great job doing it. I acknowledge that, but this is something that I want you to keep working on so that it's it's being demonstrated regularly. It becomes a conversation point. So, I don't know. For me, I think rubrics are super helpful uh especially when it comes across um the organization, right?

I can say this person I want to have for these rewards. Here's why. Here's the impact of the work they were delivering and here's how they're progressing against this rubric. Here's the things I still have to focus on. So, I find it very helpful in those conversations. And like I said, the people on my team um I don't think I think there's been like one person out of two teams that didn't really find it valuable. And I think it's because the level that they're at, the rubric starts to fall apart a little bit. That's probably the best way I'd put it because like it's really diff it's at a high level. It's very difficult to capture all the things and then it starts to become kind of ridiculous. Like every every single cell in the rubric because it's a big table. Every single cell was like its own full-time career.

And I was like I don't I don't know about that. But um anyway, like you know, aside from this individual and I don't think that they were against the idea. It's just like it was hard to navigate it that way. Every other individual has really valued doing that. So, uh that's a tool for doing it. It's not the only way you can do it. But if you watch my other videos, I always come back to saying level setting expectations, right? So in terms of if the question is really like what things should you be looking for like I said I would establish that across the organization. Try not to make it up yourself and do it in isolation. If your company wants you to be driving this then I would basically start collecting ideas around what things should be valued. But it doesn't mean that like you as an engineering manager sorry my phone holder is dead so I have to keep looking down.

you as an engineering manager, you don't just get to make that up in isolation and some other engineering manager does the same thing and how there's different standards internally. That's not the case. But I would think about what you expect at different levels and then maybe come up with thoughts and bring that together with the other engineering managers. So for example, junior engineers, what do you what do you expect of junior engineers? Right? I expect personally like these are things I would want to see. I would want people to be exhibiting curiosity. I would have the expectation that they are relying on their team members, but there is a trend for seeing them become more and more autonomous, right? Of course, they're new. They have to learn the codebase. They have to learn the product or service. There's there's a lot going on. So, in the very beginning, they need handholding.

But if they're curious and they keep iterating, we should see that they're becoming more independent with being able to deliver things, right? They may not be able to navigate ambiguous feature asks or ambiguous debugging uh scenarios, but like they're at least eager to learn and try, right? At a very junior level, that's what I would expect. And I would kind of go through this thought exercise and think about different characteristics of engineers. If you have a talent guide that talks about values or at least if you want to write down those values first because you might say on collaboration, on innovation, on um on technical abilities on like on customer focus, write these things down. They could be very much like just your company's core values and then add in a few more things like specifically around like the engineering role. I would start with that and then I would go to the next level like depending on your company and how many levels and stuff.

Okay, engineer 2 like at this point they do have independence. They are starting to break through on more uh ambiguous challenges, right? They don't need to be handheld as much. Um senior like very capable of navigating ambiguous challenges can work cross team like just I would go through this exercise write it down for yourself and have other engineering managers do the same and kind of come together to discuss it. This is what I would recommend doing in terms of having that guidance ready and then from there going back to the level set expectations having conversations with people about it. Right? It's it's a matter in my opinion it's a matter of calling out these opportunities where they can grow and focus. There's going to be some stuff on the rubric that's like, you know, for some people you're like, "This is a no-brainer. Obviously, they do it regularly." And if you have a few of those things because the engineer is good.

Sometimes it kind of feels like a rubric's a little bit silly. But the more people that you work on it with, the more you'll realize like this person is operating at this level, like it makes sense. if we need them to continue to focus and like improve on that, then you can call that out based on your conversations with them on the rubric. But that's my my go-to for this kind of thing. Um, you know, if I if I were to work at a company, so I'm at Microsoft now. If I were to work at a company later and there was not sort of uniform expectations for engineers at different levels, that would be something as an engineering manager that I want to bring up early. Um, it's really difficult to have career conversations with people if you don't have that because it goes back to like what things do you value which you know probably can use your gut feel and intuition and you're probably not too far off the mark.

I got to exit and I'm in the wrong lane here. There's too many big trucks. Let's go. I might be okay here. Um, you don't want to do these things in isolation because it might it might work for you and your team and like that's that's actually good, right? That's a positive sign. But if there's other engineering managers in the org and there isn't alignment, then you create this really weird situation where some people are being measured in different ways against different expectations. That's not a good spot to be in. So I am encouraging you to think outside of your immediate bubble. Uh if the company is small and you are the engineering manager, great. But I still would come up with those ideas as I explained and then I would probably try to work with leadership or HR, right? Like work with some other people in the organization to be able to make sure that this makes sense, right?

This is a pretty important thing. So you might take the first pass at it. Work with um people in leadership like the you know CTO, CEO kind of thing or VP depending on the hierarchy structure. um work with HR on it and then acknowledge as a group for everyone that's participating on that. This will need regular attention as we're scaling because it will it will absolutely change. Um yeah, I think that's mostly it. But these are great questions. Like I know these are kind of things that I had to figure out over over many years when I was an engineering manager to start because like it's a similar situation, right? I was at a startup so we don't have structure in place. I've never been an engineering manager before, right? I was, you know, working as a software engineer for not long before they made me a manager.

So, I don't even know how to progress in my my own career. Like I I always joke about this like to this day, I've been an engineering manager for 13 years. I've never technically been promoted technically. So, like what what does Nick even know about like navigating careers and promotions and stuff, right? like I promoted people, but you know, I had to go make some of those decisions early on around um guiding people in career conversations, setting up rubrics and talent guides and stuff without technically ever having been promoted or promoting anyone at that point, right? And I had to go into having um rewards conversations. So like at year end like raises and stuff like that having compensation view and being like I've never done this before. So yeah like these I love these questions that are coming in on this email because um it's just this good reminder that like the beginning especially in a startup environment is like it's hectic.

And I think that's the important thing to like to keep in mind is that this stuff we're not going to do that. This stuff needs to be worked on. And um because like it doesn't exist when you when you compare startups and bigger tech companies and I don't mean just big tech like Microsoft, Amazon, Facebook, blah blah blah. I mean just larger companies compared to like a a fresh startup. You get structure at these other companies, right? They've had to build up the structure over time. And sometimes the amount of structure they have may make zero sense for you at your startup. And that's okay. But over time you need to start introducing more and more structure. Just to give you an example, if you had two engineers on your team, honestly, at that scale, if it was an early phase startup, they probably don't give a about like what their level is.

They're like, "We're building cool stuff. We're getting paid well. Like, hell yeah, let's rock and roll. This is great." Ideally, that's the situation you want to be in. But over time, you know, you grow the team to like 20 people, to 50 people, 100 people on the engineering team, like those like the structure that you need around that needs to start forming because now you're going to have people that are coming in going like, I'm not motivated by this same thing just because it's interesting and like a cool like maybe opportunity for equity and stuff like that. They're coming in being like, this is my 9 to5. I'm gonna do good work, but you know, I just want to be able to grow in my career. And it looks very different to them. Nothing wrong with that. But how do you make sure that there's uniform guidance around measuring performance of these things?

It's tricky. So, you need to start building up the structure for it. I know that um I just want to give you one more anecdote before I get to CrossFit here. Um I remember I've said this on this channel before, but I remember being like I don't really see why people care so much about their their titles. Like who cares what level you're at? What does it matter if you're an engineer one or seven or like just I could not grasp why people cared at all? I'm like, you're when you when the year end comes and you get more money and like that feels good and we give you more responsibilities and that feels good like or you're getting equity and that feels good like aren't these all the things you care about and then I realized especially um you know probably 7 years into

being an engineering manager six or seven years um there's it's different because you'll have people coming in where they're like as part of their career progression if there is no level right they're going they're a principal engineer somewhere then they go get take a job somewhere and it's like now it just says software engineer on their resume they're like I'm not showing progression on my resume I'm not showing advancement in my career right whether you agree with that or not like besides the point if that's how they see it then that's not going to be appealing to them right they want to be able to show advancement in their career. So I started to realize this when we had more people coming in that weren't just like hell yeah it's a startup. They're like no this is my 9 to5. And then I go to some place like Microsoft and I realize that especially in big tech everything is about levels everything.

Absolutely everything. It's the number one thing people care about because that's their career progression. That's the thing they're measured against. That's their pay. That's their bonus. That's their stock. It makes sense. I never cared about it until like coming to Microsoft basically where I'm like, hm, this is the only way that I can measure progress because before with a lot of autonomy, it was just like you can keep giving me responsibilities and areas and I'm going to go crush them. Like that's how you're measuring my performance. Like we can all see it. I go do good things happen, I get compensated. Hell yeah. But no, not at Microsoft. It's like I have to go I'm I I'm part of everyone else who's like how do I get to that next level? Um and realistically I don't like that because I feel like that just takes away from like uh all of the software engineering.

But that's a conversation for another video. Thank you so much for sending this one in. and a friendly reminder to people. If you want questions answered, send them in uh either in the comments, write them below, or message Devleer on any social media platform. And the code commute site is live. I vibecoded it over the weekend. So, there's a dev leader video going out on that. The question submission page is not done yet. I might work on that today and then do a YouTube video for that as well on my main channel. But very soon I will be saying go to codecommute.com and submit your questions. So talk to you folks later. See you.