How we work at SupportBee

A question I get quite often from friends or potential candidates is how we work at SupportBee. A lot of our processes are based on processes of other great companies, but like every snowflake, it is unique! Before we talk about it, some context first! We switched to being a 100% distributed team earlier this year but we have always valued being able to work remotely from the very beginning. Even in 2011, we wanted to be able to open our laptop anywhere in the world and feel plugged into work right away. We started with Campfire and started piping company updates like trial signups in there. Within a year, we moved from hosting our own git server to Github and to using Pivotal tracker for managing project work. The processes constantly evolved and they are still evolving today.

Flowdock, The Office

These days, we use Flowdock for group chat and updates. Even though Slack is the cool kid on the block, we find Flowdock’s seperation of inbox and team chat quite useful. We have four primary channels we use in Flowdock — SupportBee, Dev, Support & Community. In SupportBee Channel, we pipe all the company activity like trial signups, payments, upgrades etc. Apart from knowing what’s happening on a given day this also double up as a simple CRM and just by clicking on a customer’s account name, we can see all messages relating to them. Flowdock let’s us comment on a specific message so we can always discuss an interesting signup or the feedback from a cancellation. We use the group chat in SupportBee channel for general chat about work or to discuss interesting things not necessarily related to work (like staying fit or meditation).

Flowdock

In our Dev channel, we pipe all development related activities — Github Issues, updates from CircleCI and any alerts from Pingdom or New Relic. Even though we use the group chat to share interesting tools or blog posts, most of our code related discussions happen on the relevant Github Issues. This way, all the discussion about a new feature or improvement is preserved forever with the code. Many times, we have found it useful to share an old issue with new people in the team to give them a sense of our thinking behind a certain implementation.

In Support and Community channel, we discuss customer support and our community growth work (blogging, marketing partnerships etc). Everyone has access to all the channels in the company. We use 1–1 chat for scheduling calls etc. Otherwise, everything is done in public channels or tools like Github or Trello.

Managing Customer Feedback and Product Roadmap

We do what we preach and all of us participate in customer support. This way, we all get to use the software we are building and empathize with our customers. We use the SupportBee’s Trello App send any customer feedback to Trello and our Github App to send bug reports to Github.

Github issues is a bit limited when it comes to planning work and we use Codetree to organize the issues. Trello is pretty good at organizing pretty much anything and we use it extensively to manage our product roadmap, hiring and community work. I also use it personally to manage my tasks (like 1–1 meetings or any admin/legal work).

Shipping Software

If we are shipping a new feature, we start in Trello by reading up on support requests for that feature and creating some mockups using Moqups. Once we are ready to start coding, we create a Github issue and add it as a comment in Trello. From here on, all discussions happen in Github issues. We push often and deploy often to a staging environment and request feedback from everyone in the team. We use a lot of screenshots to post feedback in issues. It’s not uncommon for issues to go on for weeks and dozens of comments. Since we test drive all our code, we have hooked up CircleCI to Github and once everything looks good, we merge and deploy to production.

Mockups

Shipping Blog Posts and other non tech assets

We use a very similar process for shipping blog posts. We use Google drive for most of our collaboration and encourage everyone to give feedback. We also tweet our work before it goes live to get feedback from the community. Our blogs are powered by Jekyll which makes it very easy to update them or collaborate on them using the same Github process that we use for our Code.

40 Hour Work Week

This section is adapted from our SupportBee’s Handbook for Productivity & Happiness

We work 40 hours a week, or about 8 hours a day. We usually don’t work on weekends (unless we have an emergency or a planned release (for example if we have to bring down the primary database to deploy a feature). Working 40 hours a week gives us enough time to move at a good speed and also leaves us with enough time to rest and enjoy our life. It’s a good balance. We do try to work effectively everyday. This involves planning our day in advance, minimizing distractions and trying to optimize for productivity. If you are new to the world of productivity, we recommend you read Your Brain at Work to understand how our brain works and how to use it well.

We also recommend using something like RescueTime to understand how effectively you are using time. We don’t ask anyone to share their Rescuetime data so don’t worry about that. The idea is simple — whatever gets measured gets improved. If you are seriously about being productive, you should measure your productivity. You will be surprised by the benefits. There is of-course a lot more to our processes than I have talked about here and I hope to write more about this in the future. In the meantime, if you have any questions or comments about how you work, I would love to hear from you.

Hana Mohan

Hana Mohan