How we scaled technical discussions in the Android team

Published in

Babylon Engineering

8 min readAug 24, 2020

A vital part of the success of a technical team is discussing how to improve its technology stack and processes. In this article, we’ll cover the tools the Babylon Health Android team used to facilitate discussions, as we grew from 5 to 40 engineers in the span of 4 years.

What conversations does a technical team have?

Here’s a non-exhaustive list of things that we have discussed over time. Technical:

Introducing new libraries into a project.
Finding limitations in our coding conventions/libraries/app architecture and suggesting changes.
Making suggestions for new tooling to improve the developer experience.
Making suggestions for changing our CI pipeline.

.. and not so technical:

Discussions around process, like the kinds of meetings we have or how we conduct interviews.
Discussions about our support/release rotations.
Organizing a hackathon, or a night out with the team.

The way these conversations happen within our team has evolved over time, depending on our size, maturity, location, and other parameters.

2016 - Starting out

The in-house Android team was only 5 engineers when it was established in 2016, so it was easy to have all discussions either in Slack or face-to-face. We also had an hour-long session every two weeks to discuss as well. While this seemed to work rather well for our size and team (im)maturity, it did also presented some challenges:

Ad-hoc, face-to-face discussions meant it was easy for people to be excluded from decision making, either because they were working from home, working remotely, or just weren’t at their keyboard when a discussion was happening on Slack. Furthermore, most meetings weren’t recorded, so it was hard to understand why something happened.
Our bi-weekly meeting was great, but sometimes you couldn’t wait for two weeks before discussing something.
No one knew the agenda before the bi-weekly meeting started. This meant that no one could prepare for it.
Context switching is a thing, and it was affecting the engineers who had to pause whatever it was they were working on to join the meeting with the whole team.

2017 & 2018 - Team gradually growing and maturing

Between 2016 and 2018, we grew from a team of 5 engineers to a team of 12, and we gradually improved upon our discussion setup:

We moved away from ad-hoc face-to-face discussions towards a single, centralized meeting that started happening on a weekly basis.
We built out a culture more supportive of remote work: We set up better video conferencing equipment, like a Jabra speaker, and we established best-practices like not talking over each other while on VC and recording our discussions.
Finally, we set up a Google sheet, where folks could add discussion points for the upcoming meeting.

Early 2019 - Blitzscaling

In February 2019 we started “blitzscaling” Babylon. This meant that we went from 12 to 40 engineers within about 9 months. The team now included remote people from other European countries, and also engineers in the US (our headquarters are in London). To further complicate things, we got a second office in London, and a big part of the team was located there. The list of challenges started to grow again:

There were just too many conversations happening on Slack. It was incredibly easy to miss something.
Synchronous meetings no longer worked — period. At some point, we had people in London, Texas, Spain, Poland and Japan at the same time. There’s simply no meeting time that can suit all of these timezones.
With more people joining remotely, we became much more aware of the limitations of our video conferencing infrastructure.
With more people wanting to raise new topics, but also with more people having an opinion for many of the topics discussed, we gradually started to need more than one hour per week for our team meeting.
Not everyone participated in our discussions. The more introverted people didn’t feel comfortable participating in a 40-person conversation.
We became much more aware of the impact of context switching. Stopping 40 engineers that might be in flow meant that you literally threw away whole days of work in a split second.

At that point, we decided to experiment with changing some of these discussions so that they can happen more asynchronously. Our initial approach, driven by what the iOS team was doing here at Babylon, was to move some of our discussions into our GitHub repo. That meant anyone who wanted to raise an important discussion point would have to create a short markdown document to describe their idea and then create a pull request for it in GitHub. The documents lived in a separate directory, and their name was following the format <number>-<topic>.md, for example, 001-moving-to-coroutines.md. That then gave everyone time to asynchronously debate on the open Pull Request, and once the proposal was accepted and merged in (and actioned), we ended up with an archive of all the major technical initiatives that the project went through as it evolved. This approach is very similar to the Architecture Decision Records.

After trying this for a few months and creating a handful of proposals, we realized that this setup wasn’t working that well for a number of reasons:

