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).

9 Comments on “In Defense of the Open Plan Office Layout”

  1. Jonathan Wong says:

    I agree with Alan. I think the essence here is that it doesn’t matter how fast you develop if what you develop is wrong! The desire for isolation is essentially selfish. People who do this ultimately care only about meeting their goals, not the overall goals of their team or of the company. I can’t tell you how many times I’ve seen projects fail because everyone met their individual goals but failed to produce a product that worked!

  2. Jerry says:

    You do not state this, but I feel like I’ve heard this implicitly or explicitly from other people – You have to have an open floor plan and be physically close to the people that you work with in order for communication to work. That just isn’t true and it doesn’t scale. There are certainly a lot of times that I’ve had the benefit of overhearing things and getting involved in the discussion, but there are have also been times where I’ve felt beaten down by the chaos. (I don’t consider people coming to ask me questions a distraction, but I do consider the chaos to be a distraction. Yes, I know that I have a loud voice and can be part of the chaos.)

    We have issues with communication breaking down between groups that are around the corner. I find it hard to believe that the interior walls are playing much of a role in the communication issues. We shouldn’t start a new development center or hire someone new in another city, but we need to be able to deal with key contributors moving to a remote location for personal reasons, without sacrificing their ability to contribute.

    I’ve worked in environments where people had cubes or offices and didn’t communicate, but I was also the technical lead for a big project in one of those environments, where people did not sit within talking distance, and we delivered the feature on time, because we communicated.

  3. Noel Granin says:

    Alan, I’m guessing you’re a project manager, or maybe a team leader.

    Which means you’re already vastly more tolerant of interruptions, and generally more interested in interaction than people who do pure development.

    I simply can’t imagine going back to open plan after being able to achieve long periods of focus in my own office.

    When I walk into other offices where there are 2 or more people, I can literally see the person that I’m not speaking to start to tense up from the interruption.

    • Alan Keefer says:

      I’ve been working at Guidewire in an open plan layout for over eight years now, and only in the last three or so have I been in any sort of leadership position, and I’ve always avoided managerial responsibilities. I don’t doubt that most engineers don’t really like being interrupted, since I don’t really enjoy it myself, but I think that the overall productivity and collegiality benefits are well worth it. Of course even within Guidewire you’ll find a range of opinions on our layout; some people like it, some people tolerate it, and some people would prefer something else. I think that emprical evidence at least makes it relatively unarguable that it’s been pretty effective for us, however.

  4. Dan'l says:

    Data point: I’m a recent (<1 year) employee at Guidewire, and an individual contributor, not a manager. I was VERY dubious of the open plan when I started working here, but I've become a complete convert. I get interrupted now and then, but being able to approach people who have the information I need more than compensates for it. It helps that the people doing the interrupting are patient — "let me finish this line" or whatever is generally respected, and I've seen people wait silently for someone with their head down really concentrating.

    The result is that the various parts of the product — not just the parts of the software, but also things like documentation — are more tightly integrated than I've seen anywhere else.

  5. Taras says:

    I find that open layout facilitates communication quite a lot. We are currently spread over 3 buildings, and several floors, and communication levels drop as soon as you turn around the corner on the same floor.

    I personally prefer open plan, but when i need to really concentrate on something i just pop headphones on (or work from home). My main interruption is people asking questions though, not the noise.

  6. Ricky Barry says:

    I find if you allow for the ‘I’m wearing headphones which means I’m in the zone’ rule then you cover developers having uninterrupted time in an open plan environment.

  7. Marcus Ryu says:

    I agree with you whole-heartedly, Alan, if hypocritically — I spend virtually all my time in an office with the door frequently closed. The reason for this is that I am often on the phone or v-conference, which would be calamitously distracting for other people to have to overhear.

    I am sensitive to disruption, but I find that sensitivity is far greater when I am not really “lock-ed in” on what I’m working or thinking about. When I am engaged with the task at hand, I prefer the presence of others in the vicinity, especially when I need to consult them frequently.

  8. Jessie says:

    Very informative article, i am regular reader of your site.

    I noticed that your website is outranked by many other websites in google’s search results.
    You deserve to be in top ten. I know what can help
    you, search in google for:
    Omond’s tips outsource the work

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s