Falling In Love With the Problem — The Most Underrated Skill in Architecture and Design

We are trained to find solutions.

That is, if you think about it, almost entirely what school is. A problem appears. There is a correct answer. The reward goes to the student who finds it fastest. The discomfort of not knowing is something to be eliminated as quickly as possible.

Twelve, sixteen, twenty years of that training. It goes deep.

So deep that most of us carry it into every professional situation without noticing. A problem appears in a meeting. The brain immediately starts generating solutions. The discomfort of sitting with the unknown triggers something almost physical — an urgency to reach for an answer. Any answer. One that makes the discomfort stop.

We have been so thoroughly trained to solve problems that we have forgotten how to be with them.

And that, I would argue, is one of the most expensive habits in architecture and software development today.

The Problem Is Not the Enemy

The first shift is a simple one. But it changes everything.

The problem is not the enemy.

School taught us otherwise. The problem is the obstacle between where we are and the correct answer. It exists to be overcome, eliminated, solved. The faster the better.

But this framing — problem as enemy — leads directly to a particular kind of blindness. It makes us reach for solutions before we have truly understood what we are dealing with. It makes us impatient with complexity, intolerant of ambiguity, and allergic to the kind of slow, patient inquiry that genuine understanding requires.

The designer, the architect, the truly creative practitioner — they relate to problems differently.

The problem is not the enemy. The problem is the teacher.

It contains, if you look carefully enough and without the distortion of your existing solutions, the shape of what it needs. The problem is always trying to tell you something. The question is whether you are willing to listen long enough to hear it.

The Logic the Problem Presents

Here is something subtler. And more important.

Every problem arrives pre-packaged with its own apparent logic.

This is a cost problem — therefore the solution is to reduce cost. This is a speed problem — therefore the solution is to go faster. This is an integration problem — therefore the solution is to integrate. This is a legacy system problem — therefore the solution is to replace the legacy system.

The problem presents its logic. And the logic seems reasonable. Obvious, even. And so we follow it — directly into the solution space the problem has already prepared for us. Where the conventional answers live. Where everyone who faced a similar problem has already been. Where the familiar tools are waiting.

But that logic is often the problem’s disguise.

The presenting logic is not always the real logic. The problem as stated is not always the problem that needs solving. The solution space the problem invites you into is not always the solution space that contains the true answer.

To doubt the logic presented by the problem — to ask whether the problem is actually what it appears to be, whether the framing is accurate, whether the logic is worth following — is one of the core skills of true creativity.

It is also one of the hardest. Because the logic feels obvious. And obvious things are difficult to question.

Falling In Love With the Problem

There is another way to relate to problems. One that produces better outcomes and, I would argue, a richer experience of the work itself.

Fall in love with the problem.

Not with the solution. Not with your idea for the solution. With the problem itself — its texture, its contradictions, its history, its human dimensions, the reasons it exists and the reasons it persists.

The architect who falls in love with the brief — who asks every question, who sits with the contradiction, who refuses the first obvious answer and keeps looking — finds something the solution-seeker never finds.

Not a correct answer. A true answer. One that emerges from the nature of the problem itself rather than being imposed on top of it.

This is what distinguishes the work that feels inevitable — that seems, in retrospect, like it could not have been any other way — from the work that feels applied. Correct but external. A solution placed on top of a problem rather than grown from within it.

Fallingwater does not feel like a solution to the problem of building a house near a waterfall. It feels like what the site was always trying to become. That is what falling in love with the problem produces. Not the fastest answer. The truest one.

We Jump Too Soon

In architecture and software development, we jump to solutions before we understand the problem.

This is not a character flaw. It is a trained reflex — accelerated by the cultures of both fields, which celebrate speed, decisiveness, and the bias toward action.

Discovery phases are rushed or skipped. Requirements are treated as problems already half-solved — a list of answers waiting for implementation rather than a starting point for inquiry. The architecture conversation begins with technology before it begins with need. The solution is in the room before the problem has been fully heard.

And the cost is enormous.

Not just in rework. Not just in technical debt. In the deeper, quieter failure of building something technically correct that doesn’t solve what actually needed solving. Systems that work but don’t serve. Architectures that are coherent on the diagram but alien to the people who have to live inside them.

The problem was never fully understood. The solution was reached too soon. And by the time that becomes clear, the cost of going back is higher than the cost of living with something wrong.

Sitting With Discomfort

The skill that school never taught — and that the best architects, designers, and engineers have somehow developed anyway — is the ability to sit with the discomfort of not knowing.

To resist the pull toward solution. To stay in the question. To let the problem reveal itself rather than forcing it into a familiar shape.

This is harder than it sounds. The discomfort is real. The pressure — from clients, from timelines, from colleagues, from the part of your own brain that was trained in school — is real. The relief that comes from having an answer, any answer, is seductive.

But the practitioner who can stay in the problem longer than is comfortable — who can tolerate ambiguity, sit with contradiction, and resist the premature closure of a good-sounding solution — consistently produces better work than the one who reaches for the answer first.

Not because slow is better than fast. But because understanding is better than assumption.

The obstacle is the way. Not the thing to be overcome as quickly as possible — the thing to be explored, understood, inhabited.

Letting go of conventional ideas — including the conventional idea that problems exist to be solved quickly — is where the real work begins.

What This Looks Like in Practice

Falling in love with the problem is not a passive state. It is an active discipline.

It means asking more questions than you think are necessary — and then asking more.

It means being genuinely curious about why the problem exists, not just what it is. Problems have histories. They have political dimensions, cultural dimensions, human dimensions. Understanding those does not slow the solution down. It changes what the solution needs to be.

It means doubting the framing. Every problem arrives in a frame — a set of assumptions about what kind of problem it is, what solution space it belongs to, what constraints are real. Good architects question the frame before they accept it.

It means being willing to restate the problem. Often the most valuable contribution an architect can make — before a single technical decision — is to say: I don’t think this is the problem. I think the problem is this.

And it means developing a tolerance for the discomfort of not knowing. Which, like most important skills, improves with practice and intention.

The Most Important Moment in Any Project

There is a moment in every project — usually early, often rushed past — when the problem is still open. When the solution space has not yet been decided. When the frame is still available for questioning.

That moment is the most important moment in the project.

What happens in it — how deeply the problem is understood, how seriously the logic is questioned, how honestly the framing is examined — determines more about the quality of the outcome than any technical decision that follows.

Most projects invest the least attention in that moment. Because it is uncomfortable. Because it does not feel like progress. Because the client wants to see something, the timeline is already running, and the brain wants relief from the uncertainty.

But the architect who protects that moment — who insists on understanding before designing, on questioning before deciding, on sitting with the problem long enough for it to reveal what it actually needs — is doing the most important work in the project.