The Open Office Dilemma – Collaboration vs Working Side by Side

During the last 20 years, I worked in quite some companies, studied at universities, was self employed, worked full time remote and travelled a lot to customers. Currently, I do work in an environment where open office is a maxim and fully supported as this environment should encourage collaboration.

The Project Setup

I worked some days from home office but traveled most of the time to the customer. I slept in hotels a lot. When I was in a city where we had an office, usually Friday was “office day” where our team was not at the customer’s site.

We did have shared desks at the office, everybody had an pedestal and took the next free desk.  That was ok. We used the office day a lot to chitchat and to build up relationships with co-workers. We prepared for the week after, installed software, talked to to IT-support, went to lunch. Sometimes during the week we went to the office late so finish something we could not accomplish at the customers site. We stayed there late and had fun. When in the office it almost felt like a hackaton every time. Also managers and the CEOs worked that way. And the hours in the office it felt more like fetching up with your wo-corkers. Sometimes we run out of desks, so we went to a desk together. But this rarely did happen.

On the other side there was the customer’s site. These were just large project areas where a huge amount of workers tried to do things. At that time there were no meeting rooms for most of the projects I was involved. We just did the meetings and hinted down the project goals. As this job was exhausting, I did not care about the office, the project room and the open space. I never thought of “you could be more productive if not interrupted all the time” because he just chased down the project road.

In both cases there was a lot of collaboration. Within the companies offices it was like a family, we helped each other and were happy to see each other. At the customer’s site collaboration was formed due to the urgency of the projects. We where firefighters, stormtroopers and the emergency.  Why did it work that way? The project were ingeniously staffed. If these teams would have used offices, the probably would have moved to the hallway to work together. It was a team thing, though.

Everything worked, because it was a limited situation. Everybody was aware, that the projects will end. The situation will change with the next project. So you do not care that much. Also once you left the project, you are not interested much in its future. Also this sounds harsh, one has to face this.

The Team Room

Once I joined a high performing team in a SMB in the software development field. Their location was a team room, applying scrum , QA, ProductOwners and ScrumMaster did live in the same team room. With twenty people it was a crowded place. While doing pair programming, it was a noisy place as well. The setup was fair, tables were separated side by side. But one did not face the pair in front of the table as they have been separated by partitioning walls. Half of the tales have been empty. For bi-weekly sprints you worked on different places, however everybody had its own desk, drawers and so on. It was a fair environment and you felt home, even if it was noisy all the time.

At one point we had to perform deep thinking tasks that took several days and weeks. Major do overs and architectural changes. At that point some of os moved (still as pairs) to smaller rooms. for a limited time to get these tasks done. This was backed by the team as everybody did know, there tasks will not be done right if one is interrupted all the time. Still, other team members came over or you were sitting from time to time in the team room.

As this was not my preferred environment, it worked. The team room was fine, we delivered an unbelievable amount of output and the team played well together. There were a lot of offsite activities by the team members, and still, some years afterwards we meet every year to see each other.

In terms of collaboration, it was very good, as the team worked as such, but there also were individuals who did “their thing”. We had no phones at all, and did almost not use any e-mail. It was simply not necessary as everybody was colocated.

 The Team Lead in the Team Room Fail

Several years ago, I took part in establishing a new development team for a new product as a team lead. We got an small office with one meeting room, a team room and a separated office for the Product Manager and the CEO. First of all, we kicked the CEO out of this office and away from the neighborhood of the developers. Also my desk, which was placed right in front of the developer desks, was removed. I went to the separated office together with the PM. We had to talk a lot and spent a reasonable time  on the phone. I did a lot of PoCs which needed some deep thinking time. Sometimes I did this work from my home office.

The team on the other hand worked together similar as in the situation above. However, it was much more “civilized”. The team was only a fith of the size and everybody was a specialist in his field. Everybody got a huge amount of time for their work without interruptions. This team performed in an outstanding way and produced an awesome output within few months in a exorbitant rate of quality – after I removed my desk out of the team room.

The Virtual Team

