Have you ever improved some aspect of your life, only to wonder afterwards why you hadn’t done it earlier?
What was stopping you?
It might have been our natural tendency towards the easy and familiar, the comfort zone.
In physics inertia is defined as the following:
Inertia is the resistance of any physical object to any change in its velocity.
Like a physical object, we tend to slide into a certain rhythm and a way of doing things. We resist change because it requires effort.
My goal is not to judge but to make the case that this inertia can be managed. Even better, with the right approach, it can be used to our benefit.
Diverse industries have independently developed methods that give their users an advantage over the competition. What these methods have in common is that they temporarily pause inertia's effects over us. This way, they put the rational part of ourselves back in control, opening the gates to meaningful improvements.
To pause the effects of inertia, I believe, the first step is to put our default and easy path into context. To realize that it's just one of many options.
Usually in software and web development, there are many ways to solve to the same problem. Once a decision is made, however, it can take substantial effort to revise it. That is why the pull of inertia is especially strong in technical development. Developers therefore, have had to quickly find effective methods to deal with strong inertia.
One such a method is a code rewrite. As David Heinemeier Hansson explains, code rewrites were once seen as expensive mistakes. A code rewrite means to intentionally rebuild a software project from scratch, starting from zero. Of course, this takes considerable time and resources. Why then, does Basecamp completely rewrite their main app every couple of years?
One reason is that when you start fresh, you get to implement new solutions. These solutions might not even have existed when the original project was started. This benefit is particularly significant in fast-improving areas, like technology. That alone can make an expensive code rewrite worth it.
More importantly, starting again means that you get to draw from all the experience you have previously accumulated. The bigger the difference in experience is, the more significant this effect is. For example, if you had been following the same morning routine for the past 10 years, you likely have gained an understanding of what parts are most useful. If you were to plan a new morning routine, you could put that experience to use by designing a routine that only incorporates the parts that help you most.
Similarly, the zero-based budgeting method, in accounting, opens the door to new solutions and reaps the rewards of experience. The standard way of budgeting is to take the last budget and to make some adjustments. For instance, you might decide that your business should spend less money on ads next year, so you would reduce the ad budget by X%.
In zero-based budgeting, you start from zero and then justifying every expense individually. That way “by how much should we reduce our ad spend?” becomes “how much is the right amount to spend on ads?”. This subtle difference results in better decisions and, in this case, the company's resources being effectively distributed.
In both code rewrites and zero-based budgeting a restart encourages exploring all the possible options. These methods work because they encourage a bird’s-eye view of the situation. With them, it becomes apparent that the familiar and easy are just one option among many.
To pause inertia, however, it's not enough to explore and recognize new options. Being aware of a better option doesn’t make us automatically take it. Not by a long shot. I believe that it also takes getting to an effort tipping point.
By effort tipping point I mean the point at which a similar level of effort is required to both keep going or to take a new approach. Thinking: "If I'm doing X, I might as well do Y" is an indication that you have reached such an effort tipping point.
In everyday life such tipping points are rare. Once we find a path that works we tend to stick to it. Sometimes we even fail to recognize when such a path becomes detrimental or even unhealthy. To prevent that and to get to an effort tipping point, deliberate effort is required.
Marie Kondo’s cleaning practice strikes me as the perfect example of such an effort. The method consists, among other things, of gathering all the items of one category, for example books, on one spot on the floor. Then, and only then, deciding which items to keep and which to discard.
The key is to really put all the items on the floor, even if it seems unnecessary. The reason being, that the moment you do that, you reach that rare effort tipping point. Because then, if you were to keep a book, you would have to put it back on the shelf. It would take approximately as much effort as discarding it.
At such an effort tipping point, there is no inertia because there is no easiest path. In this rare inertia-vacuum the rational self gets to make the decision.
I have argued that escaping the pull of inertia takes two steps. First, it’s helpful to explore and consider all available options. One generally effective way of doing that is (re-)starting from zero.
The second step is to deliberately use a method designed to reach an effort tipping point, like Marie Kondo's cleaning practice. Once we reach such effort tipping point, we can make unusually clear decisions and improve what needs improving. With no inertia the best possible path forward can be taken.