Last week, I came to a pretty startling realization: since joining the Flowdock team three months ago, not a single internal email had been sent in our team. A big reason for this, no doubt, is that 90% of our team sits in the same room. But the main reason is that our team has moved from email to other, better team communication channels.
Email has a few things going for it. Everyone has an email address and it’s easy to use. But it also has many problems: the sender decides who participates in conversations, all messages have equal weight, the prevalence of unhealthy usage patterns and spam, to name a few. Many email clients try to cover up these problems, but at its core, email is still broken in many ways.
Thankfully, much of the communication that used to take place over email has moved on to services that support different parts of a team’s workflow much more effectively. Code-related activity and discussions have moved to GitHub, task management is done in Trello, the development backlog is managed in Rally, feedback is gathered from Twitter. And, for us, Flowdock is used as a team chat room that also acts as glue between all these services.
Using specialized tools over a general purpose one (like email) has huge benefits. They allow the team to share more relevant information, make better decisions, react faster, battle information overload, be less frustrated – and, overall, work more effectively. By adding a centralized hub (like Flowdock) to the mix, team members don’t even need to constantly jump between these services to check for updates.
In this post, I’m going to share how the Flowdock team uses an interconnected set of tools to support their daily work – a set that has completely eliminated email from teamwork.
Even though most of the team sits in the same room, the majority of our discussions take place in Flowdock. We’re strong believers in working asynchronously.
Our flows are organized as follows:
- Flowdock. The main flow where most discussions take place. Runs in our QA environment. Integrations: GitHub, Trello, Exceptional, Jenkins, Hubot, other test automation, deployment messages.
- Ops. A real-time view of the status of our different environments. Integrations: Nagios and other monitoring tools.
- Android. For our Android client development. Integrations: GitHub, Trello.
- iOS. For our iOS client development. Integrations: GitHub, Jenkins.
- Media tracking. Using RSS feeds and Twitter keywords, we track what’s going on in our industry. Integrations: Twitter, RSS.
- Flowdock support. This flow is mostly used for customer support. It’s also where Rally Software employees (who are not part of the Flowdock team) come to follow our progress, give feedback and ask questions. Integrations: Zendesk, Twitter, GitHub, RSS, Trello, deployment messages, email lists.
- Loldock. Self-explanatory.
Interconnected Software Development
Flowdock’s code lives on GitHub. We’ve integrated GitHub with our main flow to get real-time notifications in our team inbox about commits, comments and pull requests. Whenever code is committed to our master branch, Jenkins automatically makes a new build and tests it. The results of the build and tests are visible in our flow. If all our tests pass, the build gets deployed to our QA environment. If it fails, our Hubot bot publicly curses out whoever was responsible.
When someone wants to make non-trivial changes to our code, instead of committing straight to the master branch, they create a feature branch. Once the changes are ready to be merged, they create a pull request. This, in turn, is reviewed (and merged) by anyone on the team. Clarifications are asked and issues are brought up on GitHub, which usually sparks a conversation thread in Flowdock.
To deploy our QA build to production, we run a deployment script that gathers information about all the commits that have accrued since the last deployment and emails them to our flow’s email address. The message is automatically tagged
#production. This is an important step; combined with our practice of informing everyone with a
#production-tagged message whenever you change something in production, a search for
#production gives us a nice changelog of our production environment. This is very useful when trying to figure out why something broke or when some feature was deployed.
For bug tracking, we use a similar tagging convention. Whenever someone runs into a bug (or one gets reported by a user), if we can’t fix it straight away, the problem is described in our flow in a
#bug-tagged message. When the problem gets fixed, we remove the
#bug tag. A search for
#bug thus produces a list of live bugs.
Exceptions in our production code are tracked with Exceptional. Whenever a user encounters an error, we get a real-time notification in our main flow, which allows the team to assess the severity and (possibly) fix it quickly.
Responding to Feedback
Due to having many passionate users, we get quite a bit of feedback. Responding to it in a timely fashion and resolving any issues is very important to us.
Feedback comes to us from four different channels: Zendesk, Twitter, UserVoice and email. Messages from all these services appear in our support flow’s team inbox. When a team member replies to feedback, they add a “replying” comment to the team inbox item. The purpose of this is twofold: it makes sure that no-one else replies at the same time and indicates that the issue been taken care of. If the person is unsure about how to resolve the issue, they discuss it with the rest of the team in the flow.
A side note: we believe that everybody should be doing support. We don’t have dedicated support people. Keeping the support ticket queue empty is our whole team’s shared responsibility. Answering support tickets is one of the best ways to keep a finger on the pulse of your customers’ needs and problems.
Being Part of a Larger Organization
Even though Flowdock is mostly designed and developed by a team in Helsinki, Finland, Rally Software is a global organization with offices around the world. Our iOS app, for example, is developed in North Carolina.
Thankfully, asynchronous communication works well with distributed teams. We can follow development progress from the GitHub feed in our iOS flow. Discussion about the details of the app happens in the flow both asynchronously and, when we’re online at the same time, synchronously. New development versions of the apps are distributed with Testflight, and when we run into bugs, we report them in the flow.
A Culture of Transparency
Transparency is deeply ingrained in our work culture. People make the best decisions when they have the right information, and it is impossible to know beforehand who needs what information (and when). It’s difficult to overcommunicate – and if you manage to do so, you’ll quickly hear about it.
We use Flowdock to help us achieve transparency. We strive to have all discussions in flows instead of private 1-to-1s; that way, people interested in the discussion can follow along or take part, and those who aren’t can ignore it. Chat threads turn individual messages into color-coded discussions that can be mentally filtered out (or in). You’d be surprised how often an answer to a question comes from someone you wouldn’t have expected beforehand.
We also cc or bcc practically all sent email to our flow’s team inbox. Our mailing lists (
firstname.lastname@example.org, for example) forward all emails to our flow. Again, this helps the whole team stay up to date and take part in discussions that otherwise would have been invisible to them.
Yet another example of transparency relates to meetings. Whenever someone takes part in a meeting, they summarize the most important parts and post the summary into our flow (along with a
#palzu tag, Finnish slang for
meeting). This leaves us with a backlog of meeting notes from all of our team’s meetings in a conveniently accessible format.
The Challenges of Transparency
Transparency, unfortunately, has a downside: information overload. With so much available information, it becomes harder to find the stuff that is relevant to your work. Notifications pull your attention in a million directions at once. The sheer volume of data means that you won’t be able to follow everything, and this frustrates many people. Email exacerbates the problem: all incoming messages have equal weight, and thus vie for your attention equally, no matter their true importance.
Luckily, we can mitigate this problem. Most communication channels have built-in ways that help users categorize and filter content. As an example, in Flowdock, flows act as filters, and tags are a way to categorize content.
For these filters to be usable, the incoming messages needs to have enough metadata – information about what a message’s content is about. Part of the metadata can be added automatically (like the
#production tag in our deployment messages), but much of the work is manual: how flows are organized, how messages are tagged, the discipline of the team in tagging messages, what services you decide to integrate with, etc.
On the flip side, as a recipient of information, knowing how to use a channel’s filters is crucial. Filters (which flows to join, who to follow, what search terms to use) help you find the right information, and block out irrelevant noise. Being able to adjust the relative importance of a topic – how easily you want to be notified about it – is an important feature of the channel.
We believe Flowdock can help its users be more transparent, but also battle information overload – both as senders and receivers of information. We are currently working on many things to improve Flowdock in this regard: from flow-specific notification settings to smarter metadata generation.
Balancing transparency and information overload is hard. With the ever-increasing amount of information that’s available to us, it’s also a problem that isn’t going to be solved any time soon. However, with the right culture, the right tools and a bit of discipline, you can go very far.