Adding Value Through Removal — Why Creation and Building is Overvalued
Removing things is often just as complex as adding things. It is a way to add value which is often overlooked.
Creation receives the bulk of our attention. You launch a new website. You build a new feature for customers. You document a new process. These are the activities we associate with work. They are the types of activities we think of as core to our careers. They are at the center of promotions, raises, and press releases.
Creation is wonderful. Inspired creative effort created the iPhone, Stripe, and the Bar Raiser process at Amazon.
While we call these products and processes new, they're not only elements of creation. They're also the results of elegant removal. The iPhone has a user interface which was famous for its simplicity when it launched. Stripe is known to be one of the easiest payment platforms to use. The bar raiser process has been used for millions of hires, but the important elements could be described on one page.
Underestimated
Removal is an underestimated form of value creation. You can remove complexity to make something easier to use for customers. You can attribute much of the success of tools like Stripe and Instagram specifically to the removal of non-essential features. That removal allowed them to move more quickly, and also allowed customers to understand the tool quickly, adopt it, and happily share it with others.
You can remove code to improve software performance. When you are trying to improve the performance of complex software, the most drastic impact comes when large portions of code are removed from the critical path.
In large companies, process can take a significant portion of feature development time. Reducing process can be the biggest lever for an organization to move more quickly.
Undervalued
Unfortunately, the focus on creation can lead to removal being undervalued by peers or management. Camille Fournier wrote an article recently touching this topic. "Companies reward people who create new things. It is hard to identify and reward problems that are avoided." In the context of the article it was about build vs buy, but it applies equally to removal vs adding.
I once had an employee spend a few weeks looking at the latency of one of the core technologies which was used across Amazon. This technology was used on my team's website (Seller Central) along with the Amazon retail website. He was convinced that there was something taking up additional CPU on our machines. He sat there for days debugging and tracing lines of code which had not been touched by any employee for years. He eventually found a couple lines of code which saved the company millions. Keep in mind that saving millions is better than new revenue of tens of millions (low profit margins on revenue vs savings which goes directly to the bottom line).
If he'd personally invented a feature which made tens of millions, getting him credit would have been simple. Instead, it took a significant amount of effort to explain to people why removing a couple lines of code should get similar recognition and rewards as writing tens of thousands of new lines of code.