Open-plan offices must die
mattrogish.com
mattrogish.com
1) Cube Farms in large corps 2) Private offices for everyone in a startup founded by Microsoft alumni. 3) Team Rooms of 3-5 people max. 4) Large open areas with no cube walls at all. 5) Working from home (what I do right now)
Based on this experience, I think the optimal solution is the 3-5 person team room. It works well because it allows for a high degree of collaboration while keeping folks outside the team at arms length to limit distraction. In this environment, we shipped a working product written from scratch within 3 months.
Open plan offices were by far the single most distracting environment. Ironically, I was at the same company when we switched from a 3 person team room to an open floor plan to cut costs. The productivity hit was enormous.
Cube farms are actually better than open floor plans. They're far less impressive and drab, but the cube walls serve as a minor barrier to interruption since they require getting up and walking to make eye contact.
Working from home is great for productivity as a single programmer, but collaboration is more of a challenge, and it requires solid leadership capable of defining problems very clearly and staying focused. That's a tall order for most startups where the ground is constantly shifting.
Private offices were great for a single programmer working on a well defined problem, but difficult to foster the right collaborative environment. It's hard to institute concepts like pair programming and code review under this setup.
Going from this to a cube farm or an isolated office seems depressing in comparison.
Being in individual offices doesn't necessarily mean being isolated to an extreme degree. As long as people choose to keep their doors open more often than not (in my experience, most people do) and as long as the team members who work together are physically located near each other, it's not - in my experience - a bad thing at all. In fact, assuming that people are given offices that are large enough to fit 2-3 people and are outfitted with guest chairs, it's no uncommon for 1-3 people who need to "huddle up" to do so in one of their respective offices.
The difference between this and trying to encourage collaboration through "open plan" is that when somebody needs isolation it's easy to get, and the huddles are on-demand and last as long as needed and no longer.
The other advantage to this is that small meetings can just take place in one individual's office, saving dedicated conference rooms for larger groups.
So you had the inertia effect AND a less productive work environment. I wonder if there is anything out there about the productivity lost during a move.
Our own team's cohesiveness deteriorated as we all went into headphone mode and communication was slower among ourselves.
I cannot even begin to imagine how anybody could find that desirable. 3-5 people in one room? So you still get distractions, lack of privacy, and the room will probably be too damn hot more often than not (some companies get this part right, most don't in my experience)... and unless you entire team is those 3-5 people, you still don't get the purported advantage of maximum ability to communicate and collaborate without having to get up and walk somewhere. This actually sounds like the worst of all worlds to me.
Then again, I'm strongly biased towards the belief that programmers should have private offices with doors that close.
-The team decides the furniture layout.
-The team members don't have to be on the same project, but they should perform similar functions. Don't put the project managers in the same room as the developers!
-There should be ample meeting space separate from the group office space.
-The team needs someone who is senior enough to lead the group if they need rules on distractions and interruptions. For example, in one group office we sent questions to each other over IM even though we were literally elbow-to-elbow. In another group office, we talked almost constantly because we each brought specialized, non-intersecting knowledge to the project.
-The team doesn't last forever. When projects or people start to turn over, it's a good idea to re-form the groups.
(edit: list format looked terrible)
"hey, feature x.y.z is actually a pain, now that I look at it closely. Can I email scrap it?"
"scrapped. "
Way better than spending a couple of days working on it before a weekly checkup meeting.
Some teams may work more on a model where they just have to deliver X, where X is some high level business requirement.
In such circumstances it might not be unreasonable for the project manager to make decisions about which particular bells and whistles to include in the version 1 deliverable etc.
To me, it sounds like a false dichotomy to say that you either sit together and have rapid communication OR you sit apart and are forced to wait for a weekly checkup meeting... surely there's a continuum there??
While playing music on headphones can help block out conversations, it is still a distraction. It's just not as annoying as hearing other people talk.
I've worked in places where it was an issue. And it's a very difficult one to address. "Please be quieter" is much more socially acceptable than "Please use deodorant".
1. In private, tell the person "I don't think your deodorant is working well enough. Just thought you ought to know."
2. Go to their manager, and have the manager say pretty much the same thing, not mentioning that anyone but the manager noticed anything.
Almost anything else comes off as boorish.
An open room needs plenty of space.
I don't mind if it's done at moderate volume and is relevant to the work at hand. Indeed, I like those kinds of conversation to happen around me; the ambient information lets me have a better feel for how the project is going.
It's only when it's irrelevant or loud that I'd want headphones. So we just kick that kind of conversation out of the team room.
Team fit and cohesiveness become pretty critical in this setup. Ideally the team lead should sit with the team or close enough to run interference and provide air cover as needed.
The thing I like best about this is that I basically never have to wait for somebody to get back to me. Never having to check or write email for stuff that's more easily accomplished in person is awesome.
The thing I like best about this is that I basically never
have to wait for somebody to get back to me.
When it's another developer, there's an etiquette to it. Because we're in the same room, I generally know when they're focused, and will just wait a bit if it isn't urgent. You also have graduated options for interrupting. There are times when people get my attention just by looking at me, or turning towards me and waiting a moment. If somebody is in flow, they'll probably ignore that.
We also do test-driven development and a fair bit of pair programming, which makes distractions less problematic when they do happen.
I'd take an open plan office with sales people and managers screaming on the phone any day over my current situation!
Of course, the best choice would be my own office... we can all dream I guess.
At least with the open plan, you get what you see.
The idea behind the model is that small product or functional teams tend to need to talk at the same time, and therefore also tend to need 'flow' time at the same time. Breaking flow for the group is evil, hence separate space. Recongregating for a short chat between team members is evil, hence the coworking.
400 square feet is more than enough space for a brainstorming area as well as desks.
I personally hate to see a common pattern of developers with headphones on -- it means the tech teams are stressed in some way, and don't have enough flow time or personal space.
What? I can't work without them, regardless of my environment. I could be alone in a woods, coding, and I'd still need headphones/earbuds and music going to get my code on. That's been true for over a decade and I've even tried to break the habit.
+---------+---------+
| | |
| | |
+-----+ -+- +-----+
| |
| | | |
+-----+ +-----+
| | | |
| |
+-----+ +-----+
| | | |
| |
+-------| |-------+
The bottom and middle side rooms are private offices. They should have doors that close and be reasonably insulated from sound, so that a worker can work without disturbance when they want to. Ideally, the wall wall facing the central area should have a big window (with drapes or blinds!) so that the person in the office can see if anything interesting is going on in the central area. Each office should have its own light switch capable of turning off all lights in that office.
The top two rooms can be bigger offices, or conference rooms, or break rooms for breaks that might be too noisy in the central area.
The break in the bottom wall is the connection to the hallway.
With this environment, you can easily work in private, no distraction mode (go into your office, close the door, and close the blinds), or in full social mode (take your laptop to the middle area), or in between (work in your office, but leave the door and window open, so you can keep an ear and eye on what's going on in the social area.
Note that if you have two groups working on different things, but that have a manager or senior engineer working with both, you can extend this concept and put the two groups side by side, and shift and stretch one of the offices and make it connect to both groups, so that common manager's office is in both groups:
+---------+---------+---------+---------+
| | | | |
| | | | |
+-----+ -+- +-----+-----+ -+- +-----+
| | |
| | | | | | |
+-----+ +-----+-----+ +-----+
| | | | |
| | |
+-----+ +-----+-----+ +-----+
| | | | | | |
| | |
+-------| |-------+-------| |-------+It was like heaven. And I got a lot done, back then.
Bingo. It seems that so many people operate under the assumption that there is only one way to work (social or private). The truth is that some people tend to be more productive working mostly alone and others tend to be more productive spending most of their time in direct collaboration. Also, some tasks lend themselves to private, heads-down work and others lend themselves to group collaboration. An office environment needs to have the flexibility for this.
Any office setup that only allows for one style of work is bound to have problems.
I don't understand why there are so many blog posts describing how "X must die" or "Y is the only good approach to doing Z." If something works well for you, then that's wonderful! Please share it and explain the benefits and downsides and convince me to give Your Favorite Method a try. Describing how Your Favorite Method is actually The Only Reasonable Method (and by extension, that I am wrong/stupid/naive/etc. to be doing anything else) will rarely win me over.
Quite simply because this title:
"Open Plan Offices Must Die!"
is better link bait than
"Why I don't like Open Plan Offices".
Because they're click-bait. Authors of articles like that don't (primarily) care about making a sound argument. They care about attention.
And nothing will ever happen, it's a bad environment, but it's easy to set up, cheap and common everywhere. It still get the job done, though badly. You try to find a job with something better, but then you just chose to live with it, because it'd require different, worse sacrifices. That in turn sends a signal that it's in fact ok and working office plan. Is there a way out? I'd like to see a blogpost with this title, actually answering the question (preferably with something else than no).
For what it's worth, there are lots of successful companies that did fine with offices (Microsoft) and lots of companies that did fine with open spaces (Google).
I worked at LinkedIn while we moved through 3 office buildings. We had an open space, then cubicles/offices, and then an open space again (each layout decision was deliberate). Both layouts had their pros and their cons, and that's why I'm not a fan of blog posts that dismiss the other side completely. Office layout, like many other things, is not a problem with a one-size-fits-all solution.
Yup. You get less for less. Maybe that's a good compromise for some folks.
Certainly sometimes I want to go away and think by myself. I want that option, but not as the default.
If programmers don't work well together, then by Conway's Law neither will their code. Beyond that, batting ideas around is just more fun than playing the solitary genius - and produces more satisfying results.
The kind of open office I like, though, is one in which the people are all working on the same system. I agree that noise and interference from unrelated activity is a disaster. It's very simple: everything should be organized around the team.
This is the point that the "team office" plan tries to address. Everyone you want to talk to is in the same room, everyone from other departments, people on manager schedule, etc, is behind a closed door.
The noise is aweful, the distrubances are maximized, people walking all over the place, it is awkward when somebody comes to me and we dont have a place to talk other than right there - and thus distrub all my nearby collegues.
We have "cubes" for that, but cubes are too formal, you need almost an invite, and when you do, its too crowded inside, and then you are away from your workplace where you have all the stuff. Sure, bring your laptop, if you have one, the desk computers we have are not so easy to bring along.
The point is that complex enough software systems are beyond the capacity of a single person to build, and once you have a team, the team becomes the most important thing.
I really enjoyed the book, and the info about open plan offices was really interesting. I was previously a fan of the open plan, but now I think if I ever design another office, it would be common areas and offices that close.
Being able to shut your door for a few hours to crank stuff out is incredibly important. Being able to walk a few feet and collaborate is also incredibly important. They're not at odds.
It doesn't take rocket science to design a space that works. It takes something harder: Money, and the ability for non-engineers to listen to people who haven't been drinking the latest silver bullet kool-aid.
"People can't concentrate in noisy environments." How hard is that to get?
The music vs silence point, for example, is based on a tiny experiment with a small sample size. The kind of conclusions that are drawn from it in the book are a stretch.
My friends in Silicon Valley say it's because if a developer is any good they move out there. Quite simply that is just not true. They may be less reluctant to work for a startup, but those that will aren't being asked.
Sure, I'd be willing to work for a startup again. But relocation to SF would be a challenge, due to the difference in CoL, housing prices, and level of services.
There seems to be evidence that this is, at least statistically, true. There will of course be good developers in the Midwest. But when you combine the draw of the valley, with the fact that most of the best developers got to where they are by the interactions they have with other developers. Add in that the best programmers are driven by their trade, and highly likely to move to where they can get the best, most challenging problems. I could easily see this to be true.
Then, when most developers are hired by personal reference, how do you expect us to find these amazing developers hiding in the Midwest?
I don't really think you're trying and that was my point.
You're telling me the Midwest developers who move out to the Valley don't know a single great developer from back home who would jump to work for your startup as long as he could do it from home?
Sounds like you live in a bubble. There are tons of great developers who'd never move to San Francisco (family, personal preference etc), and I can interact with other great developers without leaving my city ... additionally, doing startups isn't the only interesting programming work to be done :D
Then, when most developers are hired by personal reference, how do you expect us to find these amazing developers hiding in the Midwest?
Maybe relying only on personal reference is doing it wrong then ;)
We try not to, but other forms of recruitment have thus far, returned less than stellar applicants. The only other luck we've had is actively seeking out people with projects in the same field. But that has mixed results also.
You may want to look into some remote development tools? I suggest Sococo, but I work there.
I'm always looking for more remote development tools, I'll check out Sococo, but any other suggestions.
I've also started several companies that were mostly or partially distributed. Getting funding for those is sometimes awkward depending on the investors. Most VCs in particular are pretty skeptical of remote work, especially if any of the founders are remote. Even VCs who have funded well known distributed companies tend to be a little hesitant.
Another issue is that later rounds of investment are really difficult if you don't have traction as the VCs will scrutinize everything you do that doesn't look normal, and distribution of people is apparently pretty off the charts.
YC is itself a good example. Everyone must co-locate to San Francisco at the same time. 500startups is the same way. At least in the case of incubators, the centralization is temporary, but I have no idea if there is pressure to co-locate post-YC. Perhaps someone who is post-YC can offer some similar experiences.
To that end, the (preferably open-plan) office is a set designed to demonstrate that "work is being done here" and everyone required to arrive at 9:00AM to type into their company provided computers during normal business hours are extras on the set.
I also find that face-to-face conversation and in-office team building are important aspects to build a solid company for a long time.
EDIT: Lack of sleep yields poor brain, eye, and hand coordination.
I understand that English is likely not your primary language. And no offense intended, but grammar does add substantially to clarity.
It's easier to be dismissive of people that you don't see on a daily basis.
I work in an open-plan office. I didn't realize it when I first started, but there's actually quite a bit of white noise from the HVAC system. Maybe it's the nature of white noise that it wasn't immediately apparent.
One day, about a month after I had started, someone changed the thermostat settings. The constant white noise shut off. In the silence, the sense of space of the office immediately changed. Every footstep on the loft floor was suddenly audible. All the design conversations and dev pairing suddenly seemed much nearer, the words much harder to ignore. It was like the office had shrunk.
We tried a few hours this way, and finally set the HVAC system back to how it had been, filling the office once again with a constant, hushing whoosh. The space was back to normal.
At least with the type of software we build, though, communication is absolutely critical, and it's amazing how much a difference of even 10 feet makes in the frequency with which people talk. The optimum layout for us is roughly 1 or 2 clusters of 4-6 desks per "pod" (i.e. a cross-functional team consisting of developers, product managers, and qa that are all working on the same area of the product). At that level, when people are talking about something, what they're talking about is almost always relevant to you, so it's not necessarily a distraction: they're talking about your code and your project, so it's a good thing that you can overhear and participate in the conversation if you wish. If you didn't hear those conversations, you'd be out of the loop. It's often better to be a little more distracted and all on the same page than have a team of 5 engineers plowing ahead in different directions.
That's a common conflation when talking about software engineering in general: it's not just how much you get done, it's what you get done. If you get a ton of work done on the wrong thing, you might feel really productive, but you're not actually creating any value. At least with our software, a high level of communication is necessary for most projects to ensure that everyone is on the same page and rowing in the same direction. When that communication breaks down, projects start to fail.
Your mileage may vary, of course, depending on the size of your team and the nature of what you're building. (And it goes without saying that a giant warehouse with desks arranged like an 1890's cloth factory is a terrible idea; you have to consider lines of sight, and acoustics, and other environmental things. Not all open plan offices are the same.) But this assumption that open plan offices have been "proven" to be sub-optimal flies in the face of plenty of empirical evidence from companies like mine that have used them very successfully.
However, your claim that this has worked "really well" for you "for basically the whole life of the company ... by whatever metric" is not "plenty of empirical evidence." It's anecdotal, and most importantly lacks a comparison to a different arrangement (a control). You have no idea if any of your chosen metrics (however debatable for team effectiveness) would be better for your current team in a different set-up.
I also disagree that just because the conversations people hear are about the product, constantly overhearing conversations is therefore productive. If you need everyone in the team to talk about every decision at all times, this is probably either brought on by too few conversations or a lacking framework for productive communication.
> If you didn't hear those conversations, you'd be out of the loop.
Why aren't you keeping track of decisions and new information formally, e.g. by e-mail? How do you keep employees functional after they get sick or go on a leave? If you have processes for that, then it is not absolutely essential to hear those conversations; employees can read the important stuff at the end of the day.
The hypothesis that Y is superior then becomes non-falsifiable: if someone doing Y fails, it wasn't because they did Y it must have been another factor, and if someone not doing Y succeeds, then they would have been better off doing Y. At some point, the argument becomes completely unhinged from any real-world experience.
So really, all I can say is: we have open-plan offices, and we've been successful/productive/kept employees happy, so clearly it is possible for open-plan offices to work. For someone that's convinced that open-plan offices can't possibly be a good idea, and who rejects other people's real-world experiences, what is there left to argue over? The hypothesis becomes non-falsifiable and there's no point talking about it.
To your point about conversations, when people are sick or on leave or working remotely those conversations don't happen and we suffer as a result. We haven't found any replacement for impromptu conversation, or for gaining knowledge through overhead conversations, and so on.
Just as a stupid example (though this sort of thing happens all the time), suppose Chris goes to ask Bob a question, and Alice is setting next to Bob. Bob thinks the answer is that you have to do A, but Bob's wrong, and Alice knows it: the right answer is now to do B. On top of that, Denise, who's also sitting there, hears the answer as well, and just learned something effectively by osmosis.
If Alice wasn't sitting there, able to hear the question, she wouldn't have jumped in, and Chris would have gotten the wrong answer and wasted hours or days doing the wrong thing. Denise also wouldn't be clued in to how things should work either. If Bob had a private office that Chris went to, or it was a one-off IM or phone call, you'd have the same problems. Did everyone get a little distracted by overhearing that conversation? Yes. But ultimately, that productivity hit was worth it, because Chris was saved a ton of time and Denise and Bob gained useful knowledge.
If you can convince people to use something like Campfire where they route all communication through such that people who are remote or momentarily absent are included, I think that can take the place of overhearing those conversations, but it's impossible (in my experience) to convince people to do that when they're working in the same building: people would rather just go chat face-to-face since it's much higher bandwidth than typing.
A better metric for this kind of research could be stress levels because they are significantly dependent on changes in physical working environments. Stress is affected by a number of other work factors, such as management, work/life balance and workload, but these can be measured and controlled for. The effects of stress on various performance outcomes are fairly well understood, so this relationship can be used in tandem with other variables to ensure that a change is having the hypothesized effect. Again, it's not simple, but it's far removed from having no comparison.
I wouldn't suggest using online communications for every decision, but rather recording the essence of each substantial conversation digitally. Tasking one person with sending an e-mail containing the conclusion of a discussion takes a fraction of the man-hours consumed by a conversation, especially if many people are frequently involved (which I still advocate against).
Further, summarizing by e-mail is an aid to people's memories, helps avoid miscommunication by establishing a mutual understanding, and chronicles decisions and progress for later review or lookup.
My boss was incredulous when I told him that his shiny new office environment that packed 30+ people into a 30x24 ft. space was the worst environment I'd ever worked in. He told me that they'd done this because people had complained that the office was too quiet. <sigh>.
[1] http://www.penny-arcade.com/report/editorial-article/where-t...
I must admit when you said "desk-on-wheels" my first thought was that it sounded like something from a Terry Gilliam movie.
The most critical thing is usually the customer and optimizing for the customer means doing things differently:
* having the developers take customer calls and help requests
* increasing the amount of time the developers spend understanding the users - in order to reduce the amount of irrelevelant work being done
* cultivating a culture of 'code not written'
Do you really think that cranking code is the most important thing your organisation does?
Developers tend to have the biggest ego and opinion in the room yet from time to time, they are also the ones who are clueless about the users or real-world scenarios.
But most developers don't feel this way. Forcing them to take support calls just to satisfy the boss' idea of how their ego should be adjusted just doesn't sound to me like something that's likely to be productive.
E.g., they may be working on a complex issue with a Support guy in over his head who has been reduced to relaying messages to "the developers". I'm happy to jump on such a call directly because it feels like it saves everyone time and running around.
But all companies with lots of users eventually develop layers of Support in place to shield their developers from potentially constant interrupts.
You need to take action to stop them folk coding as quick as...
Getting the customer to do it is as good a way as any.
* is the software borked?
* are the doco's borked?
* is the user community too poor/uninformed/unsupported to generate the answers without developer involvement
The devs are a key part of determining which of these things is the root cause. If they don't talk to the people who matter (the customers) how can they help solve the problems?
Almost overwhelmingly, our #1 customer request is new features closely followed by bug fixes. I enjoy talking to customers to help them with problems, but even when I had free reign to contact customers directly, I usually wrapped up conversation pretty quickly and cranked a new build for whatever the issue was.
I have spent plenty of time in customer calls with 4 or 5 other employees twiddling my thumbs, and I don't think the customer benefited much from my presence. Developer time with a customer really needs to be targeted to be valuable.
At least 80% of the time I spend is working on stuff that doesn't need a distraction.
wat.
Once a client knows that a developer will take calls, they will take advantage of it and try to get in new features and changes. There should be a layer between developers and clients. This helps the developers not get distracted or waste their time by explaining things that someone could do also (or better).
Yes, the developers should be aware of what the clients are having issues with or what features they want, but there should be a 'firewall' between developers and clients. Not all the time, but most of the time. The firewall can be imaginary, but the client needs to believe it exists.
But all developers should sometimes be on customer support - maybe 1 day a week, maybe more.
I think there should be both quiet isolation environments and communal lab-type environments in software companies. It's surprising to me how there is so much emphasis in hunkering down in one place and staying put.
Personally, I can cancel out most distractions by a large enough monitor and headphones, but get really awkward when someone is standing behind me or walking by. So I need to have my back to a wall, whether it's an open office or not.
I think we all do agree that offices without fixed desks are a big no-no. Some companies tried to do that a while ago, where you just have a cart with your stuff and work where you're needed (with thin clients way back when, and laptops a bit later). Yuck.
Granted, this would mostly apply to teams who are either very newbie-heavy or work on very small feature increments at a time - or both. And maybe some designers, but I'm not qualified to talk about that. For most other purposes, more isolated environments with a good tech solution for communication would be preferable (IRC, Basecamp, Jabbber etc.)
I'm curious why people feel this way. I've never worked in this kind of environment, but where I have worked, I've never actually had that much stuff at my desk or in the office. And I always felt like, while I could customize my workspace to work better for me, everything belonged to the company anyway so it would be silly to feel territorial about my workspace. Give me five minutes to adjust everything and I'd be ready to go at any desk.
Your point about "everything belongs to the company anyway" is basically the gist of it: If you're shuffled around too often, you yourself might feel like company property. I would say that this is true for the majority of people, just like most of them are prone to "homesteading". The nesting instinct is quite primal… (And in relation to the original point of this thread, familiar, interruption-less environments make it easier for most people to focus.)
One additional annoying point is the reason for this: Basically you've got two, either the one I mentioned above, where you've got a lot of empty offices due to consultants not in at all, or the company wants to turn everyone into in-house consultants. No fixed teams, quickly adding two new co-workers to a late project - we all know how well that works. Or one of the worst sins: Taking you out of your team because your job is done there for now, and instead of just idling along they'll just add you to another department, whether they need help or not.
Cost saving without mercy and regard to basic human nature. One might argue that it could work if you restrict yourself to those with a suitable psychological profile, but I bet this will only result in false "nomads" who are just trying to act that way to avoid losing a job (or to get it in the first place).
Having a heavy distraction-oriented work flow forces you into a mode where you segment your tasks as atomically as possible, for example using the pomodoro technique. There are certainly times when a quiet space is necessary, and I will retreat away from my desk to a library or quiet corner where I'm not near people.
I wonder how much of this is because I am young (24). My generation has grown up bombarded by distractions. So much so, in fact, that I find that there are equally many distractions inside of my computer as there are coming from the office plan.
It's when you try everything possible to shut out distractions (yes, including the Les Nessman tape on the floor, you older folk will know what I'm talking about) and it still doesn't work.
On a bad day, they could get interrupted by that thing 4 or 5 times! :-) They were typically big interruptions though, as it was considered quite rude not to give the other person your full attention pretty much for as long as they wanted it.
As with the article I agree that there should be some private space for programmers to work alone. Perhaps not 100% of the time but instead have the open plan aspect for communication and then a separate series of offices people can move to and close the door for some privacy. Not sure how well that'd work in some environments but it's something to think about.
Having worked in different arrangements, I must say that every developer having their own office with a closable door is really the most productive. Though I have seen very small close-knit teams work sitting around the same table together.
But most companies prefer to give the offices to managers and put software developers out in the cubes.
Offices aren't intended as workspace, they're intended as status symbols.
At my last job, I had a bigger windowier office than the CEO, and our company had millions in revenue.
In any case, it doesn't really bother me as long as I have the resources to get my work done. It's just an interesting observation.
Some of these factors are:
* Gathering the team in one place and ideally at the same time. Standup meetings do this, as well as catered breakfasts and lunches.
* Open spaces that provide ready access to other folks, engineers, designers, product owners. It's amazing how high the hurdle of having to get up and open a door can be and how amazing the cost of inferior decisions made by coders is when asking someone requires overcoming hurdles. Remember that the desired behavior must also be the easiest behavior.
* No employee-specific workstations. The easier it is to move around and the more common the computer setup the better collaboration can ensue.
* Subdued noise levels. This can be accomplished through white noise generators, Dj Tiesto, sound swallowing wall fabrics and carpets, etc.
* Systems that capture project data in structured ways, minimizing the need and role of email.
* Separate gathering spaces for socializing, ping pong, lunches, meetings, phone calls to not disturb the main work area.
* A prevailing practice of pair programming and TDD.
Interestingly, some of the most successful development shops like Pivotal Labs and Hashrocket do exactly that.
http://www.home-designing.com/2011/06/pixars-office-interior...
It is good to have a mix of spaces, but designing people's main work space to be a place for constant interruptions does seem to be a fundamental flaw. Breakout rooms and private spaces should be in the mix.
Each has its benefits. Open-plan offices shouldn't die, but people need to realize that they come with ups and downs.
They can provide a creative, collaborative and egalitarian studio like environment, again when executed well.
What they struggle with primarily is sound isolation, attenuation, and masking. Secondarily they struggle with visual and olfactory distractions.
Designing an open office to look like an Apple store is a mistake. Apple stores are designed to be lively and animated - there's a reason for all those hard surfaces, particularly the glass ceiling. That reason is that they reflect sound. There's also a reason coffee shops provide big overstuffed chairs and carpeted floors.
- cuts out distractions: you can only get distracted if you decide to talk with your office-mate. If either of us wants to chat with someone else, we move our discussion to a meeting room.
- avoids the isolation and slacking off that a single person per office setup generates.
- if office-mates are chosen intelligently, it can result in good collaboration for e.g. pairing a mentor with a junior programmer. A good idea would be to change the pairs every few months.
We're very collaborative, so being locked away in rooms would be a pain. We all sit together, but we reduce the pain of open-plan offices by being careful to minimize distraction. E.g., phone calls happen in other rooms. Meetings that don't involve the whole team go in the conference room.
I would also arrange the cubicles such that your back is never to the entrance. So you know when someone is walking into your space.
I worked in a very large dev office that was essentially a gigantic low-height cube farm and sound carried for-frigging-EVER - conversations 20m away may as well have been in your lap. Plus, if you happen to be taller sitting down than the wall height (as I was), then you also get the nice distraction of seeing developers and other worker bees shuffling around the place.
If you are in such a space, then yes, snagging a desk that does not expose your back to the entrance is key to maintaining some level of sanity. A better solution long-term is to find a less brain-damaged environment to work in.
My current job is at quite old building (70's) with a floor laid out like this, and it's just fantastic. I have enough space for some computers, a room I can work in in peace and quiet, and just enough space for small meetings and co-working when needed.
Any negative effects of being in a private office can be canceled by having office communicator, Yahoo! chat etc.
Typical 70's office buildings seem to often be laid out like this.
I understand -- you don't like open-plan offices, you don't think that they're an effective environment. That doesn't mean that they're universally terrible; it may work for some companies, and it may fail for others.
I'd love to have an office but I prefer open plans over cubicles.
In fact, the last company I worked at had hired way too young, and they had a bunch of kids who thought that being in your office writing code was somehow "Bad" because you were "siloed away". They liked to hang out all together at one big table, and chat away all day long with their laptops out.
In the time I was there, I don't think they ever realized they were getting nothing done. (I was curious as to whether they were onto something or not, so I tracked the number of stories and features they committed vs. me and my officemate who at 26 was the "old man" of the bunch, though still much younger than me he was old enough to know what flow was.)
Result: the two of us were about 4 times more productive than the 5 of them.
One of those five, though, was the "director of engineering" (20 years old) and was constantly chastising us for spending too much time in our offices.
When it became clear that this was going to affect my evaluation, I chose to exit that company. (They folded about a year later, never having accomplished the short term goal they were working on while I was there.)
But maybe I'm wrong. Maybe some people are more productive in groups of 2-3. That's fine. Set up offices for them to work that way.
Just let me have some damn peace and quiet so I can get work done! (and I never seem to have a problem hooking up with other engineers to talk about architecture or what have you to keep us coordinated, though often this is via email or chat... which is much less interrupting than a tap on the shoulder.)
-----------
On further thought-- maybe designers and people whose job is to sling HTML or javascript don't need to have "Flow". Maybe the jobs for these people are light enough that there is no context switching cost or the cost is low. That's not the case for my work or my career. There's often a very large amount of stuff I need to track in my head... because I'm generally solving hard problems on the back end, rather than making UIs or web pages.
Sometimes. I work from home, so I'm mostly distraction free, but sometimes I need distractions to get the motivation flowing again. I think the perfect office would have the opportunity to work under many different environments, depending on your mood. Moderation is, like always, the key.
Getting a site to work in IE6, or designing a usable UI, is probably hard to do with constant interruptions.
What was that? Coding HTML or programming in javascript might not be as mentally hard (most of the time), but is just as much work as anything else.
So, what you did, was, you cut out a few words, removing all context, and then pretended like there was no context, and put words in my mouth implying I denigrated a certain type of work.
In short, you told a lie.
Disagree with me if you like. In fact, the whole point of that addendum was to acknowledge that some will disagree with me.
But lying about what I said like that? In an attempt to pretend like I said something offensive so you can be offended?
Childish.
If you'll read what I wrote, you'll notice that I was granting a possibility to the people who disagree with me about open plan office spaces-- and there are a number who have done this in this thread-- by saying that maybe for some types of work the interruptions are not as expensive.
Rather than accuse me of saying something I didn't say in an attempt to feel superior, and thus bring down the quality of hacker news (as seems to be the trend these days), you could have taken what I said, considered it in context and responded. Maybe I'm wrong, maybe designers need as much flow as programmers do.
If you want to backpedal, you actually have to take the pedals and run them backwards. Otherwise it's not effective.
Typical HN narcissism: it must be trivial if it's not what I'm doing.
In teaching we have various 'learning style' audits. A common one is the VARK profile
http://www.vark-learn.com/english/page.asp?p=questionnaire
Could you imagine what a 'preferred productive environment' questionnaire might look like? Would this help make sensible choices and slot people in to existing teams?
Frank Coffield and team evaluated the field some time ago. VARK was one of the few that they found had some merit. I find that a visual explanation can help some students over the 'textbook' verbal/arithmetical presentation. See
http://www.slideshare.net/keithpeter/reverse-percentages-a-v...
(Rendering oddly in Firefox, slideshare used to be so useful...)