Introducing The One Minute Commute

May 27, 2010

Chapter 1 – Introduction

When I first started working as a remote engineer, I didn’t know any of what you’ll be reading in this book. I thought my success would be determined by how much code I produced and how good it was. I was completely wrong, and I had to learn most of the lessons in this book by making the mistakes. I decided to write this book in the hopes of sharing what I, and others, have learned through trial and error. It’s the book I wish I’d read before I became a remote engineer.

On the first team I worked with as a full-time developer the build process took over an hour. A little while after I started I rewrote it and the build time went down to 10 minutes. It was the first piece of code I wrote that really made a difference to someone else. Engineers I had never met were thanking me in the hallway. I had been worried I wouldn’t make it as a real engineer and this was a validation I needed.

The build process I wrote fell into disuse less than a year later when John, a coworker of mine who I counted as a friend, replaced it with his own build system. Having my code replaced didn’t hurt nearly as much as the way my former friend did it: without any warning. I updated one day and it was just there.

To make matters worse, he had discussed it with almost everyone but me. I felt left out and excluded. John was my friend and he betrayed me. Not only were my feelings hurt, but my confidence was shot. I had lost a big step forward in my career, and I didn’t know why.

I left one detail out of this story: between the time I wrote the build and the time John replaced it I started working remotely. John didn’t ignore me out of malice or spite. He wasn’t jealous of my talents or the success I had on the team; although I was secretly certain he was. He just didn’t know how to talk to me now that I was permanently out of the office. Sure he could have picked up the phone, but I didn’t make it easy.

When I started working remotely I almost disappeared. I boycotted IM and avoided conference calls. I never sent new emails and only replied to the ones I received when I was sure there was no other way. I wrote a lot of code and thought that should be enough.

In essence, I put out a big sign for my team saying “Leave Me Alone!” And John did. The saddest part is that it all could have been avoided by a few emails and conference calls.

Many people who start working remotely fail. They become isolated from their team and create a working environment with very little teamwork. The code the team produces gets worse and projects slow down or fail altogether. Many remote engineers falter because they lack an understanding of basic human communication.

Your team won’t see you at your desk when they show up at the office, neither will your manager. You may have been working for hours, they just don’t know. One of your biggest challenges is making sure that “out of sight” doesn’t mean “out of mind.”

Working remotely means accepting substitutes for standard communication. Instant messages replace a friendly chat and group meetings are now conference calls. Using these new, and in some cases old, alternative forms of communication effectively requires a fundamental understanding of how humans interact.

I have faith in teams. I believe that many people working together can achieve more than they can alone, but only if they work together well. Communication technologies will be cheaper, more widely available, and better in the future. Companies will take advantage of these technologies to build teams from around the world. The success or failure of those teams depends on the abilities of individual contributors to communicate well and stay close with their team, even when they are far away.

Previous post:

Next post: