When Julien and myself decided to start TailorDev, our main wish was to create a remote-first company, even though we were only two. In this article, we describe the tools we chose, as well as the workflows and the processes we decided to follow.

On remote work

One of the most annoying things we had to deal with in our careers was meetings. Since we knew that meetings were toxic, we, at TailorDev, killed meetings, and embraced asynchronous communication instead.

Chat & Slack

Everything happens in Slack, company’s internal chat. We use private channels for projects for which external people are involved. We did that when Slack had a clear separation between public and private channels. At some point, we will get rid of those channels since we mainly use public channels now. Our public channels are organized as follows:

  • #admin is for all boring administrative stuff;
  • #business is for (yeah you got it) business-related discussions. Everyone at the company can join and talk about TailorDev’s business strategies;
  • #community is for social media interactions. We can tweet from this channel for instance (more on this in a moment), and we also receive notifications, e.g., from MailChimp and Twitter;
  • #dev is for development-related discussions. This the place where you can ask a question or mention someone to review a pull request;
  • #general is used to talk to everyone like greeting people when you start working;
  • #incidents gathers errors that require a human intervention, sent by a monitoring tool, like Papertrail (affiliate link) or Sentry;
  • #music is for sharing and discovering music. At TailorDev, we love music. We believe that music boosts (informal) chats, and that is also why everyone gets a paid Spotify subscription;
  • #ops is mainly used to interact with our infrastructure, deploying code, but also discussing about any “ops” topic;
  • #random is rarely used. We have mainly jokes, tweets, and gifs in it;
  • #activity aggregates events coming from most of our tools. We recommend to mute this channel though, since we do not have to be aware of who does what in real-time. Yet, it is sometimes interesting to be able to review what has happened over the last 24 hours.

Slack at TailorDev

We try to keep the number of channels as small as possible so that each channel has a crystal-clear purpose everyone can easily understand. We also tend not to use direct (private) messages. Finally, asynchronous communication also means we can ask a colleague a question and not worry about bothering her: we do not expect an answer right away. In case of (critical) emergency, we have phone numbers to text people. Calling someone on the phone is the last option when things go really wrong, but we did not encounter such a situation (yet).

ChatOps & Hubot

In our Slack, we have a special guest, Hubot, the company’s robot. It originates from GitHub, which they wrote to automate a lot of tasks. At TailorDev, Hubot does many things too, including “ops” tasks, a.k.a. ChatOps.

Hubot is part of our team. It is the one who remember us the AWS console URL, who can translate sentences into any language, who send us Google Maps directions, and so on. Hubot is not only fun, it is one of our most precious keys for transparency as well as a better communication in the company.

In the figure below, I let everyone know that I tweeted something. Thanks to Slack reactions that we use as acknowledgments, I also know that what I have done as been seen by my teammates. This is a simple yet efficient workflow, which avoids disturbing people for no reason. Hubot tweets in Slack

But Hubot has more superpowers, especially in the #ops channel. We can tell Hubot to deploy our applications, to fetch graphs from Datadog, or even to retrieve some logs from Papertrail for instance.

Hubot knows how to talk to our third-party services, most of us do not, and we do not have to. This is incredibly useful since there is no need to manage a lot of credentials and permissions anymore.
Furthermore, this helps being explicit all the time. When something goes wrong, everyone can learn how problems are approached because most of the actions are done in Slack, in front of the whole team. We do not automate everything yet, but it is definitely on our roadmap.

Social Coding & GitHub

Besides Slack, our second most used application is GitHub. This is the perfect place for a remote team since it provides (almost) all of our needs when it comes to deal with software. Everything lives in GitHub, from formal documents to applications, and from infrastructure configuration to press kits.

Among all the available options to work and collaborate with Git, we chose to follow the simple Git branching model. We create a branch for every change, and we open a Pull Request (PR) as soon as possible. All discussions and decisions about a change happen into a single place: its corresponding PR. Talking about GitHub, we are big fans of GitHub task lists to indicate the current state of the Pull Request.

GitHub Pull Request

In the previous section, we briefly introduced how we deploy code thanks to Hubot. When we ask it to deploy an application, Hubot talks to GitHub’s Deployment API, which is great because a deployment becomes part of the associated Pull Request. Deployment events are then received by Heaven, whose role is to deploy our applications.

GitHub deployment API

Everyone should be able to deploy without knowing which script to run, on which server, or which credentials to use. Of course we could restrict permissions (like having only a few people being able to deploy) but that is not how you inspire trust and make people more responsible. The only restriction we enforce is that people must deploy from the #ops channel. Last but not least, start considering that your deploys should be as boring, straightforward, and stress-free as possible.

For project management, we chose Waffle.io as it integrates well with GitHub. It is one of the less intrusive systems that synchronize with GitHub repositories, and it is simple to customize it to fit our needs. Waffle provides Kanban boards on top of GitHub issues. When we gather the whole team somewhere, we are also happy to play with (real) Post-it notes, even though we have to “save” it into Waffle thereafter.

With GitHub and Slack, we have many fine-grained information to know who does what, or what is either done or being done. In addition, we also use a non-intrusive tool for “macro” reporting: iDoneThis.

iDoneThis


iDoneThis is a fantastic tool to have total transparency into everything that is getting done by all of us. Every day at 6pm, we get an email asking us the following question: “Hi there. What’d you get done today?” We tend to write short sentences using the past tense, and that can include any activities that you think is interesting to share with the team (including non-work-related activities). The day after, everyone gets a digest email with what others have done.

Calls & Appear.in

Time to time, we do brainstorming or we want to talk and see the person. We use appear.in right now, and we are happy with it. We have two rules regarding video conversations. First, we have to write a minutes right after the call (and there is Monod for that!). Second rule is GitLab’s rule to start a video conversation:

11. If you agree in a chat to start a video call (typically by asking ‘call?’) the person that didn’t leave the last comment starts the call. So either respond to the ‘call?’ request with a video link or say ‘yes’ and let the other person start it. Don’t say ‘yes’ and start a call 5 seconds later since it is likely you’ll both be creating a video call link at the same time.

Frequently Asked Questions

What About The Admin?

We keep some official documents (mainly bills, invoices, and other tax documents) in our ownCloud instance, shared with everyone in the company. This is also where we host our team calendar by the way.

What About Emails?

We tend to favor GitHub issues and comments over anything else, but it is not always possible. Although we dropped most of our internal emails over the last months, thanks to the tools we covered in this article, we still rely on emails for most external exchanges. Sometimes we need to get in touch with our accountant for instance, or we receive an email from a customer or partner. We use email aliases to sort those emails, and the aliases mirror our different Slack channels. When an email is sent from our side, we cc an alias so that we bring enough people in the loop.

What About Phone Calls?

Phone calls are hard to make asynchronous. We do not make phone calls internally, it is definitely not our preferred communication mode. Nonetheless, when someone receives a phone call, she writes a transcript, sent by email or shared in our Slack.

Final Thoughts

There is still room for improvement, especially because we are just at the beginning. Our tools and processes may evolve in the future, and we will happily share updates on how we work and enforce a remote-first environment. In the meantime, you can ping us on Twitter for anything related to remote work or this article!

To conclude, it is worth mentioning that GitHub used to work that way for years, with many employees. It is a mindset first, following by great tools and processes. It does not work because we are a small team, it works because we do everything we can to make it work.


P.S.: I also recommend to watch how Buffer builds his culture with remote workers, and if you are interested in remote tips, the Remotive newsletter is awesome!


We shared some updates lately!

Remote work: 6 months later