If you want to capture the hearts and minds of globally dispersed virtual team members, you must consider two main factors: situated learning and identity construction.

As defined by organizational theorist Wanda Janina Orlikowski in the Organization Science article entitled “Knowing in Practice: Enacting a Collective Capability in Distributed Organizing,” situated learning is “the practice of intervening knowledgeably and purposefully in the world.” It encompasses things like questioning, proposing ideas, discussing issues, and seeking feedback. Identity construction is a process of understanding who one is, what one can do, and to what extent one becomes more or less legitimized and valued by the other members. Both are essential components of a successful virtual team.

The way these two factors relate within a virtual community is defined by a theory called legitimate peripheral participation (LPP). First proposed by anthropologist Jean Lave and educational theorist Etienne Wenger, LPP theory describes how interpersonal participation within a community is interrelated with the two key factors of situated learning and identity construction. LPP theory contends that situated learning allows team members to build their individual competencies, become increasingly recognized by the virtual community, and construct their identities.

Simply put, situated learning and identity construction are like two mutually interdependent sides of the participation coin. As individuals engage in situated learning and identity construction, they move from being peripheral participants to fully legitimate central players.

Consider the vast online communities of the open-source software (OSS) phenomenon as a great example of the power of virtual teams. OSS originated in the 1970s as a way for computer programmers, initially university-based, to openly and voluntarily share ideas, build tools, and deepen their technology knowledge. Before long, individuals and organizations worldwide were taking part in open-source development. Today, one popular OSS project platform, GitHub, has 26 million users and 74 million projects.

Various explanations for what motivates software developers to join OSS teams have emerged. Motivators include the direct usefulness of the software to the developer, reciprocity for a prior benefit received, desire for professional or personal recognition and status, hunger to learn something new, and even the simple personal enjoyment of programming as a hobby.

Although individual reasons for joining a virtual community are interesting, we became intrigued with a different question: “What motivates and propels people to continue to actively contribute?”

Our question was relevant to OSS projects primarily because such a large number of them failed—over 80 per cent by some estimates. And yet, some OSS projects have yielded truly world-class software with massively successful results, including the Linux operating system, the MySQL database, the Apache web server, the Firefox web browser, and the WordPress website authoring platform.

The potential payoff for activating deep commitment and engagement among virtual team members can be enormous.

We wanted to understand what motivates people to long-term commitment to a dispersed working group, which has led to a rapidly growing virtual team trend. According to the U.S. Bureau of Labor Statistics, 38 per cent of Americans employed in management, business, and financial roles did some or all of their work virtually in 2015. In 2016, an industry white paper revealed corporate teams are now “almost entirely virtual,” with 41 per cent of team members never meeting in person and 48 per cent comprising members from different countries.

“The potential payoff for activating deep commitment and engagement among virtual team members can be enormous.”

Other research has reported that well-managed virtual teams can outperform traditional co-located teams. According to the MIT Sloan Management Review article “How to Manage Virtual Teams” by Frank Siebdrat, Martin Hoegl, and Holger Ernst, one reason is that virtual teams allow for global access to people with deep, heterogeneous competencies.

Overall, the research shows that organizations are heavily relying on virtual teams to deliver long-term results. As such, understanding how and why some virtual team members become continuously motivated and committed, while others falter and “check out,” could provide considerable benefit to your business by improving human resource productivity.

For our research, we zeroed in on one active OSS community called phpMyAdmin. The purpose of this particular open-source project was to provide an easy-to-use, web-based interface for accessing another popular software package—MySQL. The phpMyAdmin project was hosted on the SourceForge OSS platform, a popular project repository with millions of users. According to marketing material, the phpMyAdmin software package has been downloaded nearly 37 million times and translated into 72 different languages since its inception.

The phpMyAdmin community was home to 715 registered project members during the four years of our study. One benefit of studying an online virtual community like this one is that it provides an essentially complete set of past and present communications. In our case, this included dozens of published project documents and thousands of various forms of messages in the tracking system (including bug reports, feature requests, patches, support requests, and language translations).

To start to make sense of this massive dataset, we split the 715-member community into three groups of participants: sustained, unsustained, and inactive.

Nine sustained participants actively updated the codebase and contributed many email and tracker messages over a long period of time.

