As an engineering manager, more often than not, you will encounter conflicting priorities. This is especially true if you’re managing a team that’s doing new development and maintaining existing code.
Let’s say that your team is developing new software with a hard deadline. But the team members you have working on it were responsible for creating a previous system that’s now in production and needs support - suddenly, a critical bug comes up in that system. This is what ruthless prioritization comes into play. You’re going to have to say no to something and balance a few risks.
You can put a more junior person (or someone not familiar with the system) on the critical bug in the production system. You can pull an experienced person from the new development effort into the analysis of the critical bug to get a feel for what the problem is, what a possible solution(s) is, and how long it would take them to implement, test and release it.
If it’s half a day of work for the experienced person, can you spare the experienced dev? Is the context switch too jarring? How many times have you done this recently? Don’t forget that the fix needs to be tested as well as deployed - those are critical pieces that you need to add to the risk equation. Who can do them? Are they trained up on the processes?
If the work is longer than half a day, can you have the experienced dev explain the fix to a new person and expect the fix to get done correctly? It’ll take longer, but now you’re still moving forward on multiple fronts - always a good thing if you can do it.
Having an experienced developer work with the less experienced person has multiple benefits. It gives the experienced team member the opportunity to mentor another team member. It gives the newbie a chance to learn how the experienced person approaches problems so they can learn the craft of software engineering; and it gives them experience in a new part of the system. By slowing down slightly in this way, you’re increasing your velocity in the future because now you have multiple people that can work in that part of the system - you’ve eliminated a single point of failure.
For green field development, you’re also going to get conflicting priorities. Companies and product managers always want more features, delivered quickly and under budget. Being able to explain tradeoffs and the impact of priority changes to stakeholders, while difficult sometimes, will pay off in better trust with stakeholders, trust in you for your team members and consistent delivery of value.
An important aspect of ruthless prioritization is stakeholder management. If you say no to something or deprioritize something, you need to communicate that and be able to explain it clearly. You need to understand the tradeoffs and, if possible, be able to quantify them. Doing this will not only help reach multiple goals, but it will give your stakeholders confidence that you know what you’re doing and will build trust.
There are going to be times when it’s going to feel like you just can’t prioritize - ruthlessly or otherwise. But you must try - for the sake of your team, the project and your stakeholders. Whether or not you think true multitasking is a myth or is possible, for teams it’s not sustainable. The constant context switches will wear down your team, frustrate your best people and, at worst, lead to burn out.