With the trend of remote work on a rocket ship to the moon, I thought I’d share some things I’ve learned working in a distributed organization where remote work is common.
Asynchronous Communication
As software people, we’re familiar with the concept of asynchronous communication. When my web app needs to kick off a long-running process on the server, it doesn’t freeze up until the server finishes the work and gets back to it. When I’m working as a member of a distributed team, adopting an asynchronous style of communication with my fellow humans becomes important.
I start by getting out of the synchronous mindset where I’m
blocked until I get feedback from a specific person at a specific time. Remote team members are like long-running processes on a distant server. I assume that my communication with them is mainly asynchronous. I keep other tasks in mind that I can keep making progress on while that remote process is generating a response for me.
Effective Writing
When working with distributed team members, written communication takes a front seat. Getting input from people via writing is more effective when I keep a few points in mind.
Set the person up for success
Since email tends to be the dominant form of written communication in my distributed team, most of the important lessons I’ve learned relate to effective email. When I’m writing up an email to a team member, I try to set them up for success.
Since some of the folks I work with tend to have unpredictable schedules and receive a ton of email, I want to make it easy for the other person to provide a clear, unambiguous answer in one email that can unblock me.
I anticipate some of the reasonable possible responses they’re likely to give and include those in the email. It’s almost like preparing a
menu of options they can pick from so they don’t have to start from scratch when they’re writing up a response for me. This becomes easier the more you work with certain people and learn how they tend to think.
Assuming as little as possible about the person’s mental
context is another lesson I’ve learned. I avoid jumping in with a very specific question, assuming that the person will know exactly what I’m talking about. I’ll remind the person of the context of my question so they don’t have to rack their brain to rebuild the context. If we’ve written about the topic before, I’ll dig up our previous communications and quote them in the new one.
Include
links! If I’m referencing something that has an online artifact, I link it up! Don’t make the person chase down things that I can pre-chase. For example, if we’re discussing the requirements for a particular
backlog item, I grab the URL to the backlog item in
TFS and include it in the email so the person doesn’t have to first dig up the backlog item before they can respond to me.
The sort of meta-point behind all these lessons is that people are more likely to respond effectively and in a timely fashion if you
make it simple for them to do so. Set them up for success!
A picture is worth a thousand words
The
old saying is true. When I’m discussing something that could be
screenshot‘d, I include a screenshot! Windows has for several releases included the
Snipping Tool, which is a simple screenshot tool I use a ton, as I work in a Microsoft shop. If you’re on OS X or Linux, I’m sure you can find similar tools for taking screenshots and marking them up.
Circle elements of the screenshot and draw arrows. When I
visually draw attention to the most important aspects of a screenshot, it leaves no ambiguity as to what I’m talking about. I can’t count the number of times an email chain could have been shortened by a simple screenshot with red circles around the areas in question.
Mockups accomplish a similar purpose to screenshots, before something exists to be screenshot’d. When my team is in the stages where a new chuck of functionality for our application is coming into being, a simple mockup in a tool like
Balsamiq can bring untold clarity to a design discussion and form a solid
starting point for productive conversation to focus around. I’ll touch on Balsamiq again a little later.
Explain it to the duck first
Often I find that when I take care to thoroughly explain something in writing to someone, I end up not even needing to hit
Send. Writing requires one to clarify one’s own understanding of a concept. Developers have a term for this process:
rubber duck debugging.
State of the Project (Single Source of Truth)
When working in a distributed team, it’s important to have an online Single Source of Truth (SSOT) that people can go to to pull information from. You can’t rely on word of mouth to spread the status of work throughout the team.
There are about a million and one tools that will get the job done, whether it’s
Pivotal Tracker,
Asana,
Trello, or something else. On my team, we use
TFS for this purpose. Pick one and stick with it. Our whole team knows that TFS is the SSOT.
When I find some important piece of information missing from the SSOT, and I have to ask a team member for the information, I ask them kindly to answer the question by updating the SSOT. That way this new piece of information becomes available to the whole team the moment it becomes available to me.
If someone asks me for the status of something, I point them to the SSOT, because I’m always keeping the SSOT up to date with my status.
When the product owner dreams up a new requirement, right away we capture the requirement in the SSOT. Eventually you can weave into your team culture that if something doesn’t exist in the SSOT, then it doesn’t exist.
Build a Rough Version and Show It
There’s no doubt that it’s a bit more cumbersome to discuss highly visual concepts remotely. That new page in your web app that your product owner wants is tougher to design without a whiteboard in front of the two of you.
I encourage folks to get away from the idea that you have to perfectly define every aspect of some new thing before anything can be built.
I think this is a skill you develop with experience, especially if you’ve gotten used to working with a particular product owner. You can cultivate a part of your brain that can act as a sort of proxy for your product owner if they’re not immediately available to answer a question.
Taking care to
understand the high-level motivation behind a feature allows me to rough in some of the details in the early stages with the confidence that they’ll only change slightly in the later stages when every little thing is being defined. For example, I won’t stop making progress on a new screen because I’m waiting for the product owner to tell me what color a button should be or the exact phrasing of a label. I use my
best judgment, then keep on truckin’. Those things are easy to change later.
When finding myself in doubt about the general approach to take with some new feature, there’s no better way to get the conversation moving in a productive direction than to create a quick
mockup. Again, a picture is worth a thousand words. Once you have some sort of visual artifact you can both look at independently,
even if it’s wrong in many ways, then you’ve got a basis for productive conversation.
Balsamiq is a fantastic tool for mockups. It’s very quick to produce a rough sketch of an idea and start getting opinions on it. Balsamiq has the awesome property that its shapes look rough and unfinished by design. The lines are a little squiggly, the font is almost
Comic Sans-ish. It gets the message across that
this is just an idea, it’s not intended to be a final product. Get the broad strokes of an idea across without people getting caught up in the fine details.
Once I have a mockup that shows my best understanding of the problem being solved, it’s time to send it over to the product owner (or whosever opinion I’m seeking) and get their comments on it. Once we’ve agreed on the general layout of a page, we can proceed confidently with development, knowing that we’re not wasting time and won’t have to bug each other for a while.
When You Just Have to Be Synchronous
Up to this point, all the tips I’ve discussed have been about how to work
asynchronously as much as possible and how to be effective in that mode of communication. Well, there are times when I just need that real-time exchange with someone because the thing we need to discuss can’t wait. There are three main ways that I go synchronous with remote team members: screen sharing, conference calls, and instant messaging.
When we have some visual artifact that we both need to have our eyes on at the same time,
screen sharing tools are the way to go. On my team we use
WebEx, but there are a million other tools that can do this, including
GoToMeeting,
Microsoft Lync, and
Google Hangouts.
Conference calls are old-school but they can be handy in some situations. For example, my team has a regularly scheduled stand-up every morning. There’s a standard con-call number everyone knows, and if you’re working remote that day, just call in and you can participate in the stand-up just like the folks at the office.
I have conflicted feelings about
instant messaging. For one-on-one conversation, it beats a phone call as it’s less intrusive and people generally understand that an immediate response is not needed. But it has the same downside of ad-hoc in-person conversations in that the content of the conversation is not preserved for later reference. For anything beyond the most trivial of exchanges, I prefer to use email as it automatically creates a record that I can search through later when weeks (or months, or years) have gone by and I can’t remember why we decided to do thing
X over thing
Y. Somewhere in the middle are tools like
Campfire that do group chat with automatic transcripts. I’ve used tools like this in past jobs, but they haven’t found wide use at my current company yet.
Writing is Searchable, Voice Isn’t
This is a sort of meta-point that I’ve touched on above, but I’ll call it out here as a separate thought. If a team can get used to written communication as their main form of communication, they get the awesome benefit of a
searchable, historical record of their decision making process. Be honest, how many times have you wasted effort trying to remember why some feature of your software works the way it does? No one can remember because it was designed via ad-hoc conversations in the hallway or over the phone and no one thought to write down the salient points that led you to do whatever it was that you did. Or when you demo a completed feature to the product owner, and a moment of panic ensues because they remember telling you to do
X, but you thought they said
Y, and no one knows what’s correct because no one wrote it down.
Writing is recorded, voice isn’t. Writing is searchable, voice isn’t.
I ♥ Remote Work
Some of the most blissfully productive days I’ve had are when my whole team is working remote because a winter storm has left us snowbound. There’s nothing quite like the glorious zone of productivity sans soul-crushing interruptions. I’m extremely optimistic about the global trend toward remote work, and I’m confident that more people will keep making the jump to full-time remote work (me included).
There are undoubtedly unique challenges that come with working remote. The most helpful lessons I’ve learned are to communicate asynchronous-first, express myself clearly in writing, keep my team up to date, exercise careful independent judgment, and go synchronous when asynchronous just won’t do. When my distributed team does these things well, we can kick ass
together.
