02. Do we discover problems, or construct them?
The question: The alarm went off, but what was the problem?
At two in the morning, a red alarm starts blinking on one side of the monitor. Response time has increased by 300 milliseconds. The on-call engineer's name appears in Slack, and one line on the dashboard begins to creep upward. The team immediately asks, "Where did the problem occur?" The database? The network? The latest deployment? A little later, another question surfaces. Did the problem already exist somewhere in the world? Or did it become a "problem" only because we chose particular numbers, thresholds, and service levels?
Engineering often treats problems as if they were natural objects. Something is blocking the way like a rock, so we only need to find it and remove it. Bugs are hiding in the code, incidents are lurking inside the system, and requirements are already complete inside the user's head. But problems do not appear so cleanly in practice. They emerge from the entanglement of how we observe, what units we measure, what the organization is trying to achieve, and who has the authority to name an inconvenience.
The philosophical point: A problem is both a fact and a choice
Philosophy stops us at the apparently obvious sentence, "There is a problem." That statement is not a simple report of fact. It already contains judgments about what counts as normal, what should be counted as a loss, and whose experience should be accepted as evidence. This is why John Dewey understood problematic situations through the interaction between human beings and their environments. A problem is not a label attached to the world. It takes shape when some flow is obstructed and that obstruction calls for action.
The same phenomenon can become entirely different problems depending on the viewpoint. Suppose the click-through rate of a recommendation system has fallen. To the growth team, it may be a revenue problem. To users, it may be the experience of seeing unwanted content repeated. To creators, it may be a distribution problem because their work is no longer being seen. The question "How do we increase click-through rate?" has already shaped the problem in one particular direction. While answering it, we quietly delete the other problems.
That does not mean problems are entirely arbitrary. Servers really do go down, people really do wait, and budgets really are spent. Philosophical reflection does not deny reality; it separates its different layers. We need to distinguish physical constraints from organizational habits, users' needs from proxy metrics that happen to be convenient for us to measure. To say that we construct a problem does not mean inventing fiction. It means bringing one aspect of a complicated situation into the foreground and giving it a form we can act on.
An engineering case: The moment a customer complaint becomes a ticket
Imagine that a team receives customer feedback saying, "Search is frustrating." An engineer might think first of autocomplete, indexing speed, or spell correction. But if the team follows the user's experience through an interview, it may discover that the frustration is not caused by slow results. It comes from not being able to trust the results. The same product appears under different names from different sellers. Sold-out items remain at the top. Even after the price changes, the old description is still displayed. The problem here is not latency in the search API. It is that users cannot judge whether the results are reliable.
Change the problem definition and the system you build changes with it. The first definition calls for cache work and index tuning. The second calls for consistent product data, timely inventory updates, visible sources for results, and an interface that lets users refine their queries. The difference is not a single line of code. It is a difference in what the system is expected to take responsibility for. Engineers solve problems, but they also draw the boundary around what is worth solving.
That boundary becomes even clearer in AI systems. "The model is wrong" is a convenient diagnosis, but it is too broad. Is the model missing knowledge? Is the prompt ambiguous? Does the evaluation data fail to represent reality? Or did we automate a judgment that should never have been automated in the first place? Unless we reconstruct the problem precisely, a team can keep making the model larger while making the product more dangerous.
Counterpoint and tension: Can we not act without naming the problem?
Of course, we cannot redefine every problem forever. We cannot hold a philosophy seminar in the middle of an outage. There are operational targets and contractual obligations, and sometimes the system has to be restored immediately. The insight that problems are constructed must not become an excuse for delaying action. Sometimes you have to put out the fire first and examine the location of the smoke detector later.
But speed and reflection do not have to oppose each other. Good teams handle emergency response and problem definition on different timelines. Roll back immediately when an immediate rollback is needed. Then, in the retrospective, ask: Why was this metric a problem for us? Who bore the cost of the incident? Did we improve recovery rates while hiding the possibility of recurrence? A fast fix is necessary, but fixing a badly defined problem quickly is the most expensive kind of speed.
A question to leave with
Is the next "problem" you receive in a sprint really a solid object handed to you by the world? Or is it a temporary shape molded by your team's metrics, authority, and habits? Before we write a solution, perhaps the first question should not be "How do we fix it?" but "A problem for whom, by what standard, and in what sense?"