I have been thinking about a paradox that seems to appear quite often in everyday life: sometimes, the things we create to solve a problem gradually become things that we simply maintain. And somewhere along the way, we may forget what we were originally trying to achieve.
A simple example is the FAQ section of a product or service.
When we develop a product, we usually provide instructions, documentation, and a list of frequently asked questions. These are useful. People naturally have questions when they encounter something new, and answering those questions is part of good communication.
But if we look at an FAQ from another perspective, it tells us more than what customers want to know. It also tells us where our product, design, or communication may be failing to explain itself.
If hundreds of people keep asking the same question, we can certainly write a good answer and put it in the FAQ. But that should not be the end of the process. We should also ask: Why do people keep having this question in the first place?
Perhaps the instructions are unclear. Perhaps the interface is confusing. Perhaps an important piece of information appears too late. Perhaps we are explaining something according to our own understanding rather than from the perspective of someone encountering it for the first time.
In that sense, an FAQ should not simply grow forever. Ideally, some frequently asked questions should gradually disappear.
If a question reveals unclear instructions, improve the instructions. If it reveals a design problem, improve the design. If people repeatedly misunderstand the same concept, change the way we communicate it. Once the underlying cause has been addressed, people should no longer need to ask that question so frequently.
Of course, an FAQ will probably never disappear completely. New users will have questions, products will evolve, and new problems will emerge. But the same questions should not remain forever.
A healthy FAQ should therefore be dynamic. New questions appear, patterns are identified, improvements are made, and old questions gradually disappear. In this sense, an FAQ is not merely a customer-support tool. It is also a feedback mechanism for improving the product itself.
If the same question has remained at the top of the FAQ for five years, perhaps we should not congratulate ourselves for having a well-written answer. We should ask why we have spent five years answering the same question instead of removing the reason people need to ask it.
This leads to a broader version of the same paradox.
Imagine an organization whose mission is to help a community overcome poverty. To achieve this goal, the organization needs people, funding, offices, technology, procedures, management, and other forms of infrastructure. All of these things may be necessary. Without them, it can be difficult to pursue the mission effectively.
But over time, something subtle can happen.
The organization needs money to maintain its staff. It needs staff to maintain its programs. It needs programs to justify funding. Gradually, more and more attention may be directed toward keeping the organization functioning.
At some point, maintaining the infrastructure can quietly become a goal of its own.
But that was never the original purpose.
The infrastructure exists to solve the problem; the problem does not exist to justify the infrastructure.
This creates an uncomfortable paradox. If an organization is created specifically to eliminate a problem, then in the most successful scenario, it should eventually make its original form unnecessary.
If your mission is to eliminate a particular problem, complete success means that one day there should be no such problem left for you to solve.
That does not necessarily mean that the organization itself must disappear. The knowledge, people, relationships, and capabilities developed through solving one problem may be useful for solving another. An organization can evolve. Its people can take what they have learned and apply it elsewhere.
But this possibility should not distract us from the more important question: are we maintaining this organization because it continues to serve its purpose, or has maintaining the organization itself become the purpose?
The FAQ and the organization may seem like very different examples, but I think they reveal the same underlying pattern.
An FAQ is created because people have questions. An organization is created because a problem needs to be solved. A process is created because something needs to be accomplished. Infrastructure is built because a goal requires support.
These things are means, not ends.
Yet once a means exists, it develops its own momentum. People become responsible for maintaining it. Resources are invested in it. Procedures grow around it. We become better and better at operating it. Eventually, we may stop asking whether it is still moving us toward the original goal.
We become good at answering the question instead of preventing the question.
We become good at managing the problem instead of eliminating the problem.
We become good at maintaining the system instead of asking why the system needs to exist.
This does not mean that every recurring problem can be eliminated, nor that every organization should eventually disappear. Some problems are continuous by nature, and some systems provide value precisely because they need to operate continuously.
The important thing is not disappearance itself. The important thing is direction.
Are the recurring questions becoming fewer? Are the underlying problems becoming smaller? Is the infrastructure helping us get closer to the goal for which it was created?
If not, perhaps activity has begun to replace progress.
A good system should not merely become better at handling the same problems. It should learn from those problems and, whenever possible, remove their underlying causes. Sometimes, real progress means that the questions people once needed to ask are no longer necessary, the processes we once depended on are no longer needed, and even the structures we built to solve a problem may eventually have to change or disappear.
So perhaps, from time to time, we should look again at the things we have built—the FAQs, the processes, the infrastructure, the organizations—and ask ourselves:
Are we still using these things to solve the problem, or have we become so busy maintaining them that we have forgotten what problem we were trying to solve in the first place?