STOP Being Randomized By Competing Or Uncertain Priorities!

as software Engineers how do you prioritize the different work items that you have to focus on this is a question that I had from an employee in a 101 and they were looking for some different perspective on different ways that they can try to balance the task that they have to do it's a common thing that many software Engineers have to do if you're working on more than one thing or you're aware of more than one thing coming up that you have to focus on so in this video I'm going to share with you some of my perspectives as a principle software engineering manager at Microsoft and that will include both my perspective as a software engineer because I was doing that for many years as well as as a manager now before I jump into some of those details just a quick reminder to subscribe to my free Weekly Newsletter if you haven't already you can find a link to that in the pin comment below there's software engineering and net topics that go out every week totally for free no strings attached all right so when you first think about this question about how to balance different priorities many of you are probably jumping to the idea that there are systems for this there's different processes we have things like scrum and can ban and we have different systems like jira or Azure devops that allow us to track and see the work items that we have to focus on but I want to back up from this for a second because I don't want to focus on tools and processes I want to focus on the philosophy of this and that's because I think when you focus on the philosophy about what's important and how to prioritize the tools and the processes you put in place you can Implement those as you need and they're going to look different from Team to team company to company and they might have a better fit for personto person so the engineering manager in me wants to ensure that everyone on my team is a able to have autonomy when it comes to prioritization and that doesn't mean that everyone gets to necessarily decide the highest priority thing but what I want to ensure that they have the ability to do is for the different streams of work that they might be responsible for because there's often several projects ongoing at the same time of different sizes different priorities I want to ensure that they know with their own work what is the top priority to focus on they're aware of the different deadlines the different priorities the amount of work going into each each where they're blocked where they're not who they're holding up and who they're not I don't want to be in a position where I have to micromanage everything they're doing and I'm sure that they don't want that either so within the work streams they have I do want to ensure that they have autonomy that's a philosophy that I have and to me part of my belief is that if someone doesn't feel like they're able to make a good decision about the priorities for the work they have then I have some work to do with clarification ultimately as a software engineering manager I need to make sure that my team has a cohesive of Vi about the different priorities that are ongoing and then specifically for the streams of work they have what's a priority within that and it's not a one-way Communication channel I need to ensure that they can give me feedback as well because as things are changing in the work they're doing perhaps the priority of what they're doing is also going to change as well so this does require a feedback loop and we can use things like standup meetings or different sync meetings depending on how your team structure works whether or not that's every morning or once a week week or what have you but if you have some type of feedback loop that's going to help ensure that when things like the priority shifting and people aren't really sure that you have an opportunity for me as an engineering manager to hear about that and for you as a software engineer to be able to voice that you have different concerns about what's coming up or how the state of things are changing as software Engineers if we're willing to get behind that philosophy of having some amount of autonomy again that's not to say that you pick the priorities it's that you understand them and get to pick the different tasks based on those priorities that you have what are the different things that we can look for to make sure that we understand those priorities or if they're shifting and we have different feedback that we need to offer about the work we're doing well one thing that I shared with this employee is that if you have different streams of work and you're not clear about the deadline for them this is a really good opportunity to try and get that Clarity and I've certainly experienced this as a manager delegating tasso to different team members of different levels what I found and this is just anecdotal I don't have some you know huge set of data that proves this is a perfect generalization or something like that but I find that more Junior software Engineers actually really benefit from having more structure and more concrete deadlines so having multiple different Milestones that they can work towards that are smaller is very helpful especially for more Junior software engineers and that's not to say that it couldn't be more beneficial for more senior level software Engineers but I do find that if there's a rougher time frame or you know few Milestones that are further out the more senior software Engineers are able to work through this a little bit better so that's just a piece of advice for you that if you're not really sure the due date or the different milestones for the work that you have and maybe you know for two of the three things you're working on but you're not sure for the third get that Clarity because if you understand the urgency of those different things the priority and the impact but you're not really sure when it's actually do that can be a big deciding factor for how you want to go spend your time the second tip that's probably really obvious is that if you've been assigned work and you're just not sure of the priority in the first place you should be asking about that and as a software engineering manager I would be happy to have a conversation with different people on the team to try and clarify that but why am I bringing up this one because it seems so obvious right if you're not sure just ask about the priority well that's because at least in the organization I'm working in there's a lot of randomization that can come up Microsoft is a huge company and even the space that we're in it's not all of Microsoft it's still a very large organization and that means that we'll have tons of different teams that reach out to us and it's not always directly through me they'll reach out to people on the team and they certainly have pressing issues that they need help with but how is every individual on the team supposed to understand as individuals what the priority is of all of these randomized actions that are coming in and again from my experience as a software engineering manager I've seen that the more Junior folks struggle with this a lot and that's not their fault they have less experience in the domain they're not sure because should they be doing the stuff that I tell them to do that they've been working with their other team members on or should they just start doing the stuff that someone from another team happen to contact them for that seems really important other software Engineers or other product managers can be really good at selling the priority of things but if we're not looking at it holistically it's really challenging for those individuals and I don't blame them to be able to prioritize effectively the more senior software Engineers on the other hand generally have seen patterns like this come up before and they have a roughly a better idea for how they might try to weigh out the pros and cons of prioritizing things in a certain order but there's going to be cases where they just don't know and that's okay that's why I'm bringing up this point of if you don't know instead of just assuming that something sounds urgent because someone's reached out to you it's a great opportunity to pause and say hey team or hey manager how however you want to approach it like I'm am curious like is this truly urgent and we can have a conversation about it I do need to generalize this a little bit right because I don't know the makeup of your team I don't know if you have a product owner an engineering manager and a you know a project manager and a product manager and all the engineers like I just don't know how you're situated and who's um sort of signing off on making prioritization decisions in my current organization my current team generally it's going to be the engineering manager doing that but even in my last role we worked really closely with the product owner who was a product manager the titles and things like that can look different at different places but in those particular situations even myself as the engineering manager I might want to turn to the product owner and say look like here's my thoughts around the engineering effort here but I don't know what you think might be more valuable for the customer let's say so I would want to run that past the product owner and ensure that we could have a conversation and level set with the engineers about priorities so it's never an issue to ask for clarification about priorities and in fact I think it's extremely helpful if you're not sure to ask early and that's going to wrap up some quick thoughts about how you can think through some of your prioritization the first part I mentioned was that as an engineering manager I like to try and ensure as much autonomy on the team as possible so I need to work to help level set expectations around priority as much as I can and because that's not a perfect solution I need to ensure that there's a feedback loop with the engine working on different things and that's going to mean that as software Engineers some things that you might want to focus on are understanding different milestones and due dates for things as well as asking for clarity about the priority if it's not totally clear I realize that for some of you that might seem very obvious but I think that this is at least a good reminder that if you're in situations and you're not totally sure there's no harm in asking it's not a stupid question to say hey look I have these couple of things and I'm not sure the different priority between them asking for clarity can help avoid a lot of different friction that could follow later if other people don't agree with the priority that you picked and because this is always a really interesting topic when it comes to prioritization if you want to see my thoughts about tech de and how to schedule that you can check out this video next thanks and we'll see you next time