Random reflections on the throwaway mentality in our culture
- Our throwaway culture is due to planned obsolescence
- From physical goods to non-material processes?
- Systematically fixing everything that’s broken
- Information exempt from the throwaway mentality?
Our throwaway culture is due to planned obsolescence
Lately I’ve been thinking about our throwaway culture, and when to choose buying or getting a new version of something instead of repairing the broken one. I’m not really thinking about physical goods, but let’s start there.
Thanks to the “planned obsolescence” model that companies follow, where products are designed to last only a certain duration, we’ve grown accustomed to throwing things away when products break, even if it’s just a minor issue with an otherwise good product. Companies deliberately make repairing broken products harder than simply buying new ones. Gaia Vince explains that “this way of selling more products by designing products that deliberately fail, cannot be repaired, or have a set lifespan imposed in some other way is known as planned obsolescence” (The High Cost of our Throwaway Culture).
Think of your light bulbs. Light bulbs can last for years, but companies build them to burn out after a number of months so you have to replace them.
Or think of Macbook Pro laptops, where the memory and hard-drive are soldered in and can’t be replaced. As newer operating systems require more memory and rich multimedia requires more and more space, the products meet their inevitable end of life — by design.
From physical goods to non-material processes?
Although this throwaway mentality typically applies to our physical goods, how do we avoid not applying the same mentality to everything around us – our jobs, relationships, friends, lifestyles, studies, and more? Is there a danger of incorporating a throwaway mentality into the rest of our lives?
For example, if our job has some aspects that we consider “broken,” does our throwaway culture encourage us to throw the job away and get a new one? If we run into a rough patch in a relationship, do we decide to throw it away and start a new one? If a child is having trouble at school, do we decide to transfer the child to a new school system?
I was reflecting on job goals the other week (as part of a regular review), and I decided to list out every process, system, or other job-related aspect that I felt was broken and then set about trying to fix it. What’s broken? Well, “broken” might be too strong of a word here, but some processes that could be improved include documentation ownership for certain products, synchronization with other groups such as Marketing and Support, the susceptibility of our tools to git catastrophes or page outages, the tediousness of our localization process, and more.
In my 15 years of working in the corporate world, I’ve learned that every job has aspects that could be improved. That’s usually the reason the company hires me in the first place — to fix these aspects that are broken. And addressing them is why our jobs engage us. Yet all too often, we let broken processes and issues persist, which only results in increasing negativity and resentment among teams.
What if, instead of living with broken processes, or waiting to just get into a new team or new tool or project, we were to meticulously identify every process we felt was broken and then set about trying to fix them in a systematic way?
Some processes are easier to fix than others, for sure. For example, figuring out how to increase awareness of your team’s services in a large company is easier than figuring out how to get senior leaders to champion docs and increase headcount across tech writing groups. But even if the task seems to be insurmountable, we should still seek ways to fix it.
Systematically fixing everything that’s broken
Why do we live with broken processes? Most likely, it’s because fixing the process requires more energy than simply living with it. (I wrote about this previously in When the pain of ignorance exceeds the pain of learning.) I’m embarrassed to say that I can’t shift into the bottom 3 gears on my Trek bike — but I guess it’s fine because I rarely use those gears anyway. I mostly stay in the same gear all the way to work and back. So why fix it? I know that eventually I’ll just get a new bike anyway, replacing this one.
Perhaps if we determine that a process can’t be fixed, at that point we throw it away and get a new one, whatever that might look like for the situation. But distinguishing between repair and replace can’t be done easily without first attempting repair.
I know I’ve only scratched the surface here, but my intent isn’t to dig too deep. I recognize that distinguishing between when to repair versus when to replace is a tricky situation, and in many jobs, relationships, and other areas of life it really might be better to skip attempts at repair and go straight to replace.
Information exempt from the throwaway mentality?
Interestingly, our throwaway culture mentality doesn’t seem to apply to information. Most people at companies avoid deleting outdated wiki pages at all costs, thinking that some nugget of useful information might be lost in removing the content. We’d probably be much better off periodically deleting our documentation and starting over every several years. Otherwise, the gradual accretion of content (the newly added page, the new section, the new diagram, and so on) tends to break the coherence of the documentation as a whole.
If you’ve ever inherited documentation that’s been around your department for half a dozen years, with no clear author, you know what I’m talking about. In some of my documentation projects, there are many pages whose history is a mystery to me. Who authored it, when, which group needed it, which group owns it, who reviewed it, is the information current, etc? All that information has been lost, as this content was handed down from writer to writer, slightly modified or updated to respond to support tickets, email threads, updates to products, and so on over the years. It’s a piecemeal compilation of a variety of information.
Would documentation be better off if we periodically deleted it and just started over? Probably yes, but it’s too much effort. Usually instead of starting over, we just abandon the information, and it sits there as an old web page, its pixels fading as it resides on the 16th page of Google’s search results.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.