The true answer is that you don’t. You’re always stuck with the same basic problems: how do I find food, water, breathable air, shelter, community… and so on. They don’t go away, you just trade one set of problems for a different set of problems. This remains true whether you’re talking about necessities like sustenance or frivolities like next season’s fashions.
Here’s how this works. Suppose you manage an organization growing out of the dark ages of technology. Everything used to be word-of-mouth or pen-and-paper, but with a couple hundred people this is no longer tenable. So, to replace your workflow you choose a piece of software that implements that workflow for the user as a distributed service accessible anywhere the appropriate infrastructure exists–in this case, anywhere there’s an internet connection and a computer. You’ve removed some problems from your list–great! An individual user’s workflow is enforced, so no more forgetting step 3. The information is available anywhere, so no more forgetting paper records, or having to wait two weeks while someone gropes through their filing cabinets for that report from three years ago. Also, it’s kept for you, so you don’t wind up losing whole swathes of records when someone’s basement gets flooded or they have an unfortunate oversight while moving.
But I’m misguiding you here, and anyone who’s ever dealt with backup knows it. Sure, that information is kept safely on the server, but with what kind of backups? How regular are they? How easily are they restored? Backup shows a major hole in the new organizational structure because it highlights that you’ve replaced your old set of problems–house/office fires, floods, forgetfulness–with a new, digital set. It’s obvious why anyone would do this, because the digital problems are easier to deal with. I can prevent or at least reduce loss of carbon copy information the same way I can prevent loss of digital information: diligence. But a fire has avenues I can’t easily prevent. Digital data loss has even fewer avenues that can’t be prevented, and it’s possible to patch those so thoroughly as to never lose data. At least, not unless our civilization collapses entirely, in which case you’re probably going to be less concerned with last week’s financial report anyhow.
In the case of data and workflow, going electronic is a pretty good trade for anyone. However, there are problems where either tradeoff makes sense depending on who’s doing it. Open Source vs Proprietary, for instance, represents a dichotomy where either branch carries a set of problems amenable to different types of people. Some of us can be bothered with occasionally diving into code to fix something. Some of us would rather wait for the coders to fix it either because we don’t know how or because we don’t have the time. (Actually, the former breaks down into not having the time anyway.)
But why am I splitting hairs? If problem solving consists of trading a set of problems for a more manageable set, doesn’t that count? What’s wrong with just thinking of the problem as solved?
Well, it’s all in the words to a degree. The word solve dissolves into Greek meaning “to untie” and is related to the English word loose. So you’ve loosened your problems, figuratively. The temptation is to scrub them from the list entirely and pretend they’ve gone away. However, it’s most rational to replace them with the new problems you’ve accepted. They’re higher-level problems, more abstract, and perhaps more manageable if you’ve chosen a good solution. But if it’s non-obvious why one must pedantically track problem exchange, let’s consider a bad solution.
Let’s consider our old friend backup again. Suppose your previously did digital backups, but after the carbon-copy fashion, as was common before the internet made it easy for us to move data around without sneakernet. Every week your users copy their files to a floppy disk that is studiously passed mailroom style back to IT for filing away. This is little better than paper, except that the data density is way higher. Assuming that you’re not backing up more than could be printed out in a report, you’ve just increased the expense of backup. You still have the same problems, except that your users have a new process to learn, and some people will take longer to deal with this. Opting for this kind of backup in this day and age is ridiculous, but not unheard of. I used to do IT for a small company that burned their database backups to CD every week instead of just dumping them into something like Dropbox. (Or an Amazon Bucket as I had recommended.)
This is a simple example, and frankly there are probably better ones, but they require more backstory and explanation. The bottom line is that keeping the notion of problem exchange in mind helps keep the evaluation of new systems honest. Does our solution really simplify the problems we have? Does it actually trade any of them at all, or just change their context? A good solution will remove all the problems it addresses and replace them with fewer problems which are each themselves easier to handle. Sometimes this isn’t easy to see from Mount Solution. Our modern agricultural system has many problems, but people who live under it starving isn’t one of them. (If anything, the major question there is why our food surplus still leaves people outside of it starving when we produce more than enough to feed them, but that’s a different question about modern civilization.)
There is also the temptation of management to ignore the new problems since the old ones are gone. This is part of how bad code gets written. If those old problems are removed from the board, the issue is considered gone entirely. We already paid to solve that problem last quarter–why do we need to put any more money into it this quarter? It’s this kind of thinking that I’m hoping to eliminate. We’re always climbing the hierarchy of problems, trading them out for better sets. We can’t ever solve our problems, just bootstrap ourselves into better ones.