What It Takes To Work Remotely

What It Takes To Work Remotely

June 3, 2010

Chapter 1 – Introduction

This book is for every type of remote engineer. Developers, testers, documentation writers, and anyone else involved in the software development process who works in a different location from the rest of their team. This includes engineers who work half-time from home and those who live on the other side of the world.

Although working remotely can have a lot of benefits for you and your employer to be successful as a remote engineer and enjoy those benefits you will need to:

This section was strongly influenced by my conversations with Karl Fogel. Karl is a founding member of the Subversion project and the author of Producing Open Source Software: How to Run a Successful Free Software Project. I didn’t speak with Karl for very long, but his influence on this project was profound.

Write clearly. You’ll write email, bug reports, chat room messages, wiki pages, and a dozen other forms of text all day every day. You need to write clearly and concisely so you can get your point across and avoid misunderstandings. You need to organize your thoughts in a way that other people can make use of them.

Take criticism well. You have to be secure enough in yourself to not assume the worst. Imagine another developer on your project drops you an email that starts “Question about your commit last night.” Karl Fogel, the author of Producing Open Source Software: How to Run a Successful Free Software Project, asks, “What is your immediate emotional reaction? If you are worried and frightened, this is probably not going to work out well. If you are curious to know what’s in that mail then you’re pretty safe.”

Learn conventions quickly. Every team follows a set of unspoken rules. These are the small processes that keep the team running smoothly; code style, check in comment formatting, how bugs are referenced, and many others.

Fogel says, “It’s all on you to find [these conventions] because the effort of saying it to you is so much higher when somebody actually has to type an email and express this thing they’ve never expressed in words before… It is so much work for the other people that they just won’t bother.”

Be self-sufficient. Being in a distributed team means you need to send an email or pick up the phone to get a question answered. This makes communication more difficult, so you need to communicate wisely Put more time into finding the answer yourself. Save the team communication for the times that it helps the team and not just you.

Stay motivated. Working from home means less distraction and more flexibility, but it also means nobody watching over your shoulder making sure you get your work done. You have to stay motivated and get your work done.

Show your work. Much like high school math class: you can’t just have the right answer, you need to show how you got there. Your work can’t speak for itself until it is done. If you wait that long you will have already alienated your team. You have to communicate with your team about your process so they can know what you’re doing before you’re done.

Communicate your status. Managing your status is a way of managing expectations. In the office you are there or you aren’t. It is really easy for your coworkers to see if they can ask you a question. Out of the office you need to let them know when you are there and when you aren’t. You need to make it as simple as possible for someone to see if you are available by using IM, IRC, or another technology.

Be consistent. People are naturally suspicious of what they can’t see and being remote means they can’t see you. Help your team by being a steady presence. Keep consistent hours and let them know you are working hard.

This all might seem like a lot to know. And it is. And it isn’t even the full list. Being a good engineer out of the office is more difficult than being a good engineer in the office. Being remote has huge benefits, and these skills are the cost. The good news is that these skills will help you be a better engineer out of the office or in it.

Every skill that makes you a better remote engineer makes you a better engineer. Every change a team makes to work with distributed engineers will help the team. A distributed environment is like a lens which will focus all of your attention on how the team functions as a team. You can clearly see issues which would be difficult to see in the office. This is just one of the many reasons why working remotely is not a perk.

Previous post:

Next post: