5 lessons in continuity for distributed technology teams

Few can argue that 2020 hasn’t been full of worldwide rollercoasters – the biggest being the global COVID-19 pandemic. Due to the accelerated spread of the virus, many organisations have been forced to adapt to a remote working model.

Technology companies have been working with distributed teams for years. For most organisations, this hasn’t been by choice, but rather due to the shortage of skills in the industry. In such a globalised world, building the right technology team with the right skills, experience and chemistry is very unlikely to happen in one location.

At Entelect, we have been running distributed and remote teams for some time now, and so are fortunate enough to not be too disrupted by these unforeseen changes. Below are 5 lessons we’d like to share with others in industry who are perhaps finding themselves in unfamiliar territory:

Lesson 1: Your technological workforce will adapt easily. Be sure to pay attention to non-technical team members who might need support.
Developers, technologists and tinkerers are usually content with working in solitude. They are used to installing and configuring tools, and having their workload managed via a virtual SCRUM board on Jira or Azure DevOps. This means their workflow is the least impacted in a remote delivery environment. On the other hand, analysts, scrum masters, product owners, subject-matter specialists and other less technical roles have a disproportionately harder challenge being as effective as they would have been in a fully co-located working model.

During disruptive times like these, it’s important to establish what degree of frequent communication is required. A well-balanced distributed team should have low-comms roles making an effort to support the high-comms roles, and recognise that this might be a more difficult adjustment for them.

Lesson 2: Ensure there’s someone to bridge the gap.
When running a distributed team, there is often a gap between the remote team and the on-site business team. This gap can cause anything from delays in feedback from business to overall patchy communication between the teams. Having somebody “on the inside” is critical for all distributed teams.

Although it’s not always logistically possible, there should ideally be at least one allocated person from the distributed team who is physically based at the business. This person needs to be specifically tasked with helping the remote team by working closely with the business, and acting as a translator and clarification layer between your distributed engineering team and the business. When urgent feedback is required or if there are blockers preventing progress during the project, having an ally to receive mandates or requirements is immeasurably valuable.

Lesson 3: Culture is critical.
If you’re completely new to running a remote team, focusing on culture is probably more important now than ever. Switching to distributed model is not an easy transition – especially if it’s done abruptly. Digital tools will go a long way during these transitions, but focusing on team culture will take it a lot further.

Don’t disregard the importance of how people interact to solve problems, socialise and support each other. This might be a good time to relook at your team charter and ensure that the unique attributes that kept your team’s culture alive are still implemented, even when working remotely. Over time, this will result in a culture of delivery regardless of which working model you’re using.

Lesson 4: Collaboration is easy, communication is hard.
Teams often have a big push towards collaboration when working remotely. There is no need to start stressing about collaboration. It’s only as difficult as it always was, and only as good as your communication. This is why you need to focus on communication instead. Communication in distributed or remote teams is extremely challenging, and therefore collaboration becomes more difficult.

Good collaboration flows from good communication, and if you spend time and effort on improving comms in your team, you’ll naturally get better at collaborating. The biggest communication challenges in running distributed teams are availability and responsiveness. You need to establish when each team member is available during the day and agree on how frequently everyone responds to requests or enquiries. Lack of availability and responsiveness in teams create bottlenecks that will delay the success of the project.

The challenge here is not the administrative tasks of potentially moving your project backlog to a virtual application or using digital tools to collaborate. It is rather fostering a communication environment that allows for availability and responsiveness to thrive.

Lesson 5: Mistakes will be made.
Change is difficult and can often be frustrating. Very rarely will teams pick up a new working model without some hurdles along the way – and that’s okay. Learning to use new communication tools and facing other difficulties like portraying tone and body language correctly will be an adaptation for any team. Have patience with each other and go through these changes as a team.

For many organisations who are currently not using a remote working model by choice but rather due to circumstances, this is the ideal opportunity to see the potential this model has to offer. When you’re capable and confident in how you operate projects with a distributed workforce, scaling teams becomes substantially easier because you can source and manage them anywhere. There is also value in running the right distributed team versus the wrong co-located team. Don’t view a remote working model as a present complication, but rather as an opportunity to prove your team’s determination when faced with challenges, and prepare your business for new ways of working.