Telecommuting
I recently came across a few articles by Esther Schindler on telecommuting which struck a chord with me.
The first, “Getting Clueful: Seven Things the CIO Should Know About Telecommuting”, is directed at managers of telecommuters. It covers the benefits to the company of having telecommuters (cost savings, productivity, etc.), potential pitfalls (not everyone can manage themselves well enough to work remotely, ), and how to cope with them. She places a heavy emphasis on building trust in the manager/employee relationship, especially through communication.
The second article is directed at the telecommuting employee. In “Telecommuters Need to Develop Special Skills”, Schindler goes a bit beyond the basic advice normally found in articles like this. Unsurprisingly, most of that advice centers around communication issues such as status reporting and “visibility”. One key item regards conference calls and telling people sitting around a speaker phone to speak up – we have that problem frequently at my company.
Both articles include specific advice from experienced managers and telecommuters. I’m happy to say that my company gets most of this right. We are based in Atlanta, and unless you live in the same building as your company there is no easy commute in Atlanta. From the very beginning, my manager told all of us he would rather have us working than sitting in traffic and we have been expected to figure out how to do as much of our work from home as possible. This went beyond the grudging acceptance of telecommuting at my previous employer to active encouragement. He saw the immediate cost benefit in office space and productivity benefit in gaining as much as 2 hours per day of extra work.
As far as remote communication goes, we follow the technology chart laid out by Schindler pretty closely. We don’t have formalized rules; it just seemed to work out that way naturally. One category of tools she does not mention for status/discussion are online collaboration tools such as wikis and issue tracking systems. We rely on both, with the ticket tracking system used for asynchronous design discussions and the wiki for historical documentation, how-tos, etc.
After an initial settling in period (2-3 months) where I got to know my new co-workers and learned about the development environment, I have been working at home as much as possible. These days that usually means 4 of 5 days in a week, sometimes 9 of 10 over 2 weeks. There have been stretches where I didn’t go to the office for a few months at a time, but those are rare. One day in the office per week works out well, since most of the developers seem to talk better with a whiteboard in front of us. I’ve looked into online whiteboard tools in the past, but haven’t found anything to replace the nuance of the in-person meeting. Perhaps if we installed some web cams…
We’re a small group, so we try to keep everyone informed of all design issues. The code is usually implemented by just one or two developers, but everyone has an opportunity to be involved in signing off on design and implementation before anything goes into the svn trunk. We’ve been doing this for 5-6 years now, so we’ve settled into a pattern. For small designs, an individual developer may do the work and write up the “approach”, explaining the design and tricky implementation details. The approach (a wiki page in trac) is then submitted for review along with the completed changeset. This works well for small changes or bug fixes, but for larger projects we usually have some sort of conversation before development begins. It might be a simple sanity check by one other developer via IM, phone, or email. If a more formal review is needed, we typically write a preliminary approach, without any code, and submit it for comments. If we can’t agree on the approach it is time to schedule a meeting, either as a conference call or in person.
Of course, we also make heavy use of instant messaging on our own Jabber server. Most of our quick communication has moved off of email to IM, and we use IM for “presence” notification. If I step away from my desk to take care of something around the house, run an errand, or get lunch, I use the IM status message to tell people when I expect to come back. Email tends to be reserved for progress updates, issues that don’t need immediate resolution, and sometimes scheduling times for more direct means of communication.
A drawback to working remotely so often is that I frequently end up the last to know about things like schedule or priority changes. If an informal discussion in the hall results in a major decision, an email still might not go out right away or the eventual message might assume more knowledge of details than I have. This is a group communication problem, and we’re working on it, but it can be frustrating at times.
Schindler does not offer tips for handling physical space for telecommuters in the office. She mentions the opportunity to save office space, but doesn’t get into what to do when all of those remote workers do show up at the office. For a couple of years I had my own cube, even though I was hardly ever there. We’ve recently grown big enough that my desk was needed by someone who is in the office more frequently than I am, so I gave it up. When I cleaned out the drawers, the only things I kept were a handful of business cards and a couple of pocket reference books. There wasn’t anything else in the drawers that belonged to me!
Now I sit in the “hotel” room when I’m in the office for meetings; that’s typically the only reason I go in, any more. Even if I don’t plan specific meetings, I usually end up spending the day in informal discussions rather than writing code. We converted a small conference room by replacing the central table with folding tables along the walls to serve as desks and by adding a few chairs. There are internet connections (or wireless), a phone, and the old whiteboard from when the room was actually a conference room. I used to spend most of my time at the office in a conference room anyway, so this works out fine. :-)
And of course when I’m at home, I work at my desk here most of the time. I do try to mix it up a bit, though. On nice days, I start on the patio after breakfast. I catch up on email, read news, listen to podcasts, etc. If it is cold or wet, I usually start out at the dining room table, or on the sofa with a cat in my lap. When I am ready to do some coding, I move to my home office, where I have a door to close and space on the desk to spread out notes or reference manuals. I also have a second monitor for my laptop there, which turns out to be a lot more useful than I ever expected. Occasionally I take some reading or documentation work to a local coffee shop, but their chairs tend to be less comfortable and the people traffic can be distracting, so I don’t usually do any coding while I’m there.
Our application runs on Linux, and my desktop is a PowerBook, so I rely heavily on remote access tools such as ssh and VNC. I have a development box at home, because the lag time to the office is intolerable sometimes. Most of the collaboration tools we, such as trac and Jabber, use can be tunneled, so my ssh configuration includes a lot of port-forwarding. The end result is that I can access any of my work systems or tools remotely, even from the coffee shop if need be.
I’ve been working remotely for several years now, and I have a hard time imagining going back to the office every day. I do like being in the office, but the commute is killer. If the job were closer, or we lived somewhere else, it might not be as big of a concern. But this is a good situation for me now, and I’ve had no trouble getting used to it.