Your architect designed a building. Your contractor built it. Your facilities team now manages it. And somehow, none of those three groups are fully satisfied with the result.

This is not unusual. This is normal. And the reason it’s normal has less to do with people’s competence than with the incentive structures baked into the contracts that govern every phase.

Contracts optimize for the wrong thing

Design contracts typically pay for deliverables: drawings, specifications, calculations. The design team gets paid when the documents are complete and approved. Whether those documents translate to a building that performs the way the owner needed is largely outside the contract’s scope.

Construction contracts typically pay for completion: the building built to the drawings, within the schedule, within the budget. Whether what was built matches what the owner actually needed from a business standpoint is similarly outside the scope.

The result is a chain of well-executed handoffs that cumulatively fail to deliver the owner’s real objective. Everyone did their job. The building opened on schedule and within budget. And the owner is still not sure it’s quite what they needed.

Design without understanding the operator

The most common failure mode looks like this. An owner brings in an architect and says “we need a 200,000 square foot office building.” The architect proceeds from that brief. Questions get asked and answered: occupancy, program, aesthetic preferences, systems requirements. A building gets designed.

What doesn’t get asked, or doesn’t get asked rigorously enough: how will this building be operated? What does it cost to maintain over 20 years? What happens if the business changes and needs different configurations? How does this building support or impede the specific workflows of the people who’ll use it?

These questions belong at the front of the design process. They almost never get there because the architect isn’t paid to deliver operational outcomes and the owner usually doesn’t know what questions to ask.

The MEP engineer designs systems that meet code. The structural engineer designs a structure that’s sound. The contractor builds what’s drawn. And the owner gets a building that is technically correct and operationally awkward.

The feedback loop that doesn’t exist

Buildings perform, or don’t, for decades after the design and construction team has moved on. The operational data that would teach future designs how to perform better never makes it back to the people making design decisions.

Maintenance costs that exceed projections. Energy consumption patterns that reveal design assumptions were wrong. Occupant workflow problems that become apparent only after years of use. None of this gets systematically captured and returned to the teams who could use it.

Instead, every project team starts from first principles. Same mistakes, same misalignments, same gap between design intent and operational reality, project after project after project.

What changes when you insist on outcome alignment

Some owners are starting to structure their relationships differently. They’re bringing operational stakeholders into design conversations from the beginning. They’re specifying performance requirements, not just design requirements, in their design contracts. They’re demanding that designers and contractors show their work on how the delivered product meets operational needs, not just programmatic requirements.

This is harder to do than it sounds. It requires owners to have clear operational requirements before design starts, which requires doing thinking that most owners defer to the design phase. It requires architects who are willing to be held accountable for outcomes they don’t fully control. It requires contractors who understand why the operational context matters to the building they’re constructing.

But the owners who get this right build buildings that work. Not just buildings that meet the spec. Buildings that serve the business.

The question to start with

Before your next project goes to design, ask this question: what does success look like in year five of operations?

Not year one, when everyone is still adjusting and giving the benefit of the doubt. Year five, when the honeymoon is over and the building is just part of how the business operates.

The answer to that question, worked out before design starts, is what should be driving every design decision that follows.

If your design team can’t tell you how their decisions connect to your year-five answer, you’re designing without the most important information. And you’ll be wondering why the building feels off when it opens.