If Your Culture Requires a Building, What You Have Is a Terrarium

For three years I left the house before my kids woke up. Ninety minutes door to desk on a good day, ninety minutes back. Somewhere around year two, I remember sitting in traffic at 7 a.m. thinking: my kids are going to grow up and I am going to have been in a car. Twelve hours gone, day after day. It was eating at me in a way I had not fully let myself say out loud.

The specific irony of those three years: I was commuting three hours a day to sit at a desk and put on a headset. My scrum master was in a different office. My product owner was in a different office. The project manager was elsewhere. Every coordination meeting happened on a screen; the colleagues sitting three feet away from me had nothing to do with how the work moved. The building changed nothing about how work flowed. It just made sure I was already depleted when it started.

I have been working with distributed teams since 1999, and I learned to adapt to the needs of every configuration. What I learned early, and what most organizations are still arguing about: culture is not a poster on the wall. Culture is what is tolerated when a crisis arrives.

The return-to-office conversation is largely a conversation about real estate dressed up as a values argument. Leaders cite collaboration, connection, and culture. What they are actually describing, if you read the mechanism carefully, is visibility management: the ability to walk over when something breaks, to apply pressure by proximity. This framing is not honest, and it is not cheap. Real estate, utilities, commute costs absorbed by employees, and the attrition of every person with enough options to leave: none of that appears in the culture argument.

Here is what the mandate actually produces. The coordination model does not change. The scrum master is still remote. The dependencies are identical. Engineers who were productive from home now spend two to three hours a day in transit to run the same calls they were running from their home offices. Then the system sorts itself: the people with the most options calculate the cost and leave; the people who stay are, in many cases, the people who feel they have no better option. This is a population sorted by desperation, and sorting by desperation is not a culture strategy.

What leadership interprets as a lack of buy-in is the signal of an operating model that was never designed. Proximity was masking that absence. When everyone was in the same building, a leader could apply pressure physically: walk over, interrupt, redirect. Remote work removed that release valve. The gaps were always there; the building was keeping them invisible. Robert N. Harris named it precisely: if your culture requires a building, what you have is a terrarium, and what a terrarium produces is controlled conditions and dependency management, not culture.

The leaders who resolve this do not have more resources or more authority than you do; they stopped solving an operating model problem with a real estate solution.

Every team has an operating system: the way decisions get made, how work moves, how conflict gets handled, the cadence of communication. Most teams inherited theirs. Nobody designed it; it accumulated, survived because the environment stayed stable, and fractured when the environment changed. The investment required is not in real estate; it is in the explicit architecture of how your team coordinates: who decides what, how information moves, what gets escalated and what gets resolved at the edge. When these are designed intentionally, remote teams do not merely match co-located teams; they outperform them, because the coordination clarity that remote work demands turns out to be what makes all work faster.

The diagnostic question is this: have you actually designed how your team interacts and how work flows, from an engineering standpoint, or has it simply grown into what it is today? If you cannot answer that with a document, a decision log, or a set of explicit norms your team could recite without prompting, you have an inherited operating system, and that is the starting point for the design work that replaces it.

I write about structural leadership for technical leaders in high-stakes operating environments. If you want to see where your system is load-bearing on you personally, the LeadershipOS™ Scorecard maps it: https://theleadershiposbook.com/scorecard

---

I write about structural leadership for technical leaders in high-stakes operating environments. If you want to see where your system is load-bearing on you personally, the LeadershipOS™ Scorecard maps it: https://theleadershiposbook.com/scorecard