Remote software teams - the secrets of efficiency

Remote software teams are fast becoming the norm. It was a growing trend pre-pandemic, but the pandemic has accelerated that trend, proved that it is a workable model and has broken the barriers that usually slows the the pace of change for such paradigm shifting ideas in an established space. No longer are software products and companies stagnated by the lack of skilled resources in the neighborhood. Software resources can be added to a team as and when required from anywhere in the world. And this reality is completely changing the landscape of how software teams run and operate.

As with any new way of doing things, a new set of good practices are emerging for managing highly spread out remote software teams. Some of the old ways of doing things have to be adapted in a certain way to make things more effective. We’ve been writing about our experiences in managing remote software teams and setting up workflows that bring about the culture of enthusiasm and spontaneity that is the seal of all good software development teams. Today’s post is about the lessons we have learnt about making the remote software team more efficient at work. Here are some of the top tips from our technical leads:

Enforce the use of tools and process

Tools are essential for remote software team. Sometimes in software development they feel like overhead, and software developers hate following the rules set out by the team about work process updates on collaboration tools. For teams that work together, the process often breaks down because of oral communications or just plan and simple laziness, yet it may still work out, even this break down can accelerate the development process. Not true for distributed remote teams. With team members working away from each other, sometime working in completely different timeslots and often communicating in different languages - tools are the main process of keeping things moving forward without confusion. The number one loss of efficiency in remote teams come from confusion about a task and circular nature of debate about the work at hand. Tools reduce this inefficiency. So remote teams must make sure that they are not deviating away from work process and they are using the tools as planned. I’m being very expansive about the meaning of tools. When I say tools I really mean any pre-decided set of steps that the team uses to get their jobs done. Tools can be the collaboration tools like Jira or slack, or they can be some build environment, or deployment standard, or email chain that is sent out after every push to the repository, etc.

Make it easy to ask anything

The biggest downside of remote teams is the lack of face to face interactions outside of work between team members. These interactions break down the barriers between team members, making them operate at social level, ideally as friends. We’ve suggested many ways a company can try to solve this problem and bring the team together. The goal is simple: make it easy for team members to ask anything to other team members. There should not be a worry of “what others will think of me” or “she might think I don’t even know the basic stuff” etc. Having that sort of barrier means that remote team members spend an inordinate amount of time solving something that is already solved or could be solved in a matter of minutes if someone else in the team answered a simple question. You’d be surprised how many times hours even days are spent by software developers looking for a certain thing, say a database file, just because he did not feel good about asking about the location of the file.

“Failure is a learning opportunity” culture

On the same lines as the previous tip, the remote team should feel that failure is totally acceptable in software work. If the remote team members get a feeling that they have to hide their failure - because it reflects badly on their performance, or that their boss somewhere else in the world might get angry about the failure, they’ll waste time in trying to hide that failure. Time will be spent trying to fix it with a patch that will break down soon, or even worse shift the blame to someone else in the team. All such behavior leads to downward spiral of inefficiency, loss of team morale and eventually bad software. The solution is simple, from day one the team’s motto should be that failure is acceptable, when it happens discuss it with other team members, find a solution and learn from it so that the team doesn’t make the same mistake.

Team leads are the sheep dogs too

Team leads are typically the shepherds - leading the flock forward, showing the way to go, etc. But in remote teams the team leads have to play a significant role of sheep dogs too. Sheep dogs help the shepherds from the rear, making sure that no one is left behind, or no one at the rear are going in the wrong direction and most important everyone knows what the direction go is by making quick corrections to small mistakes as they happen. Remote teams spread out geographically has a much larger chance of individual members getting lost or going the wrong way in their work compared to teams that work under the same roof. This is where the team lead’s sheep dog role comes in. A team lead should setup a process where she can regularly check the status of work of team members - code reviews, regular meetings with individuals, product demos, etc. all help in this sheep dog work.

Solving issues fast become more important

All issues should be solved quickly in any software project - that’s normal. Issues lead to confusion that leads to delays. But in remote software teams this fact is magnified hundreds of times. A small issue, say a broken build, leads to a bunch of developers working in a completely different timezone to be sitting and waiting for someone to wake up from sleep to fix the break. Solving issues as they come up becomes a priority for team lead in distributed teams.

Goals first, everything else follows

Last but not least, remote teams need to have clarity about the goal of their work and of their company. When the team knows the goal it’s decision making process becomes much more independent. Individuals don’t have to wait for a team lead to answer every question for the work to move forward. With every team that’s important, but for remote teams clarity about the goal of their work may not be communicated enough. They may not be hearing from the management or the business leaders a lot. Their interactions get limited to a small section of the company - usually the technical teams. And this might lead to confusion about what the overall purpose of the work is. A company might be planning to build the fastest checkout tool for eCommerce, but remote developers may understand that they have to build out the most customizable interface possible for the checkout - leading to decisions that make the interface slow. If the goal was made clear then developers would then probably compromise on features of the customization in the interest of staying on the goal of making the interface fast.