People Analytics Should Allow Employees to Oversee the Usage of Their Data

We can empower employees in the digitalized workplace, and enable accountability for data misusage, by making usage of personal data visible to those who are affected.

This blog post summarizes our paper “Rethinking People Analytics With Inverse Transparency by Design (open access preprint, arXiv version). The paper was published in Proceedings of the ACM on Human-Computer Interaction and presented at the 26th ACM Conference on Computer-Supported Cooperative Work and Social Computing (CSCW).

Bidirectional (inverse) transparency can empower employees. Photo by Scott Graham on Unsplash.

Most workplaces are increasingly digitalized, which enables advanced people analytics. These are tools for data-driven management of the workforce that may use various data, including email communications or in some cases even health indicators (e.g., step count). Employees have little say regarding if and how their data are processed, and the inner workings of advanced people analytics can be quite opaque to those subjected to them. Therefore, data misusage or discriminatory analysis errors can become harder to detect or react to.

Simply preventing advanced analytics (e.g., with more powerful privacy legislation) can seem like an attractive solution, but it may stifle sensible use cases for data as well. Instead, we propose a different solution, inspired by David Brin’s 1998 book The Transparent Society: We can empower individuals by letting them “watch over their watchers”, a concept they call inverse transparency. Imagine the same people analytics, but whenever data of an employee are processed, this data usage is made visible to them. This allows employees to monitor usage of their data and decide for themselves if they find it appropriate. In case harmful consequences arise, they have access to a usage log that can then, e.g., be made available to the worker’s council or a lawyer.

Fig. 1. Providing inverse transparency on a conceptual level. The data consumer accesses a datum from the data source. Their usage is logged and stored. The data owner can now retrieve the logged usage information.

Incorporating inverse transparency by design is vital, as this may change how the people analytics tools are designed in the first place. Consider the typical analytics tools and specifically a scenario we refer to as ambient usage of data: When opening such a tool, data are often immediatelly loaded and processed, e.g. to display a data-driven homepage (see Figure 2, left side). Now, consider inverse transparency: The simple act of opening a tool would lead to multiple recorded data usages, even if none of the generated insights are of interest to the data consumer. This may lead to a small but impactful change in the design of such tools: Instead of immediately loading various data and presenting insights up-front, they may instead present only blurred windows that require an explicit request (e.g., button click) to show the generated insight (see Figure 2, right side). Thereby, the data consumer’s explicit intent is expressed.

Fig. 2. Example of how interaction paradigms may change as a consequence of inverse transparency, illustrated at the example of Jira Software (image source: Atlassian; modifications: the authors). The status quo in Jira (left side): analyses are run and insights presented automatically when the tool is opened. Inverse transparency may transform this paradigm (right side): the insights are hidden and need to be explicitly activated, signaling explicit intent by the data consumer.

Two important stakeholder groups need to be heard to assess the feasibility and potential effects of our proposal: developers (responsible for the software design) as well as users (employees subjected to people analytics). Therefore, we conducted two exploratory studies to assess these perspectives. We propose a paradigm shift, so we need to fully control the setting and remove potential confounding factors to support internal validity. A high internal validity means that we can know for sure that our interventions were in fact responsible for any measured effects. Therefore, we conducted two laboratory studies with students that mirror the real-world use case of a software development department. While the use of students was necessary for our case, the artificial nature of the studies may limit their external validity. A lower external validity means that the study results may not be transferable directly to real-world workplaces. Therefore, given concrete usage scenarios, small case studies may be a useful next step that can help investigate context-specific differences.

Developer Perspective

In our first study we assess, among other research questions, how the approach of inverse transparency by design is judged by developers. Four teams of a total of 12 developers implemented people analytics tools with inverse transparency by design over a period of three months. They regularly submitted reflection reports and filled a questionnaire after the study ended.

Generally, our participants understood the potential value of people analytics, highlighting that these tools can provide “a more objective view” and help “verify [one’s] hypotheses about a team.” Yet, they also noted risks, including the tools being potentially “privacy invasive”, “flawed”, or “biased”. Therefore, “inverse transparency with regards to data access is desirable,” as it can “avoid misuse of [the tool]” and “reassure the user of the safety of their data.” Regarding the technical realization, integrating inverse transparency by design was judged as a “viable concept which can […] work in practice.”

