274 years

The population of Manhattan is roughly 1.5 million people. On the weekend. On a weekday, the population doubles to 3 million people. Almost two million people commute from outside the city. Each work day.

Their commute time is, on average, 48 minutes each way.

For 1.5 million people, who spend 96 minutes a day commuting, that’s 144,000,000 total minutes. 2,400,000 hours. 100,000 days. 274 years.

274 years spent commuting to/from Manhattan each work day

Of course, many of these are retail, service, or support staff who need to be physically located here to perform their job.

What about the rest?

82 years burned every day

Of that number, from labor.ny.gov, we can estimate that roughly 30-40% of them are white collar computer users, or folks that support them. It’s not an exact number, but we’re talking napkin math here. Let’s be conservative and say 450,000 people.

That’s 82 years of completely wasted time every single day. For ~240 work days? A ludicrous 19,680 years every year.

Is this not insane? And this process repeats all over the country, as this chart shows:

There are other costs, too – building giant skyscraper office towers that aren’t getting filled, traffic from delivery vehicles and other support, and increased pollution. Not to mention you need to pay higher salaries to compensate for the extreme cost of NYC living.

Why aren’t these people working from the comfort, quiet, and sanity of their home?

Bright, shiny, work-in-your pajamas future

Working remotely, building remote teams and companies – these are not the “default” ways we’ve been taught to work in companies. But, it’s increasingly the way that some savvy companies are beginning to think, and default.

But for those that aren’t, there are a lot of objections to remote work:

“How can you build culture without seeing everyone each day?”

“How will people communicate and collaborate if they are working from home?”

“How to you make sure people can get their job done from the couch?”

At a half-dozen companies I’ve worked or consulted with, we had high-performing remote teams (either partially co-located/remote, or completely remote). I do not believe that to be successful, you need to cram everyone in one giant open-office nightmare.

The first cut is the deepest

The first step is letting go. Letting go that people need constant oversight. That butts-in-seats-time has a correlation with output. And you have to trust your people to do the right thing.

If you start with this mentality, everything will go a lot better. And even if you don’t manage remote people, this is the right approach in management anyway.

The best managers figure out how to get great outcomes by setting the appropriate context, rather than trying to control their people.

Fighting entropy through facetime

Did I just say facetime isn’t important for results? Yes. But, just like any garden, you have to tend it. Groups take time to gel and until that happens, you’ll have decreased performance. With co-located teams, folks are going to lunch, happy hours, and various other forms of casual interaction. This constant interaction allows people to get to know each other, know the personalities in the group, and helps smooth over any intra-work conflict.

Remote people don’t have that luxury. It’s hard to get to know someone over chat, email, and pull-requests. Without that periodic face-to-face interaction, the team might not ever “gel”..

I highly recommend periodically getting everyone together in one place and time. If you have the budget, fly everyone to one of the cities every 6-8 weeks, for a whole week. Yes, it’s expensive, but it’s necessary to shorten that forming-storming-norming-performing cycle. And, without paying big-city salaries and office rent, you generally still come out ahead.

People

I’ve found that it is a lot riskier to hire people who have never worked from home before. It’s a different work style that some might find uncomfortable or dislike.

You can encourage people to go to a coworking facility to help give them that human interaction if they need it, but some folks will simply not like working remotely.

For folks who have never done it before, I’d suggest starting out on a contract basis in case they find it’s not what they want to do (saves their resume from taking a hit, gives them a reasonable out without needing to quit, etc.).

Tools of the trade

The rest of the tools are pretty straightforward.

Default to asynchronicity in all things.

Don’t have a meeting to discuss something when a pull request or collaborative Google doc will do. Encourage rubber-duck debugging (or slow time).

Default to openness.

That means all conversations and meetings should happen out in the open – in the chat room or a recorded video chat (and the video pasted into the chat room or wiki). If someone happens to be asleep or otherwise not around, the recording or chat scrollback will allow them to get up to speed when they return.

Speaking of being away from the keyboard – communicate your schedule when you “start” work for the day, so I can plan anything I might need. If I know you’re seeing a movie with your family at 2PM, I can make sure to get what I need from you ahead of time. As they say, a failure to plan on my part does not constitute an emergency on yours.

Discourage 1-on-1 conversation

Provide for individual conversation (Skype, GChat, whatever) but only for highly specific things that are not appropriate for a larger audience. Hardly ever use email. Do not collect team member’s phone numbers or make available to the group (if you want to share your mobile # with the rest of the team, that’s up to them).

Checkin Periodically

We don’t want to silo person-to-person communication except for periodic one-on-ones. I like to do weekly (or bi-weekly) one-on-ones with each person in the team.

Automate everything

If there is any process that relies on a person doing it, find a way to automate it. This includes deployments, CI, new developer onboarding, test/staging server refreshes, etc.

Did I mention CI? You should have it, and everything should grind to a halt if it fails.

Centralize the centralizable

Any company assets should be centralized in something like DropBox, Google Drive, a git repo, or the like. If someone needs an asset (logo), they should know exactly where to look for it. Their inbox is not that place.

Trust the process

Lots and lots of people have made this work. You can do it, too! Individual tools may come and go, but enter remote work with the right philosophy, and you’ll very likely be successful.