The TOP Things That Will Get Your Program Manager Resume Noticed

something a little bit different for the résé review series. Today we're going to be looking at a program management role that someone has submitted and this is going to be a friendly reminder to you that if you want your resume reviewed, you can submit it to résuméser.ca. Now, I want to let everyone know that for the résé reviews, I don't do roasting. I don't grill them. I don't make fun of them. This is all about trying to give constructive criticism, calling out the things that I think are done well and the opportunities for improvements. Now, this isn't a software engineering resume, so that's not typical, but I still want to give some perspective on this because someone was looking for some insights from my point of view. So, let's jump over to this and start going through this resume. Now, this person has a ton of experience. So, just to call it out right at the top, right, we can see that they have 13 years of waterfall and 8 years of agile. As a program manager, I think this is really good to call out because you have companies that might focus on different things. It's probably worth pausing on that for a moment when we see program manager. I have seen roles defined as product manager, as program manager, as project manager. And I generally find that program managers are sort of like this hybrid role between the two. But depending on where you're working, the roles and responsibilities may overlap a dramatic amount. I do find generally that product management side of things focuses more on sort of like what customers are looking for and how to uh sort of develop and shape features whereas project managers focus more on uh coordination between teams road maps timelines things like that but again with program management I see this as a bit of a hybrid often so in this person's particular case I can't say exactly but I think a lot of their uh their work experience kind of does highlight a bunch stakeholder management as well as project management as well. Just to quickly skim through because I want to talk about sort of like the shape and structure of the resume to start. We can see that there are a lot of bold highlights calling out impact areas. We can also see that they have their work experience taking up the you know overwhelming majority of their resume which is what I would expect for someone who has this many years of work experience. The other thing to call out is that we do have education kind of called out in this part down here, which is great. If you have it, call it out. And then we have some software. Usually for software engineers, we'll see people calling out different skills and technologies and things like that. So having some software called out, I think, can be helpful. It might give someone a bit of perspective on things that you're familiar with. And then certifications, again, if you have them, call them out. I think for software engineering, my perspective on this is that I I've never seen certificates like make or break someone getting a role. However, you know, if you have it, it to me it demonstrates that you were willing to go invest more into learning and that kind of stuff. I think with certifications for program management that might look a little bit different. However, it might just be that someone's looking to ensure that people are more familiar with different types of processes. So again, I don't personally think that's going to be a make or break thing to have CS, but if you have them, call them out. Let's go through this work experience. And we're not going to go through every single line in great detail because there's a ton to call out. And I think that as I was saying, as you kind of scroll through this, right, we do see a lot of bolded examples calling out impact. But the other thing is scale of the work that's being done as well. So we can see like right at the top enabled 80% self-resolution of Microsoft issues reduce 30 plus day service request by 15%. We can see the impact that's being had in terms of the work that they're helping coordinate. Again, as a program manager, this is often not like this one person is like responsible for doing all of these things, but they probably have some examples that we'll see where they are calling out things that they might actually be, you know, responsible for versus uh just the projects they were leading the sort of summation of that work being done. Similar as an engineering manager, it's not often like I have a very specific project where it was just me, but it's often times I'm leading teams of engineers that are delivering on things. So this is kind of an interesting thing to try and call out when you're talking about impact optimized jer instance configurations resulting in a 50% improvement. Like this might be something that you know they spearheaded they drove a lot of that and then had that kind of impact. All of these types of things are, you know, so far things that I would really want to see in a program manager where they're not only able to sort of lead and drive projects, but also like they're having these types of impact within the team to sort of like be able to help with operational efficiency and that kind of stuff. So, I like that a lot. Documented OKR, milestone, epic, and story hierarchies and Miro. Having familiarity with OKRs, I think, is huge. If you're a software engineer, maybe you haven't heard of this. It's a objectives and key results. It's a very popular framework for being able to help define what goals are and how you're going to measure them. And then it kind of breaks down into uh deliverables. But what's really nice about objectives and key results is that the objectives and key results themselves are not the individual work items. So you don't do planning and say, you know, on the onset of planning, we're going to do every single one of these granular things. It's actually like here's the goals we have. Here's how we measure success. And then what's great about that is with the engineering teams, you can figure out what those work items are that try to move towards those goals. And the other great thing about that is that if you're trying things out in that period of time, so say it's a quarterly or, you know, six-month period, if you're trying things out and it's not moving towards that goal, it means that you're perhaps focusing on the wrong things and you can pivot to still try and achieve those goals. So very popular framework. We see something here like a $19 million budget. I think this kind of thing is helpful in terms of calling out, you know, scale of projects that people have worked on. Terms of being able to trust program managers, you know, with responsibility in areas that they're going to be taking care of or helping coordinate. If someone hasn't really worked on something large scale, it makes it a little bit trickier to feel like you can have a lot of confidence in them. But being able to say, "Hey, I have worked on really big projects with budgets that are really large." Again, that can be tremendously helpful. Doesn't mean that you have to have it. It doesn't mean that people won't trust you without it, but it's one of those things that can really help make people feel more confident. This is just a friendly reminder that if you're enjoying this video to give it a thumbs up and subscribe to the channel so you can check out more videos just like this. I'd also like to mention that I have other YouTube channels like Dev Leader, which focuses on C.NET NET and AI programming tutorials. And I do have the Dev Leader podcast as well where I interview software engineers so you can see what it's like in their career journey. And finally, I have Code Commute. So if you have questions that you want answered, I can make a vlog entry for you. You just have to go to codemute.com and submit your question or comment on one of the code commute videos what you'd like answered. Let's scroll down a little bit lower just so we can get through more of the resume. We can see uh here, right? like achieved a $350,000 in cost savings for customer service expenses, improving uh NPS, so net promoter score by 12%. This is a really big thing I think for a lot of places and this is the kind of thing earlier I mentioned like product manager versus project manager when I see NPS like net promoter score. This is something that I've worked with product managers on cuz like I said they're doing a little bit more interfacing with the customers I find uh compared to some of the other roles. that's, you know, an exact example of like what that could look like. So, I think that's great to see that they have experience doing that. Planning sessions and they talk and should have mentioned this already, but they do talk about different, you know, tools and technology they're using along the way. Um, I've talked about this in the software engineering uh resumes. I think that's really helpful to say, hey, here's, you know, where I worked, the types of things I worked on, but also what I was using as I was doing that. The reason that helps is that when we see someone I'm going to scroll to the bottom again. When we see someone call out like I've worked with Jira. Okay. Was it one time 15 years ago or if we scroll through this do we start seeing Jirro like you know at most jobs? Do we see uh Miro at most jobs? We can kind of see like how much exposure they have to these different things to understand their familiarity. Right? It's not a perfect measure, but it helps build confidence in kind of understanding when someone says, "I've worked with Jira." Okay, like there's Jira called out right there. I've seen Jira called out in a few different spots. Like, there's Jira. We'll probably see it at most um most of their jobs. So, stuff like that, I think, is really helpful to kind of correlate what you're doing with how you're doing it, what tools you're using. Let's keep going. Coach and trained HP smart printer design team on Scrum. Right. So this is a I think a nice thing when I talk about software engineering resumes being able to coach and mentor kind of shows that not only are you like you know a solid individual contributor but you're being a multiplier within the team and I think this kind of stuff is great to call out if you have it like here is me as an individual helping those around me become more skilled in a certain area. So great to call this kind of stuff out. We see consolidate three abander backlogs. So again, as a program manager, this would be a great thing to have experience with. I would love, you know, to have program managers that have experience going through backlogs and being like, how do we like clean this thing up so that it's manageable? It's a pretty common problem that happens at a lot of software companies. So I think that's great. Implemented standardized story points. Boo. No one likes story points, right? But again, if places use it, it's good to be able to call out they have experience with it. And to see something like this, right? I'm just going to call it out. implemented standardized story points, user story naming conventions, optimized team efficiency. Like, I'm sitting here being like, I don't like story points. I think they're dumb, whatever. But if places use it or if there's people that are talking about implementing it, having experience regarding that, I think, is great to call out. You know, I have never talked to this person about story points. Maybe they're like, "Hey, we did it. It worked." Um, maybe they don't even like them. Maybe they love them and they have a really good reason for using them and that's great or they see how it can work or not work on teams but the experience I think is helpful because it's a tool in their tool belt to be able to use. We'll keep going. Um this you know good example of you know at some companies you might be working on projects that are you know very large scale very longunning and having some examples of that I think could be really beneficial. I know like at Microsoft for example there's some of the project managers that um you know they're working on things like for capacity for the data centers and stuff and that's not something where you're like okay in like this this sprint we're going to go accomplish this project where we finished our capacity planning for the next seven years and like we did it in a sprint. It's like a lot of the time this stuff takes a long time. It's evolving over years. So, it's not just a small project. It might be done in like increments, but there's a, you know, larger overarching project. So, I think really good to be able to talk through stuff like that on your resume. Let's see. Orchestrated cross functional UAT efforts, seven scrum teams. Something I want to call out on this resume that I think they've done a really good job with is they've talked about different stakeholders a lot of the way through this. This is something that I would really hope to see with a uh a program manager because this is the kind of thing when you're coordinating large product uh projects sorry that you not only are working with the engineers um you're working with engineers across different teams you're working with other program managers you're working uh potentially with customers in some of these cases. You might be working with third parties. There's a lot to be said around these types of roles that can help coordinate with different stakeholders. It's not that I don't think engineers ever should or anything like that, but I generally find that engineers if they're not exposed to it a lot of the time, they need assistance with it. It's not that they can't do it. It's something that's generally a little bit uncomfortable if they're not doing it all the time. So, having folks in place that can really help facilitate that, I think, makes a huge difference. And even if they're working with the engineers, they can help guide them through some of those situations where they do have to coordinate. So I think it's a really really helpful thing to call out like the different types of stakeholders on resumes like this. But yeah, I think you know as we get down towards the bottom uh the you know the work experience gets lighter and lighter but all still great. I think what they've done a really awesome job on to kind of summarize this is that they have a lot of impact called out. Right? You can see, you know, I'm just kind of highlighting just to draw your eyes to it. It's a lot of uh impact. And then, you know, we have things that are like the scale of what they're working on, right? Scale. Scale. I think that to me really helps demonstrate the types of things that they have experience doing. And when we think about this compared to some software engineering resumes, you know, sometimes on software engineering resumes, we'll see like built or worked on a mobile application and you know, use this framework and it's like that's great, but like I don't really understand the scale of what you were doing. Um, I don't understand sort of the life cycle of the product. So, it's difficult to gauge someone's actual experience level in what they were doing. But I think on this resume for this program manager, they have done a really good job of that. In terms of advice, I think like honestly this feels like a really solid resume and like as an engineering manager, if I had my manager come to me or my skip level and they were or even at Microsoft, we have engineering kind of split from the product group. So if the product side said, "Hey, we're thinking of hiring, you know, someone like this. Uh do you want to interview them or do you want to go through some of the resumes?" If they did that for me and I saw this, I would be impressed by this. I think there's a lot of stuff that I really like on here. Yeah. I don't know. I think maybe uh my recommendation to them would be that depending on where they're applying, they they might and again this is like I'm I'm nitpicking here. Maybe they want to take some of the things that they have and tailor the experience. So what I mean is like when I read through this, there is a lot of breadth which is awesome. Right. And given that there's a lot of breath, I can make this assumption or maybe I can't. I'm going to that they have a lot there's probably even more experience. It's not called out here. I'm just going to pick on something, right? Let's see this line here. Partner with um for for security legal stakeholders. I think I've seen legal on here a couple of times, but let's pretend they wanted to work with security or legal or like a particular domain. What I would recommend they do is like they take this work experience and then they go through it again and then they tailor it for that. So for example, if they wanted to do program management work specifically at a place where the program management role is facilitating something with legal, I would go through this resume and I would say hey look like let me draw more attention to this. Right? Are there other things on here uh mitigated potential FIN refines? Right? So like compliance violations, is there something legal here we can talk about? I would try to do that. Uh alternatively, like I picked on that one that one line cuz it said security as well. If they wanted to go get a job as a program manager interfacing more with security, I would go back through all of this again and then try to see if I can tailor that experience to call out more security stuff because I think when you have so much experience like this, they're probably trying to trim out some stuff just to be able to, you know, call out the most impactful things, but because there is so much experience, you might be able to do some tailoring for some specific jobs. So, I think that's what I would call out on here. But honestly, I think they have a an awesome job calling out the scale and the impact that they've had as a program manager. So overall, I think totally awesome work. A friendly reminder to you that if you'd like the opportunity for your resume to be reviewed, you can submit it to résumés at devleader.ca. Thank you so much for watching and I will see you in the next one.