When I joined Microsoft I think in 2004, I joined a overall virtual team. Quarterly meetings in a regional office with our managers and from time to time some events. How could one collaborate this way? To make it clear from the very beginning: This was one of the most freaking awesome teams I have ever been with. E-Mails was on a minimum but chatting was always present. I think my chat log where about a Gigabyte. We hacked technology like insane – – always linked to each other. Coordination with management was on a minimum. We had our goals and did everything to reach and regularly to beat them.

Even though we worked everybody for him- or herself, we collaborated in an outstanding manner. The most impressive memory to this team are our come togethers. They were half party half hackathon, there was no or little welcome and no goodby ceremony. We just met, worked and left with a simple, see you tomorrow – knowing we already talk in the chats half an hour from that point on.

At that point we had this idea of mobile blogging restricted to the size of a SMS. We pitched this idea to an Redmond based product manager who told us, this idea has no potential. A few years later, Twitter emerged. Also I do not remember the PM, I really do hope he regrets this moment, every day since then.

Collaboration in this team was on an unbelievable level. There was a goal for the entire team, not for a single member of it. Management played an overall role in this and still, one of our managers is a good friend of mine today.

The Remote Worker

In 2006, I joined Microsoft Research. At the very beginning as software developer as remote worker.  Over time the team grew. We had members from Russia, Spain, Italy, France, Germany, UK and the US. You know what? Collaboration was on a almost all the time high. We had simple rules for the code, few guidelines, a lot of automation and awesome team members. From time to time we met at conferences or events. On a irregular timebase we met in person in Cambridge, UK as flights were cheap to this location.

We used e-mail, chats and video phone calls. At this time Skype was not used, it was even banned, within Microsoft, so we fought to use it. We used almost every technology available. I was on a kind of 24/7 standby as you knew knew if you get a call from any country in the world. In fact I was once called in the middle of the night with the request to remote setup some demos as they were supposed to presented in front of Bill Gates. I did not kew about this until I got the call. So we fixed it. Another Sunday, I got a call from Redmond. It was my architect, telling me that he is preparing a demo for the next day and I broke the build. So I fixed it. Even I never switched off my phone, this was never really stressful. There were goals we worked on (and usually reached them) and there was a high level of collaboration. Again, the team was almost fully virtual.

The Office Day Fail

Right now, I am in product management role, doing a lot of in-house consultancy regarding enterprise architecture. My employer has an awesome policy of all work must be able to be performed from any place. And the same way we have shared desks and a clean desk policy. So far so good, but than again, there is this 20% home office rate as we do not have desks for all employees at the same time. We have open space offices or 8 open floors. Table groups of four everybody facing each other. The open space is supposed to encourage collaboration. However, everyday I see how many of my co-workers just work side-by-side rather than collaborating. E-Mails and Chats are on a all time high, Mails are written and read during meetings. There are many meetings. The places are crowded, it’s noisy and there are endless interruptions.

There is only little deep thinking you can perform. You are just interrupted that often. The most I was able to sit down 360 seconds before being interrupted and being asked “Do you have five minutes?”. I usually have 20 or more of them after such an interruption.

As there is no barrier as an office, the obstacle to interrupt someone is very low. This in fact does include myself as well. I do interrupt people way to often, which I do regret immediately afterwards.

I love being on the phone or doing Skype calls. I hate it in the office. There are thirty co-workers sitting in your neck. Also I do perform really bad in negotiations in an open space. Behind a door – I do really good I think. I just do not want to bother my co-workers to much. It happened to me that I went to a  toilet to do a Skype call for a negotiation just for having some privacy – and to say things only to be said… behind closed doors.

I don’t know how much I perform in open space in terms of coding and architectural decisions. Creativity drops down to a minimum when being afraid of being interrupted any second. On the other hand I come to the office every morning with new ideas. After sitting just for one or two hours in the evening without being interrupted.

My mails suck. Even though I try to avoid writing e-mails, I happens more than once to me that in the middle of the progress of writing, I was interrupted. Once the interruption was over, and the next interruption just queued up, I accidentally sent the mail. With an unfinished sentence in the middle of the unfinished mail.

When I try to write some code (mostly PoCs or demos nowadays) it takes ages. I either do it before the majority of co-workers arrives or later, when most of them have left.

I take my mandatory home office day. I usually get more intellectual work done during this day than in the rest for the week.

Without exact measurements, I feel like in a disruptive environment, I only perform 25% of what I could achieve otherwise.