Seven unsustained participants had at one time updated the codebase and substantively contributed in terms of emails and tracking messages, but their usage eventually fell off.

The remaining 699 inactive participants joined and perhaps offered a message or two before eventually disappearing.

Apparently, the great success of phpMyAdmin was due primarily to the efforts of the nine sustained developers and secondarily to the seven unsustained developers, while the majority of virtual team members contributed little or nothing.

What caused so few team members to become sustained participants? Why did the seven unsustained members depart? And why were so many members inactive right from the start (considering their initial motivation to voluntarily join the community in the first place)?

To find answers, we dug into the project records and correspondence, looking for similarities and differences between the groups. What we found was highly consistent with LPP theory.

The nine members of the sustained group were highly active. On average, they contributed 315 email messages, received 272 tracker assignments, and completed 3,692 concurrent versioning system (CVS) commits. The content of their work demonstrated substantive evidence of situated learning and identity construction activities. Errors and negative events did occur from time to time, but these members appeared to have built up a sufficient “bank” of positive experiences to weather the small storms, and continued their positive engagement. In effect, they experienced a positive “spiraling up” of learning and identity construction over time, as the project progressed.

The seven members of the unsustained group were only occasionally active. On average, they contributed 33 email messages, received 31 tracker assignments, and completed 30 CVS commits. Their work demonstrated a more stuttered range of situated learning and identity construction activities—both positive and negative. However, because of their relatively few interactions (compared to the sustained group), the negative experiences appeared to be magnified and significantly reduced their sense of peer recognition and status. Ultimately, members of the unsustained group experienced a negative, and typically very quick, “spiraling down” of learning and identity construction. In some cases, a single negative interaction led to a member leaving the project.

Many of the 699 members of the inactive group never engaged at all. On average, each member contributed 1.8 email messages, received 1.1 tracker assignments, and completed 0 CVS commits. Members of this group were not drawn into the community, and never had a chance to engage in situated learning or to receive any ongoing peer recognition.

Overall, the sustained members engaged in continuous situated learning and identity construction activities, leading to a combined “spiral-up” experience. The unsustained members enjoyed moments of positive situated learning or identity construction, but when they hit a negative moment (e.g., due to a coding error, a reduction in contributions, or an inability to persuade other members), they were unable to recover momentum, so they spiralled down and eventually withdrew from the community. Inactive members made some preliminary attempt to engage with the community, but due to early negative experiences they failed to produce either situated learning or identity construction outcomes. These individuals disappeared almost as quickly as they arrived.

Our research shows online community members, including members of high-tech virtual team communities that utilize exclusively computer-mediated communications, must be nurtured. Our test of the LPP theory showed that a virtuous upward spiral of consecutive learning opportunities, plus regular moments of identity building (starting with small tasks and leading to increasingly large ones), yields committed and effective virtual team members. The alternative is a negative spiral of blaming and shaming, resulting in silent departures and unsuccessful outcomes.

The lesson from this work is that virtual team success depends on the presence of positive LPP properties: working contexts and cultures that provide a range of successively challenging learning and development opportunities, and that also encourage socialization, acknowledgement, and identity construction within the team.

From our research into distributed open-source projects, we can suggest four concrete steps to increase virtual team member engagement. These lessons may not stem from a corporate virtual team context, but we believe there is a high degree of overlap and relevance to any organization.

First, the success of the project relies on the sustained contribution from a few “core” contributors with strong expertise and skills. To assemble a candidate pool of core contributors, the first step is to attract capable individuals to the virtual team community. In our study, open access was essential. Another way is to make the software (or project deliverables) personally tangible, useful, and relevant.

Second, to identify and foster the development of core contributors, every contribution needs to be recorded, tracked, and publishable. The virtual team community leaders must have easy access to these records. In this way, leaders can recognize the valuable contributions made by the corresponding core developers.

Third, to retain core contributors, special privileges should be granted to them. In the case of our OSS study, core developers had access to the CVS system that contained the project’s critical software code. This allowed them to make direct contributions as they learned and coordinated the activities of the team, and it also enhanced their reputation within the community. Thus, situated learning and identity construction could flourish, leading to strong, positive, sustained participation.

