How Our Developer Squads Use Slack, Phabricator & Google Docs


Maximizing our productivity is key to meeting goals and releasing on time. We use all sorts of project management tools, but we also have a series of informal guidelines as to how we use Slack, Phabricator, and Google Docs among our developer squads. Specifically, how we integrated into their API, follow informal internal guidelines of conversation, and how the tools themselves work great to make our work great.


Slack is a great marriage of one-on-one and group discussion tools. Slack channels can contain a group of people, where you can still call out individual people with @ mentions by name, or via “@channel” to notify everyone in the channel. We organized our channels by topics and teams, which can cover project-related items or even our next engineering outing.

The true power of this tool is in its API. We’ve integrated things like Jenkins build failures, production system alerts, link-generator bots—where, for example, I type in a ticket number, and the bot generates a link to that ticket in our tracking system. (Of course we added some bots to provide comic relief throughout the day.) We can also upload files, post URLs (which automatically display the metadata – works really well with Google Drive links), and organize our contacts and channels very neatly in the nav.

Not only has Slack reduced our email volume, it reduced the amount of info that can be lost in a one-on-one conversation. We now encourage majority of conversations to happen in a group setting unless it’s truly a private matter. And since you have the ability to subscribe just to channels relevant to you, as well as get notified when you’re specifically mentioned, the signal-to-noise ratio is very good.

It’s really opened up our communication channels tremendously. Email is an “offline” communication channel, whereas chat is “online.” An email thread also puts the burden on the original author to know off the bat who include in the thread. More often than not, people are added to that thread later on. So when a group of stakeholders are having a discussion in a chat room, and they need a manager to weigh in, it only takes a simple mention to bring them up to speed. “Hey @michael, you had this issue last week, can you paste the solution?”


We’re also switching our ticket/sprint/bug tracking system to Phabricator, a suite of dev tools coming from Facebook. It does ticketing with agile/kanban style boards has good vcc integration, a code review app that’s very nicely integrated into our git flow, and lots of other goodies. Compared to others, we found Phabricator to be light-weight, easier to administer, and—best of all—it’s free. It’s certainly not as mature of a product, but there’s a wonderful community behind it. In fact, our own Chris Burroughs has contributed to the project.

We recently made all of our old subversion repositories read-only, and are fully on git now. Adding Phabricator into the mix has also been a game changer. It allows for pre- and post-commit code reviews and audits, letting teams decide what works best for them. A majority of our groups use both approaches, and we trust the devs to use their judgement. If someone is working on a significant change, they do so on a branch and continuously commit there.

Once they’re ready for a review, the dev runs git rebase master to get their feature branch up to date with the main tree and submit the code for review. We do so with a Phabricator cli tool called archanist. Run a simple arc diff command, and the branch is uploaded into Phabricator where you can specify who needs to review the code. Reviewers can add comments right on there, and easily see any new changes since the last review. When the review is accepted, the dev runs arc land, and the branch is automatically merged back into master and pushed to remote. Small changes are allowed to bypass this process, and teams are required to do post-commit audits of all changes. It takes only a few minutes to audit changes from the day, but it keeps more people in tune with ongoing work without being disruptive.

If you’re not running a code review process internally, even if manually, you really should be. I’ve lost count on how many defects were avoided as a result.

Google Docs

Though Google Docs isn’t the full-featured Microsoft Word software, it’s not that far from it and makes us crazy productive. My two favorite features are Comments and the ability for multiple editors at once. Forget the nightmare that comes with version control when docs are sent via email. Google Docs allows the author to grant certain permissions to editors—some can only view, comment, or edit. And no matter how many edits you go through, Google keeps the versions saved and all the comments so you can go back to it if you really need to. You can also get more than one person editing the doc, really allowing for multiple contributors. We jam on new ideas quite often, and it’s a lot better to leisurely work on a document together than scheduling a meeting to discuss the topic, assigning someone to start the doc, emailing a group of people, and then . . . well, you get the point.

These are three tools and the guidelines we follow to help make our productivity insanely better. Does your developer team do any of these things? Any other project management tricks your team uses that you’d like to share?