[ChuckMcM]

I hope they also publish a follow-up after living in their new office for a year.

Specific things that I'm interested in:

1) How would folks relate the understanding of what is going on at the company now, and compared to before?

2) How do folks compare their effectiveness in getting things done for themselves? for others? as a group?

3) What is the one thing they would change?

When I joined NetApp it had just acquired a caching company, the original company had open plan, NetApp had offices. They kept the open plan for the caching employees for the transition and then offered anyone who wanted to move into an office or a cube that option. A number of people took them up on that offer.

In the non-open plan version the same people got less done and felt more out of touch than they had when they were open plan, but they enjoyed their work environment with an office more than they enjoyed the open plan space. From a company perspective it was clear that it was in the company's interest in doing open plan, and in the employee's interest it was better to do offices. Of course as an anecdote it provides no statistically valid data to the debate. But it left me with the questions above which, in a different experiment like Wildbit's I would love to have another data point.

[diek]

Can you quantify "got less done" in the non-open plan? Fewer projects?

My anecdotal data is that people in an open plan sling more code, but better architectural decisions that don't require as much rework down the line (and as a result smaller 'output') come from private offices.

[ChuckMcM]

That is a good quantitative question. The 'sling less code' is the metric I was using.

I would love to come up with a good architectural quality test that was more quantitative. I've got a script that can go count how many times a given function or module was rewritten but running that on our code base of a few million lines of code really doesn't correlate with a 'gut' feeling of good architecture or bad architecture. For example, the Blekko crawler has essentially been rewritten from first principles three times over the 7 years we've been doing this. Generally that was not a result of "bad architecture" so much as it was unknown unknowns, basically writing a crawler that can run unattended for weeks or months is a really complex and often subtly nuanced problem. And sometimes is clear that the rewrite was just because someone didn't understand how something originally worked and so re-implemented it in a more understandable way. What I'm getting to is that code "touches" are not the quantitative measure I'm looking for.

[cnagele]

These are great questions. I'll be sure to do a follow up post in a year and see where we are. I know that the biggest reward when we went from 100% remote to having an office was the feeling of being in touch with what was going on. It was also the spontaneous conversation. I am hoping we don't lose that.

It's actually the biggest reason why we have a chef prepared lunch. We found that it forces everyone out of their desks at one time to hang out as a team. We usually don't even talk about work, which is the way it should be.

The other assumption is that the break out rooms will become longer term project team rooms. So if a couple of people are working on a feature for a few weeks they can take over a room to focus together.

I can say for sure that being a remote team enabled us to work around a lot of these concerns. It's easy to feel isolated when you are remote, so we work hard to make sure all communication happens asynchronously or in chat, even if we are in the same room. We also use video a lot, and my hope is that we can use it even more in the new office with remote team members.