What a Thoughtful Case for Returning to the Office Actually Reveals

I have been working with distributed teams since 1999, when the first cable modems made it technically possible. For the twenty-one years before the pandemic forced the conversation on everyone else, remote work was not a trend I was managing. It was simply how technical teams at the scale I was operating actually functioned.

I also spent time commuting ninety minutes to two hours each way to sit at a desk in an open-plan office wearing headphones most of the day. Half my team was in that office. The other half was in other locations. Every team meeting still happened with each of us at our own workstation because there was no room that held everyone. The commute gave me presence. It did not give me proximity to the work.

The arrangement that actually worked was flexible: in the office when I could maximize direct interaction with local team members, at home when I was working with the full distributed team or running work that required depth. It was productive and thoughtful and, for a while, well-designed.

Then the CEO walked through the expensive Stamford waterfront office on an ordinary afternoon and saw empty desks.

WFH became a problem that day. Not the decision to locate a development team in expensive waterfront real estate. Not the absence of a team operating system that would have made the location irrelevant. The empty desks.

I was genuinely irritated. Technical teams are not administrative teams. They are not sales teams. The work is different, the coordination patterns are different, the environments that support deep technical work are different from the environments that support relationship-driven commercial work. The mandate that followed reflected none of that distinction. I exited that position and I have not been in an office since 2018.

I say this not to establish a position but to establish a baseline. Twenty-one years of building and managing distributed technical teams is not a theory. It is a pattern.

Which is why I recognize what is happening when engineering leaders post about wanting their offices back. The version circulating recently is honest and well-observed: seven years of remote work, senior teams built across multiple states, real products shipped with people only ever seen as squares on a screen. The case for returning is not about output. It is about the speed of course correction. In person, the wobble gets caught early. An engineer pauses at the coffee machine, says “just one thing,” and eleven minutes later the problem is gone. Remote, the same signal becomes a 1:1 agenda item, surfaces two days later, and costs someone their confidence in the interim.

The symptoms are real.

The diagnosis is wrong.

What that post describes is not a remote work failure. Each symptom it names is a specific operating system failure wearing the clothing of a location problem.

The engineer who waits for the 1:1 to raise something small does not wait because they are remote. They wait because no low-friction mechanism exists between 1:1s for small signals to surface before they become expensive. That is a Cadence failure. The office coffee machine was catching the wobble by accident. Proximity was substituting for design.

The introverts who stop unmuting on Zoom do not start unmuting in conference rooms. The loudest voices are still the loudest voices. What silences introverts is meeting design that rewards the fastest and most confident speakers, in any medium. The fix is the same in both environments: structured participation, deliberate turn-taking, async input before the synchronous discussion. That is a Coaching and Clarity problem, solved at the system level, not the location level.

The new hire who is three weeks in and too embarrassed to admit they do not understand the deployment pipeline is not confused because they are remote. They are confused because the onboarding system has no structured checkpoint that creates explicit permission to not know things yet. That is a Clarity failure. The open office did not solve it. It just made the confusion more visible to the people walking past.

If you do not design the system, what assembles in its place is whatever organically emerges. And organic systems have gaps in every environment: remote, distributed across multiple offices, or colocated in a single building. The CEO who saw empty desks in Stamford and mandated presence did not close any of those gaps. He filled the chairs. The gaps remained.

Proximity was substituting for design. When proximity is removed, the gaps become visible. The instinct to restore proximity is understandable. It is not a solution to the system that produced the gaps.

The leaders building teams that function regardless of location designed the system. The wobble-detection mechanism does not require a coffee machine. It requires a cadence structure where small signals have somewhere to go before they become large problems. The introvert who goes quiet needs meeting design, not a conference room. The new hire who does not understand the pipeline needs a structured thirty-day check-in, not an open floor plan.

Geographic diversity is now the norm for technical teams, not the exception. You are not choosing whether to lead a distributed team. You are choosing whether to architect the system for the one you already have.

Name one coordination problem your team has right now that you believe physical proximity would solve. Then ask what would need to be true in the system for that problem not to exist regardless of where people sit. That is the operating system gap. That is where the work is.

I write about structural leadership for technical leaders in high-stakes operating environments. The full operating model is in LeadershipOS™: http://TheLeadershipOSBook.com

---

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