It is now several months since the global COVID-19 pandemic has confined millions of employees to their home offices around the globe. In the US, half of those employed before the pandemic are now working remotely compared to just 15 percent before the public health crisis, per research conducted by MIT. Cross-functional teams, including some software development teams that were once co-located, and met in person every day, have become distributed teams overnight.
The abrupt move toward distributed teams in software and other industries has spawned numerous studies about what this shift means for both today and tomorrow. Some of the study findings have been surprising.
For instance, research from organizations as diverse as the U.S. Patent and Trademark Office, consulting firm Accenture, and Stanford University have found that productivity has increased, contrary to expectation. These organizations have reported productivity growth of between 4 and 20 percent. Whether these gains are sustainable, however, is open to question. Innovation is a different matter. We suspect that incremental innovation will slow down, but we have great hope that transformational innovation will go on as before, or even increase.
With months of experience now behind us, and with the benefit of years of research dating from before the pandemic, best practices for virtual product development teams are slowly emerging.
Table of Contents
Despite the optimistic findings from some quarters, remote teams have significant risks outside their function of product development. In an article in Forbes, researcher Andrew Mawson reported the results of a 2020 literature search of studies related to distributed teams. He found that there were six factors that become vulnerable when software development teams become distributed :
These broad factors have special implications for distributed software teams since these teams require scrupulous version control and management of requirements. This raises implications for project management and project communication. Project-related visibility and transparency are at risk. These specific challenges make remote teams even more susceptible to the vulnerabilities mentioned above.
See our guide on recruiting remote software developers.
Among the reasons that many management teams expected productivity to decrease when employees were sent home was a lack of trust that the latter would continue to do their jobs, when faced with the inevitable distractions from their families and other factors.
Research indicates that senior managers’ lack of trust was not warranted, although these fears are also reflected in the tendency of some companies to track employees’ laptops when they’re at home. It’s evident that trust issues still linger.
A best practice for ensuring trust in distributed teams is to have a visual means of tracking task completion. This way, all of the members of the distributed teams can see what’s been done, maintaining managers’ need for oversight, while keeping the team on task.
A tool called a Deliverable Hit Rate chart can help. The chart monitors the progress of completed tasks against a target over time. It provides a graphical representation that indicates whether the cadence of task completion is on-track for delivering the software program on time. This is a simpler version of an Agile burn-down chart. It is easier to use because it does not require task estimation. It relies on data to compute an average trend of deliverables over time.
The team constructs the tool by first establishing a linear target rate for completion. Calculate the target by dividing the total number of tasks required to complete the program by its duration. At the end of each month, the team maps the number of completed tasks against the target for that time period.
Social cohesion, a vital element in company culture, is clearly threatened by the shift to distributed teams. Culture is an intangible element that transcends productivity but has an observable effect on it. Culture is reflected in casual interactions such as the conversations overheard in the next cubicle, the water cooler catch-ups on Monday, and the “what are you doing this weekend?” queries on Friday.
Mawson observes the distinction between “strong ties” and “weak ties” in an organizational culture. Strong ties bind employees to their closest colleagues and associates. They tend to survive the move online, while weak ties, the links you have to others in your organization with whom you communicate less frequently, tend to fray. Mawson notes that it is the weak ties that most often lead to innovation.
This stands to reason. Software developers tend to have their strongest ties with other software developers or with their managers. They live in a common universe and tend to share a sense of what’s possible. The sales rep a software developer might speak to a couple of times a month dwells in a different universe. Sales reps can add input that software developers are unlikely to hear as long as they stay within their bubble. Innovation often happens when worlds collide, for example when the sales rep brings a tidbit from a customer interaction to the attention of a software developer. Thus, the loss of “weak ties” that occurs when teams go virtual threatens innovation.
One best practice that can help support social cohesion, and hence innovation, is to make opportunities for casual social interaction, for example with an online happy hour. In goal oriented company cultures, such activities might seem frivolous, but companies that play together, stay together. These informal interactions build connection in the categories of both strong and weak social ties. Who knows? Your next innovative idea might come from a casual social interaction online.
Another practice is to conduct “town hall meetings,” large all-hands-on-deck events. Companies can conduct these meetings remotely. In the days before the pandemic, one company was accustomed to having such meetings where senior managers conveyed vital, big picture information, using carefully edited PowerPoint presentations. When teams work remotely they found that this was too much for their remote teams. Nonetheless, this company found that even a minute or two spent conveying a larger context maintained the cohesion of the company, the feeling that “we’re all in this together.”
A semiconductor company found that the chat function in tools like Zoom made their periodic remote town hall meetings even more effective than their in-person events. People who were reluctant to speak publicly in a large meeting, could submit their questions and comments in an unobtrusive manner via chat. Also, executives discovered that participants responded differently when managers were not in the same room to coordinate responses. The company found that active participation in their town hall meetings, in the form of the give and take between managers and contributors, increased when they went virtual.
Another good practice is to continually reinforce what makes the company culture special. Take every opportunity in one-on-one meetings and larger online gatherings to reinforce and celebrate the culture. Refer to the culture and its traits at every opportunity.
Information sharing can also become an easy casualty of the shift to distributed software teams. Distributed teams have a tendency to store information locally on their own computer hard drives. For example, when their remote desktop slows down to a snail’s pace, they may give up on it and store important documents on a home computer, where they’re not shared with colleagues and may become vulnerable to hacking. As a result, the flow of information, the lifeblood of the Tech world, becomes clotted. The leads to rework, poor communication, and schedule slips.
Thankfully there is a suite of tools that can help. The most important Agile software development methodologies include Backlog, Definition of Done, Burndown Chart, Release Plans, and Retrospectives. For each of these, there is an enabling technology that helps teams share and keep their information up to date. For instance, the Jira suite of tools helps for recording and managing bugs; Pivotal helps remote software teams manage requirements, while Trello aids the Kanban methodology.
Also, have a clear escalation process with a communication map. Such a map clarifies the boundaries and channels of decision-making throughout an organization. It shows a path that allows your distributed software dev team to make decisions at lower levels of the org chart while having a clear path to bring decisions to higher levels of the organization when necessary. It creates a clear communication path that improves information sharing and speeds decision-making.
Vision and goal clarity may also erode as each contributor slips more deeply into their own bubble. It’s easy to lose the forest in the trees. A clear vision provides a sense of purpose, and a context for the work software developers are contributing to every day.
Software developers working from home can become disconnected from this larger purpose, which may threaten, in the long term, the gains in productivity some researchers have observed.
First, distributed software teams require much more communication than co-located teams. It is a best practice to keep interactions short but frequent. Frequent one-on-one communications between supervisors and their direct reports creates structure, and reminds employees of the shared goal and vision. It also allows for frequent opportunities to ask and reply to questions, on both sides of the relationship.
Along the same lines, keep your distributed teams focused on the shared product vision by holding monthly meetings where you review the product roadmap. This reinforces that individual work at home is part of a narrative with a beginning, a middle, and an end. Assess the past, present and future of the app under development. Then take out your one-page, corporate vision statement at the beginning or the end of this meeting and share it on the screen for all to see. Show where the product at hand fits into this larger scheme.
Next, create a strategy memo and store it in a private cloud. Update this document frequently and place it in a location accessible to all who might need to refer to it. One large software firm found that Wikis were the most effective way to store and communicate strategy information. Create shared locations and insist that important work documents find their way into this space. Check in with team members and ask if any vital documents have migrated onto personal desktops and remedy that as soon as possible.
In a distributed team, it’s impossible for managers to walk around and see how people are working, or to answer questions asked opportunistically, as the manager passes by a workspace. An important question might linger in a supervisor’s email inbox while she’s off watching her kids.
Both the supervisors and the supervised might worry that they’re not getting their needs met. And written communication, in an email, text, or chat, is much easier to misinterpret, and far less rich than face-to-face interaction. We all know that it can take three or four emails to clarify what would take a few minutes in an in-person meeting.
One countermeasure for software dev teams is to assign peers to interact with one another on a regular basis and to help one another resolve issues that are within their scope. Also use wikis to track questions and answers. One software company used an app called Phonebook to store contacts and keep them organized according to the company’s organization chart. This eased communications between layers of the organization.
The available technology for online meetings, as it is used in most instances, represents another hurdle for distributed teams. Just as we now have desks and chairs that are designed for the ergonomics of the physical body, we also need tools that account for psychological ergonomics.
For example, the way the most popular online meeting tools such as Zoom are commonly used causes users to stare at their own face. These popular tools generally force individuals to appear to be staring at one another. In most primate species, including homo sapiens, staring directly at another individual is considered threatening. This might explain, at least in part, the phenomenon of “Zoom fatigue” we have all felt.
One solution is to find creative ways to use Zoom and similar tools. For example, a psychiatrist came up with a novel solution to the disconcerting phenomenon of staring at one’s own face in Zoom meetings. He used Zoom with his online patients, but had both doctor and patient face away from the camera. This way, participants can turn and face one another if they wish, but don’t have to look directly at themselves and others.
If necessary, block self-view on Zoom, or set your camera at an angle so you’re not staring directly at meeting participants. Or revert to voice-only calls. As much as possible, make your online meetings imitate face-to-face interactions. Experiment with Zoom or other such tools, to find out what tends to mitigate Zoom fatigue.
There is no substitute for software teams that work together and see each other every day. But the best practices described above, taken together, and done consistently, will improve your distributed teams. We’re in a brave new world. No one has all of the answers. The research, best practices, and best technology for distributed teams is still emerging.
However, the best available data tends to suggest that distributed teamwork improves when companies take the following steps:
With these practices in your playbook, your distributed teams may be able to sustain over the long-term the productivity gains some organizations have seen. And you may discover new best practices that enrich the growing knowledge base on how to make distributed teams as effective as any you had before the pandemic. Don’t be afraid to experiment. And then share with the entire company everything you have learned.
Teamwork is a skill. Like any skill, practice makes perfect.