Revisiting: You don't have a PRIORITY problem, rather a CLARITY one
This is an updated and slightly complemented version of a previous post from August 2023.
"I totally understand and agree this is needed, but how does that stack up in priority against [the big strategic business priority going on] for the upcoming quarterly planning"?
Those weren't exactly the words I recently heard in a meeting, but that was the meaning. And most people will find it a very valid and honest question. It would be, if the context was one of comparing two business priority demands, a clear-cut case of conflicting priorities. But it wasn't the case; the new request was related to setting expectations around engineering excellence stuff, so more on the process improvement side of things.
That's when we enter the realm of the largely intangible. And more importantly, it's not even a fair question to stakeholders because we are not comparing "apples to apples" at all.
I found myself reflecting on all of that, and eventually it hit me! It is a question with an impossible answer as long as we frame it as a priority matter in the typical sense of what stacks up over what. This isn't a matter of priority in that sense, yet it is somewhat related to priority in a broader sense (which in context might mean selection, sequence, schedule, or class of service).
But perhaps it is better not to take a priority frame in the end, and look at it from a different angle. I actually wrote about it before in the post: Is it a priority issue? Or more like lack of transparency?. However here I would like to suggest going deeper on it and calling it a matter of CLARITY.
Allow me to walk you through what I mean…
It is a matter of CLARITY because of the risk, as John Cutler points out in his tweet below.
And I honestly don't believe teams out there aren't aware of it. That's not typically where the problem is; rather, how can they ensure not to be pushed around to keep adding and doing more and more new requests? How to go about it without risking becoming largely an emotional discussion.
That brings me to my main observation…
It's a matter of CLARITY because clarity means transparency and understanding. So it is not enough to be transparent that you need to take care of more stuff than just accepting new demands and adding new capabilities. It has to be accompanied by an understanding of the underlying "rules of the game", so to speak.
But the "rules of the game" can only be properly understood once we also understand the art of managing and developing products as gardening:
It's not only about working directly in the plants, but also taking care of the underlying ecosystem around it (so that they keep growing sustainably).
Thus, the real question, the problem we should try to solve, is how to build that understanding, how to make the "rules of the game" clearer. My personal suggested approach for that would be built upon a few enabling concepts:
Make rules (or policies, if you prefer) explicit.
Limit WIP (at all relevant levels), already defining as well as at the level of the different nature of work you need to take care of (e.g., new demands, improve existing functionalities, process improvements)— that is, by the way, the first rule to be made explicit.
Agree within the team on useful patterns to dynamically deal with the practical allocation of people (e.g., anyone can take up some process improvement item at any moment, but only as long as additional help is not needed to make progress on the more urgent things like new demands).
All of that together, more or less, means to use CLASS OF SERVICE as a basic overarching concept. Here is how that could look more visually:
And I know, I know… That will somewhat sound idealistic to some, and it is definitely much easier said than done (and yes, I am done with the clichés for now). But it is far from impossible; there are people out there using such patterns, and it is absolutely worthwhile. The results in the long run should be even more appreciated by stakeholders, although at first they might have an issue with the additional constraints on their demands. A small testimony of someone I have helped (with a single live conversation, triggered by reading some of my texts, and followed by some back and forth via chat) illustrates the tangible gains that can come out of it:
The outcome was an improvement of 40% in lead time and that has impacted our capacity to acquire new customers and deliver even greater results.
Now, there's one more thing though… What I like to call the matter of leverage. This means that to simply apply the patterns described here mostly touches upon improving flow, which is an enabler. But things can get even better if you also add clarity also from the perspective of the overarching intent of what we are trying to achieve, which is to be strategic. Just like Stephen Bungay explains with a telling quote in his great book, The Art of Action:
“Business engage in a vast range of activities. The art of strategic thinking is to identify which of them is the decisive differentiator, the determinant of competitive advantage. It involves mastering and sorting through a vast range of activities and simplifying them accurately down to the essentials which make the difference. The true strategist is a simplifier of complexity.”
By Rodrigo 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.