Still on prioritization: revisiting a plot twist on a sad tale…
This is a bit of a new experiment, where I not only revisit a previous post (from February 2023) but do that while connecting dots with a much more recent one (precisely the)...
I wrote this, a bit tongue-in-cheek, some time back on my LinkedIn profile:
If you have seen or experienced that, or you're just OK taking my word on it, you might ask yourself: fair enough, but what is the alternative? How exactly could the engineering teams behave differently? Such as perhaps that brings about a higher level of maturity in their delivery process.
Again, if you're OK taking my word on it, I am happy to share some thoughts… However, I can't get either the bonus or the onus for whether it will work or not in your context. But I do happen to know for a fact and from benchmarking that the patterns that I am about to describe are helpful and robust.
The first part is a pre-condition, which can be framed as both a matter of self-awareness (jargon for "you know your stuff") as well as credibility (jargon for "people are fine taking your word on stuff"):
You have a delivery system in place, which is stable enough, meaning you know empirically what it is capable of delivering in a given time frame, and that imposes limits to what is currently going on (i.e., WIP limit), and through that, you have shown explicitly your customers can trust the predictability of your services.
Without that pre-condition, I would be very skeptical of the success chances of any engineering team to push back when already having too much and getting pressured with more work pushed down and from different directions. It just is not going to happen that easily, that way.
Taking that for granted, what can come next? Well, I don't think I need to write much else, because that was precisely where I was coming from in some other previous posts:
The gist of it is really this:
You take a more nuanced and contextually (value = risk assessment) relevant perspective on what should be done next (priority), and that nudges and hopefully leads to meaningful conversations.
Then, next time that a new rushed demand comes from someone somewhere, you can hold up a kind of a 'mirror' against that demand with that sense of urgency, and do it in a way that doesn't come across as just pushing back for the sake of it – not defensive.
It could sound something like this:
Hey John Doe, I am glad you had this new idea and am happy to consider it further. You know that we already have a lot going on here, but we should always be open and ready to change gears if need be. Let's shape that up, let's use that little profile assessment thing I showed you some time back, and see how that looks like against other options we are considering or even what is currently going on. And take from there.
And let the chips fall where they may… In a non-speculative, highly factual, mature, and robust way to go about making decisions, managing risks, and stakeholders, and playing offense rather than reacting and getting defensive.
The actual conversation may sound a bit different, more or less formal depending on your context, and probably done in stages. But I think you get the spirit.
And in case you haven't connected the dots by yourself, what I was alluding to in that previous post was precisely what I better elaborated on last time here: a robust framework to make sense of priority with a multi-dimensional approach and with a risk profile lens. While there are other multi-dimensional prioritization approaches out there, the main advantage of the one explored last week is to enrich the conversation by visualizing all dimensions at the same time, as opposed to sort of hiding that complexity in a single final number spat out (like happens when you use other multi-dimensional frameworks like ICE, RICE, CARVER matrix, etc.).
ByRodrigo Sperb, feel free to connect, I'm happy to engage and interact. If I can be of further utility to you or your organization in getting better at working with product development, I am available for part-time advisory, consulting or contract-based engagements.