The Floor Plan Is Your First Architecture Decision

It was 10:47 on a Tuesday when I noticed her. A junior engineer, two desks down from me, staring at Slack with the particular stillness of someone willing a green dot to turn into a reply. Her Thai iced tea was sweating onto the desk next to her elbow. I asked what she was working on. She told me she was waiting on the team in the row behind us — a team I could see over her shoulder, headphones on, less than ten metres away.

That gap — between the people she needed and the channel she was using to reach them — is the entire post. It’s also one of the most expensive design decisions your organisation has made, and almost nobody treats it as a design decision at all.

The Decision Nobody Reviews

Most architecture decisions get a design review. They get RFCs. They get whiteboard sessions where someone draws boxes and someone else asks pointed questions about consistency guarantees. Then there’s the seating chart, which gets handed to someone in facilities with a spreadsheet of headcount and a cheerful request to “fit everyone in.”

That decision — who sits next to whom, who shares a kitchen, who’s within earshot of whom — will shape the information flow of your engineering organisation more than any service mesh, any internal wiki drive, any Slack channel naming convention. It is, in the strict sense, an architecture decision. It determines what is coupled to what, what information flows where, and what conversations happen at all. And we’re outsourcing it to a spreadsheet.

This post isn’t going to relitigate remote vs in-office. There’s a companion post for that, and there’s plenty of noise on it elsewhere. The argument here is narrower and a lot less contested: wherever and whenever your engineers are physically together, the floor plan they sit in is itself a design decision. Pick the couplings you want. Pick the ones you’re willing to break. Treat the seating chart like architecture, because it is.

“We shape our buildings; thereafter they shape us.”* — Winston Churchill, House of Commons rebuilding debate, 28 October 1943*

Churchill was arguing for rebuilding the bombed Commons chamber in its original cramped, adversarial shape — because the shape, he said, had produced the British two-party system. The chamber was too small to hold all the MPs. The benches faced each other. You couldn’t slip in unnoticed; you had to physically cross the floor to change sides. The architecture was producing the politics. The same logic applies to your engineering floor. You picked a layout. The layout is now picking how your engineers work.

The Snacks Engineer

A few months ago I was talking to one of our engineers about a team he kept running into for code reviews. The team was always slammed — heads-down work, calendars full, the usual. But this engineer’s PRs kept getting merged faster than anyone else’s. So I asked him how.

“I just walk over,” he said. “Sometimes they’re not free, so I wait at a desk nearby until they are.”

I was a little surprised. “Don’t they find that intimidating? You just sitting there?”

He grinned. “No — because I bring them snacks. I’m nice about it.”

That’s the entire post in one anecdote. Not a productivity hack. Not a process. A guy with a packet of orange Kit Kats from someone’s last Japan trip, walking over, waiting politely, getting his PR reviewed in twenty minutes when the Slack version would have been a day. Multiply that by a thousand interactions a year across a hundred engineers, and you’ve quietly redesigned how your organisation moves.

The Slack version isn’t slower because Slack is bad. Slack is fine. Teams is, well, less fine — but you knew that. Whatever your tool of choice is, that’s not the problem. The problem is that asynchronous communication has a built-in tax that synchronous communication doesn’t, and that tax compounds across every interaction in every day in every team. Walk over once and you save twenty minutes. Walk over a hundred times — politely, with snacks — and you’ve outpaced the team that’s still typing.

The Allen Curve, or: Why “Just Slack Them” Is a Lie

In the late 1970s, an MIT professor named Thomas J. Allen did the experiment most engineering leaders have never heard of. He measured how often engineers communicated as a function of how far apart their desks were. The result was an exponential decay: engineers two metres apart communicated four times more often than engineers twenty metres apart. At fifty metres, weekly communication had effectively collapsed. On a different floor or in a different building, they almost never communicated at all.

The natural objection is the obvious one — and it’s the assumption this post is pushing back on: “That was the 1970s. We have Slack now. Email. Teams. Zoom. The internet. The tools have replaced presence.”

They have not. Allen ran follow-ups in the 2000s and the curve still held — and crucially, all communication channels decayed with distance, not just face-to-face. Phone, email, video — all of them. The richer your in-person relationship, the more you also use the digital channels. Out of sight, out of mind, on every channel, not just the in-person one. The tools didn’t replace proximity; they amplified the relationships that proximity already produced. Your most-DM’d colleagues are also the ones you sat near, ate with, ran into at the kitchen. Take the proximity away, and the digital channel slowly atrophies too.

