Some thoughts on growing and making a success of a remote / distributed team would be useful for many people - Nexmo Dev seems to do a pretty good job of it..
— David Low (@daviddlow) March 5, 2019
Of all the questions I’ve received to date this is one of the most difficult because I feel we’re not there yet. We’re still working through some problems. So, what I thought I’d share here is our current team members locations, team structure along with a combination of what I’ve seen working, some of the issues we’re presently experiencing and thoughts on how we may remedy these. In doing this, I hope others will provide feedback and pointers to help us and others improve.
I expect to update this blog post from time to time as we learn more about building an effective remote team.
Nexmo DevRel Team Member Locations & Team Structure
The Developer Relations team at Nexmo, the Vonage API Platform is a remote-first team. We are a team of people located from San Francisco to London through to Singapore.
The team has grown from three full-time people and one part-timer person back in March 2016 to 26 full-time people in April 2019 (we expect to grow to nearly 40 people in 2019). With that, the team’s responsibilities have increased as well as an expectation to do more of what we were already doing. To enable this, we’ve created smaller teams within Developer Relations who focus on specific areas.
- DevX - Nexmo Developer (our documentation platform) and API standards
- Content - blog posts, webinars and videos
- Extend - how you can use the Nexmo APIs with complementary technologies and platforms
- Server SDKs - maintain and enhance API wrappers that make it even easier to use our APIs
- Community - enable our internal and external community involvement and support
- Developer onboarding experience - help more developers get up and running quickly on our platform
We also have a few product-focused initiatives that will evolve with the product life cycle. For example, the Nexmo Client SDK is in “developer preview” so a lot of time is being spent working on the experience our SDKs provide, documentation, developer tooling and code samples. When the product is more mature, the focus will shift to raising awareness of the product and further demonstrating what it makes possible.
Now that the team structure, location and focus has been shared. Here are the factors that are presently top of mind for me when building a successful remote team.
Meet In-Person
As a remote-first team, you can fall into the trap of undervaluing team members meeting in person. We’ve made this mistake in the past, and it’s contributed to losing some great people. So, in 2017 and 2018, when the team was of a size in the mid-teens, we had two full team all-hands (Lisbon, Portugal and New York, US). In 2019, with the team approaching thirty people we’ve kicked off the year with a full team all-hands (Athens, Greece) and will have likely regional all-hands mid-year (US and EMEA + APAC).
Meeting in person is easier for some than others. We have quite a few people based in the UK, and we’re all only ever a few hours travel away from a colleague. For those spread across America or based on in locations where we have fewer team members, it’s much harder. So more effort (and budget) is required to ensure these essential in-person meetings take place.
We’re lucky enough to have a reasonably good budget for travel and spend around 10% of our time travelling (averaged across the whole team). Because of this, we’ve recently started encouraging people to use events as an opportunity to catch up by extending event trips by a day or two. Sometimes just working in the same space for the day is enough to ensure relationships are established and maintained.
Spending time maintaining relationships is something that I’ve personally seen as being important. As the team has grown, I’ve had less face-to-face time with those that I used to spend quite a bit of time with. The lack of face time has resulted in relationships breaking down. So, I’m spending more time in 2019 travelling to meet my colleagues in person and having video calls with all the team.
Use Voice & Video Calls
Our team spends a lot of time in Slack. It’s a fantastic tool for remote workers but also co-located teams that want to quickly communicate without the need for the time it takes to have in-person meetings.
However, as a team that relies so heavily on text-based communication, that form of communication becomes the default when a voice or video call would be more effective. When co-located, those moments happen naturally. When a team is so used to communicating using text, those “quick chat” moments take place far too often.
My recommendation is that remote teams should take advantage of video calls more often with voice being the next best option. Being able to see the person you are communicating with, see and interpret facial movement and body language, and react accordingly, adds depth to a conversation. A prerequisite for good digital communications is good a high quality Internet connection.
Assume the Best of Each Other
When team members have good relationships with each other, then actions and comments tend to be interpreted with a bias to a positive intention. When relationships don’t exist or degrade due to lack of in-person meetings or video calls it’s possible that the very same comments or actions to be interpreted negatively.
My ask of each individual within our team is to remember that we are a group of good people who do not go out of their way to annoy others. When they share a thought or idea, they’re doing so with a good and positive intention.
Use a Wiki (a.k.a Write Down All Important Things)
All vital information for a team - remote or co-located - should be written down. However, co-located office workers spend a lot of time speaking to each other, and it’s more likely that important information will spread by word of mouth, so the need for information to be captured and shared in digital form is often forgotten.
As a remote team, we spend a lot of time communicating in Slack, so most communications are written down. However, “chatty” content is frequently skipped, and key information easily missed. When an interesting or important topic of conversation takes place, is discussed, actions suggested, or conclusions made that information should be captured and summarised in a wiki. Should it be a topic of discussion for a future call? If so, make it an agenda item. If a conclusion is reached ensure it’s added to the appropriate place in your team wiki or to whatever task solution your team uses, e.g. Jira or Trello.
Our meetings generally take place via video. We try to ensure that each session has a clear agenda beforehand, that those participating have the chance to read, comment or add items and that minutes captured along with any assigned actions. This is good practice no matter the team working environment. We also try to record all meetings.
Since we also encourage meeting up in person, it’s essential that these practices are followed for those meetings too.
Transparent & Timely Communication
Transparent communication is something that every business and team with tout as essential when fostering a great culture. Since forming the larger Nexmo Developer Relations team in March 2016 a lot of decisions have been made as a group, communication has been open, and news from across the company instantly shared with everyone in the team.
Based on what is a limited experience of just three years - growing from a team of 3 in a company of 150 to a team of 26 in a company of 2,400 - being instantly transparent works with smaller groups; the amount of information to share and the number of decisions to be made at a smaller scale are manageable. If you continue to instantly share information and ask for full team opinion on every decision to be made in a larger team and company, far too much time is spent discussing and thinking and not enough time is spent executing.
In a larger team, information has to be digested and distributed at an appropriate time, and feedback sought when ideas have more clearly formed and set of options are ready for a more focused discussion. A key enabler for this is trust in the individuals receiving the unfiltered information who then have the responsibility to form proposals ready for additional input and feedback.
All of this is, of course, relevant to co-located teams. However, I’ve found the problems to be exacerbated within a remote team because it’s easier to work through more difficult conversations in-person.
Flexibility
A big reason for remote working is to fit a job around your life. However, there’s no point in allowing remote work if there’s an expectation of being at a desk during fixed hours.
It is important that people are reachable during normal working hours so they can reply to questions or requests in a timely manner. But, where and when people do their more focused work should be up to them as long as it’s effective for the rest of the team.
Conclusion
As a software engineer, I’ve worked in co-located teams practising agile development methodologies. I distinctly remember hearing an agile coach that we’d brought in for some training saying that remote teams are ineffective and should not be formed. I didn’t believe that then, and I don’t now.
However, I do think that it’s harder to build an effective remote team than it is a co-located one, but there are so many benefits to remote working that the positives outweigh the negatives. For now, we’re working through some of the practices I’ve just outlined and I hope these thoughts are useful to others.
As our journey continues and team evolves, I’ll share what is working and what isn’t.
Questions & Comments
Please comment on GitHub, tweet me or drop me an email.