Co-location, Remote First, and the Rollback Every Few Decades
Or: Why the Most Important Architecture Decision Is Your Floor Plan
Somchai’s cursor hovered over the merge button for eleven seconds. He’d counted. The MR had two approvals — both from engineers who’d left comments like “LGTM” without, he suspected, actually opening the diff. The deployment window closed in forty minutes. Three Slack messages to the service owner had gone unread since yesterday morning. The air conditioning in the Bangkok office hummed at its usual aggressive seventeen degrees, but Somchai was sweating anyway. He merged it, closed his laptop, and spent the BTS ride home refreshing Grafana on his phone.
Two years earlier, before the seating reshuffle, the service owner had sat four desks away. Somchai would have rolled his chair over, tapped a shoulder, and had the conversation in ninety seconds. That world doesn’t exist anymore for a lot of teams. And we keep pretending Slack is an adequate replacement.
As the historian Barbara Tuchman wrote, “Men will not believe what does not fit in with their plans or suit their prearrangements.” She was writing about governments marching into wars they’d been warned against. She might as well have been writing about the technology industry’s relationship with remote work — a forty-year cycle of discovering the same truths, ignoring them, and rediscovering them with the confidence of someone who’s never read the previous chapter.
The Forty-Year Rollback
Here’s a story most engineers don’t know, and it starts before most of us were writing code.
In 1979, IBM allowed five employees to work from home via terminals. Five people. An experiment. By 1983, that experiment had grown to 2,000 remote workers. By the early ’90s, IBM had formalised a telecommuting programme allowing employees to work from home up to three days a week. By 2009, 40% of IBM’s 386,000 global employees worked remotely, and the company had shed 78 million square feet of office space — saving roughly $100 million a year in the US alone.
Then the turn. After 19 consecutive quarters of declining revenue, IBM’s CEO Ginni Rometty ordered thousands of remote employees back to the office in 2017. The CMO’s internal blog post carried the subject line “It’s time for Act II: WINNING!” — capital letters, exclamation mark, zero self-awareness. Employees who’d originally been told by IBM to work from home decades earlier received mandates to relocate to one of six hub cities or leave.
Then — the second turn. COVID hit. IBM went remote again. By 2022, CEO Arvind Krishna acknowledged that only about 20% of employees were back in the office three days a week and predicted that number would never exceed 60%.
That’s three positions in forty years from the same company. Pioneer, enforcer, and reluctant pragmatist — all wearing the same logo.
But IBM wasn’t alone. Not even close.
The Pattern Nobody Reads
The concept of remote work didn’t emerge from Silicon Valley optimism. It was born from crisis. In 1973, the OPEC oil embargo sent fuel prices through the roof, and a NASA communications designer named Jack Nilles coined the term “telecommuting” as an alternative to the daily commute. A 1979 Washington Post article floated working from home as a way to save gasoline. The idea wasn’t about productivity or culture or collaboration. It was about not burning fossil fuels to sit in traffic.
By 1987, about 1.5 million Americans were working remotely. J.C. Penney let call-centre employees work from home. American Express and GE experimented with their own programmes. In the early 1990s, Peter Drucker — the management thinker whose name still gets dropped in every strategy deck — declared commuting to an office obsolete. The phrase “work is something you do, not somewhere you go” entered the lexicon.
And then the industry started to forget.
Yahoo’s Marissa Mayer dropped the first major reversal in February 2013. Fresh from Google, she banned working from home entirely. The leaked internal memo from HR head Jackie Reses read like a mission statement for the back-to-office movement: speed and quality suffer when people work remotely, the best decisions come from hallway conversations, we need to be physically together. Mayer later defended the decision by acknowledging people are more productive alone, but insisted they’re more collaborative and innovative together. The ban affected roughly 200 of Yahoo’s 12,000 employees — hardly the workforce revolution the headlines suggested — but the signal it sent was deafening.
Meanwhile, some companies never entertained remote work at all. Steve Jobs designed Pixar’s headquarters around a massive central atrium — placing the only bathrooms, the cafeteria, the mailroom, and the gym at the building’s heart — so that every employee had to pass through the centre multiple times a day, engineering serendipitous encounters by architectural force. His original idea reportedly involved a single bathroom for the entire campus. Ed Catmull, Pixar’s co-founder, noted that random encounters in that atrium were what kept the culture alive. Apple Park — $5 billion, 12,000 employees under one roof — was the physical manifestation of the same philosophy.
Then 2020 happened. COVID forced the largest remote work experiment in human history. Everyone went home overnight. Productivity studies said it worked. Remote became “the future of work.” Think pieces declared the office dead.
And now we’re watching the fourth iteration of the same argument. Amazon ordered 350,000 corporate employees back to the office full-time in January 2025. JPMorgan Chase ended hybrid work for its 300,000 employees in March 2025 — then discovered it didn’t have enough desks in its London headquarters to seat them all. AT&T, Dell, the Washington Post, even the US federal government — all mandating five days. JPMorgan’s internal employee survey showed significant drops in satisfaction around work-life balance and wellness, which leadership openly attributed to the return mandate.
The comedian George Carlin once said, “Some people have no idea what they’re doing, and a lot of them are really good at it.” We keep oscillating between “remote is the future” and “everyone back in the office” with the institutional memory of a goldfish and the confidence of someone who’s never been wrong.
Why The Rollback Keeps Happening (The Part Nobody Wants to Admit)
The charitable reading is that leaders are responding to real collaboration problems. And sometimes they are.
The less charitable reading comes from research. A study from the University of Pittsburgh’s Katz Graduate School of Business examined RTO mandates across S&P 500 firms and found no significant improvement in financial performance or firm value after mandates were imposed. What they did find was significant declines in employee satisfaction — particularly around work-life balance, perceptions of senior management, and cultural values. The researchers’ conclusion was blunt: the findings were consistent with managers using RTO mandates to reassert control and blame employees for poor firm performance, rather than genuinely improving outcomes.
But here’s my contrarian take, and it’s the one I think matters more than either side of the debate admits: both camps are partly right, and both are mostly wrong about why they’re right.
The remote advocates are correct that mandates destroy trust, that individual output often improves with flexibility, and that talent pools expand dramatically. But they’re wrong about why companies keep rolling back — it’s not just about control. The thing that breaks in remote-first organisations is decision bandwidth — the speed and fidelity of high-stakes, ambiguous communication.
I wrote about this in The Slack Channel Graveyard: not all communication is equal. Lightweight, reversible, low-context stuff works brilliantly async. But anything involving tradeoffs, ambiguity, or cross-team coordination — the stuff that actually determines whether your architecture holds together — degrades catastrophically over text channels. People post to feel like they’ve communicated. People read to feel like they’re informed. And the quiet loneliness of remote work is the emotional tax of maintaining that fiction.
And yes, output may improve when you isolate your workers. But we don’t measure output — we measure outcomes. A developer who ships three features in isolation that don’t integrate well with the broader system has high output and negative outcomes. Less collaboration doesn’t just risk worse outcomes — it almost guarantees them, because the problems worth solving are almost never contained within one person’s context.
The Level Six Story
When I first joined Agoda, most of the engineering organisation sat on a single floor. Level six. Half the floor. You could see everyone. If you needed a code review, you didn’t ping a PR bot and wait — you walked over and sat down. If you were blocked on another team’s API, you could see whether they were in a meeting or heads-down or at the coffee machine, and you calibrated your approach accordingly. The feedback loop between “I have a question” and “I have an answer” was measured in minutes, not hours or days.
That environment didn’t just enable speed. It made isolation visible. When someone sat alone struggling with a problem for three hours, you could see it — the posture, the frustrated scrolling, the third coffee. In a remote setup, that same isolation looks like a green Slack status dot and “deep work” in the calendar.
We run regular intensive co-location events — not one-off experiments, but a repeatable process. Engineers from different teams, same room, same week, same problem. The pattern we see is consistent: what would normally take weeks of async coordination compresses into days of focused, high-bandwidth collaboration. Engineers consistently report the same thing — the problems that get solved immediately in person would have been a week of Slack back-and-forth, reply maybe next week because everyone’s busy. The context switching drops. Instead of juggling ten things and making progress on none, they focus on one thing at a time, and it ships.
We also track co-creation patterns in our codebase. If 88% of merge requests have a single committer, that’s not collaboration — that’s people working in isolation and integrating through master. Co-location doesn’t automatically fix this, but it makes the problem visible. And visibility is the first step toward change. I’ve written about how shared taste and co-creation patterns shape engineering culture — the short version is that working alone produces divergence, and working together produces coherence, and no amount of documentation or ADRs substitutes for the shared understanding that builds when people solve problems side by side.
The Exception: Gamers Figured This Out First
Here’s where I’m going to lose the remote-sceptical readers and win them back at the same time.
Online gaming communities have been doing high-bandwidth remote collaboration since the late 1990s, and they cracked the model that most “remote first” companies still haven’t figured out. Ventrilo, released in 2002, TeamSpeak before it, and Discord after — these tools enabled something corporate tech wouldn’t understand for another two decades: persistent, always-on voice channels where people drop in and out without scheduling a meeting.
Raid guilds in World of Warcraft coordinated 25–40 people through complex real-time operations with extraordinary precision, across time zones, often with people who’d never met in person. EVE Online alliances ran fleet operations involving hundreds of players with clear command structures and instant accountability. If the main tank died because the healer was AFK, everyone knew immediately. There was no hiding behind a Slack status.
What made it work wasn’t the software. It was the operating model.
Voice-first, not text-first. The default channel was open voice. Text was supplementary. This is the opposite of how most “remote first” companies work, where Slack is primary and calls are the exception. Persistent presence — you logged into the channel when you sat down and stayed connected. You could hear when people arrived, sense the ambient energy. This is closer to being on the same floor than any Slack workspace will ever be. Shared mental models built over hundreds of hours — not through documents and wikis, but through shared experience. The guild that wipes on the same boss fifty times develops the same kind of tacit knowledge that a co-located team builds by debugging together.
As someone who’s played enough games to know the difference between a coordinated team and a collection of individuals who happen to be in the same instance — the gap is enormous. It’s the same gap between a co-located engineering team and a distributed one trying to align through threads.
The implication for companies is uncomfortable but important: if your remote team operates like a raid guild — persistent voice, shared mental models, high trust, rapid feedback — you might be the exception. But most “remote first” companies don’t operate like this. They operate like a Slack workspace with scheduled video calls, and then wonder why alignment is so hard. The tooling exists to make remote work at high bandwidth. The culture almost never does.
The Default, Not the Mandate
Here’s the thesis, stated carefully. Not “remote is bad” — that’s lazy and wrong. The argument is: the default should be co-location. Remote should be the exception you earn, not the baseline you assume.
The difference matters. When you default to remote and then try to create collaboration, you’re fighting gravity. Every sync meeting has to be scheduled. Every whiteboard session needs a tool. Every decision goes through text, where tone is ambiguous and urgency is invisible. You’re building collaboration infrastructure on top of isolation.
When you default to co-location and then allow remote for specific needs — deep work days, life logistics, timezone-distributed expertise — you’re starting from high bandwidth and selectively reducing it where it makes sense. The gravity works for you.
The evidence from the RTO wave is messy, but one pattern is clear: companies that mandate return without fixing why their offices were empty keep failing. You can force people into a building, but you can’t force them to collaborate. Yahoo proved this — the mandate didn’t save the company. The leading reasons businesses cite for going back to the office are collaboration, productivity, and communication — all outcomes that empty mandates don’t produce.
What works is what Jobs understood at Pixar: design the physical environment for collision. What works is what we experienced on level six: proximity so tight that the fastest path to unblocking was standing up. The mandate isn’t the point. The architecture — organisational and physical — is.
What to Actually Do
Co-locate by default, not by mandate. The difference matters enormously. A mandate says “be in the office or else.” A default says “we believe this works better, and here’s the evidence, and here are the exceptions.” Mandates create compliance. Defaults create culture. Our co-location events aren’t mandates — they’re invitations backed by evidence, and the results speak for themselves.
Design for collision, not surveillance. Jobs understood this. The bathroom location at Pixar wasn’t about monitoring attendance — it was about engineering encounters. Level six wasn’t special because management could watch people; it was special because the physical architecture made collaboration the path of least resistance. If you’re tracking badge swipes to enforce RTO, you’ve already lost. You’ve confused presence with participation, and they are very different things.
When you go remote, go voice-first. Study the gaming model. Persistent channels, not scheduled meetings. Drop-in voice, not camera-on-or-you’re-not-present. Let ambient awareness replace status updates. Discord — born from this exact gaming lineage — gets closer to the right model than Zoom or Teams ever will. Slack huddles are better than scheduled video calls, but push-to-talk in a persistent channel is the closest thing to being on the same floor that technology has produced.
Measure what co-location actually gives you. This is the hard part, and it’s where most organisations wave their hands and rely on vibes. Track decision latency — how long from “we need to decide X” to “X is decided and implemented.” Track time-to-unblock — when an engineer is stuck, how long until they get help. Track decision revisit rate — how often does a “decision” get reopened because alignment wasn’t real. These aren’t easy metrics to automate, but you can start by instrumenting your workflow tools. Measure the time between MR creation and first substantive review comment. Measure the gap between a question asked in a channel and a definitive answer. Compare these across co-located and distributed periods. If co-location improves them, you have evidence. If it doesn’t, your office design — not the concept — is the problem.
Accept the cycle and build for transitions. The honest answer is that your organisation will probably oscillate between more-co-located and more-distributed over its lifetime. Build systems that work in both modes. Document decisions in actual persistent docs — not in Slack, which is a hallway, not an archive. Create onboarding that doesn’t depend on osmosis. Make the implicit explicit, so that when the pendulum swings, you don’t lose institutional knowledge. I’ve written about how silos form and how to break them — the common thread is always communication bandwidth, and bandwidth is always a function of proximity, whether physical or virtual.
The Floor Plan Is the Architecture
Conway told us in 1967 that organisations produce systems that mirror their communication structures. Most people read this as being about software — your microservices look like your org chart. But the deeper reading is about physical and temporal structure.
Your org chart is one kind of architecture. Your codebase is another. But the architecture that shapes both of them — the one that determines how fast information flows, how quickly decisions happen, how much trust accumulates — is the architecture of proximity. Sometimes that’s a floor plan. Sometimes it’s a Discord server with persistent voice. But it’s never a Slack channel and a weekly sync.
As the architect Christopher Alexander wrote, “When you build a thing you cannot merely build that thing in isolation, but must repair the world around it.” We’ve been doing the opposite — building remote work infrastructure that makes the world around it less coherent, one async handoff at a time.
IBM pioneered remote work in 1979. It took them nearly forty years to decide it was a mistake, and another three to change their minds again. The question isn’t whether your company will go through this cycle. The question is whether you’ll be honest about the costs each time the pendulum swings — or whether you’ll just write a memo with the subject line “It’s time for Act II: WINNING!” and pretend you’ve solved it.
Now, if you’ll excuse me, I need to go sit next to the team that owns the service we’ve been trying to coordinate with over Slack for three weeks. Turns out the fastest protocol is still shoe leather.