Finally, for contributors to gain recognition and reputation within the team community, both direct contributions (e.g., in the form of solving software coding problems) and indirect contributions (e.g., in the form of offering advice to others) are needed. Both of these types of inputs can lead to positive situated learning and identity construction opportunities to ensure successful virtual team member engagement.

APPENDIX 1

Selected Examples of Virtual Team Member Experiences

Sustained (S) Members	Unsustained (U) Members	Inactive (IN) Members
The formal leader of the project, S1, could access all project resources and was in charge of managing the direction of the project and work assignments. He manifested a comprehensive understanding of the whole project. He actively provided suggestions to developers, answered their technical questions, and made effective decisions. His contributions were recognized and greatly respected within the community.	Initially, U1 had access to the CVS system due to his abundant experience with PHP. He actively provided suggestions and cooperated with other members, became recognized as a competent advisor, and even appeared on the list of authors in the 2001 release. However, at one point U1 withdrew without explanation. He later returned and restarted as a peripheral participant, and attempted to offer opinions and advice; however, at that point he was not re-granted CVS access. U1 left the community soon after.	IN2 began participating in the project when he reported a bug, which he also attempted to fix. However, another core developer reported that IN2’s patch “doesn’t seem to work… at least on my test system.” IN2 disappeared immediately after this critical feedback was posted.
From the beginning, S4 had full access to the entire project. He proactively engaged with and helped other developers by answering their questions. He gained recognition for his active participation in the construction of the systems and prompt responses to others’ requests. S4 was considered a strong member.	U3 became a core developer at the early stage of the project due to his coding and functionality experience. His useful advice to other members gained him a positive reputation in the community, and gained him access to make CVS updates. However, his experience was limited to the one module he had originally coded. When the team began moving on to new modules, other members began questioning U3’s value. He gradually disappeared.	IN4 entered the community with a question, but did not provide any suggestions to resolve it. Subsequently he reported a second bug, with some coding contribution trying to resolve it. However, the community leader tested the coding and reported that it did not work. IN4 did not participate any further.
S5 was publicly welcomed by a core developer when he joined the community, and he was immediately assigned some tasks. S5 proved himself to be both an advisor who shared important ideas, and a hard-working coder. His contributions were acknowledged and appreciated by his peers. Over time, he was assigned more and more tasks.	U5 was an experienced developer who frequently helped others by providing technical suggestions. Her contribution earned her praise and recognition within the community. However, over time she stopped submitting patches and code updates, apparently leading to the loss of identity status. After one year, U5 withdrew completely from the community.	During his short tenure, IN9 reported and attempted to fix numerous errors and bugs. Despite frequent participation, he made several mistakes, and the suggestions he provided were not considered useful. After one core developer stated that, “Your page just causes JS errors here (with IE 6.0 SP1), nothing else,” IN9 disappeared from the project.
S9 started as a peripheral participant and eventually became a core member. He actively fixed bugs, both those he identified himself, and others assigned by the administrators. He was formally recognized as a major contributor for his work rewriting “dump code” for PHP4 and MySQL table statistics. S9 followed through on his promises, helped other developers solve their problems, and earned a strong positive reputation.	Although there was no access to the CVS system, U6 was active in responding to questions and concerns. His contribution was manifested by a large amount of communication with the core developers. However, U6’s participation in the project was blocked by a more experienced core developer when their ideas about how to move forward conflicted. Concurrently, U6 was unable to solve a technical problem, raising questions about his technical competency. He left the community gradually over a six-month period.	IN11 was always passive in the community. Instead of trying to solve problems himself, or offer advice for how it might be solved, he merely reported bugs that were reported to him by his customers, apparently expecting other developers in the community to resolve them. (For example, “Can someone else try to recreate this? If so, please tell me I’m not insane.”) IN11 eventually left the community, having made little to no contribution.

RELATED READING

• W.J. Orlikowski, “Knowing in Practice: Enacting a Collective Capability in Distributed Organizing,” Organization Science 13, no. 3 (2002): 249–273.
• Yulin Fang and Derrick Neufeld, “Understanding Sustained Participation in Open Source Software Projects,” Journal of Management Information Systems 25, no. 4 (2009): 9–50.
• Jorge Colazo and Yulin Fang, “Impact of License Choice on Open Source Software Development Activity,” Journal of the Association for Information Science and Technology 60, no. 5 (2009): 997–1011.