A 2013 University of Michigan study put numbers on the modern version. Researchers in the same building were 33% more likely to collaborate than those in different buildings. Researchers on the same floor were 57% more likely than those on different floors. Same internet. Same email. Same video tools. The floor plan is still doing the work.

This is the part that’s hard for engineering leaders to internalise: the seating chart builds a second org chart, running in parallel to the official one. Your reporting lines are still the reporting lines — they decide who you escalate to, who reviews your performance, who owns the team’s outcomes. But your real day-to-day communication paths are a function of where people sit, not of who technically reports to whom. Conway’s Law says your software will mirror your communication structure. Your communication structure is the parallel org chart, the one you didn’t draw, the one that runs on proximity. So the floor plan is, transitively, helping to design your software.

Which is why treating the seating chart as a logistics question is the quiet failure most engineering organisations make. When facilities sends the seat map for the new floor and a manager forwards it to the team for “any concerns,” that’s not a process — that’s outsourcing the architecture. The tools-replace-presence assumption is what makes that outsourcing feel safe: if Slack is doing the real work, who cares where the desks go? But the data has been clear since the late 1970s. The desks are doing the real work. The tools are a top-up.

What Co-location Actually Buys You

Be concrete for a second about what you lose when you lose proximity. The traditional phrase is “water cooler conversations” — fine, but that understates it. Here’s a less polite version of the list.

The pattern: proximity creates a steady drip of low-cost information flow that nobody planned, nobody scheduled, and nobody can replicate in a tool. The Slack equivalent of “overhearing the next team’s standup” is reading their channel — except nobody actually reads other teams’ channels, because there are forty of them and the signal-to-noise is dreadful. So the information doesn’t transfer. The team next door ships something you should have known about, and you find out three weeks later in a stakeholder meeting where someone says it like it’s old news.

The Gemba walk deserves its own paragraph. The Lean tradition uses the term for factory floors: go to the place where the work happens, observe, ask. In an engineering org, it’s the senior engineer or manager who walks up to people’s desks and just asks: what are you working on, and what’s blocking you? The information you get from fifteen minutes of that is information you would never get from a status report.

I do this regularly, and the pattern is consistent. I’ve sat down with engineers and uncovered issues with testing frameworks that were hard to use and slowing the team down — issues that had never been escalated. I’ve found patterns of last-minute requests from supporting teams that nobody had thought to raise as a systemic problem. The list goes on. None of these would have come up in a standup. Standups are about what you’re doing today, not about the recurring friction that’s been quietly costing you a day a week for six months. None of these would have come up in a retro either, because retros tend to surface the acute — the thing that broke this sprint — rather than the chronic — the thing that’s always slightly broken and that everyone has learned to work around.

You can’t really do this on Teams. Or you can, but it lands differently. A drive-by question at someone’s desk is conversational. The same question in a DM is an interrogation.

The corollary to the Gemba walk is the kitchen test. When I haven’t seen someone in a while, I always lead with: working on anything interesting lately? It sounds like small talk. It’s not. The question gives them permission to talk about what they actually care about — which is almost always also what they’re stuck on, what they’re proud of, or what they wish someone else knew about. Many times in large organisations, two teams are solving the same problem in isolation, and neither knows the other exists. The kitchen conversation surfaces those overlaps more often than not.

There is no Slack channel for “interesting things people are working on that you should know about.” There can’t be. The moment you create one, it becomes another channel nobody reads. The kitchen, for as long as engineers go there, is the channel.

The Pixar Principle: Designing for Collisions

Some leaders intuited all of this before the data caught up. Steve Jobs is the canonical example, and the Pixar building is the canonical artefact.

When Pixar moved to its Emeryville campus in the late 1990s, the original design separated computer scientists, animators, and editors into three buildings. Jobs killed it. He insisted on one building, with a giant central atrium — and then, infamously, put the cafeteria, the mailboxes, the meeting rooms, and (most insidiously) the only bathrooms inside that atrium. People had to come to the centre. People had to bump into each other. John Lasseter’s verdict afterwards was unequivocal: he’d never seen a building that produced collaboration like that one.

