At the very start of most projects, there is often a disconnect between stakeholders.
Architects and developers come to the table with different priorities, different incentives, and different definitions of success.
This tension was surfaced clearly in a recent LinkedIn post that sparked a wide-ranging discussion among architects and developers about where projects break down before they even begin.
The comments reflected a familiar pattern, each side felt they were being misunderstood by the other.
We spoke with people who participated in the above thread, along with architects and developers in our broader network, to unpack what is really happening in those early conversations.
Our aim is to share real experiences, aimed at helping anyone kicking off a project better to understand how their counterpart is thinking and how to speak the same language from day one.
Creating confidence
A recurring, if unsurprising, theme from our conversations with developers and architects was that developer's usually have an architect in mind before they ever start a project.
The selection of these firms is based on prior working relationships, reputation, and a sense of predictability. One developer we spoke with emphasized that what they are really buying early on is confidence. Confidence that the architect understands their unique business lens. Confidence that the person across the table already “gets it” before the first sketch is produced.
This begs the obvious question though, how was this confidence established in the first place?
The developer’s priorities shape the project
Some of the best architects we spoke with emphasized that their early job is to be interpretive - rather than moving directly to drawings taking a beat to understand what the developer is actually optimizing for.
"It's so important to understand clients financing or their outlook. If If they're looking for a return on their investment within 10 years, it's a very different outlet to 25 years or 100 years"
Philip Gillard
Developers we talked with have ranging priorities from speed of iteration, maximizing efficiency, and minimizing unknowns. Those differences fundamentally change what “success” looks like.
Several interviewees noted that when architects come in with a one-size-fits-all pitch, it tends to fall flat. What works for one developer may be irrelevant or even risky for another.
The "stretch armstrong" problem
"It's like those "strech armstrong" toys or web diagrams, you pull one side, and it is going to push another, everything is connected and that is the challenge we solve for. An architects job is to look at those triggers and buttons and lay out the different options"
Philip Gillard
Developers we spoke with wanted to know that their priority is being maximized, once the architect can show this requirement is met, the job really begins. For example if you maximized efficiency based on the constraints of a particular site the iterations may shift to questions like 'sellability', tenant appeal, and long-term value.
Architects that stood out to developers were the storytellers - the firms who could actually demonstrate why a 5 percent hit to efficiency might unlock a much larger gain elsewhere.
In contrast developers felt that a overly-simple version of this was architects that led with the assumption that their design was standout. Everyone acknowledge there are projects where a unique design is the priority but these are the minority of projects.
Form vs function
Speaking of over-simplification the old adage of form or function came up often. Despite how often this is cited, most people we spoke with however felt the debate itself misses the point as projects are never this black and white.
Architects described their responsibility as holding multiple ideas at once. There is rarely one right answer. Good design contributes to placemaking, landmark identity, and the things that make cities worth inhabiting. At the same time, there is a clear obligation to make the project a financial and operational success for the client.
Developers echoed this. They expressed appreciation for architects who can speak fluently in dollars and cents, then layer design thinking on top of that foundation. Interestingly, they also noted skepticism toward architects who optimize too aggressively for a single metric. That often signals shortcuts in thinking rather than rigor.
A shared starting point
Across all of these conversations, one theme stood out.
The most productive working relationships start with a shared understanding that projects are rarely one-dimensional.
The projects that are the smoothest began with both sides establishing a shared understanding of what is being optimized, what is negotiable, and what is not.
Architects and developers may enter projects with different lenses, but the early stage is where those lenses either align or quietly diverge. The people we spoke with were clear. When alignment happens early, everything downstream becomes easier. When it does not, no amount of design excellence or financial engineering fully corrects for it later.
❤️ Thank you to everyone who took the time to sit down and talk with us!