> If I need to ask a teammate a question, I turn my head slightly to the left and ask them. They respond immediately.
And then they stand the chance of losing anywhere from 20 minutes to an hour of productivity thanks to your interruption.
Part of the reason remote work appeals to so many of us is because we don't deal well with the constant stream of interruptions that occur in many office environments.
I don't believe this is the case for everyone. There are some individuals capable of working productively in a noisy environment all day while sleeping only 3-4 hours per day. But I think such individuals are rare, and you're doing yourself and your organization a disservice if you think all developers can work this way effectively.
My main drivers for working remotely are what you just described and eliminating commuting time. I find I'm much more productive and happy without those inconveniences in my life.
Yeah, I get that. You are more productive. You are interrupted less. You can focus more easily. You are happier at home.
Now, where's the consideration for everyone else on your team? That seems to be the one thing missing from all these counter arguments, yet it's the crux of the matter.
They can reach me via IM, phone, webex, etc. Initiating communication this way (maybe excluding IM) is somewhat more formal than face to face chatting. This gives the initiator more incentive try to work out their own problems first without bugging me (and that's great). If they truly need me for something, I'm happy to oblige. The casual face-to-face "do you have a minute" interruptions are the ones that really kill productivity.
I'd like to respond to some of your other comments:
If I had to endure a culture where this was acceptable:
> Why aren't you answering your phone? Why haven't you responded to that email I sent you 5 minutes ago? Are you even at your computer right now? Hello???
I wouldn't work there for very long. This mentality of "butts must be in chairs" flies against the notion that software engineers are professionals and should be treated as such. This nagging is a great way to lead to a broken, angry engineer.
That said, I agree with your premise:
> Team productiviy > your individual productivity. It's that simple. Do you think your team members interrupt you just for the fun of it? No, they interrupt you because they need your help to accomplish something.
But there is a fine line between nagging and actual necessary interruptions that is deepened by remote work. Asking a professional why haven't they responded to the email you sent 5 minutes ago, to me, is crossing the line and if everyone on the team has to endure that kind of behavior then individual and team productivity will both suffer. I've experienced being micromanaged and it's terrible and it's definitely not conducive to my productivity. The rest of the team seemed the same way and thus the team productivity suffered as well. Creative thinkers need uninterrupted time to plan, think, and execute.
Still teams of gifted individuals tend to achieve more than sum of gifted individuals working alone, distractions notwithstanding.
Anyway I'm reserved about the very thesis that office life is particularly full of distractions. At home office you might have spouse and kids who are even less understanding of your "zone" than your coworkers. If you are single it might be neighbors driving their renovation project with hammer drills at work hours. You probably have a TV, game console, your guitar, your pet, and basically have to rely on self-discipline with that.
I can usually deal with interruptions in a gracious and friendly manner. I'm a nice guy, usually laid back, and capable of rapid context switching.
I have discovered, however, that since I do not work for an emergency room, my context-switching-skills are rather undervalued by the free market. The value I generate for clients and employers is very much correlated to my ability to train clients & colleagues to let me focus on solving one problem completely before moving on to the next problem.
I find when you describe the effect of interruptions in terms employers understand — "working this way costs you money, both directly, because I charge a not-insignificant amount per hour, and indirectly, because there are opportunity costs to my working on emergencies instead of farther-reaching goals" — they will become your allies in fighting off interruptions. If you just complain that interruptions are distracting and irritating, well, you're just gonna get a prima-donna label for yourself.
I love working as a team. My creatives can make something look more visually appealing in a few hours that I could in a few months. I can develop the functionality in a few days when they wouldn't know where to start. We all have our strengths. But creative work is inherently a selfish, individual act requiring concentration, and interruptions, in most instances, don't help the team meet their goals.
Absolutely agree - anyone wandering into one of these opinion articles/discussions would think that developers are a self-centred bunch of arseholes whose productivity is the most important thing in the entire universe, and isolation/concentration is critical. Even brain surgeons need to collaborate and operate - literally - in conjunction with other people.
I'm a software engineer married to brain surgeon. She will be the first to tell you that the actual procedures, while technical, are essentially arts and crafts; they require care, but not extreme mental focus.
However, when she's reviewing patient charts and imaging to prepare for a procedure, that requires absolute focus, and she will isolate herself completely for hours and not talk to anyone no matter what. So, there is a time for collaboration, but there is also a time for focusing on one task to the exclusion of everything else.
So when brain surgeons are operating, do their bosses pop in and ask them inane questions they could get answers to via email?
Developers don't need to continuously collaborate. Even brain surgeons spend a lot of time reading up on papers and research and interruptions do not help them.
Absolutely - anyone wandering into one of these opinion articles/discussions would think that developers are a self-centred bunch of arseholes whose productivity is the most important thing in the entire universe, and isolation/concentration is critical. Even brain surgeons need to collaborate and operate - literally - in conjunction with other people.
Oh, really? Because researchers disagree with you:
> Another field study compared interruptions in paired, radically-collocated and traditional, cube-dwelling software development teams, and found that in the former interruptions were greater in number but shorter in duration and more on-task (Chong and Siino 2006). Close proximity improves productivity in all cases." -- http://conway.isri.cmu.edu/~jdh/VRC-2008
Have you even read the study, or are you just quoting it blindly? Your link provides a very brief summary but mentions no details about what tools and workflows remote workers were using. It also doesn't mention anything about the type of project that was being delivered and the various constraints that it had. Maybe you're just taking this stuff on faith.
So reading through that study it appears as though that the remote test group ("Team Solo"):
- was actually working in cubicles in the same room and could overhear each others conversations.
- used email and a very basic text-based chatroom built in 2002 as their primary means of communication, as well as the telephone. Doesn't sound like a sophisticated setup to me.
- did not use any screen sharing software or VOIP software like google hangouts or skype and no mention was made about version control software, wikis, project management software ala Asana or Basecamp, or any other of the modern tools we developers use today.
They mention that "Team Pair" benefited greatly from pair programming, which any remote worker (including myself) can tell you is more than just possible using the tools of today, but perhaps even better than hovering over someone's shoulder in the instances where the software allows you to take control of the other person's screen.
From the study:
"On Team Solo, by contrast, intrusions were both functional and
social in nature. Intrusions were longer and generally involved
movement – team members physically visited another team
member’s cubicle."
Again, their "remote" team is actually just a team in the same room but separated by cubicles. They state that the reason the interruptions were lengthier for Team Solo was because of the physical distance between the team members. In my experience, when team members are truly remote, the interruptions drop significantly in both length and frequency.
You have linked to a very old study that determined that working in an open-plan office is better than working in a cubicle-based office. You either didn't read the study, or are not understanding how this clearly does not apply to truly remote workers and the topic at hand.
The tools people have today to collaborate remotely are much better than they were in 2002, and getting better every year. Unless you can point to a recent study that actually compares truly remote workers using modern tools to co-located employees I'm going to go ahead and say that the evidence is weak at best.
This... x10. Having worked remotely from 2000-2002 and also 2010 to the present, I don't know how anyone can make an accurate statement about remote working in 2013 based on a study from 2006.
And then they stand the chance of losing anywhere from 20 minutes to an hour of productivity thanks to your interruption.
Part of the reason remote work appeals to so many of us is because we don't deal well with the constant stream of interruptions that occur in many office environments.
I don't believe this is the case for everyone. There are some individuals capable of working productively in a noisy environment all day while sleeping only 3-4 hours per day. But I think such individuals are rare, and you're doing yourself and your organization a disservice if you think all developers can work this way effectively.