Look at the Right Frame

There’s a principle attributed to Eero Saarinen, the Finnish-American architect responsible for the Gateway Arch and the TWA Flight Center, that most people have never heard, even though it describes a failure mode they’ve encountered dozens of times.

Always design a thing by considering it in its next larger context.

A chair in a room. A room in a house. A house in an environment. A city in its region.

Saarinen wasn’t making a philosophical point. He was describing a discipline of a specific cognitive move that separates design that works from design that is merely correct. The chair might be structurally sound, ergonomically tuned, beautifully finished. And still wrong, because it was designed in isolation from the room it would inhabit, the people who would use it, the purpose the space was meant to serve.

This is not a problem unique to furniture.

What the Principle Actually Says

The framing matters. Saarinen didn’t say consider the larger context. He said consider the next larger context. implying a specific, bounded move. Not infinite abstraction. Not “zoom all the way out until everything looks small.” One level up. The immediate containing system.

That precision is what makes it useful.

When you’re designing a door, the next larger context is the wall. When you’re designing a wall, it’s the room. Each step requires you to ask: what is this thing for, within the system that holds it? What constraints does that system impose? What would make this element serve the whole rather than just satisfy its own internal logic?

The failure mode Saarinen was naming is optimization at the wrong level of abstraction. You solve the problem in front of you so thoroughly that you create a new problem one level up, one that didn’t exist before you started, and that your solution actively caused.

What This Looks Like in Architecture

The TWA Flight Center at JFK, completed in 1962, is the clearest example of Saarinen working from the next larger context outward. He wasn’t designing a terminal building. He was designing the experience of flight. The emotional register of departure and arrival at a moment when commercial aviation was still new enough to feel like an event.

The swooping concrete shell, the sunken conversation pits, the red carpeting, the tubular passenger tunnels. None of these make sense as isolated design decisions. It is coherent when you understand that Saarinen’s unit of analysis was the passenger’s psychological journey, not the building’s program requirements.

The building served its brief. But it was designed for its context.

Compare that to the vast majority of infrastructure built in the same era: functional, code-compliant, internally consistent, and experientially incoherent. Buildings that solved the problem of enclosure without asking what the enclosure was for.

Where the Principle Travels (long time readers know I was moving to this understanding)

The reason Saarinen’s framing is useful beyond architecture is that optimization-at-the-wrong-level is a universal failure mode. It appears wherever complex systems are designed by people who are focused on their own component without sufficient visibility into the containing system.

In software development, this is the microservices trap. Individual services, each optimized for their own performance and maintainability, can compose into a distributed system that is slower, more fragile, and harder to reason about than anyone intended. Not because any single decision was wrong. But because no one was optimizing for the whole. Systems degrade not through failure, but through the accumulation of reasonable choices.

In organizational design, this is the classic silo failure. Each department optimized for its own metrics, producing outcomes that satisfy every internal scorecard while the organization as a whole loses coherence, speed, and the ability to deliver anything that requires coordination across units. The departments work. The organization doesn’t.

In policy, this is what happens when a regulation is written to solve a specific problem without modeling the adjacent systems it will disturb. The rule is internally logical. Its second-order effects undo the first-order benefit.

In personal decision-making, this is optimizing a career move for compensation without accounting for the organizational culture, or choosing a house for its features without thinking about the neighborhood, the commute, the social infrastructure around it. The thing is fine. The context makes it wrong.

Why We Keep Getting This Wrong

Saarinen’s principle sounds obvious once stated. It is not obvious in practice, for a structural reason: we tend to have clearest visibility into the level we’re working at, and progressively less visibility into the levels above it.

The engineer sees the component. The architect sees the building. The urban planner sees the block. The policymaker sees the system. Each of these perspectives is real and legitimate. Each of them is also incomplete.

The problem is that authority and accountability are usually organized around the component level. You are responsible for the thing you’re building. You are not formally responsible for the system it enters. Which means the incentive structure actively discourages the move Saarinen is recommending.

Considering the next larger context costs time, creates ambiguity, and often produces constraints that make your immediate job harder. You might discover that the thing you’ve been asked to build shouldn’t be built at all — or should be built completely differently — because of what the containing system actually needs. That’s not a career-enhancing finding in most organizations. So the discipline gets skipped. Not from ignorance but from incentive.

The Practical Move

Saarinen’s principle becomes a usable tool when you treat it as a diagnostic question rather than a design philosophy.

Before committing to a solution, ask: what is the next larger system this will enter, and what does that system need from this component?

Not “what are all possible contexts?” One level up. The immediate container.

Then ask a harder question: does my solution serve that system, or does it serve my component at the system’s expense?

This question surfaces a specific class of problem that most analytical frameworks miss: the problem that doesn’t exist at the level you’re working at, only at the level above. The chair that works perfectly and ruins the room. The policy that solves its target problem and destabilizes the adjacent one. The feature that performs well in isolation and degrades the product. Infuriating.

These problems are invisible if you don’t look for them. They are obvious once you do. Most of the time we don’t see it until after the thing is already built or in process.

The Discipline, Not the Insight

What made Saarinen’s work distinctive wasn’t that he had a clever principle. It’s that he applied it consistently, even when it made the immediate design problem harder. The TWA terminal is more expensive and more structurally complex than a conventional building of the same size would have been. The Arch required engineering solutions that didn’t exist when the project was commissioned.

The next larger context often demands more of you than the component alone would. That’s the point. The discipline is in not looking away from what the larger system requires, even when what it requires is inconvenient.

Most failures of design in buildings, software, organizations, policy, are not failures of execution at the component level. No, they are failures of framing at the system level. The thing was built correctly. It was built for the wrong context.

Saarinen’s move seems simple: before you build, look one level up. Ask what the container needs. Then design the thing to serve that, not just itself.

It won’t make the work easier. It will make it right.

Nicole