Less can be more

I was listening to the podcast series Cautionary Tales and their episode Do nothing, Then Do Less. By all means listen to the whole thing but I’d like to highlight the crossover with The Happiness Lab starting 12 minutes 30 in.

Bias for adding

People are apparently biased towards adding things in order to solve problems. The podcast mentions several examples from the book Subtract – Untapped Science of Less. One has people improving an itinerary for Washington DC visiting many of the sights, spending 20 minutes at each. What normally happens is they re-arrange the trip reducing travel time and making things more efficient. What doesn’t normally happen is someone cancelling half or even more of the visits and letting the visitors really appreciate what’s left. That’s one example in the episode there are several more. Are people biased towards adding things? I haven’t read the book myself for more details but some of it rings true. I can see how “improving an itinerary” might become “improving this itinerary” in someone’s head.

Opportunity cost

Later on they look at things from an economic viewpoint and opportunity costs. Everything you do has costs and benefits. Not just money but time, energy, social and more. If you go out every night in the week you might have lots of fun but no spare time and end up tired. Tomorrow should you go to the new movie at the cinema or the local pub with a few friends? Maybe you’d be better off spending a quiet night at home. You can’t do all the things. You have to pick and choose. Not doing something, indeed not doing “anything” for an evening is still a choice. They just have different costs.

Software design

In software, once we come up with a plan, a set of features to have, that is often it, the MVP. You work on the features one by one and try to get them done for the deadline. Maybe you don’t get all the features done in time and, retroactively, remove them from the plan. Pausing in the middle of a project to say, “Did we really want this?”, isn’t the norm. I’ve worked on features that took way longer than expected and managed far less than was hoped. An agile approach is meant to be good for managing this sort of thing. However the project goals still need to be flexible to take advantage of this.

The podcast suggests a mechanism for addressing this. Deliberately ask the question, “If we were forced to take something out what would it be?”. It can enable people to engage with the idea of doing less. If you free up the conversation to include this maybe it will suddenly become apparent how much easier things would be with just this one aspect removed.





Leave a Reply

Your email address will not be published. Required fields are marked *