Remote

Nine ways to kick ass on a remote team

It's my ten-year anniversary of working remotely. That's a decade of coding at home in my underpants.

In that time, remote work has gone from being a fringe idea to being a mainstream industry and lifestyle.

Best practices for remote work are emerging, but they're far from codified. These are the things I do every day to make sure my projects run smoothly. They've made my teams happy and my clients happy.

1. Use (and learn!) a project management tool

It all comes down to threading. Every single time I've used email or chat to clarify requirements, it started a death spriral of scrolling up in the chat log to find the thing I said last week or last month. When you keep everything in context, it's a lot easier to track everything.

And keep it a simple tool. Just use something that has support for making comments in separate todos that you can mark done when they're done. Forget complicated velocity tracking and projections. They're going to be wrong anyway.

2. Invite the developers to every planning call

An agency I used to work with would exclude me from scoping and discovery discussions with their client. Their creative director would meet with the client, then relay the client's vision back to me.

Because of this, there were constantly questions left unanswered at the end of our planning sessions, since I tended to ask specific questions the creative director couldn't answer.

So he went to the client to ask them for answers.

And then we'd meet again. And the cycle would continue.

It's powerful to have constant contact with stakeholders. Introduce the team to your client and foster their relationship. When I do, I find the project ends up running itself.

3. Invite the client to every planning call

Building software is an amazing adventure because we get to work on projects in all sorts of industries! I've worked in fashion, pharmaceuticals, government, social media, and energy engineering, just to name a few.

Because of this, we're at the mercy of our clients to really know what they need built.

The why is critical. Make your client the focal point of your sprint planning.

4. Batch and limit conference calls

Meetings and conference calls are the only way to brainstorm and discover new features. They're also the only way to plan a development sprint.

But they're expensive. They demand the full attention of your entire team. If you have a two hour meeting with your four team members, you've lost a full workday's worth of work to that meeting.

I do my darndest to limit mandatory meetings and conference calls to under 10% of my total work hours, and batching that time all at once. The planning has to get done, but getting it done all at once means you're free to create and produce the other 90% of the time without interruption.

5. Make every task actionable

Semantics are important.

If you need to build the new marketing site and you add a task with the caption "Build new marketing site", you're going to spin wheels trying to figure out how to get it done.

But if you identify the pain points within that monumental task and sketch them out in separate tasks, you can delegate and accomplish each of them separately.

So maybe you write "Survey CMS's for new marketing site" and "Pick CMS for new marketing site" and "Deploy CMS".

And then you break down each of those tasks.

And then if it's necessary, break those down.

Suddenly, everything is in view and your team can execute.

6. Refine incomplete tasks

If there's a task that's done except for a tiny edge case, add a new task to cover the edge case, call the original one done, and make a note of it in the old task.

Now you're razor-focused on the edge case. And now your team can better assess the sprint progress without digging into every single task ticket.

7. Peer review every commit

I used to resent the process of mandatory peer review. But after having been humbled by being called out on my bullshit a few times, I can attest to the value of knowing someone else's eyes have grazed my work before it goes to production.

8. Don't use email or Slack to delegate tasks

If there's work to be done and you want to ask someone else to do it, open a ticket in your project management tool and assign them.

Don't explain it in Slack.

Don't send them an email.

A project management tool is designed to track and manage project requirements and progress. Email and Slack are fantastic platforms for informal communication, but if it winds up in the product, make sure it has a ticket.

See #1.

9. Close email and Slack most of the day

This is my superhero hack. And it's hard, because we're conditioned to be responsive and always-on.

But the truth is, the world won't end if you disconnect and focus on one thing for a few hours. I have to tell myself that every time I do.

Slack and email have their place, but it's not in the middle of your focused creative work.

I limit my Slack online time to an hour each morning, and I check my email twice daily. Sometimes I break these rules, but I think they're worth aiming for.

Read Cal Newport's book Deep Work and watch Merlin Mann's Inbox Zero talk for more on this.

Your best candidates demand to work remotely

Tuesday morning. It's 6:32am. You yawn. You stretch and turn over on your side. No alarm woke you up. You, like most highly-productive people like waking early. You rise, stretch again, and don your bathrobe. You go into the kitchen. You press play on a podcast, leisurely cook yourself a healthy breakfast, eat, and then make coffee. It's 7:41am.

You sit at your desk and decide on your first task. You work, with no interruptions, for 1 hour and 54 minutes. It's 9:35.

