Art & Logic’s Distribution, September 2013
I’ve been seeing a lot of articles and discussion lately on the pros and cons of using distributed teams. It’s a topic I’ve given a lot of thought to — I just had my 17 year anniversary working for Art & Logic in a completely distributed environment, and over the years there have been many words written both in favor of it (see Scott Berkun’s recent book The Year Without Pants) and against (maybe most emphatically by Alistair Cockburn, who in his book Agile Software Development (2002) who says that ‘distributed development is becoming more commonplace, but it is not becoming more effective’). I’d certainly take exception to the assertion that it’s not possible to be successful and effective developing software in distributed teams, but that doing so requires that you adopt or reject certain situations, practices, and scenarios:
Infrastructure and Support
What we’ve found over the years that works for us (and our clients!) are the following things:
- Use of a threaded conference system instead of email. Lately, we use Google Groups for this, and every project that we work on has a pair of groups. An externally-facing group captures all communication with the client, and an inward-facing group is used by the project team. By keeping all these conversations in a single shared location, there are fewer opportunities for miscommunication or leaving important people out of the loop.
2. Always available text chat Sometimes you need a question answered and you need that answer right now. The least intrusive way to do this is via an IM-style text chat. Unlike a phone call, there’s never a busy signal, and it’s nice to be able to solve a problem on one project while on a conference call discussing a different project.
3. Robust shared-resource systems Obviously, we rely on good source control systems as developers, but being able to use shared documents, spreadsheet, and wikis makes everything go more smoothly.
4. Voice communications We spend a lot of time on the phone, but maybe less than you’d imagine.
5. Video A common assumption among people that I talk to is that we must have been early adopters of video conferencing. In reality, we were intentionally late to the party here — it’s only in the last few years that tools like Skype and Google Hangouts have had high enough quality and we’ve been able to count on everyone having solid broadband connections that video provided enough benefit to outweigh the hassles.
“Telecommuting”
Over the years, I’ve heard many stories about how ‘telecommuting’ doesn’t work. Inevitably, those stories end up talking about a situation where an entire team is colocated except for one or two team members who are remote. Because the bulk of the team is in the same space, it’s easy for them to forget those ghostly folks who only appear by email and conference call. It’s no wonder that telecommuting has gotten a bad rap over the years. The problems that happen aren’t so much because there are remote workers as because remote workers are trying to work in an environment that hasn’t done much to adapt.
I suspect that this problem is lessening in the recent past, just because the kinds of tools that we’ve adopted for a long time to address the needs of remote workers are no longer rare in the way that they were even a decade ago. We often joke that we don’t telecommute, because there’s no central location for us to be telecommuting into. To the extent that an organization is already communicating in a remote-friendly way, the more likely it is that remote worker is going to be able to succeed in their midst.
Keeping people connected: online
“My parents wanted to move me into high school out of the sixth grade, but we decided to chuck the idea because I’d have trouble making friends, blah, blah, blah. Now blah, blah, blah is all I ever do.” — Heathers, 1988
Industry spent years trying to find ways to prevent workers from doing anything that wasn’t directly
on task, dating back to Taylor’s early time and motion studies to current policies relating to ‘time theft’ at some retailers.
In a distributed environment, it’s proven to be crucial that we work against the common feelings of
isolation that come along with (let’s be honest here) being isolated from each other. Over the years, we’ve lost more people than we like because they burned out on being alone and needed to spend more
time around other people.
For a long time we tried unsuccessfully to use video conferencing to address this problem, but it’s only been in the last few years that the quality and stability of these systems has been good enough for us to rely on. We’ve also got separate persistent text chats running throughout the day for discussions both project-related and not, and it’s key to remembering that we work with people, not just email addresses.
Keeping people connected: f2f
As good and useful as those text and video hangouts are, the most important thing we do every
year is to fly everyone to the same place for a few days so we can talk business, tech, and whatever else comes up. I don’t know that I’d have wanted to (or have been able/willing to) stay working here for as long as I have if there had never been this kind of regular face to face connection. It not only re-energizes the company in a very palpable way, it makes the company work more smoothly for months afterwards, especially for anyone who’s joined the company since the last conference. In a colocated environment it’s an easy thing to seek out a teammate to discuss all kinds of issues; the friction involved in doing that online is higher, and it’s compounded when the person you need to track down and ‘bug’ is someone that you haven’t actually met yet. It’s a waste of time and energy building systems to keep people connected online if they’re too hesitant to use them all the time.
Maintaining Boundaries
Perhaps the largest problem in remote work for people who work from home is that when your work is always right there where you live, it can take great discipline to not let work take over your life. It took me a few years to stop feeling pangs of guilt after hearing my work phone ringing at 9PM and making myself let it go to voice mail instead of running to answer it (but I still haven’t gotten to the point where I can wait until the next morning to listen to the voice mail, just in case it’s a dire emergency that I really do need to attend to right away).
There can also be attempts to penetrate that boundary from the other direction. My wife teaches, and both my kids are still in school. For ten months of every year, I can work without anyone except the dog needing any attention from me. When June rolls around, even after all these years I need to remind the entire family that just because I’m home, that doesn’t mean that I’m home. Eventually they get used to leaving me (mostly) alone, and I get used to occasional interruptions. Then they go back to school and I spend a few weeks adjusting to the sudden silence.
Structuring Projects for Success
It’s important to structure projects so that they can be executed succesfully by team members that are not only separated spatially but also temporally. By breaking down a project’s tasks to minimize the opportunities for developers to block each others’ progress, everyone is able to spend more time in a head-down productive state. We’ve learned to use approaches like using the natural fault lines of a project to divide responsibilities on either side of a clear and obvious boundary. For example, in a web project, we’d spend time defining a clean API and then letting the developers on each side of that work as independently as possible between integrations. Project Managers used to working in an environment where there team is completely colocated might want to do that, and have every intention of working like that, but it can be difficult to enforce when it’s so trivially easy to get people used to poking their heads into a co-worker’s office and introduce a tighter coupling into the process.
…But that’s not enough
Let’s assume that you’ve created a situation where all of the above things are in place. A software development organization is a machine that has human beings as moving parts, and we’ve also seen some common reasons that people are interested in working remotely (most often where ‘remotely’ is pronounced ‘at home’) that are red flags at the very least. It might be possible that other organizations would have better results working with people who are primarily motivated by the things listed below, but they’ve proven to be disastrous for us.
“WORK (at home)” vs “(work) AT HOME”
If your primary motivation for wanting to work remotely is that when you read the phrase ‘work at home’ you primarily see the words ‘AT HOME’ and not the word ‘WORK’, you’re likely to encounter difficulties. Over the years that I’ve done this, I’ve had conversations with many people who don’t believe that they’d be successful because there are too many distractions at home for them to stay focused on work. As someone who hates yardwork, I’ve always been taken aback by the large number of people who tell me that if they worked at home, they’d end up spending most of their time outside mowing.
“I don’t need a babysitter”
Sometimes when we’re interviewing and ask a candidate why they’re interested in working with us, the reply that one of their main goals is to get into a situation where they don’t need to pay for childcare. In reality, this rarely works out as hoped; anyone who’s tried it has ended up giving up after a brief trial; any kids young enough to require childcare are almost certainly going to need more attention during the day than would permit someone to remain focused on tasks. When I started with A&L, my son was eight months old, and when he was too sick to go to daycare, he’d stay home with me, but I learned quickly that a sick day for him ended up being a sick day for me as well.
“I can work weird hours”
Some folks want to work Dracula hours, or whenever the urge hits them, or in one memorably bad example,
work for 35 hours straight and then disappear for the remainder of the week. This is an area where
different places will have very different attitudes, but what we’ve learned is that in any kind of a team
project, the developers working on it will inevitably need to have a reasonable amount of overlap during
their work days. When this isn’t the case, you quickly encounter the situation that we’ve seen in cases where we’re working with clients on the other side of the world — when questions inevitably arise, there’s suddenly a 24-hour turnaround on everything, even trivial questions that could have been settled in a few minutes of chat.
Successful projects are designed so that the developers working on them are coupled loosely enough
that they can work asynchronously, but there are limits to how asynchronous things can get without making the project spend all of its time spinning its wheels in the mud.