The design principle: proximity by accident is unreliable; proximity by design is leverage. Jobs didn’t trust serendipity. He engineered the floor plan so that serendipity was the default outcome.

For most of us, the takeaway isn’t “build an atrium.” We aren’t designing buildings. The takeaway is the disposition: the seating chart is a forcing function. Use it. Two teams that need to integrate? Sit them together. A platform team that’s drifting from its consumers? Put them next to a consumer team. A new hire who needs to absorb culture? Don’t put them on the empty desk in the corner — put them in the middle of the noisiest, most opinionated team you have.

There’s a related insight from a different field. Jane Jacobs, writing about cities in 1961, argued that street safety came from “eyes on the street” — the casual, ambient awareness of residents and shopkeepers going about their daily business. The principle generalises beyond cities: public visibility is its own coordinating mechanism. When you can see what’s happening, you act on what you see. When you can’t, you don’t.

In an engineering office, eyes on the street is the manager who notices a junior engineer staring at the same stack trace for forty minutes and walks over. It’s the senior who sees a whiteboard sketch on the way back from lunch and goes wait, that’s wrong, here’s why. It’s the architect-equivalent — at Agoda we don’t have architects, just engineers, but the same role exists informally — who walks past a cluster of people arguing and joins the conversation uninvited because the conversation is important. None of this happens on Slack, because Slack hides everything that isn’t explicitly shared. The kitchen, the desk pod, the open floor — those are streets. Eyes on them produce coordination at no cost.

Our level 6 in Bangkok is not Pixar’s atrium, and I’m not going to pretend it is. But the mechanic is the same: when teams sit close enough that walking over is cheaper than messaging, the conversations that matter happen on the way to the kitchen instead of three days later in a calendar invite.

The Loud Team and the Quiet Team

A few years ago I had a team that was very collaborative. They worked out loud — and I mean genuinely out loud, not metaphorically. Throughout the day you’d hear them. Not the whole team at once, but at any given moment at least two of them would be pairing for an hour, or talking through the current piece of work to align on approach, or sorting out a merge conflict at someone’s desk. They were all working towards the same goal, and the conversations were about the work. The talking was the working.

When we shuffled the floor plan, they ended up next to a team from a different department who happened to be working on a closely related problem.

The other team had a completely different working style. They sat quietly at their desks all day, headphones on, world shut out. Both teams were good. Both teams shipped. But the seating arrangement produced a specific kind of complaint — the quiet team kept telling me the loud team was disturbing them. Couldn’t focus. Too noisy. Could we move them?

We didn’t move them. The loud team won.

That sounds harsh, so let me explain why. Software engineering is a collaborative endeavour. If you’re sitting on your own all day with headphones on, deeply focused, you are also building in isolation. Less feedback. Fewer eyes. Less informal pressure-testing of your assumptions. The code that comes out the other end is more likely to have blind spots — not because the engineers are worse, but because the working style produces a worse coverage pattern. The collaborative team was, by accident of how they worked, doing constant peer review just by being audible to each other. This connects to a thread we’ve pulled on before in Code Entropy: The Silent Killer of Engineering Velocity — entropy grows fastest where there are fewer eyes on it.

What happened next is the part I didn’t expect. Over time — not weeks, more like a quarter — the quiet team caught on. They started picking up some of the louder team’s habits. Talking through problems. Pulling each other into conversations. Working with at least one ear on the room rather than two ears in a hoodie. They didn’t become a different team. They just became a team with more open channels. And their work got better. The complaints stopped not because the loud team got quieter, but because the quiet team realised they’d been missing something.

The lesson isn’t that loud teams are better or quiet teams are wrong. Some work genuinely needs deep focus, and noise-cancelling headphones are a real productivity tool. The lesson is that the seating arrangement made a working style visible that hadn’t been visible before, and the comparison taught the quieter team something they couldn’t have learned in isolation. Sometimes the floor plan should be deliberately uncomfortable, because the discomfort is where the upgrade happens.

When You Can’t Co-locate Every Day, Co-locate Hard for a Week

The point of this post isn’t that everyone should be in the office every day. That argument lives in the companion post and isn’t worth relitigating here. The more interesting question is the constructive one: when full-time co-location isn’t on the table — distributed teams, external partners, hybrid policies, four offices in three countries — what do you do?