Most people are still stuck in traffic, but you just clocked nearly 2 hours of completely uninterrupted work.

You take a break to stretch and make some more coffee. You check your email, because you know checking your email before you complete your most important task of the day is the best way to ensure it won't get done. You process all your email. Inbox zero. It's 10:00.

You have a brief, 5-minute meeting with your team members. You do this every morning. Once the call is over, you work again, with laser-focus, for another hour.

It's lunch time. You make a healthy salad for lunch. You spent only 28% of what it would have cost to buy a comparable lunch at a restaurant. You take your time washing the dishes.

You decide you'd like to take a walk. You take a leisurely half-hour walk around the neighborhood. You remember you need to buy some toiletries, so you stop at the grocery store.

When you return to your house, you sit for another two hours of uninterrupted work. Your superior is thrilled with your output. You are thrilled with being able to work on your terms.

It's 4:35. You turn off your computer and go spend time with your family and friends.

If you work remotely, it's likely you're familiar with the lifestyle I portrayed above. Thousands of programmers, designers, writers and other creative professionals are working remotely and enjoying the fruits of a self-driven, telecommute lifestyle. And thousands of companies are reaping the benefits of sourcing the best talent by allowing them to work on their own terms.

The Best Will Demand It

If your organization doesn't allow remote work, it's not attracting the best talent, because the best talent will demand to work remotely.

Remote work is becoming more common, and your best talent isn't having a hard time finding employment with remote-friendly employers.

The best talent has invested in creating a home workspace tailored to their personal tastes. They have created the ideal place for their productivity to flourish, and you didn't spend a dime. They've created systems that enhance their unique work style and culture.

Your best candidates are self-motivated, outcome-oriented people. Why would someone self-motivated and outcome-oriented want to spend their entire day in an office? They want to be spending their days productive when they can be, and enjoying life when they run out of steam.

They recognize the finite nature of time, which is why they strive to do excellent work for you while reserving the right to enjoy mid-day leisure.

Creative knowledge work is unlike the industrial and clerical work that came before it. There is no longer a linear correlation between hours worked and productivity. A programmer who works eight hours in a row will not produce twice as much as a programmer who works four hours in a row. I have personally found that I reach my productivity ceiling at around four hours' work in a day. Why are you requiring your team to stick around for eight hours straight?

A Broader Base of Talent

According to Payscale, the median salary for a senior web developer in San Francisco is $102,157. In Seattle, it's $83,903. That's an $18,254 difference, and they're happy to split it with you.

If you're hiring for a San Francisco company and you source your developers from the north, you could incentivize your candidates with a $9,127 salary increase over their local Seattle options, and save $9,127 per year compared to hiring someone in San Francisco. It's a win-win scenario for both you and your new hire.

With hyper-specialization becoming more common for technical workers, hiring outside your local metropolitan area also means you're able to find talent with experience that better matches your organization's needs.

When you offer a relocation package, you incur the additional risk that your new hire won't be the star player you thought they'd be. You'll have lost the airfare, the moving expenses, and the time spent interviewing and training them. When you hire remotely, your hiring costs are minimal.

Commuting is Expensive

In America, the average commute to work is 25.5 minutes. That's 51 minutes per day, or 4 hours and 15 minutes per week. That equates to a 10% pay cut: 4 hours of unpaid time for every 40 spent working. But that's not the worst of it.

The average per-mile cost of operating a sedan in America is $0.60. Assuming a 30-mile round-trip commute, that's $18 per day, or $90 per week spent commuting, in addition to the opportunity cost of the lost time!

Consider an average-salaried San Francisco senior web developer. They make $102,157 per year. Assuming they work 50 weeks per year, for 40 hours per week, that means their effective hourly rate is $51. When we apply their effective $51 hourly rate to their time spent commuting, their opportunity cost lost to commuting is 4.25 hours × $51 = $216.75 per week. That's an annual cost of $10,837.50. Add the cost of operating the car, and their effective salary dropped $15,337.50.

Commuting has turned your candidate's $102,157 salary into $86,819. That's a 15% effective pay cut. Armed with this knowledge, how many of your best and brightest candidates do you think would agree to a daily commute?

Conclusion

Remote workers enjoy a lifestyle that cannot be valued in dollars. They are high-output, self-motivated professionals who recognize the opportunity costs associated with mandatory office hours, and so they seek employment with firms that also recognize these costs. The life of a remote worker is richer and less restrictive. This richness and freedom will translate into better work for you.