When analyzing the developed technical artifacts, we find similarly promising results. All developers could integrate inverse transparency without inhibiting core functionality. Interestingly, one team’s realization of inverse transparency seems to intentionally counteract the issue of ambient usage that we discuss above: When their “Git Analysis Tool” is opened, the data consumer needs to explicitly select the desired analyses before any data are processed or insights are generated (see Figure 3). This can be considered the most basic form of implementing inverse transparency, as the interaction paradigm and features can remain the same — the tool simply needs to add a step before starting its data processing.

Fig. 3. Sequence diagram of how one team realized inverse transparency. Data consumers have to explicitly select analyses before any data are processed. This data usage is logged before the report is generated.

User Perspective

In our second study we assess, among other research questions, if our participants considered inverse transparency for people analytics valuable in general. To that end, 15 participants were separated into four teams with one “team lead” and four “developers” in each. This, again, mirroring the use case of a software development workplace. During the study, regular written self-reflections were submitted. After the study, participants answered two additional questionnaires.

The teams in the study worked with people analytics that were built by the developers in our first study with inverse transparency by design. The workflow (see Figure 4) is an instantiation of our concept (see Figure 1 above). The tools “Jira” (issue tracking), “Slack” (team communication), and “Git” (source code version control) were used for work and collaboration by developers, while team leads could access the generated data from these tools to gain insights delivered by the people analytics.

Fig. 4. The workflow and utilized tools in the second study. Developers worked with Jira, Slack, and Git that collected data on these interactions. These data were then analyzed by the team leads with the people analytics created in the first study. The logged usage information was finally made available to developers via a transparency dashboard.

As part of the questionnaires, we asked all participants how valuable they considered inverse transparency in general. Concretely, we asked them to rate their agreement with the following statements:

• Inverse transparency improves upon the protection of the GDPR. (Q18)
• I would prefer inverse transparency over just having the right to consent to or reject data usages outright. (Q19)
• If my company offered me the choice, I would like to have access to data usage tracking. (Q20)
• I would feel safer knowing how my data are accessed in detail. (Q21)

Fig. 5. Results of the questions about inverse transparency generally (abbreviated as “InT” above). All participants (n = 15) were asked to express their agreement on a five-point Likert scale (X-axis), from 1 for “strongly disagree” to 5 for “strongly agree.”

We find (see Figure 5) that participants responded overwhelmingly positively. When asked to reflect on their responses, participants noted their support. The overall positive sentiment is nicely summarized by the following quotes:

I think that if implemented correctly, Inverse Transparency could be a game changer for privacy.

Another participant wrote:

[B]eing able to track how my data is used is beneficial to myself, to transparancy [sic!] within the team and ultimately to the relationship between data owners and data consumers.

Expecting a rethink of people analytics design may seem rather ambitious. Yet, in practice, companies use only few people analytics tools. And, as we could see with the introduction of the GDPR, changes in software design can be swift if legally or contractually enforced.

We believe that more transparency for employees is vital to increase acceptance of people analytics. This shift may have a more pronounced influence on software design than just that, though—fundamental interaction paradigms may need to change to counter the risks of ambient usage as outlined above.

Still, while providing inverse transparency can be a valuable step, it may not suffice: too much transparency or “wrong” ways to frame it may have a negative impact, making individuals more anxious of how their data are used. And habituation, meaning becoming blind to a large volume of relatively similar usage logs, may become a long-term issue as well.

Thus, careful consideration and additional, context-specific, research will be necessary before introducing inverse transparency into the workplace.

These efforts are valuable, though: We found that inverse transparency by design can be practical from a technical standpoint and is experienced as beneficial by participants of our studies, including both users and developers. This is a promising sign that it has the potential to be an important factor in accepted and responsible people analytics.

Citation

Valentin Zieglmeier and Alexander Pretschner. 2023. Rethinking People Analytics With Inverse Transparency by Design. Proc. ACM Hum.-Comput. Interact. 7, CSCW2, Article 292 (October 2023), 29 pages. https://doi.org/10.1145/3610083