comment 0

In defence of open plan offices

Anil Dash, CEO of Fog Creek, recently criticised Apple on Medium for their mistake in housing their developers in an open plan office, despite $5 billion investment into their new campus. He makes his case – that open plan spaces are simply bad for concentration – eloquently, referencing the hugely influential Peopleware as a corroborating source. Unfortunately, he also misses the point.

Things open plan offices are good for – namely, collaboration and teamwork – are as important for software development as coding ‘flow’. Yes, a good developer can bash out hundreds of lines of quality code in a short space of time if you simply leave him alone – but what if he’s writing the wrong code in the first place? You may assume that the developer has a good specification and design to work from, but that’s usually a fallacy – requirements change, designs change, contexts change. That’s a big part of why modern development practices like Agile and Lean are so attractive – because they cope well with inevitable change.

In my most recent position at a startup, for example, I used to factor 30% time for scope creep and design change when planning a sprint. That might sound high. You might suggest that we plan things more rigorously – and yes, we did try that. Nobody liked it. Because it meant that the product team had to finish their work before the design team started and the design team had to finish their work before the development team started, and suddenly we had something that looked a lot like Waterfall and a 4 week feature became a 10 week one.

Jumping in and getting things done… well, gets things done. It’s also fun. When you’ve got design and product and operations and development all collaborating – and collaborating well – to build a great feature on a short timeline you get a kind of buzz. It’s hard to describe until you’ve experienced it. You’re not working particularly long hours – at least, we weren’t – but the hours that you are working are pretty intense, because you know that you’ve got to be smart about what you do. You have to make Decisions. You have to take Ownership. You have to work as a Team.

This sounds ephemeral. But my experience at Movebubble was that when we had a deadline, we worked together, got things done, and enjoyed ourselves. When we didn’t, we tended to get stuck into our own personal little worlds and drift along and the work that we did never felt quite so satisfying.

I think that a lot of this becomes harder if everybody is working in their own enclosed space. I can count multiple occasions in my last couple of jobs alone where I have either saved myself development time or spotted a quick win because I overheard a conversation between a project or product manager and one of the team, or the client, or somebody unrelated to the project.

At this point you might suggest that communication should have been better in the first place – well, actually, communication in all these cases was pretty good. Because the thing about an open plan office is that the stakeholder in question can have the conversation somewhere where I can listen if I want to but phase out if I don’t, which means she doesn’t need to be thinking all the time about what she needs to tell me and I can be an active participant in choosing how much communication I need.

If you don’t want to listen, put some headphones on. I code better to Kasabian anyway. Because yes, I agree, open plan offices can be distracting. But then, distractions can happen anywhere. I am writing this post in a home office with a closed door and my wife just walked in to gossip with me about a Whatsapp conversation she is having discussing whether to use a naughty word in the name of her feminist group. If I really wanted to avoid distraction, I suppose I could put a lock on the door – but that wouldn’t be great for my marriage. Instead, I simply tell her that I’m writing and I’d rather not be distracted.

In an office context, I tend to have agreements with my colleagues about how to approach me when I’m working. Generally, this boils down to ‘slack me first, if I’m free I will come over’. We apply this rule even when we are sitting next to each other. It’s a general rule, we’re not religious about it, but then, that’s the thing about judgement – you build a relationship with each colleague that lets you collaborate in a way that suits you both. Much like a marriage.

And if you’re incapable of working out a mutual working relationship with your colleague, then I suggest you have bigger problems. Joel, another advocate of private office space, gives a simplified example of two workers, Jeff and Mutt. Mutt interrupts Jeff and Jeff loses his flow. Yes, this could be solved by putting a wall between them. Or, alternatively, it could be solved by Jeff and Mutt having a conversation about interruptions and building a mutually respectful working relationship. You know, as adults do.

What if, in the example above, Mutt is a junior developer, fresh out of university or whatever academy he learned to code? What if he hasn’t learned to code and he’s just learning on the job? That is, after all, how I learned. Then, if there’s a wall between him and Jeff, that might be great for Jeff, but it’s not so great for Mutt. As a senior developer, I’ve found that an increasing part of my job is mentoring others and being reasonably available for them is important. And if you happen to work at a company that doesn’t take junior developers, then fine, but they have to learn somewhere.

One last point – it’s not just about collaboration within a team, either. I gave a talk at Cisco a few months ago, during a three-day conference for a number of their international staff on trying to foster a better working environment. The one bit of advice I gave there was to forge stronger lateral bonds between teams. If Jeff is in fact working in marketing and using some software that Mutt wrote and notices that a particular feature isn’t quite doing what it needs to, then he might want to talk to Mutt to change it. But in order to do so, he may need to talk to his manager, Jill, who might talk to her manager, Scott, who in turn might report it to tech support who then add it to a backlog that Mutt will see several months down the line if he’s lucky.

Alternatively, Jeff could talk to Mutt and Mutt could write a one line fix and deploy in a few minutes.

This isn’t my idea. It’s one popularised by books such as Lean Startup on the value of communication and teamwork in writing the right code, not just writing good code. Software development isn’t just about the developers. It’s not just about you. You may be smart and sometimes, yes, the managers should get our of your way and leave you to get on with it.

But smart people make mistakes too. Sometimes they are misinformed. Sometimes they lack all the information. Sometimes they just make bad decisions. Being in the thick of things isn’t always a bad thing and walling yourself in isn’t always a good one. Open plan offices aren’t without problems, but neither should they simply be dismissed.

Leave a Reply

Your email address will not be published. Required fields are marked *