Don't "bucket" work together when planning
Its human nature to categorise information to help organise and reduce cognitive load. So why is this bad for prioritisation?
Customers experience the entirety of what an organisation produces — that can be the products, services, marketing, customer service, sales — whatever interactions with the organisation that occur.
Customers don’t differentiate between which part of the organisation was responsible. To them, experiences were positive or negative or whatever combination that makes up their overall impression. This is evident whenever you collect customer experience feedback such as verbatims from NPS or other forms of survey - feedback comes back about everything from the rude salesperson to the UI bug.
So it makes sense that if customers experience the whole then we should be planning with the whole experience in mind. But in organisations, this seldom happens. Why is this?
Simplistically we can say this is due to siloes but more fundamentally it starts with a very human trait to organise information — I will this ‘bucketing’.
There are of course other things that influence siloes as well — in future posts I will cover the ripple-effect that cost-centre accounting practices have had on organisations and other such factors.
The problem with bucketing work
People like to organise and group things to simplify understanding. The most common technique is to bucket, that is, to treat a group of things which share a common trait as one.
When it comes to goals and our ability to understand and measure them we need to be very careful about what we group together.
Aggregate information can often mislead or reduce our understanding so we need to be really careful about what we group together and when.
An example of bucketing which creates less useful aggregate measurements is to group similar activities together or similar goals together.
Grouping similar activities has the effect of conflating multiple goals, which is less related to each other than the activities and can lead to needing to form measures of progress which need to be very general to encompass the messy, entwined goals.
This is one cause I have seen for teams feeling compelled to choose broad measures like ‘change in visits’ and then facing the issue its a measure that can be influenced by many different causes. Or worse still, having to fall back to measuring progress through completion of activities (tasks, projects etc.).
Another negative, possibly worse, side-effect of bucketing is that this is can create artificial dependencies and this can reduce our ability to maximise results and minimise delivery effort and timeline.
An example of bucketing creating artificial dependencies might be to group similar types of work together such ‘backend work’ or ‘security work’.
Later in planning — ‘we can’t prioritise this until the security stuff is done’ but in reality it was only a subset of specific security settings was the dependency. The result is a longer delay of the critical path for the desired outcome and additional cost for that delay is incurred.
Yet despite these significant shortcomings, because it is in human nature and instinctual to bucket information, this practice remains commonplace.
That its instinctual heightens the conviction that this the right thing to do. Dealing with the aforementioned side-effects is then assumed to be a necessary evil rather than what it actually is; avoidable.
A classic example of bucketing, which may seem like the right time to bucket at first glance, is the grouping of two types of work; ‘new value’ and ‘business as usual’ (BAU).
It’s true there are times when we do need to know what is attempting to add value and what is attempting to maintain existing value. But this is still a form of bucketing which can form a barrier to understanding what is creating value for our customers and how we might be able to improve the value we are delivering.
It is not uncommon to see businesses struggling to justify the investment to support existing value — sometimes face-palm level repeated choices not to correct something that is broken, wasteful and hurts customers.
The division into new and BAU can create a false sense that improving value is achieved through adding new things — it can be but in competitive spaces, it can equally be about providing a better experience than your competition. And its done right at the very start which is why within the organisation we can be blind to the consequences!
This bucketing can occur again because of an activity-centric mindset. ‘Well the BAU activities are mostly done by these operational teams’ — the rationale, then, is to manage these separately.
Yet customers experience even in a single moment can quickly span many parts of your organisation — for instance, an inquiry into customer service about your product sets may be crossing the work by customer service, sales, marketing, strategy, product, tech…
Such siloing of planning and cooperation of parts of an organisation can lead to very strange customer experiences because a kludgy experience without the context of how it may be affecting the overall customer experience may seem like something that can be lived with.
In a former workplace, one glaring example of how our perspective changed when we moved from siloed planning to holistic planning related to password resets.
There was almost 75,000 manual password resets being conducted each year. This had been this way for many years. It was Asia and the bulk of the staff responsible for this were in lower-cost locations so at any point in time was not seen as the highest priority to automate.
However, once we mapped out our e-commerce goals, where friction was in the process and what dependencies limited our ability to scale selling online to our hundreds of thousands of customers it became very obvious that addressing such manual steps was essential both for the speed of converting a customer and for freeing up operational staff to do higher-value interventions.
A way to think about goals in the same frame that we used was as follows — we would include all work in the same view:
Goals which attempted to create new value,
Goals which attempted to sustain existing value,
Goals which attempt to improve our ability to improve or protect value.
Again, you have read these and I know you are tempted to go bucket up things under each of these. Resist. Instead, see that these are all aspects of maximising value provided.
The only benefit to classifying the work into these types maybe to eyeball whether there appears to be balance in the portfolio of work being engaged in — i.e. we know right now we are losing on the quality of experience — does it look like we are investing enough of our effort into improving this?
We focused on keeping each goal specific, discreet, measurable but also invested further effort into understanding how different goals related to each other.
Keeping things out of buckets, the most important things in view and the relationships between each well understood is a terrific formula for improving cooperation and reducing siloes.
We would create a map so we could see these in one place. The result of this awareness of how things fit together and what very specifically needed to change was of teams and departments championing for work which supported other areas which under the previous way of looking at things ‘was not their problem’.
This approach in our experience helped discussions around investment in addressing quality, investing in service design, reducing technical debt, investing in our delivery capability and whatever else in trade-offs against other value-creating activities such as building new products and features.
It was much simpler to view all of these elements in a system that supported the value for customers rather than bumping into the problem of being dismissed because of how it had been bucketed.
I will cover the approaches we used for identifying and communicating the relationships between goals in future posts. How does your organisation organise its goals?
Do you see bucketing occurring? Is the new value work discussed very separately from the Business As Usual work or is all of this work in view? Do you have examples of broken customer experience which were the result of any of the side-effects I mentioned?
One of the major data projects I worked on was building a "customer journey" asset to stitch together and sequence each interaction a customer had with the company: sales, billing, processing, call center, website.
Each department was huge (there were many millions of customers over decades), and so each was bucketed by function. There was no universal "customer id" and this made it incredibly hard to create that sequence of data. We relied on fuzzy matching and other algorithms to get our best possible results.
Beyond the data, for the employees of those divisions they didn't really have perspective of the entire customer experience. No idea that problems in the billing department transformed into calls to the service center (which transformed to operational expense on the company's bottom line).
At any rate, some mental model of bucketing is useful for all the reasons you mentioned. But it's up to the savvy mind to create buckets well fit for the end-game solution.
Love this bucketing metaphore. Thanks Daniel! Found this via the "estimation does not help us..." post.