There was a separation between small tasks (that this process felt like overkill for) and larger tasks.
It seemed like the format wasn’t that convenient for the engineers even though everyone was in favour of the idea: we started seeing a drop in the number of proposals coming in.
These proposals didn’t have enough visibility, as they were appearing in the repo along with another 20 or so Pull Requests that get created every day.
Smaller discussion points were still being discussed synchronously during our weekly meeting, which was an issue for people in different timezones.

Mid 2019 - Using Threads

At that point, someone from the team suggested trying out Threads for having all technical, team, and process discussions there, regardless of their size. We reached out to the Threads team, and even though at the time they were running a private beta, they were kind enough to let us try out their tool. Threads is an awesome tool that focuses on asynchronous team communication:

It is a very polished experience that also comes with a mobile app.
It allows you to have nested comments and replies within threads on a specific discussion topic, allowing for multiple conversations to happen in parallel.
Every discussion occurs in a thread object, which also has comments and replies that can be upvoted, which helps to gauge interest/agreement around the point being made.
You can mark discussions for “follow up” so that you are reminded that you need to reply to them, and so that others can be informed that you plan to follow up as well.
You can mark replies as “Decisions” so that it is clear what the outcome of a long conversation is.
It integrates nicely with Slack so that everyone can be notified when a new discussion topic is created or a decision is taken.

This is what the main page of Threads looks like. You can see some discussion points in the middle of the screen, and some different spaces on the left.

Moving away from source control proposals and into Threads, we saw new discussions being created almost daily that recommended changes to the way we do things. These were then discussed over the course of a few days/weeks (depending on the importance of the topics — default discussion duration was 2 weeks), and eventually, they were accepted, leading to changes in our tech or in the ways of working of the team. Of course, every now and then some suggestions were rejected after being discussed by the team. All of these discussions were then moved to a separate space in Threads called Android decisions taken so that we could keep them as an archive until the end of time, hopefully providing a bit of context on why things are the way they are in the team/codebase. We still rarely had meetings about specific topics when we felt that we needed to debate further about something.

Let’s now revisit all the challenges that we described in the previous sections:

Ad hoc face-to-face discussions were no longer happening. Either Slack or Threads was used, with a strong preference for Threads for anything that the whole team should be aware of.
Our weekly meeting was time given back to the engineers. We only had a monthly retrospective session for the whole team.
Our discussions were now remote-friendly and asynchronous, giving everyone the time they needed to think about the topic and provide their arguments.
Using Threads meant that discussions were staying open usually for a number of weeks, making it possible for everyone to participate.
It was now easier for introverts to participate in discussions, without having to speak in front of a 40-person crowd.
Anyone could create a discussion at any point and you no longer needed to wait for a week. We could have as many discussions as we wanted.
There was much less context switching happening, as everyone went to our discussions on Threads at their own pace.
Threads acts as an archive for all of our discussion points and decisions.

Where are we now?

We are still happily using Threads as it provides us with an organized way to communicate and collaborate asynchronously. Our company infrastructure has improved substantially since we installed proper monitors, a camera, and multiple ceiling microphones in every meeting room. At the same time, we all are currently connecting remotely to meetings due to COVID-19. All of these meetings are recorded and then uploaded to the team Google Drive.

We also created a separate #android-announcements Slack channel that helps with sharing important updates, making it less easy to miss thanks to the low volume of messages flowing in that channel.

Looking ahead

Over the past 4 years we’ve made a lot of changes to our approach for technical discussions in the Android team. Looking back, the biggest impact came from removing defined meeting times and replacing them with a tool — Threads — that allows for conversations to happen asynchronously. Spending the time to finetune the way we work is something that many teams may ignore, but it is (in my opinion) a very important contributor to productivity, engagement, and in the end, a better product. This process never really ends and, as such, we will continue to monitor and adapt our ways of working to suit our current team structure and circumstances.

At Babylon, we believe it’s possible to put an accessible and affordable health service in the hands of every person on earth. The technology we use is at the heart and soul of that mission. Babylon is a Healthcare Platform, currently providing online consultations via in-app video and phone calls, AI-assisted Triage and Predictive Health Assistance.

If you are interested in helping us build the future of healthcare, please find our open roles here.