The answer we’ve found is the acceleration week: a short, deliberate, intensive burst of full co-location aimed at a specific problem. Not an offsite. Not a hackathon. A working week with people who normally don’t share a floor, in the same room, on the same problem, with all the boring daily structure that real work requires.

A recent one. We brought eight engineers from three external companies to Bangkok to work alongside fifteen of our own — twenty-five people total, five days, in the same room. The trigger was a serious production incident that had landed earlier in the week, in exactly the area the visiting engineers were already coming to work on. By Friday, the legacy architecture behind the incident had been replaced with something safer, and a stack of long-pending merge requests had finally landed.

The numbers aren’t the point. The rate is. One of the engineering managers put it cleanly afterwards: if we hadn’t done this, the migration probably would have lasted a year. All of those problems we solved right away. Otherwise that becomes communication on Slack, and a reply maybe next week, because we’re busy or they’re busy.

That’s the entire economic argument for acceleration weeks in one sentence. A year of intermittent Slack-and-meeting work, compressed into five days of focused, high-bandwidth collaboration — because the cost of asking a question dropped to zero and the cost of context-switching dropped with it. A senior engineer described what made it different: normally, day to day, I’m doing ten things at a time and nothing gets done. This kind of stuff is really good productivity.

A few mechanics worth naming, because the format is reproducible:

Three stand-ups a day, not one. When work moves at compressed-time speed, you need to re-sync more often. Twice a day at minimum, three when things are flying. Catered meals, deliberately — people stay together, lunch is not a break from the work, it’s where half the cross-pollination happens. The kitchen test, applied to a hotel ballroom. Pre-share the context two weeks ahead — architecture overviews, tooling guides, reading material. The first day shouldn’t be onboarding. Invite the supporting teams from day one — infra, security, on-call — because the bottleneck on day three is always the team you didn’t invite. And accept productive discomfort. One of the visiting engineers nailed it: you kind of have to be comfortable being uncomfortable. The looseness around the planning is why you’re able to find the problem, get the people, and tackle it — because there’s no set scope. Tightly-scoped weeks produce tightly-scoped outputs. The good ones leave room for the problem to define itself.

The most telling quote came from one of our own engineers. Not pitching the format. Just describing what it felt like:

This is more what it used to be like in Agoda when I first got here, because everyone was in the office. Everyone in our department was on level six, and we only took up half the level, so you could see everyone from one end. It’s much easier to get stuff done. If you’re waiting for a code review, you wouldn’t use the PR bot to ping someone on Slack. You’d go and sit down at the desk and say ‘hey, can you do this code review for me? I’m waiting.’

The acceleration week didn’t invent a new mode of working. It rebuilt, briefly, the working environment that produced casual collaboration in the first place — and reminded everyone in the room what that mode actually feels like. Proximity is a tool, and tools can be used at different cadences. When the floor plan can give you proximity full-time, design it well. When it can’t, design the intensive that gives you proximity in a burst. The mechanic underneath is the same — put the people in a room, make asking a question free, watch what happens to the rate of progress.

The Generational Gap

There’s a careful version of the next point and a lazy version. The lazy version is kids these days don’t know how to work in an office, which is wrong, condescending, and unhelpful. The accurate version is harder to say but worth saying: this is a real generational gap, and it goes deeper than office culture.

Engineers who started their careers in 2020, 2021, or 2022 worked entirely remote during the formative period when most people pick up the unwritten rules of how work works in person. They didn’t get to watch a senior engineer push back from the desk, walk twenty metres, and end a Slack thread that had been spinning for three hours. They didn’t get to see how someone reads the room before interrupting. They didn’t develop the muscle for the bounded, polite, in-person ask. None of this is a character failing. It’s a missing chapter in their working education, and it has to be backfilled the way any missing chapter does — by being taught.

Which brings me back to the engineer at the start of this post.

I stopped by and asked what she was working on. She told me she was waiting on a reply. I looked over at the team — same room, same floor, less than ten metres. I asked her: why don’t you just go talk to them?

Her answer was kind, not lazy. I don’t want to bother them.

