Working in a distributed team? Reduce email, use async tools

At Hackers & Painters last Friday, Jon Yongfook Cockle shared with a full-house crowd how he managed to build his online business while traveling around Asia.

As an independent technopreneur who manages his own Lean customer discovery cycle, designs his own interface, writes his own code and supports his customers online, Yongfook is able to live a balanced digital nomad lifestyle beautifully. Over a period of one year (since July 2013), he has built a web application with a strong value proposition that serves his target customers; and has created a sustainable online business with a recurring revenue that allows him to travel indefinitely.

What about teams?

His presentation led me to ask myself a few more questions in the context of a bigger team.

  1. If you are working in the context of a team to run a slightly larger business, can the team also function effectively as digital nomads?
  2. What are the skills and tools we need so we can collaborate effectively in the context of a team?
  3. What if you have a hardware component to your product and you are not building a 100% software product?

Before I began my journey to build an Optometry solution/product in AlgoAccess, I was working in a semi-distributed team as a tech consultant – with some colleagues working in Europe and some working locally in Singapore.  In that context, I set up and manage tools such as Redmine, Gitlab, Emails (obviously), Skype and use online invoicing tools like Freshbooks to keep the whole team in-sync.

My current team in AlgoAccess is a co-located team until recently. Over a period of 7 months of co-located work since Jan 2014, we have designed and built an Optometry solution from the ground-up.  We have raised a seed round of angel funding from veterans in the Optometry industry and we have designed and built a fully working product over 4 sprint cycles and a couple of months of on-site customer discovery and product trials.  Our product development pace is balanced and fast as a co-located team and even though our team also included 3 software interns, the co-located environment allowed us to share knowledge quickly, level up as a team and handle uncertainties with regards to product decisions (a typical challenge new products always face).

From co-located to distributed

This brings us to the next phase of our company/team – can we still function effectively in a distributed manner?  Now that the interns are heading back to school but continuing with us as junior developers and one of our core engineers will be working from the States AND we have a new mum who will be working in a flexible manner from her home and I will only be working on-site with customers or with hardware as needed – can we still share knowledge and skills effectively and continue evolving our product to serve our customers?

In technical jargon, we are transiting from an Agile/Scrum team into an Async Development team (special props to Adrian Quek for teaching me this term “Async Development”).

In my mind (and based on my previous experiences working in a distributed team), it is a challenging task to operate as a distributed team but it is completely possible. Many successful tech companies like Github, Treehouse, 37Signals (37Signals do have a core co-located team though) and Buffer have continued to grow and succeed as a distributed team.

In my opinion, these are some criteria, skills and tools that are pre-requisites for a distributed team to succeed:

  1. The hiring process must be rock solid and the company must be prepared to pay each individual well.  Distributed teams depend on the fact that each individual in the team has good mastery over specific tech knowledge and skills and each person must have good time management skills and be able to use a variety of tools (mock-up tools, communication tools, coding tools) to function effectively.
  2. Effective tools and shared understanding of systems must be made available to support the team’s day-to-day operations.  For instance, the ability to communicate fluently at code level and review code in Gitlab is critical.  The ability to illustrate software workflow in Illustrator or Photoshop and share ideas on Trello as a product development tool is critical. Members of the team should also avoid creating busywork by communicating using emails; instead, use communication tools like Slack which integrates with Trello, Gitlab and Google Docs effectively
  3. Jon Yongfook Cockle specifically mentioned that the best kind of businesses that are suitable for digital nomads are businesses which do not have any “hardware” or “physical product” components.  In our situation, this is unavoidable as our Wifi/BLE peripheral (hardware) is an integral part of our Optometry solution for our customers.  Fortunately, this peripheral is not too complex and in my opinion, it is still possible to provide the necessary hardware components to specific members of our team so that they can work from home; or simply head down to our co-working space at Blk 71 to work on the hardware integration work whenever required.
  4. Don’t always work with each other remotely — it is important for members in a distributed team to meet once in a while for casual get-togethers OR for serious work.  Nothing builds trust like face-to-face communication and in order for a distributed to work effectively, there needs to be a continual “maintenance” of trust between team members.

As our team transits to a more flexible working style, it is important for each individual to keep learning and keep improving their skill set in order to function effectively and continually contribute to our growth as a company and provide good support to our expanding customer base.

Aren’t Emails asynchronous in nature?


The problem with emails is that they create information silos.  This hinders autonomous involvement in actionables and creates long chains of discussions which end up being busywork when nobody takes ownership on decisions and actionables.  Favor the use of tools like Slack which allows individuals to choose for themselves which channel (of discussion) they would like to participate in, public and/or internal wikis and blogs so the barrier to participation for distributed team members is limited simply to a “search” action.

Individuals should acquire the ability to communicate effectively using various tools – public blogs (like this one), slack for internal communication and reduce busywork created by emails.