Written by Chris McGreal (Co Founder & Product Owner)

When we first started Cordial, the founding team put a lot of consideration into operating as a distributed team. Of the four founders, Jeremy and Adam are located in San Diego, David is in the Bay Area and I am living in a yurt off the grid in a remote area of Big Sur. We decided to headquarter in San Diego, but we also decided we would be open to building a distributed team. This allowed us to hire the right people based on talent, without the constraint of finding ALL of our talent in San Diego. The core San Diego team has since grown and the distributed team now includes folks working from Orange County, Minneapolis, Kiev, Calcutta, and Belgrade.

There’s been plenty of discussion around the merits of working remotely over the past few years, at topic which peaked in the media 2 years ago when Marissa Mayer pulled the plug on remote employment at Yahoo. Arguments in support of distributed teams are pretty well established, so it is not my intent to rehash these arguments. Jason Fried, Basecamp (formerly 37 Signals) CEO of wrote a book “Remote” on the subject that makes perhaps the most succinct case for remote contribution.

Operating as a distributed team has been a work in progress. Without getting into Cordial’s actual development methodology (another topic for another post), we have found certain principles, process and tools to be integral. We’d like to share what we’ve learned so far.

3 Simple Principles

As we ramped the engineering & product development team, there were a few basic principles we decided were critical for our distributed team to succeed:

  1. Autonomy
  2. Trust
  3. Ownership


Talented contributors are by nature self motivated, self directed and have a strong desire to be highly productive. Give these folks the right direction, the right tools to communicate and get out the their way. This doesn’t mean, give them a task and ignore them. It means give them a goal and allow them to decide how and when to accomplish the goal. It also means you have to provide good methods or tools for them to collaborate and communicate often, even if that collaboration is asynchronous. The right level of autonomy will lead to a stronger sense of ownership.


We’ve recognized the talent of our team, and we’ve given each other autonomy, because we absolutely trust each member to make the right decisions or illicit help from others when there is any doubt about a decision. We prefer to give each other goals versus instructions and we favor clear and frequent communication over micro management. Remote work advocate Richard Branson says “To successfully work with other people, you have to trust each other. A big part of this is trusting people to get their work done wherever they are, without supervision.”


As the Product owner and UX lead, the final product delivered is my responsibility, but that doesn’t mean I need to “own” the entire process. A strong sense of ownership is an ethos shared by every contributor in our process. We start a project with user stories, requirements, wireframes, and sometimes a prototype. The developer may take the reigns and steer things in a slightly different direction due an architectural reason that was unforeseen by the designer. The developer works with the product owner to communicate the reasons for a change. If the developer took the attitude that a task was simply “work to be fulfilled by a deadline”, without the sense of ownership, we have lost an opportunity to deliver our best as a team of owners. This sense of ownership must be felt by all contributors from the Product owner, to the designer, developer, QA Engineer, and dev-ops person. The true sense of ownership must be felt collectively.

Rethinking the “meeting”

With a distributed team, especially when multiple time zones are crossed, large face to face meetings can tend to ostracize those who cannot attend due to geography. Meetings with more than 3 people, more often than not, tend to be about planning to solve problems or talking about solving problems versus actually solving problems. Hunkering down with one or 2 other people to actually solve a problem is a much more valuable and productive use of time. If your day is peppered with meetings that have to be attended in real time, you break your rhythm and focus. Zach Holman, speaking about Github’s sparse use of meetings, nails it: “you want your employees to be in ‘the zone’. Putting people in an atmosphere where they can only work for an hour before a team meeting pulls them out of that flow.”

Larger group meetings have their time and place, but they need to be well focussed, purposeful and scheduled sparingly. Replacing gratuitously scheduled group meetings with more efficient asynchronous methods of communication, not only allows more people to stay in the ‘zone’, it also creates a healthier forum for everyone to consume the content of an important discussion at their own pace. Giving people time to react and respond can actually foster more thoughtful participation. Any Singleton, CEO of Assembla, notes: “…many hard-working people prefer asynchronous communication. Even if they are sitting at the next desk, you will see that they often email each other and respond at leisure. This trend is particularly strong among young people who prefer to receive text messages rather than voice calls.”

Tools to empower our principles

Learning to communicate asynchronously