That sentence captures the gap in one line. She didn’t think she’d be turned away. She didn’t think they’d be rude. She just hadn’t internalised that walking over isn’t an imposition — it’s the normal way engineers work in person, and it’s almost always faster, lower-friction, and counterintuitively less disruptive than a Slack message that pings someone out of focus mid-task. A walk-over is bounded: it ends when the conversation ends. A chat thread is open-ended — it pings, gets ignored, gets replied to two hours later, gets clarified, gets clarified again, and consumes everyone’s attention in fragments.

I told her — gently, because the fear of bothering people is genuine and considerate, not a fault — that for this kind of question, walking over is the right move. We talked through how to do it. Catch their eye first. Ask if it’s a good moment. Keep it short. Leave when it’s done. The skills of the walk-over. None of them are obvious. All of them have to be modelled.

For leaders, this is a teaching problem. Engineers who started remote will not magically learn office culture by being put in an office, any more than a kid who missed two years of in-person school catches up just by being back in a classroom. They have to be coached, deliberately, by the senior engineers who do remember the rhythms. That coaching is a real responsibility, and it’s not optional. The skill is real, it can be taught, and it has to be taught — because the alternative is a workforce that never developed the muscle and an organisation that never figures out why its best ideas don’t propagate.

“The single biggest problem in communication is the illusion that it has taken place.”* — George Bernard Shaw*

Shaw was being witty about Edwardian dinner parties. He could have been describing the Slack thread that ended in thanks, makes sense when neither party actually understood the other.

The Manager’s Floor Plan Playbook

A few opinions, sharpened.

Sit teams together that need to integrate. The frontend team and the backend team for the same product. The platform team and its biggest consumer. The two teams whose services have the most cross-team API calls. If they need to talk every day, stop making them schedule it.

Sit teams apart that you want to evolve independently. This is the less-obvious application. If two teams need to make different architectural choices, putting them together can produce harmful coupling. They start adopting each other’s conventions, and the system loses the diversity that lets it experiment. Sometimes distance is what you want.

Walk the floor. Gemba is not a workshop. It’s a habit. Twice a day, walk through the area where your engineers sit. Don’t aim for anyone. Let yourself notice what’s happening. Ask what people are working on. The information you’ll get in fifteen minutes of walking is information you would never get from a status report.

Treat seating changes as architecture reviews. When facilities sends you the seating chart for the new floor, don’t approve it as a logistics question. Read it as a system design. What does this proximity create? What does it break? What’s the new Conway’s-Law-implied software architecture? If you can’t answer those questions, you’re outsourcing your architecture to facilities.

Build for collisions, not for quiet. Open-plan offices are unpopular for good reasons — they’re noisy, they break focus work, they cost more in headphones than they save in real estate. But the collision benefit is real. The right design is hybrid: focused desk pods for deep work, plus shared spaces — kitchens, big monitors on walls, sofas, whiteboards — where collisions happen. Pixar’s atrium is the maximalist version. The minimalist version is make sure two teams have to walk past each other to get coffee.

Coach the walk-over. For engineers who started remote, the skill of going to someone’s desk doesn’t exist yet. Name it. Model it. Tell them, when they’re stuck waiting on a Slack reply: go talk to them. Bring snacks if you’re worried about being a bother. Make it explicit that this isn’t bothering people. This is how the work is actually supposed to flow.

The Question That Cuts Through Everything

When you’re deciding where someone should sit, ask yourself one question:

What conversations do I want to happen by accident?

Then put those people near each other. The conversations you have to schedule are the conversations that are too expensive to happen often. The conversations that happen by accident are the ones that compound. Pick which is which, and seat accordingly.

“There must be eyes upon the street, eyes belonging to those we might call the natural proprietors of the street.”* — Jane Jacobs, The Death and Life of Great American Cities (1961)*

Jacobs was writing about urban safety. The principle generalises to any environment where coordination matters and full surveillance isn’t an option. Visibility is the cheapest coordinating mechanism humans have ever invented. Engineers in line of sight of their colleagues coordinate by accident. Engineers behind walls and time zones coordinate by meeting. The first is free. The second is not.

Now, if you’ll excuse me, I need to go find an engineer on level 6 who’s been waiting two days for a code review from someone sitting fifteen metres away. He has Slacked them three times. They’re heads-down with headphones on. I’m going to walk him over there. I’ll bring snacks. I’m nice about it.