In Defense of the Open Plan Office Layout

Every so often some meme seems to fly around the internet (or at least around the parts that I tend to frequent) that explores some variant of “engineers need offices (or cubes) so they don’t get interrupted” or “physical proximity doesn’t matter.” Now, I’m a firm believer in the theory that if it works for you, keep doing it, and that different things work for different people, but it seems like plenty of people are not so charitable and assume that there’s one right way to do software development, and that what works for their team must be the right thing for everyone else as well.

Here at Guidewire, our development teams use an open plan layout, and we do it because it works for us. We’ve got clusters of desks all around our engineering floor, with developers, product managers, and QA all mixed together in small groups that we call “pods” which collectively form our application and platform teams. The company started with an open plan setup from the beginning, and we’ve been anti-cube on the development side from the very beginning, even going so far as to pay to disassemble and store the cubes that were already set up in our current offices when we moved in. At first the open plan takes a bit of getting used, but over the years I’ve really come to like it, and I really have a hard time imagining working another way.

In my opinion, communication is actually one of the hardest problems to solve in software development, at least once you have a team of any decent size where knowledge is spread across a number of individuals. That problem is magnified when you’re in an industry-specific business like we are, where the developers aren’t experts in the field the software is targeting. As a result, we have to rely on product managers and subject matter experts to make decisions about how features should work and what should be prioritized; while I might be able to make reasonable decisions for myself about how a feature of an e-mail client should work, since I use one all the time, I can’t on my own make reasonable decisions about how a policy administration system should function, and it’s important that I talk to someone who does know what to do. Furthermore, that communication channel needs to be high-bandwidth and constant: you can’t just decide on requirements up front and then go work for a month, because there are a million small decisions that need to be made every day and many of them should really be made by an expert and not arbitrarily by someone who isn’t an expert user of the system.

The communication between the other members of the development team is also critical, though. The QA team needs to know as much about the product as the product managers or the developers, and they need to be able to understand the customer perspective in order to properly exercise the features and to understand the design of the feature so they can know if what’s happen is correct and intentional. They need to be able to ask questions of the product managers and developers as they go, and they need to be looped in as even small-scale decisions are being made. The developers also need to talk to each other on any reasonably-sized system in order to share knowledge about areas of the code, transmit best practices, and help get each other unstuck.

A lot of failures of software projects are failures of communication. With a team of highly competent engineers, the chance that any one person will do anything catastrophically stupid in isolation is pretty much 0. If I go off to implement a hash table, I can pretty well make sure that the thing works before I hand it off to other people. The far, far more likely causes of failure lie on the boundaries between people: things don’t get done because of a communication breakdown where two people each thought the other person was doing it, or the wrong features get built because the developer didn’t understand the use cases and product direction, or the team can’t expand enough because there’s not enough knowledge sharing, or the features themselves are right but the work wasn’t prioritized correctly and too much time was spent on relatively inconsequential things. Mitigating most of those risks requires optimizing for communication between the right parties, and part of ensuring that communication happens is setting up the right environment.

An open office plan is one way to optimize for that kind of communication. It’s not the only way to do so, of course, but if you have the luxury of physical proximity it can work well. Physical proximity has another benefit as well: you develop better relationships with the people around you. Cubes and offices can be very isolating, depending on the environment, and simply being around the other people on your team tends to lead to better working relationships, which improves both the work environment and makes communication even better. If you talk with people a little bit all day, asking questions and brainstorming and making jokes, assuming you like those people it can lead to a really good work environment.

The most common concern I’ve heard about the open plan office is that it’s too easy to get distracted; that concern is usually then followed up with some reference to how it takes 15 minutes to achieve “flow” again after being interrupted, so if you’re interrupted just once per hour that kills 2 hours out of your daily productivity. Of course, with an open office with conversations going on all the time and the ease of asking questions of other people, we all must be getting interrupted all the time, right? How can we possibly get anything done? We must be killing ourselves! If only we all worked in splendid isolation in offices, with very rare, pre-arranged meetings to hash out details, we’d certainly be way more productive!

But the reality is, it doesn’t actually work out that way, at least not for me. It’s true that interrupting someone can remove them from “flow,” but not all interruptions are created equally, and not everyone is in a state of “flow” all the time anyway. But supposing even then that a five minute conversation does result in a 15 minute loss of productivity for the person being interrupted: even then, it’s worth it if that 5 minute conversation saves someone a couple of hours of fumbling around on their own (“don’t reinvent the wheel, I think Bob did something similar last month, so just go talk to him and see what he did”) or, even more dramatically, saves someone from several days of going off in the wrong direction on something. It’s very easy to feel productive when you’re just writing code, but it’s a poor measure of productivity if you’re doing stuff that doesn’t need to be done or doing it sub-optimally. Most people also eventually develop some strategy for dealing with the distractions: they wear headphones or earplugs much of the time, or they work remotely sometimes so they have fewer distractions. Techniques like pair programming also help reduce the impact of distractions; one member of the pair can answer questions while the other stays focused, and when the interrupted developer returns to the task at hand their partner can help them context switch back much more quickly.

I’m sure it’s also the case that some companies set up gigantic factory-like warehouse floors full of anonymous coder units that are conveniently herded together so they can be more easily lambasted en masse by some dictatorial manager . . . but that’s not exactly how we roll over here, and many companies like us choose open plans intentionally and thoughtfully because we really feel like it’s the best way for us to develop. Again, that’s not to say that this is the right thing for every team or every product, or that it’s the only way to do things. But it’s often a good way to do things, and it’s a well thought out way that’s intentionally set up to optimize for communication (and collegiality).

---