There are times for synchronous communication and times for asynchronous. Asynchronous channels of communication are important for a distributed team because they leave a footprint where information can be consumed by a contributor. The idea is that you can respond to a conversation when you have the time and focus to respond, without a need to be hooked into every dialogue that is happening in real time. This is important when you’re team spans across time zones. Fewer meetings should not mean less dialogue, it should mean more focussed and efficient dialogue.


Slack, a tool that powers both synchronous and asynchronous communication has become our main hub of communication. Slack offers one-on-one private chats that we typically use synchronously. Slack allows you to create many public channels that are focussed group conversations around a specific topic. For example: we have a #sales-support channel, and a #competitive-landscape channel that are ongoing conversations. We’ll spin up channels around an open initiative and suddenly the dialogue, previously happening in a black box of private chat, becomes something consumable and participatory for other stakeholders. All historical content is available and searchable. You can also @mention other team members in a thread if you want someone’s specific attention. I would recommend turning off browser notifications or they can become too chatty and distracting. Their mobile app is also awesome. It can take a while to get used to asynchronous conversations where a reply may not come immediately. Slack also has great webhooks that allow us to pull in Assembla tickets, Zendesk tickets, idonethis “dones”, and our shared team calendar.

Assembla for ticketing and tasks

We use Assembla for our code management, release management (Git), task management and ticketing. I like the view which gives us a Kanban style cardwall of tasks. We have customized columns for Design, Development, Needs Review, QA Ready, Release Ready, and tickets are assigned to developers (pushed) or pulled by the developer, reviewer, or QA Engineer based on capacity and prioritization (tickets are color coded by priority). This is a great way to visualize the progress of tasks through your development life cycle.

Jing & Screencast

Jing is a video capture software and Screencast is the sister product for hosting the videos. This tool is incredibly useful for explaining complicated steps to reproduce an error or demonstrate a workflow. This helps ensure that there is less misinterpretation of something described in a lengthy text document, which can be more apt to happen when there are some language barriers.

Trading Agile ceremonies for asynchronous communications

We’ve created a #daily-dev-status channel in Slack that serves as a replacement for a daily face to face standup meeting. It is our version of a distributed scrum. This channel allows the team to post quick updates about what they are focussed on and any blocking items they need help unblocking. All Assembla ticket updates and comments are also pushed to a channel in Slack, which is another way to monitor daily progress.


The grandfather of asynchronous communication. The majority of my email has been reduced to private communications not fit for a channel or chat. The overall volume of email I consume daily has been drastically reduced within the past year.

Synchronous communication is still vital

Synchronous, real-time communication is also very important, and is most challenging when working across time zones. In this case, there is no way around the fact that if you want a real-time chat with someone halfway across the globe, someone needs to be online at an odd hour. Luckily a couple of us are night owls, myself included, and this allows us to have a chat or video hangouts with our overseas contributors. Because there is a strong sense of ownership, it is not uncommon for an oversea contributor to pop in for a conversation during our morning (late in their evening).

Google Chat

Even though most chat occurs in Slack, we often ping each other in Google Chat, where for some reason it seems to be more expected that if someone is online, they will respond in real time. But since we started with Slack, I’ve noticed Google Chat use has gone down significantly.

Google Hangouts

Google Hangouts is a great way to run a quick audio or video chat with 2 or more people. We use Hangouts for our weekly general team meetings and for ad hoc meetings during the week. It is especially useful for video screen sharing.

Google Docs & Sheets

So much great collaboration is done using these free tools. Most of our tickets and channels are sprinkled with links to Google docs. Multiple people will often huddle on a single shared document and work together on a problem while chatting on the phone or a Hangout.


The phone is still one of the most critical synchronous communication tools. As soon as a chat starts to feel too long winded, complex,or if the tone becomes hard to read (snarky?, frustrated?… am I imagining this?…) it’s still best to grab the phone and knock out an issue quickly.

Face to face

As often as is possible, it is absolutely crucial to get real life face time with as many team members as possible. I get into the San Diego office every month for a chance to get in a room with teammates. Some team members are much more social, have a desire for more direct face to face human interaction while working. Those folks will put more hours in at the office than others. When it comes to personal dynamics, there is no replacing face to face communication. It is very important and should happen at a fairly regular interval if possible.

All in all, working as a distributed team has been, and will continue to a be, a work in progress. It is an important part of our culture and I’m hoping it will evolve as quickly as our technology. New tech, tools, apps and innovations will continue to offer specialized solutions to the challenges of working remotely in ways that are effective and efficient. Things will probably look very different in 10 months…

Leave a Reply

You must be logged in to post a comment.