Episode 2: Just say no!
This episode delves into the dreaded to-do list. Featuring guests Susannah and Anna; experts within product management, who want to wave goodbye to backlogged work for good, and AJ, who explores the psychological ramifications of an unmanageable list of work undone. Maybe we could all see ourselves saying no to ever-growing workloads after this episode of Pi & Mash.
Product Owner Blog – Anna Miedzianowska’s personal blog
Basecamp (formerly 37 Signals)
Guests in order of appearance:
Anna Miedzianowska – Head of Product at Ocado Technology
Susannah Ellis – Product Owner
AJ King – Organisational Scientist
Written and hosted by Holly Godwin
Produced by Green Barge Audio with original music by Nic Sims
Episode 2 – What if we started saying no?
Hello and welcome to The show that takes a step inside the world of technology to shed light on the human stories behind the big ideas fueling this ever accelerating Information Age.
We’ve all scribbled down a to-do list at some point, whether it’s in a leather bound organiser, on our smartphones or the back of a crumpled receipt we find at the bottom of our bags. Most of us need to do this, simply in order to remember what it is we’re meant to be doing. But what happens when these lists start to get out of hand?
Imagine for a moment, that you never make these lists. In fact you burn whatever remains and start from scratch. Chaos undoubtedly ensues.
Last week I went and spoke to a few individuals who work within product management and advocate exactly that, but before we get into the whys and hows, let’s take a step back.
The specific to-do lists we are talking about here are product backlogs – the list of feature requests stakeholders ask software developers to build, in order to improve upon a product. It’s the role of the team’s Product Owner to decide upon what features, known as user stories, make it onto the backlog, and in what order. This is in effect, the ultimate to do list.
But what happens when our lists get too long and unmanageable, when the work added to the end of the list is never likely to get done, and why do we let it get to this point?
So the biggest backlog I’ve seen was three thousand, three and a half thousand items and it’s way too many…
My name is Anna Miedzianowska and I’m Head of Product at Ocado Technology
…I have no clue how it happened, but I guess it was growing over a long period of time. I guess maybe Product Owners were changing and were afraid to delete some stuff that wasn’t coming from their management. That’s not a great starting point if you’re afraid, if you don’t understand the items and you just keep adding to the backlog
So how does a backlog like that build up? I spoke to Anna and her colleague, Susannah to find out more.
I’m Susannah Ellis and I’m a product owner at Ocado Technology
It’s a bit of a safety blanket. You don’t want to let go of good ideas, so you think if I add them to the backlog then I won’t forget them and I can come back to them later in this mythical time in the future when I’ve got masses of time and infinite resources, and actually what happens in reality is if those were good ideas they’ll reappear later, and you don’t actually have to record every idea that’s ever had.
It’s not always just a case of holding onto good ideas in the backlog. Sometime teams can be holding onto bad ideas too, and not know it. Technology provides such a fast paced environment that what was a good idea 6 months ago, may not even be relevant today.
I think it is true that the requirements change over time, and certainly, having picked up a couple of legacy backlogs in my career, you look through and there are an awful lot of things on there that people can’t quite remember quite where they came from, or even things that are on the backlog that it actually turns out were fixed a number of years ago, or that are no longer a problem because you’ve built another solution to a problem over here. So, you end up with a kind of gnarly mess of things that no longer make sense and certainly aren’t a priority.
We’ve just explored two core factors that contribute to an overload in backlogged work, but we haven’t quite reached the root of the cause.
So, you work with your stakeholders on a daily basis and you do want to have a good relationship with them. So, you want to be nice so usually instead of saying no, you chose to say not yet, but I’ll add it to the backlog, which is working in the short term, but not really great in the long term.
We don’t like saying no.
But why? Where does this fear of turning down an impossible workload stem from?
I spoke to AJ King, organisational scientist and behavioural economist, to gain an insight into exactly what’s going on with the human psyche when we struggle to say no.
There’s two levels why we struggle to say no to tasks we don’t have time for which are at a cultural level and also an individual level. At the cultural level of things, most organisations have this sort of social norm that we say yes now and we will deal with the consequences of that later.
AJ works within the tech industry making sure no one loses sight of the human element behind the business model.
So, I’m an organisational scientist, so I have a background in psychology and kind of in the whys of what people do and how they do them. So I spend a lot of time chatting with people around the business and trying to work out ways that they can work better together as a team, more effectively across teams and all of that sort of organisational development space.
I asked AJ why businesses allowed this overload of work to happen, to the point where in some professions it’s almost universally accepted, and what effect this could have on individuals and team’s morale.
It’s probably conjecture on my part, but maybe the reason that we have this culture in businesses and it’s quite such an epidemic across businesses that you chat to, is that when we make a decision, we like to be able to justify that decision, and so back in the days when businesses ran on conveyor belts and productivity was easily measured in the number of units created in a given time, then it was easier to say no to additional work, because the time you’re currently using is clear, the time for the additional task was clear, and there was concrete justification that there was not time to do this. However, this isn’t the case for tasks in a technology company, which start their lives as relatively abstract constructs, which then require creativity to come to life. Quantifying that process from abstract to real life I guess takes time, and we don’t know how long that will take and so we can’t kind of quantify it in a way that feels justified enough up front.
I imagine most of us feel incredibly uncomfortable saying no to more work. Are we letting others down? Are we proving to be a monumental disappointment to everyone. Our insecurities often seem to win out here and we find ourselves drowning in an ever growing sea of jobs undone.
At an individual level we don’t like to say no to people because we just aren’t willing to face the social discomfort in the moment of saying no. And this is probably down to present bias, which is something we’re all afflicted with, and that’s that basically as people, we like good things now and we like to delay bad things. So we don’t say no to additional tasks because the awkwardness and the social discomfort of having to disappoint someone in the moment feels bad.
However, by avoiding this short and uncomfortable decision upfront, we end up with more work on our backlogs, with more tasks, and as a result, we end up with a longer lasting discomfort in the form of stress. Stress is really bad for obvious reasons, but it takes up valuable thinking capacity for us, and so by ending up stressed about tasks in a backlog that we’re never planning to do realistically, then it’s slowing down actually how much effort and focus we can put on the work that we should be doing in the moment.
It appears we are far more likely to chose self preservation and popularity now, than effective workflow and reliability in the future. But, maybe we shouldn’t. This can’t be the best way to accomplish our goals.
If you see your backlog constantly growing, you don’t have this feeling of achievement that you actually completed something, because as soon as you deliver something, there is more to do. And you deliver the next thing and then there’s double of that in the backlog, so that’s very demotivating.
And the psychological ramifications aren’t the only negative consequences of a big backlog. It comes with it’s own time cost:
The most annoying one is the backlog grooming session that has to happen from time to time. Everyone hates it, people are super bored in these meetings and most of the time it’s like “I don’t remember what this is about”.
Going through a long backlog one item at a time is labour intensive, and by the time you get to a particular user story, 6 months after it was requested, will your work still be as relevant?
As we mentioned earlier it may be something they no longer need, but also they might be quite surprised when you’ve done that work. And suddenly the value that you might have created for them and the feedback you might have got from them, you don’t get, because it’s not that important to them anymore.
It may be easier said than done, but maybe we should write off backlogged work completely. Afterall, what would happen if we cast aside the safety blanket, lived in the present and disbanded the backlog for good?
No backlog grooming session, focus on the only one most important thing. Always negotiating with stakeholders at the right time, the latest possible moment to decide what’s the most important thing. So, that would mean being more agile and more adapting to the reality, which is changing constantly.
Having no backlog also avoids context switching. Try thinking about all the things you need to do this week in quick succession. What shall you cook for dinner tonight? Where do you want to go on that holiday of a lifetime you’re planning this summer? Have you sent your mum her birthday card? Did you remember to leave time to see your friend in their debut show next week?
Could you actually come up with any of the answers to those questions? The most likely answer is no. Context switching can seriously limit our productivity. If you start working on one user story and then glance over at an ever growing backlog, there’s any number of distractions to focus on. And there you have it, you’re overwhelmed. Demolishing the backlog could allow us to be far more focussed, and yes human nature probably means you’ll always find distractions from time to time. But limiting them is surely a priority?
So we’ve now regained our focus by cutting the backlog. What’s the next step?
I think having a zero ticket backlog would also force you to have more conversations with stakeholders on a more regular basis.
The communication between you and your stakeholders (or equivalent) is the key to banishing the unrealistic workload. If we make the effort to be honest and transparent about our time and resources, we could save ourselves a lot of hassle. We can’t be afraid to be bold and upfront about our expectations and capabilities with the given time and manpower.
So that backlog of none or one means that you can have that conversation regularly and say ‘okay, so what’s your most important thing that you’d like me to do for you right now. Not 6 months ago, but today, what’s important to you?’
I asked Anna whether there were any negative side effects to demolishing the backlog.
There is probably one thing that could be perceived as negative – not everyone is already ready to have the conversation about the next thing, so we might end up with some slack in the system. So, it might be perceived as negative but maybe it’s not a bad thing, because if you have some slack in the system, why don’t you go and learn something? why don’t you reflect on something that you have done in the past? So, this is actually a good thing in the end.
Hypothetically this sounds like a great plan. But before you burn down your boards littered with user stories, and post-it notes (or, somewhat less dramatically, delete your virtual kanban boards), can it really be done?
The company called 37 Signals, they don’t really have a backlog. They say no to every single request and they wait for the request to come back, and they wait for the request to come back. If a request keeps coming back then this means that this is important. Otherwise you might end up with implementing millions of features in one single product, which is really bad practice.
Yes, we could all potentially ban the backlog for good. But I imagine going cold turkey would instill fear in most of us. So, maybe we should first work towards cutting our ever growing lists down.
I laboriously went through every single ticket, reading what was on it, trying to understand it, trying to understand whether it was still relevant. And to be honest, looking back, it was a massive waste of time. So, my new technique is a lot more radical. I would love to say that it is 100% hit the delete button, it’s not quite that radical, but as much as possible it’s a question of scrapping 95% of the backlog and working on the principle that if it’s really important, somebody is going to ask you for it again in the near future, so you really don’t need to keep very much at all.
So delete away. However, we also need to be aware that this may be a shock to the system for those we’re saying no to, for perhaps the first time.
So I think you need to start from building trust, so your stakeholders understand that you do want the best for the business and you’re just being pragmatic and realistic.
And how can we build that trust? With hard data and jargon free communications. Keep everything as simple as possible. Your stakeholders may not speak the same language as you, so make sure that your conversations aren’t wasted. Perhaps give each user story a layman’s description, so stakeholders are better placed to see how a feature may take more time than they intended. This will be the same for any industry. We are very used to communicating within our own circles with others who have a similar skillset. But, in order to ignite a cultural shift towards the word ‘no’, we first need clarity.
It’s obviously very hard to break out of this cultural cycle, but at the end of the day realistically we’re all trying to achieve the same thing: a stakeholder wants an outcome, we’re delivering and creating on a backlog, seeking exactly the same outcome. So, from my understanding of people and interactions, the best way to start the shift to more effective working is to make both sides of that coin aware of the needs and ways of working of the other side. We all spend a lot of time isolated within our groups, working to the best that we can be, because it’s easier to do it within these groups, we’re already better aligned, we have a commonality of language and we all come from the same perspective, but we fail to appreciate quite often what the effect of us fine tuning ourselves within the box, the effect that that has on everyone outside of our own box. So, having that conversation to address the wider system and how it all interacts with each other, is probably the right way to break this cycle of just saying yes to everything. Probably more important than focusing just on individual shifts in approach as that will be met by differences in individuals on both sides.
This extends past the relationship of stakeholder and developer, to every element of every business, both with internal and external dealings. We all know we have our own limits, as teams and as individuals, so it’s only fair to assume others do to. If we had more of an understanding of the ways in which other teams, departments and businesses functioned on a day to day basis, we’d be far better placed to have realistic expectations. Communicate, develop that understanding and set your to-do lists on fire, unless there’s anything really important…
So, I think that long backlog is an illusion. It’s a promise that you can’t really keep, because the stakeholders think that you, at some point, rather sooner than later, you’re going to deliver that, but you’re not, let’s face it. So short term, yes, add things to the backlog. Long term be pragmatic and don’t.
Just because you can’t moan about how much there is on your ever growing to do list at the water cooler each morning, doesn’t mean you’re working any less. In actual fact, disbanding the backlog for good could see a rise in productivity and communication between you and your stakeholders. This fear of saying no to work we can’t complete seems to stem from a fear of disappointing those around us. Will they think we’re lazy? Are others able to do more than us? Do you need to appear overworked to gain the respect of your peers. Possibly… but probably not. I would guess that as long as you are producing work of a high quality at a regular rate, no one could care less about your list of jobs still to do. So, why not try saying no today?
Thanks for tuning into this week’s Pi & Mash.You’ve been listening to me, Holly Godwin, and the team here at the buzzing hub of Ocado Technology. Produced and edited by Green Barge Audio with original music by Nic Sims. Subscribe to hear the rest of our series wherever you tend to find your podcasts.