Does that not just create silos though. So many things require cross-team working. If each team has its own private space then information bottlenecks will occur
You have to compare the cost of potential information bottlenecks with the cost of no deeper work being done at all. To combat the bottlenecks, just include shared spaces - a kitchen with a water cooler, a foosball table, a customary time where people go to lunch as a group. Serendipity will happen there, and workstations can be reclaimed as places for concentration.
The best approach I have seen is individual offices with shared collaboration areas nearby. People can do deep work by closing their office door. People can pair-program, have someone look over their code, have a private conversation etc by going to another's office without disturbing everyone else. The shared collaboration area allows for quick easy group discussion when helpful. In terms of preventing information bottlenecks, it is easy for someone in another team to walk by and ask a question of someone or run an idea by them without it being a big deal.
Maybe, i'm not convinced. In my experience social interactions in shared spaces like kitchens etc tend to be dominated by general niceties and non-work chat. Which is fine, obviously, but I don't think you get the benefits as when people working on similar stuff are physically proximate to one another in their workspace, and can get feedback on an idea they are working on now instantly from knowledgeable coworkers
> people working on similar stuff are physically proximate to one another in their workspace, and can get feedback on an idea they are working on now instantly from knowledgeable coworkers
Yeah, but the issue people arguing against open-space have, myself included, is that we explicitly don't want to have these interactions, at least not in unstructured form - because your request for feedback from me "now instantly" is actively preventing me from getting my work done.
It's just that, a request. You are not obliged to help people straight away if you are deeply engaged in something. In fact most people are polite enough to not ask if it's clear you are busy. But if you're not, having access to that immediacy is a real boon IMO.
It's a request, but just issuing a request to a developer in a state of deep focus stands a good chance of kicking them out of that focused state, ruining anywhere between half an hour and the rest of the day for them. So you need to be really mindful of the cost of just asking someone if they have time.
The usual solutions I've employed or been subjected to in the past are: 1) headphones on == no interruptions of any kind, 2) direct questions and requests to IM (with notifications off), and 3) if you need someone's repeated help during the day, then note your questions on a list, and agree on a period (e.g. every hour on the clock) when you and that someone will go over the list together. In my experience, 3) is magical, because once you start noting questions down instead of asking for help immediately, you'll discover that before the hour is up, you'll have answered most of your questions yourself.
I feel like you're being a bit precious. If someone asks you 'hey, can you help out with this', and you respond 'no not right now i'm busy', that knocks you out for half an hour to the rest of the day???
FWIW I'm a pretty independent worker and I agree people should try and work things out on their own before asking for help
It's not necessarily about having that happen once though. That can happen the many times throughout the day, and 2-3 interruptions in one day can be a lot. I think a lot of the point of not doing open-plan is to engineer an environment where it happens less often.
That being said, it's entirely possible that some tasks will require absolute focus and having a 2 minute conversation will legitimately lose you a large amount of productive time. There may also be a subset of people who are more likely to get these particular tasks, and those people will feel the negative effects of an open plan office much more than others working on more easily interruptible tasks.
Yes, it is that bad for some people. But most importantly, even if it meant "just" 5 minutes to get back into flow, you still have an organization that doesn't know how to share information and you have a manager that is crippling team productivity without even knowing.
> I agree people should try and work things out on their own before asking for help
That is far from ideal in two ways:
- knowledge sharing suffers. You do your research and solve your problem or you don't and you have to ask to someone else more experienced. Knowledge sharing is kept to an oral tradition. Teams quickly start depending on one or two key members and juniors are often with a feeling with being left alone.
- you still have this anxiety of "when is it okay to interrupt?" On both ends. Everyone's threshold is different, so there is always someone who will be annoyed by the interruption and suffer.
The way to fix this is by promoting collaboration (pair-programming sessions are great and both partners already expect the communication, so "flow" is easier to maintain, also it is terrible to do on open-floor plans) and having a clear written practice to share knowledge and documentation.
There is no single situation where an open plan office leads to more team and individual productivity.
In my experience, "Being able to be productive while not in The Zone" is a job skill like any other that can/should be learned and improved with practice. I used to be like that, where if you said peep to me while I was focused, I snapped out of it and couldn't work my way back up to productivity easily. This is kind of a "junior developer" problem that IMHO developers just need to overcome with practice. Having a kid helped me a lot. Suddenly there were distractions all day, and I was forced to learn how to be productive in 30 minute spurts.
As one gets more senior in their development career, their days will get more and more punctuated with meetings. You start gradually moving from the "maker" to "manager" schedule. So your reality will be a day with a handful of 1 hour time slots available for deep work. In my view you just need to deal with this reality and learn how to be productive in it.
>> Just like I can drive to my local mall without even thinking about it.
I have seen plenty of software that appears to have been written by someone who was 'not even thinking about it' and it is invariably problematic and expensive-to-maintain.
Do you really believe there are senior devs that are productive without even thinking about it?
That just strikes me as odd -- maybe they are working on stuff should be given to Juniors?
Yeah, after two kids I did manage to learn to deal better with interruptions, but I still feel a difference between "able to work" and "being in the zone". I am able to be interrupted in the middle of a list of actionable items and resume to it somewhat painlessly, but ask me to, e.g, plan a sprint or write a longer-term strategy doc and I will just wait until all the lights in the house (or office) are out.
I do disagree, however, about it being a problem related to lack of experience. It is good when someone can learn to handle interruptions, but it's even better when they don't have to. Handling interruptions and impediments are the main responsibility of a good manager, not of the developers.
