What Buildings Taught Me About Software

There is a common assumption that leading physical projects and leading software projects require entirely different muscles. I believed a version of it myself. Then I started directing enterprise software work and kept having the same feeling: I have seen this failure before, on a job site.

Over fifteen years running Synchronos we delivered thousands of projects, most of them multidisciplinary — automation, AV, security, lighting and networking that all had to work together in one building. The technology itself was rarely the problem. The failures lived in the space between disciplines. The electrician didn't talk to the AV integrator. The automation vendor didn't understand the networking constraints. Each trade did competent work, and the building still didn't work.

When I moved into enterprise software, the pattern was waiting for me. The backend engineers didn't understand the business constraint. The interface designers didn't understand the data model. The AI assistants wrote code without understanding the production environment. Different trades, same gaps.

What transferred

In physical projects, our answer had been to own the whole cycle — discovery, design, procurement, delivery, commissioning, support — so that there was one team answerable when systems met each other. Clients didn't buy automation from us. They bought the absence of finger-pointing.

In software, the same instinct translated into two habits.

The first is writing down what "finished" means before work starts. On a job site this is a commissioning checklist; nobody argues with it. In software it is strangely controversial, and its absence is why so many projects are permanently eighty percent done.

The second is keeping a single point of accountability for every joint between disciplines. Committees do not ship buildings, and they do not ship products. Someone has to own the seam.

The part that surprised me

I expected the physical world's discipline to feel heavy in software. It didn't. If anything, software teams were relieved when the ambiguity was taken away — when the requirement was written down, the boundary was explicit and someone would actually check the result against the intent.

If you are struggling to deliver a complex system of any kind, my field note is this: look for the gaps between disciplines, because that is where the project is failing; give the seams an owner; and define what finished looks like before you start. The medium changes. The discipline doesn't.