If I look at the team, everybody works side by side. Almost no collaboration. Excessive usage of communication tool for remote communication and ticketing systems are utilized rather than collaborating.

Is it Only Me?

I wondered if this only for me. No one seems to have an issue with this. Everybody seems to be happy, beside me. Until a few weeks ago.

Two co-workers told me, that If I want to get something done in code, I should join there every-evening.-coding session. So they set up a Skype conference for one or two hours almost every evening where they actually do the new things.

Another co-worker came by with an awesome presentation. He did an overall comparison of platforms. He showed it to us, and showed us a book he worked through. He did during night hours for the last few weeks.

Actually, these are my top developers. I have to wonder why they have to do this during night hours. When they are not disrupted.

And then I read something here:

If your work environment fosters distractions (commonly known as “open space”), a grand majority your engineers will be stressed to the bone, and probably doing 10% of what they can actually accomplish.

tl;dr Conclusion

Also this is my very personal opinion, I had the best collaboration experience in remote teams – workin remote. Not based on working hours. Working on-site was never that awesome.

Good people will probably always sacrify their free time to fetch up disruption at their work place.

But why does remote work rock that much? In my opinion, you can work when you can perform the best. Who says I work the best at 8 am in the office? Maybe “my creative time” is 11 pm to 2 am.

If you set up an remote working environment,  this might not work out for everybody. There are always individuals not providing sufficient discipline for self-responsible work. However, in my experience, if you set up a remote working team, you usually have only team members in it, capable of providing this kind of work.

This might not work for a given team, but should be considered when creating new ones as already Martin Fouler pointed out in his article.

The fact that you can get a better team by supporting a remote working pattern has become increasingly important during my time in the software business and I expect its importance to keep growing.

Based on my experience, remote first teams can outperform co-located teams due to many aspects.

Teamwork in Scrum

ScrumMaster Logo SealSome aspect attracting my attention since my very first Scrum training is the fact how a Team actually handles team work.

In a conventional software development team you probably find a bunch of hierarchical organized group members including managers, an architect, engineers and developers. While the architect figures out what to do with respect to the managers needs, the engineers define how to do it and de developers eventually do whatever the hierarchical organization above has defined.

In a Scrum Team, the Team is told what to do directly by the ProductOwner in form of stories. Consequently, what to do, how to do it and the act of doing it is completely within the responsibility of the Team. In the conventional approach, each level could blame the level above in case of a failure. The developers blame the engineers for insufficient definitions, the engineers blame the architect for a faulty architecture or misleading bullet tracing and the architect might blame the managers due to a strict budgeting, too much pressure and so on. Of course each manager might blame his manager in turn and so on.

So, how do we end up in a team effect? I have seen teams where each developer picks a story from the task board, teams where each developer had his/her own area of stories (server, client, user interface etc.) and teams where the overall team works at one story at once. Boris Gloger, holds the view the entire Team (of developers) works on the same story. I am not absolutely sure yet,  how this works in larger teams (5+ developers) with small stories, however in theory, if a story is done by the hole team it succeeds as team.

If each developer works on a separate story, I recall a passage from the latest book of Robert C. Martin, talking about who breaks the code will own it. What’s the logical implication of this? If a developer breaks code he might get blamed by other team members. That’s the quick death to a team. If the team separates in smaller groups which maybe blame this developer, this might be an even quicker detach to the team. If the blaming happens in front of the ProductOwner, this might fundamentally harm the overall Scrum Team, in particular the Team – ProductOwner relationship. Suspiciousness, maybe shorter sprint duration and additional tension within the whole Scrum Team might be the result. The very best ScrumMaster will have a hard time undoing this. Considering the fact that a really good team might take up six to twelve moths to form up, blaming should be avoided at all circumstances.

So what’s the right attitude in this case? If something goes wrong, a story is not fully implemented, code is broken, previous functionality is lost or whatever goes to the dogs, the whole team should stand up, work together to fix this issue as quick as possible without caring who introduced it. Of course the team should perform a root cause analysis what exactly happened, however, as it should be done in retrospectives, the topic should not be what went wrong and who’s fault it was. Instead it should be about how to avoid such a issue in the future. That way its all about improvements and that’s what Scrum is about at the very end.