What have I learned about running remote teams?
By Matthew Longden (Entelect, Delivery Manager)
As far back as 1964 Arthur C Clarke predicted the digital nomad trend was coming to the work place. “Perhaps only 50 years from now a man [may] conduct his business from Tahiti or Bali just as well as he could from London”. He went further: “Men will no longer commute; they will communicate, […] They will only travel for pleasure.”
It's just over 50 years later, and while we’re perhaps not fully nomadic in our choice of where to work, the idea of remote work is more and more prevalent, certainly in the IT sector.
For several years, Entelect has been implementing a version of remote work, essentially our offsite project model is that. We gather requirements for a system and then we proceed to design and build it with teams based at our offices in Melrose Arch, Centurion and Cape Town. As we’re advocates of Agile SDLCs we try to communicate progress frequently and prefer a high level of interaction with product owners or client stakeholders to get prompt feedback on development. We’re good at this model and we’ve provided many high-quality systems to our clients in this way.
More recently though we’ve been engaging with clients and colleagues in different ways. For instance, when a colleague decided to move to Eastern Europe last year he continued to work for us, producing mobile dev, for the first six months of his new life there. We now have several engagements where we have expanded our onsite team augmentation model to include remote teams.
It’s this remote augmentation model that I am particularly interested in.
First, let me paint the perfect remote augmentation picture from my point of view. Teams that really nail this will be able to onboard and work with colleagues who are not coming into the same office as them. Being able to learn the domain, access systems and communicate with the wider team, will not be impacted by lack of physical presence. Remote members of a team will contribute and be valued in exactly the same way as their colleagues and they will undertake all the same tasks as the core team.
The idea of such a team is attractive to me as a Delivery Manager because it opens up possibilities to support our clients in new ways. By tapping into the major commercial hubs in South Africa we can find the best composition of skillsets and experience to help them achieve their development aims. No doubt, it has to be better for our economy and the growth of South Africa’s IT industry to recruit people in this country rather than looking abroad, and as the IT skills pool is relatively isolated in this country we need to be flexible in our approaches to teams.
What have I learned so far?
To assume that remote augmentation will work in just the same way local augmentation does (we all just use jira and get on with it, right?) is simplistic in the extreme. By its nature, augmenting into a team typically requires much closer interaction, both in terms of frequency of communication and in the nature of tasks being taken on. It should be perfectly normal for the person sitting 400km away to develop the service tier which the front end developer sitting locally will consume, or visa versa. However, achieving this is not always trivial.
(The right) tech can help
Tech has been the enabler of people working remotely so its unsurprising that it sits at the center of any solution to remote working. Its vital to have the correct array of communication mediums available and that the team members are able to use them appropriately. The humble telephone still has a huge part to play but provisioning a team with IM, video conferencing, group messaging such as Slack, as well as the now common tools like Jira and BitBucket is key removing the inherent friction in communicating from a remote location. Products such as Basecamp are also available, they aim to provide a single platform off which you can run a distributed team. It goes without saying that high speed, stable network access for the remote teams is a ‘must’ as well. Security policies, especially of corporates, need to align to allow remote workers access to all the systems they need to do their job.
The remote team is not a second class citizen
The ideal here is that remote colleagues simply pull tasks off the same backlog as the core team. I have seen instances though where the core team allocate simpler tasks to the remote team under the reasoning that they’ll be easier to do in isolation (this is also a common model when dealing with high capacity offshore teams in places like India and the Philippines). This sets a tone where the remote guys feel like they are never given access to the more complex, interesting work. Over time this will lead to them feeling disengaged and is likely to lead to frustrations around their ability to contribute to the development effort.
Making it work is also a people problem
I find the really insightful part of Clarke’s 1964 prediction not to be the idea of remote work itself but that of people needing to communicate. Despite the fact that we grow up with so many ways of communicating these days we are generally still very bad at communicating effectively, especially when not working face-to-face. This is, and will remain for some time, the main barrier to how well any given remote team will work in my opinion.
In an industry not known for high EQ levels across the workforce, it is especially important to make sure there are nominated people in both the local and remote teams that will help facilitate excellent communications. This will ensure expectations across the team boundaries are managed.
Management support and buy in
I encounter managers who are open to trying a remote team however they feel there is no extra overhead needed to make the engagement a success. In addition to the above points around tech, equality between teams and great communication pathways, it is important that the management team themselves are clear in where potential issues may lie and are proactive in dealing with them. My experience of remote augmentation is that when things do start to go wrong you really need strong leadership to act quickly to put plans in place to address the issues at hand.
Being able to build teams that can operate in this fashion does require different skills, approaches and tech than simply running a local team. If you manage to get it right though the potential to unlock talent pools in other South African cities, and ultimately further afield, is an exciting prospect for Development Managers struggling to find the skills they need locally.