How to Work Together When Everyone’s Working Asynchronously

asynchronous work

Remote teams are forced to work asynchronously, but it can be an incredibly powerful constraint.

To Zach Holman of Github, that “everything is asynchronous” is his favorite part of working at the company. It kills distractions and interruptions—especially meetings—and helps people get in “the zone” or a state of flow for getting stuff done.

The problem that we’ve experienced recently is that to enable asynchronous work, we’ve felt that every developer had to have his own long-term project that he’d able to execute on totally independently.

The upshot is that in decoupling developer dependencies, we’ve lost focus and a coherent sense of what we’re executing on as an organization because the projects are too disparate. It feels like everyone is working on something totally different and that we’re going broadly on several things but not deep on anything in particular.

When someone on the team does need help, there’s a far more painful context switch to a project that’s potentially very different from what that person’s project is. Ironically, more help on big picture and direction is needed because the decoupled projects don’t present a unified bigger picture of product direction.

To fix the problem, we decided to go in the opposite direction—we had everyone in the company work on shipping one single thing, and that’s how we got our Slack integration out in a week.

Focus is critical for personal productivity

It turns out that for personal productivity, multitasking is one of the worst things that you can do.

Stanford researcher Clifford Nass conducted a study where he gave participants different tasks to do in order to figure out how the brain works — and he was shocked by what he found.

[M]ultitaskers are terrible at every aspect of multitasking. They’re terrible at ignoring irrelevant information; they’re terrible at keeping information in their head nicely and neatly organized; and they’re terrible at switching from one task to another.

On the other hand, researchers have shown having the ability to direct your focus to disregard impulses and distraction — maintaining “cognitive control” in psychological terms — has been shown to be a more powerful long-term predictor of future financial success than IQ and wealth.

In a thirty-year study, psychologists followed the trajectory of over 1,000 New Zealand children to find that those who became the most successful weren’t the smartest or the most well-heeled. They were the children who had shown the greatest self-control. And it’s focus, or control over the mind, that holds the key to self-control.

What focus means for a startup

Why shouldn’t the absolutely critical importance of focus also be true for startups? Stories from the early days of super successful startups like Facebook emphasize just how laser focused they were.

Back in 2005, long before they began approaching $10 billion in annual revenue, everyone thought that Facebook was a cool app, but no one thought that it would ever make any money. Observers laughed at the idea that Facebook could be a real business.

With that backdrop of doubters and detractors, Noah Kagan, employee #30 at Facebook, pitched Mark Zuckerberg with what he thought was a genius idea: prove the Facebook skeptics wrong and show them that the fledgling startup could make real money.

15growth-one-articleLarge (1)

As Kagan recounts the story, Mark listened to the pitch and then wrote out one word on a whiteboard: “GROWTH.” Then he “proclaimed he would not entertain ANY idea unless it helped Facebook grow by total number of ‘users.’”

The harshness of the story was startling and made us realize that we’d taken asynchronous work to an extreme. We had been optimizing our development for working asynchronously, when we should be optimizing for focus.

How we worked

We made our goal to launch a new feature in a week. We planned on the project the Friday before the week started, and used Asana to lay out the roadmap with tasks broken down and assigned.

On Monday, we sketched and used the sketches to iterate on the flow. We invested more time in sketching and mockups than we’d done before, because we wanted to make design changes when they were cheap, not when they were in code and expensive.

Screenshot 2014-11-04 19.37.30

An early mockup

On Tuesday, we built. On Wednesday, we refined and made sure we can deploy it. On Thursday, we released and executed on the go to market. That left us with Friday to fix issues arising from the Thursday release and plan for the following week.

We strove to have a war room-level of focus, accountability and vigor, without the long hours and physical, synchronous work in the same room.

Our team is spread out between New York, Wisconsin, Germany and Italy, so we have timezone overlap, but not much. We used iDoneThis and to manage the carryover of work from one day to the next by briefly explaining what we did, why and what was upcoming.

Whenever anyone woke up, the first thing to do was check iDoneThis to sync up on progress that happened while they were away from the keyboard. If there was a slippage or change of plan, the what and why would be noted in iDoneThis with the timeline revised in Asana accordingly. That made it simple for us to stay in sync and focused, asynchronously.

What we learned

There was a stronger sense of cohesion and teamwork than we’d had in previous weeks, because we were all working on the same thing. When someone needed help or got stuck, it was easier to remove roadblocks and help with a fix because we all had more context around what each other was doing.

Working on the same thing, especially given the short timeframe, focused us on only the essentials when it came to what to build on the product, and we ruthlessly cut non-essential work. The flip of that is that we did accrue technical debt. We made an attempt to note the debt we saw, be intentional about the decision not to address it, and set aside time in the future to pay down that debt.

We were still able to work asynchronously for the most part and didn’t feel the increased need to be online at the same time or in video chat / meetings. Attempts by the U.S.-based folks to wake up at 4am-6am daily didn’t last anyway!

Most of all, we found that being focused wasn’t at odds with asynchronous work.  We had to be more deliberate and explicit about how the work would be divided and executed on, but having to think about that made us better.  With remote work, you have to be explicit and intentional—you can’t cram your team into the same room for a month and just take for granted that everyone’s focused.  And that’s a good thing.

Of course, there’s still a lot of experimentation to do on how we can work better and produce a great product. This is just the starting point for iterating on how we get stuff done. We’d love to hear what you think and how your team gets stuff done in the comments!

What we made—iDoneThis for Slack


After a week’s worth of hard work, now you can use the integration we built to post dones directly from within Slack!

output (2)

Go here to get the Slack integration or read more about it here.

Not using Slack? Stay tuned for HipChat and Google Calendar integrations. (Looking for something else? Tell us!)

Image: Rebecca Partington