I am fond of meaningful contradictions, and I’ll use this one to kick off my second stream of blogs posts, this one about leadership and management (the other being sustainability).
Prioritizing brutally is obvious but sometimes we confuse that with prioritizing strictly. When asked to prioritize, teams often look for a strict order which has the appeal of absolute clarity. As example, when working on a product, a strict prioritization of regulatory compliance first, followed by security and quality, then customer satisfaction issues, then new features seems to make sense. But it leads to a suboptimal outcome. Progress needs to be made on all four buckets and prioritization is not strict at the topmost bucket level. A “prevent loss of customer data security fix” might well take precedence over a “regulatory compliance to enable sales to a specific segment”, even though the compliance bucket is at the top. Again, this is obvious, right? But there is a third element — prioritize discretely. Otherwise, progress will be made on multiple fronts, but progress is not the same as completely meeting a bar or a scenario (95% compliant is still not compliant). It is better to be fully compliant in one market than to be almost compliant in three!
Prioritization is one of the most important things that a leader needs to do, but it is hard when you add the constraints: brutally, discretely, and not strictly. If you ask, most leaders will say they prioritize. Look objectively around your organization. Do you have things ‘we continue to do because we have started’ while there are things ‘we really should do’ that are not funded? Do you have multiple things in progress but do not reach a discrete point (meeting a bar or completing an end-to-end scenario) by some milestone? Do you have resources working on a lower priority item in a higher bucket that should be working on a higher priority item in a lower bucket? If the answer is ‘yes’ to any of the three, the chances are you might be prioritizing, but not brutally, not discretely or you might have gone about it strictly. This would be a good time to take a step back and ask, “how did we get here, and should I think about it differently?” In my own experience, the vast majority of teams struggle with this, primarily because of the sunk cost syndrome, personal attachment to projects and the unpleasantness of having to tell someone to redirect from what they are working on.
