Answering the Question of Engineering Prioritization
Published on Jan 2, 2022
12 min read
I recently gave an interview to https://www.tryexponent.com/ on how to respond as an engineering manager to the question of prioritization as part of their engineering manager interview prep course, which you can learn more about here.
The video discusses how to make various tradeoffs in a mock interview format. “Let’s say your engineering team has to build two features, but there’s only bandwidth to build one. What do you do as the engineering manager?”
Youtube: https://youtu.be/CJVpg4enHPA
Let me know if you have other thoughts or approaches that I missed in the comments.
Transcript
[00:00:00] Kevin: Let’s say your engineering team has to build two features, but there’s only bandwidth to build one of them. What do you do as the engineering manager?
Hey, everyone. Welcome back to another exponent engineering manager mock interview. My name is Kevin and on today’s show, we have Vidal we’re going to be doing a behavioral or leadership type question today. And before we get into that, Vidal do you mind just telling the audience a little bit about what you do and what.
[00:00:28] Vidal: Sure. My name is Vidal Graupera. I’m an engineering manager currently at LinkedIn and I lead a couple of teams there. I’m really passionate about engineering, leadership, and management. I also have a website and podcast where I post about it.
[00:00:43] Kevin: Great. Thanks for coming on today’s show. So we’re going to be doing leadership or behavioral type question today, and this is what I like to ask.
Let’s say your engineering team has to build two features, but there’s only bandwidth to build one. What do you do as the engineering manager?
[00:01:00] Vidal: Okay. Part of it depends on the company. So let’s say a couple of different companies I’ve worked at, for example when I worked at Walmart, it was a very data-driven company.
And so there, I led an engineering team that worked on a mobile website and I would get requests all the time for features. And so in this case, say we had two features, only had the bandwidth to build one. Okay. We had north star which was to increase the conversion rate of the website. That was the most important thing.
It came from senior management plus everyone on the team agreed that this would be the thing that’d be most impactful. So when product managers would come with feature requests it would always ask them, okay, how much do you think this is going to move the conversion rate, right? Do you have a theory for how much it will improve it or how it will improve it?
If we had any kind of data to show that’d be even better. And then the team would do I, so that’s the data they would give us. And then the team as a good estimate, the effort rice engineering team would estimate the effort of the feature. And we would look at the impact to effort ratio, right?
How much it’s going to move the conversion rate based on the effort. So in this case, we had two features. If they were equal effort, we’d look at which one would improve the conversion rate more, or that we believed would improve it more. Otherwise, we would just, do this impact effort calculation in that case.
[00:02:26] Kevin: Sounds like you would look at the company goal and then you would also look at some matrix consisting of impact and effort.
[00:02:33] Vidal: Yeah. How does this feature move? Like the big goal we have in this case, and that team was to improve the conversion rate. So that was very very clear. At another company I worked on, we had a list of prioritized programs.
Okay. So if two different features came in we would see which program they mapped to. And the higher priority program would get preference unless there was some extenuating circumstance that there wouldn’t be. I’ll just say two more things there, which I think are helpful is one, it helps that the product managers that are coming to you or whoever’s asking for the.
Kind of understands that process, right? They understand, Hey, this is what we’re this is how we’re thinking about it. We’re trying to move this metric. Or we’re looking at this list of prioritized programs and this is what we’re going to do so that they buy into it. But we also give them an escape valve, right?
We say, okay if you don’t like the result, no offense, it’s fine. Here’s how you can escalate. You can escalate. To these people. And if they agree with you, maybe we’re wrong and then we’ll do the other feature. So as long as there’s a clear escalation path and the process is clear, It’s fine.
And this happens all the time. This is like an engineering manager job a lot. When you’re doing planning, whether you do quarterly planning, yearly planning, any kind of planning, what does that escalation process look like? So do you give them like the engineering directors or do you like, who do you link them up with?
So like at LinkedIn, we have a very nice process for this. We have this RAPID process, which you may have read about. So there’s discussions, between say me and the other engineering manager, then, you can involve their manager, try to find like a common point, where there’s a decision maker.
Okay. Maybe we both fall into the same VP, for example. So then the VP might be the decision maker, but you should be some negotiated. We’ll write up a document, which lists the pros and cons of all the approaches and what the recommendations are. So it’ll be like spelled out, a little bit. I don’t want to say it’s like a legal brief, the arguments will be laid out in writing.
And then that will be sent up the chain and presentations will be made and decisions will be made.
[00:04:55] Kevin: I like that. Yeah. I think a written culture really helps people get their thoughts out and helps people be more comprehensive in thinking about decisions. So that sounds good for choosing one of the two that you have to build.
Let’s imagine that the one that you choose is a progress bar, for example, in the UI. And let’s imagine that there are some edge cases in the bugs. So the teams building this progress bar, and sometimes the progress bar goes past a hundred percent. Sometimes it goes to a negative percentage when it’s not supposed to.
And the team is not going to meet the deadline. What would you do here?
[00:05:27] Vidal: Okay that’s that these things happen also. So I would look at first of all how important is it to meet the deadline? Can we extend the deadline? What would it take to fix this bug? And is it acceptable to extend the deadline, to deliver the bug?
It could be, I don’t know what product this is going into, but say we, it’s not a good customer experience, right? So I’m always thinking about the customer a lot because I manage front-end engineering teams and I’ve managed mobile engineering teams where things I’d like stuff that customers can touch and it doesn’t look good.
If the progress bar goes, so that’d be one thing. Okay. How much what’s it gonna take to fix it? It’s some amount of time. Usually can’t get an extension, but I’d want to ask anyway. Is that a possibility what’s the impact of this being late?. Okay. Like maybe it’s no big deal if it’s late an extra day or two, but maybe it’s a really big deal.
Maybe this is holding up some other, it’s not usually just the progress bar that’s going out. It’s going out. I would assume as part of a larger project. So now if that’s going to hold up a larger deliverable, which is going to have impacts, then we probably can’t hold it up just for the progress bar.
So then we’re going to have to look at what is the impact if the progress bar goes negative or positive? Okay. It looks bad, but is any user data going to be lost? That’d be the first thing. If user data is going to be lost, there’s gonna be some financial impact or regulatory violation.
There’s some really bad thing like that, then we might have. So say, wait, we really have to stop this because you can’t lose user data. We can’t lose financial information legally protected stuff, but a progress bar doesn’t seem likely that it would have those kinds of serious negative impacts.
[00:07:05] Kevin: Okay. So that, that makes sense for it in the event that the progress bar cannot be moved. So let’s maybe talk about what could you do as the engineering manager. If you learn that you can move this.
[00:07:15] Vidal: If we can move the deadline we might fix the bug, right? I think you’re just using that as an example, right?
A progress bar is like a very tiny thing, but if we could move the deadline, there’s no real impact to moving it. There’s also the car, here’s the other thing too. Maybe wouldn’t even move the deadline. It’s not that big a deal. I really don’t understand what is the impact again, I really hate to send stuff out that doesn’t look good, but Software does ship with bugs, right?
Every piece of software out there has known bugs that it goes out with. So maybe if the impact is not that bad and there’s lots of other goodness, cause the other is, if we delay it, then all the other goodness, which is going out this feature will also be delayed, which might have far more negative impact to delay.
So you could just put it in the release notes. What does it say to your team though? If you’re allowing them to ship software with these known bugs. Look, I want to keep a high bar for everything, but the reality is software does ship with bugs, right? Video games, ship with bugs, all kinds of things have, they’re not perfect.
Sometimes you don’t know what the bugs are. So this is like a known bug. I don’t like to I’d like it to be at a high level of craftsman. But these are things that I’ve been trading off in my mind, how many people are going to see this. Okay. So you say the practitioner might go negative or over a hundred percent.
How many people, how likely is it that a customer is going to see this? If it’s like one in a million customers in an. Edge case then it’s not that important. If you’re saying every customer is going to see this bad experience, then I’m much more concerned. So I guess I wanna understand how many people are going to see this.
If it’s a very tiny number, maybe that’s acceptable because to delay, it would say 1% of people are going to have this experience. But if I delay it a hundred percent of people, aren’t going to have the other experience, which is. Right by rolling the thing out. You’d have to make that kind of trade-off, I feel.
[00:09:07] Kevin: Okay. Are there any sort of frameworks that you use at work when it comes to moving deadlines or is it mainly just thinking about the impact and going from there?
[00:09:19] Vidal: That’s a good question. I don’t know if there’s a formal framework that I’m aware of. I’m sure there is. There’s a frameworks for almost everything.
I can’t think of one off the top of my head, I guess I would lean on, I would look at the impact to see how many customers are going to be impacted. What’s going to be the impact is just cosmetic. Is it a devastating, data loss thing. And you have to make a judgment call, whether it’s worth delaying the product launch for this defect versus rolling it out and fixing it later.
Knowing as you say, yeah, it does, it’s It’s not perfect. Nobody likes to send us up. It’s not perfect, but it can’t be a perfectionist.
[00:09:56] Kevin: Got it. You mentioned something interesting where you had mentioned how this could impact the release of a broader product. And I wanted to ask you, let’s say that you the delay of this progress bar impacts the downstream roadmap for a larger, like maybe some super group product.
How would you communicate that impacted the roadmap to your stakeholders?
[00:10:16] Vidal: Then you’d have to communicate So that then it’s not just a question of me deciding to delay the progress bar right now. It’s Hey, I have to move this release out because I have an issue that we believe we need to fix.
And so now we’re not gonna be able to start work on the next phase, which is going to impact downstream roadmaps. I’d have to talk with those other teams, let them know that, I’m thinking of delaying the release because I have this issue. And maybe they’re okay with it and be like, okay, that’s fine.
Or maybe they’re not okay with it. No, you can’t do that. So I’d have to, discuss, I just wouldn’t do it unilaterally. I’d have to talk with them and say, Hey, so what’s going on? What do you think? Assuming I think it’s really we really have to delay the release cause this progress bar.
It’s so bad.
[00:11:00] Kevin: Got it. Yeah. So let’s say you’ve done all this, the stakeholders, the people you work with, the leaders in the team are all happy with the direction, even though there is this delay now, how would you like what would you say to, to the team, just to keep team morale high and make them feel confident in their work?
[00:11:18] Vidal: Yeah, I would say that we’re going to fix the issue and we want to have a good customer experience. I wouldn’t try to blame anyone for it. Maybe, at our retrospective or if we had to do a post-mortem of this, you could do that, try to understand how this happened, so that we could prevent it happening in the future. No one, again, no one intentionally would code a progress bar like that. So I don’t assume any, bad intent on anyone’s part, it’s just oh, interesting progress bar doesn’t work, how’d that happened?
What can we learn in the future? Okay. Let’s fix it. Let’s move on. But this would be some of the thoughts that have,
[00:11:57] Kevin: yeah. That makes a lot of sense. Not blaming anyone making sure that you have a retro with think about what went well, what didn’t go well totally makes a lot of sense. We can stop the mock interview here.
Thanks for your time. And I’m thinking now that not now that you were put in the seat of the interviewee, do you have any advice for the viewers who might be going through their own engineering manager interviews?
[00:12:20] Vidal: Oh like general advice or interviewers
[00:12:24] Kevin: or people who are going into engineering manager interviews.
[00:12:27] Vidal: Yeah. They’re going into it. There’s a lot of resources now. I know that exponent has resource, right? Like you have launched a course. I’ve written a book on the topic. I think other people have written books on this topic. There’s I think you should prepare for it. You should prepare for it because it’s difficult. The engineering manager interview is difficult. There’s a lot of people. It’s difficult because companies, there’s a natural disinclination to hire an engineering manager. If there’s any doubt that something could be off because the impact of hiring. I’m making a bad hire for an engineering manager is not just that person.
It could impact an entire team. It could impact the entire org. So it’s not even just about you, like if if you’re an individual contributor and you get high. And you don’t work out. Okay. Then it’s like your localized, the impact that you had, but an engineering manager or leader, CEO, whatever has a much broader impact.
So I think you should really take the interview very seriously because people are going to be, the higher and higher position it is. I think the more rightly people are going to be asking very hard questions. You know about the person and being maybe a little more disinclined to give them the benefit of the doubt because the risk of a bad hire is a much greater.
[00:13:52] Kevin: Yeah, that makes sense. Cool. Thanks for your time. The doll and for the. For the viewers at home. Good luck with your upcoming engineering manager interviews. Thanks so much for watching. Don’t forget to hit the like and subscribe buttons below to let us know that this video is valuable for you. And of course, check out hundreds more videos, just like this at tryexponent.com. Thanks for watching and good luck on your upcoming interview.
