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.