The most common way a developer damages a building is by having aesthetic opinions and expressing them with authority. It is an easy trap because the opinions feel like engagement and because nobody in the room will tell you they are unhelpful.

The useful role is different and harder. It is to hold the constraints honestly, make sure the team is solving the actual problem, and be the party who notices when two disciplines are quietly assuming different things. That last one is most of the value. Design teams are competent and they are also specialized, and specialization means each group solves its own problem correctly against assumptions the others never stated.

So the questions I try to ask are about interfaces rather than objects. Not whether the facade is good, which is not mine to judge, but what it assumes about the structure behind it and whether the structural team has heard that assumption in those words. Almost every serious surprise I have had on a difficult building was living in a gap between two disciplines, each of which was doing its job properly.

The second thing the role requires is protecting the team from premature certainty, including my own. There is pressure on a difficult project to fix decisions early because fixed decisions permit planning. But fixing a decision before the information exists is how a project inherits a constraint nobody chose. Part of the job is absorbing the discomfort of an open question longer than anybody wants, and being clear that it is open rather than letting people quietly assume it is settled.

The third is being explicit about what is actually fixed. Teams work differently, and better, when they know which constraints are real and which are preferences that could move. A developer who leaves that ambiguous gets a design shaped around guesses about their opinions, which is a bad use of expensive people.

The fourth is sequencing who is engaged when. On an ordinary building this barely matters. On a hard one it decides the outcome, because some disciplines need to be in the room before a shape exists rather than after. Engaging a structural engineer or a preservation consultant to review a design is a completely different activity from engaging them to help determine it, and the second is usually what the project needed.

My arguable position is that developers should be far slower to express preferences and far quicker to insist on process. Say almost nothing about how something looks. Be immovable about whether the right people are in the room at the right time. I have met capable developers who think this is an abdication, that a building needs a client with a point of view and that refusing to supply one produces committee work. That is a real risk and I have seen it happen.

My honest limit is that I do not hold this line consistently. On projects I care about most I have pushed on questions that were not mine, and I cannot always tell afterward whether it helped. The discipline is easier to describe than to practise.

Everything above assumes retained professionals doing the actual work. Structure belongs to a structural engineer, code to people who practise it, and preservation to a consultant. The developer's contribution is the interfaces between them, not a second opinion inside any one of them.