The Coevolution of Tasks and Expertise
-
Published:2025
Lisa E. Cohen, Le H. Bui, "The Coevolution of Tasks and Expertise", Expertise in and Around Organizations: The Changing Constitution and Ecology of Expertise, Kasper T. Elmholdt, Ruthanne Huising, Elina I. Mäkinen
Download citation file:
How do tasks and expertise coevolve? Tasks and expertise are tightly linked and essential for the execution of work in organizations. Despite the link in the practice of tasks and expertise, scholars have yet to theorize them as coevolving. A small body of research provides evidence that by failing to treat them this way, research misses insights critical to explaining the evolving nature and future of work. To explore these dynamics, we analyze interviews and observations of people involved with the data-collection task in an early-stage startup. We trace the task’s detailed movement across jobs and by doing so, observe complex dynamics between the task and associated expertise. The task moved from proto-analysts to analysts to data-entry operators and, with that, the core expertise required for the task moved across positions. In addition, doing data collection produced expertise that those in the analyst position applied in performing other tasks. In part, because it facilitated the production of expertise, analysts continued to collect data – a task that they routinely complained about doing – even after it migrated to data-entry operators. Based on these findings, we develop the distinction between core and produced expertise. We also refine our understanding of hiving-off with an alternative explanation for why menial tasks might not be hived-off. Finally, our findings enhance our understanding of the dynamics around change in jobs and task segregation.
Introduction
Work tasks and expertise together shape how and how well work gets done. When expertise is applied, it is always in performing tasks. When tasks are performed, that performance always draws on some form of expertise. Yet, while the two are inextricably linked in practice, scholars rarely treat them as co-evolving – that is, as reciprocally affecting each other’s evolution in a reverberating way over time. For the most part, scholars study one of these concepts at a time, consider them as co-existing without influencing each other, or, at best, examine one as subservient to the other without significant reverberations (Ericsson & Lehmann, 1996; Greenwood et al., 2019; Haerem & Rau, 2007). Furthermore, while evolutionary change is likely to occur at the level of individual tasks and the related expertise, scholars often treat these concepts in the aggregate: they discuss sets of tasks at the level of the job, organization, or occupation (e.g., Cohen, 2016); they discuss bodies of expertise as properties either of individuals who develop, maintain, and apply expertise or of a higher-order collective – for instance, occupations or organizations – where expertise is applied (Heimstädt et al., 2023). These problems are exacerbated by a tendency of each literature to discuss the focal construct – tasks or expertise – as relatively stable entities. That is, tasks themselves and configurations of tasks are considered to be managerially pre-determined (see Cohen, 2016 for a related argument). Similarly, while experts may increase their level of mastery or try to apply expertise in other domains, the core body of expertise itself changes relatively little (Chi et al., 2014; Ericsson & Lehmann, 1996; Green et al., 2019). In this paper, we shift the focus and ask how a single task and the associated expertise coevolve and examine the implications of this coevolution.
A handful of recent studies have demonstrated that examining the dynamics of tasks and expertise at a detailed level provides insights that would otherwise be missed. For instance, a study of puppeteers describes how new expertise emerges and becomes central to puppeteers as their work tasks shift with the transition from film to stage (Anteby & Holm, 2021). In a study of technology implementation in banking, Anthony (2021) shows that how employees perform tasks shapes the expertise developed differently for two groups of employees in the same job. The work was partitioned in one group: junior bankers did the data analysis, and senior bankers interpreted the results. In the other group, junior bankers did both analysis and interpretation. Consequently, only junior bankers in the second group developed the expertise needed to do data interpretation. Kahl and colleagues (2016) describe a case study where, in response to the obsolescence of one of their central tasks, members of an occupation successfully applied the expertise developed around the obsolete task to other tasks. The central story of the dynamics of tasks and expertise shown in these, and a handful of other studies, demonstrates considerable and ongoing give and take between the tasks and expertise. It also shows that failing to consider their evolution at a detailed level could create false impressions about the dynamics of work.
The lack of attention to the coevolving nature of tasks and expertise is especially problematic in the current landscape, where the pace of change in work seems to be increasing at an increasing rate; the forces of technology, regulation, globalization, and other institutional changes are continually altering what work is done and what expertise is needed to do it. Work scholars are challenged to predict how institutional and technological changes will change work itself and, in particular, the tasks and expertise associated with it. For instance, scholars struggle to anticipate how AI and other smart digital technologies will affect work. Discussions of AI and work have quickly gone from broad proclamations that AI will destroy billions of jobs to more subtle discussions of how AI will change tasks within jobs and ripple through systems of work (Hollister et al., 2024). At the same time, scholars of expertise struggle to predict the effects of a potential crisis of expertise brought on by similar factors: will technology usurp expertise; will society continue to lose faith in experts and expertise (Heimstädt et al., 2023; Huising, 2023; Pakarinen & Huising, 2023)? While rumors of the death of expertise may be greatly exaggerated (Pakarinen & Huising, 2023), rumors of impending change in expertise may not be. For instance, the tendency of expertise to be primarily institutionalized through occupations may not prevail in the changing landscape of work (Heimstädt et al., 2023; Huising, 2023; Pakarinen & Huising, 2023).
Taken together, the link between tasks and expertise, the existing evidence of their complex relationships, and the trends surrounding them suggest that we need to understand more about the coevolution of tasks and expertise. In this paper, we explore these dynamics by tracing the detailed movement of and changes in a single task – data collection – in conjunction with the related expertise across jobs in a tech-enabled startup over two years. We trace this task and expertise using data from 122 interviews and 180 hours of observations of people connected to this work.
We found that tasks and expertise coevolved and did so in response to various organizational dynamics. Following shifts in technology and the business and operational models, the task moved across jobs from proto-analysts to analysts and then to data-entry operators. With the task movement, related expertise also evolved. Some core expertise was required and applied to do data collection. For the most part, this core expertise remained constant as the task and expertise moved across jobs. However, another form of expertise emerged and evolved from doing the task. Doing data collection produced new expertise about governance practices, data quality, and more. The new expertise was applied by analysts to other tasks like training, analyses, and writing. Because of this produced expertise, analysts did not fully hive-off data collection. The coevolution had implications for the task and expertise but also for the jobs of interest, which in turn influenced employees’ experiences and the ability of the company to attract and retain them.
By looking at how a single task and the associated expertise coevolved, we make contributions that might have been masked by more aggregated analysis. We provide empirical evidence of the depth of the link between the two and of how that link helps us to understand reverberating changes. We contribute to the literature on expertise with the introduction of the concepts of core and produced expertise. Our findings also have implications for the study of hiving-off processes, explaining why complete hiving-off may be rare. Finally, we contribute to understanding of how the expertise surrounding tasks can shape the allocation of tasks to jobs.
Theoretical Background
Tasks and Task Evolution
Work tasks are the minute pieces of work assembled to form a larger, more easily discernable body of work known as a job, position, or role. Since Adam Smith’s (1937 [1776]) foundational discussion of the organization of pin-making tasks, scholars have engaged in a robust discussion of the effects of tasks and task arrangements on organizational and individual outcomes: e.g., efficiency, job satisfaction, control over workers, and pay (Braverman, 1974; Hackman & Oldham, 1975; Wilmers, 2020). Yet, for the most part, research has assumed that task arrangements were the deliberate and stable products of goal-directed managers responding to administrative and technological imperatives (see Burton & Beckman, 2007; Cohen, 2016; Miner, 1987 for related arguments).
A handful of scholars have more recently considered the dynamics that bring tasks into and out of jobs. One such line examines how employees craft their jobs to suit their preferences, while another related line considers how jobs might be constructed around employees (Miner, 1991; Miner & Akinsamni, 2016; Rousseau et al., 2006; Wrzesniewski & Dutton, 2001). Others have considered task allocation as an assembly process that invokes multiple actors across levels and the ties between tasks and jobs and other structures that hold them in place (Cohen, 2013, 2016). Research has also begun exploring the segregation of tasks within jobs and how the same tasks potentially have differing implications for those performing them: for instance, Chan and Anteby (2016) show differentiation in the tasks performed by people ostensibly with the same job and how that affects their career prospects. However, to our knowledge, there is only limited explicit attention to expertise in research on task evolution. When expertise is discussed in the literature on tasks, it is typically treated as an unintended byproduct.
Expertise and Expertise Evolution
Defining expertise is a complex undertaking. A recent review of expertise scholarship identified three perspectives on the study of expertise – Realist, Constructivist, and Situationist – and in each of these, the construct is defined differently, sometimes in multiple ways (Heimstädt et al., 2023). Across the varied definitions noted in this review and other studies of expertise, two central properties emerge: Expertise is based on knowledge and know-how (Pakarinen & Huising, 2023), and expertise facilitates the superior performance of experts on work tasks (DiBenigno, 2018; Ericsson & Lehmann, 1996; Eyal, 2013; Sandefur, 2015). Building from these ideas, we define expertise narrowly as the body of specialized knowledge that facilitates the execution of tasks. Like the expertise scholars who fall into the Constructivist and Situationist views of expertise identified by Heimstädt and colleagues (2023), we examine expertise as a dynamically constructed or emergent property.
Where we differ from many past treatments of expertise is that we do not consider expertise as inherent to occupations (Abbott, 1988; Gorman & Sandefur, 2011; Pakarinen & Huising, 2023). While arguably all occupations are built around expertise, not all expertise is occupationally bounded (Abbott, 1988). Recent evidence suggests that how expertise is developed and valued is determined at the organizational level (Monteiro, 2024). Nor is it likely that in the face of tectonic shifts surrounding work, occupations will remain the only way that expertise is created and institutionalized (Huising, 2023). By considering expertise outside of occupational structures, we move away from ideas typically associated with expertise: that the knowledge at the base of expertise is somehow intellectually elevated and that this elevation allows occupations to maintain control over the expert work; that expert knowledge is recognized as superior by outsiders; that expertise like occupations transcends organizational boundaries. Our approach has the advantage of shifting the focus from the occupational members who do the work to the employees in organizations – “bounded collections of people and material, financial, and information resources” (Haveman, 2022, p. 2) – where the work is done. By doing so, we can better examine how the constellations of people and resources around a task drive expertise (Monteiro, 2024).
While our definition is narrow, it does not preclude that expertise is connected throughout a broader system. As other scholars have argued, expertise is a relational construct, one that connects those performing it with audiences, actors, and structures (Anteby & Holm, 2021; Eyal, 2013; Pakarinen & Huising, 2023). This relational system of expertise includes some factors by definition – knowledge, tasks – and many others by implication – the experts themselves, those who manage the experts, the organizations in which tasks and expertise are performed, associated rewards, and, sometimes, occupations in which these are embedded. Tasks are part of the relational network around expertise just as expertise is part of the relational network around tasks.
Expertise scholars have proposed several ways to distinguish or categorize expertise based on the level, content, or domain of that expertise. For instance, Collins and Evans (2019, p. 14) distinguish levels of expertise ranging from interactional to contributory expertise. Contributory expertise, the highest level, is the ability to recognize and adapt to contextual cues and cannot be attained by novices through rules and guidelines. Only those who reach the level of contributory expertise are truly experts who perform superior work autonomously. Expertise has also been categorized based on the content of the expertise: is it processual, relational, substantive, abstract, or contextual/relational (Barley, 1996; Pakarinen & Huising, 2023), and the degree to which it is broad or deep (Heimstädt et al., 2023). Expertise has also been described based on the specific type of work or occupation it is associated with. For instance, marketing expertise (Paşa & Shugan, 1996), information technology expertise (Haislip et al., 2021), and legal expertise (Kellogg, 2014). Notably, related to both level and content, some have treated process expertise – expertise enacted in coordinating information and communication – as a distinct form of expertise that can be applied across specialist domains (Barley et al., 2020; Treem & Barley, 2016, 2018). We move the focus from categorizing expertise based on level, content, and domain to differentiating it based on when and how it is created relative to the task at hand.
The dominant streams of research on expertise, much like those on tasks, treat it as a relatively stable construct. Experts may change but expertise rarely does. Within this literature, scholars focus on how training, socialization, the transfer of expertise across members of occupations, and other mechanisms foster superior performance in a known body of work (Anteby et al., 2016; Carr, 2010; Dreyfus & Dreyfus, 2005; Ericsson & Lehmann, 1996). This treatment of expertise stems, in part, from the focus on expertise as the core of occupations that themselves are relatively fixed structures. Indeed, members of the system of occupations resist change both in terms of the addition and elimination of tasks and expertise (Huising, 2014, 2015; Sandholtz et al., 2019). Though dominant, the tendency to view expertise as fixed is not absolute, and when scholars break from it, they provide unambiguous evidence that there is much left to learn about expertise in relation to task dynamics.
The Coevolution of Tasks and Expertise
A handful of scholars have taken a more dynamic approach to the study of expertise and tasks, most often by examining how new problems associated with social movements, technology, regulation, and more lead to the emergence of new work tasks and new expertise that are allocated to occupations (Abbott, 1988). Similarly, evidence suggests that existing tasks and expertise may move into or out of occupations when problems arise with existing arrangements; for instance, regulations might mandate that tasks be added or removed from occupations (Huising, 2014). Higher-status occupations may hive-off tasks that are menial, codified, or otherwise less desirable to reinforce occupational status hierarchies and maintain the purity of their expertise (Abbott, 1988). For instance, Abbott (1988) described how, starting in the 1960s, doctors delegated menial tasks such as giving shots to nurses.
There are recent hints that tasks and expertise might co-evolve in ways other than moving into and out of occupations. For instance, differences in the allocation of tasks to groups within an occupation may lead to changes in expertise (Anthony, 2021; Chan & Anteby, 2016). Exogenous changes such as the introduction of new search technologies for librarians (Nelson & Irwin, 2014), the introduction of DNA profiling techniques for crime scene investigators (Bechky, 2020), and decreased demand for expertise for on-stage puppeteering (Anteby & Holm, 2021) produced variations in how core tasks are performed, consequently altering expertise.
Together, this work provides compelling evidence that tasks should be more central to the study of expertise and expertise should be more central to the study of tasks. Our review also highlights that occupations as such are not the sole driving force for this interplay between tasks and expertise. While most of the evolution discussed in this research is within and between occupations, it is patterned by organizational and even societal factors. Organizations and societies shape who and what work people do and how they do it through choices about technology, organizational structure, and business and operational strategies. Organizations are the funnels through which broader changes come to work. This funneling, in turn, shapes what happens to tasks and expertise, suggesting potential benefits to considering these issues in contexts where occupations have less influence. Furthermore, our review of research on the evolution of tasks and expertise highlights the importance of looking at the two as dynamic and interconnected. It also highlights the value of drilling down to the level of tasks and the related expertise in examining them.
Research Design
Because our study was exploratory and focused on questions concerning processes and interactions, we used qualitative methods to directly observe the phenomenon of interest and the factors identified as potentially important (Edmondson & McManus, 2007). We wanted a setting where we could observe the coevolution of expertise and tasks in an organizational context and see how multiple actors participated in and were affected by this evolution. Furthermore, because we believed that the occupational lens may limit understanding, we wanted a setting without a well-developed occupational structure. To meet these needs, we drew on an in-depth study of an early-stage startup that we call Sage.
Setting
Sage was founded in 2016 as a spin-off of Advisors, a corporate governance consultancy. Partners at Advisors identified a business opportunity: clients needed access to better data on boards of directors to meet regulatory requirements. This data was publicly available from internet sources – for example, in annual reports, disclosures, press releases, and media – but was not compiled in a single place or easily collected. To fill this gap, they created a project that later became Sage to gather and sell this data. Sage was about a year old in early 2018 with 15 employees when data collection began and peaked 18 months later with over 40 employees. The company was dissolved in 2020 following the start of Covid-19.
We focus on one specific task – data collection – and the expertise associated with it. While data collection is often dismissed as a dreaded and menial task (Cohen, 2020), it was central to Sage, a company created expressly to provide data. In the context of Sage, performing data collection involved online searches for information about boards of directors – for example, the number of directors, director independence, committee memberships, and demographics – from publicly available documents such as annual reports and press releases and entering the information into a structured database. This work was performed by people in multiple jobs in three different arrangements over time. We describe the tasks and expertise associated with this work and their movement across jobs in detail in our findings.
Data Sources
We collected data over two years through interviews, observations, and archival materials. Altogether, we conducted 122 interviews with Sage employees during multiple office visits and follow-up phone or video interviews with these employees and others who were not in the office during visits. This included the management team – CEO, CTO, Research Head, and Sales Manager – 16 full-stack developers, 12 analysts, and 9 data-entry operators (DEOs). Most individuals were interviewed on multiple occasions. Table 1 provides details on the interviewees and the arrangements that each discussed.
List of People Interviewed.
| Subjects | Number of Interviews | Arrangements Discussed |
|---|---|---|
| Management team | ||
| CTO (Bertrand) | 2 | All |
| Research Head (Karie) | 9 | All |
| CEO (Seth) | 5 | All |
| Sales Manager (Elijah) | 1 | 3rd |
| Analysts | ||
| Grace | 2 | All |
| Corey | 2 | 2nd–3rd |
| Nick | 2 | 2nd–3rd |
| Violet | 3 | 2nd–3rd |
| Bella | 3 | 2nd–3rd |
| Raven | 7 | 2nd–3rd |
| Ella | 2 | 2nd–3rd |
| Rina | 2 | 3rd |
| Victoria | 3 | 3rd |
| Marco | 4 | 3rd |
| Ethan | 5 | 3rd |
| Julia | 5 | 3rd |
| Data-entry operators | ||
| Seema (promoted to Junior Analyst) | 4 | 3rd |
| Gabriel (promoted to Junior Analyst) | 4 | 3rd |
| Lacey | 1 | 3rd |
| Jane | 1 | 3rd |
| Cheyenne | 1 | 3rd |
| Alex | 1 | 3rd |
| John | 1 | 3rd |
| Clive | 1 | 3rd |
| Kanta | 1 | 3rd |
| Developers | ||
| Andy | 3 | All |
| George | 3 | All |
| Owen | 4 | All |
| Kenny | 6 | All |
| Ian | 2 | All |
| Mike | 3 | All |
| Leo | 3 | All |
| Aurelien | 1 | 3rd |
| Valeria | 1 | 3rd |
| Sabrina | 2 | 3rd |
| Genevieve | 2 | 3rd |
| Kelsey | 3 | 3rd |
| Parker | 2 | 3rd |
| Adrian | 1 | 3rd |
| Horatio | 1 | 3rd |
| Jennifer | 3 | 3rd |
| Other | ||
| Business Intern 1 (Sophia) | 1 | 2nd |
| Business Intern 2 (Shane) | 1 | 2nd |
| Business Intern 3 (Edith) | 1 | 3rd |
| Senior Site Reliability Engineer (Rupert) | 1 | 3rd |
| Site Manager (Christine) | 1 | 3rd |
| Advisor (Duke) | 1 | 3rd |
| Office Manager (Scarlet) | 4 | 3rd |
| Marketing Manager (Vincent) | 1 | 3rd |
| Total: 49 people | Total: 123 interviews | |
| Subjects | Number of Interviews | Arrangements Discussed |
|---|---|---|
| 2 | All | |
| Research Head (Karie) | 9 | All |
| 5 | All | |
| Sales Manager (Elijah) | 1 | 3rd |
| Grace | 2 | All |
| Corey | 2 | 2nd–3rd |
| Nick | 2 | 2nd–3rd |
| Violet | 3 | 2nd–3rd |
| Bella | 3 | 2nd–3rd |
| Raven | 7 | 2nd–3rd |
| Ella | 2 | 2nd–3rd |
| Rina | 2 | 3rd |
| Victoria | 3 | 3rd |
| Marco | 4 | 3rd |
| Ethan | 5 | 3rd |
| Julia | 5 | 3rd |
| Seema (promoted to Junior Analyst) | 4 | 3rd |
| Gabriel (promoted to Junior Analyst) | 4 | 3rd |
| Lacey | 1 | 3rd |
| Jane | 1 | 3rd |
| Cheyenne | 1 | 3rd |
| Alex | 1 | 3rd |
| John | 1 | 3rd |
| Clive | 1 | 3rd |
| Kanta | 1 | 3rd |
| Andy | 3 | All |
| George | 3 | All |
| Owen | 4 | All |
| Kenny | 6 | All |
| Ian | 2 | All |
| Mike | 3 | All |
| Leo | 3 | All |
| Aurelien | 1 | 3rd |
| Valeria | 1 | 3rd |
| Sabrina | 2 | 3rd |
| Genevieve | 2 | 3rd |
| Kelsey | 3 | 3rd |
| Parker | 2 | 3rd |
| Adrian | 1 | 3rd |
| Horatio | 1 | 3rd |
| Jennifer | 3 | 3rd |
| Business Intern 1 (Sophia) | 1 | 2nd |
| Business Intern 2 (Shane) | 1 | 2nd |
| Business Intern 3 (Edith) | 1 | 3rd |
| Senior Site Reliability Engineer (Rupert) | 1 | 3rd |
| Site Manager (Christine) | 1 | 3rd |
| Advisor (Duke) | 1 | 3rd |
| Office Manager (Scarlet) | 4 | 3rd |
| Marketing Manager (Vincent) | 1 | 3rd |
| Total: 49 people | Total: 123 interviews | |
The first author and another project member spent over 180 hours in seven periods ranging from one day to one week in the head office and three days in Sage’s satellite office. As non-participant observers, the researchers interviewed subjects, attended meetings, sat in on job interviews, ate lunch with employees, joined them for after-work drinks, and observed daily interactions. The researchers were given a desk in the open-plan offices from which they observed daily activities. They typed field notes on an ongoing basis and created analytic notes afterward, which were analyzed along with interview transcripts. Meetings were recorded and the recordings were transcribed. Furthermore, we collected archival data from slide decks, emails, and job postings. Our understanding of this setting and our analysis drew from all the data.
Analysis
Our data analysis progressed through five steps (Grodal et al., 2020), moving from broad intuition about Sage to more specific insights about the coevolution of tasks and expertise. We show this progression in Fig. 1 and describe it in detail below. For each step in this figure, we show specifically what form of analysis we did and what we learned that guided us to the next analytical step.
Step 1: reviewed transcripts and field notes, finding many changes within the organisation. Step 2, Constructed and reviewed the events timeline, finding most actions and events revolved around three jobs. Step 3: wrote and reviewed job summaries, finding changes in a set of tasks around data collection. Step 4: Created and coded job arrangement descriptions, identifying three primary arrangements around data collection. Step 5: coded data collection dynamics, finding coevolution of tasks and expertise.Data Analysis Process.
Step 1: reviewed transcripts and field notes, finding many changes within the organisation. Step 2, Constructed and reviewed the events timeline, finding most actions and events revolved around three jobs. Step 3: wrote and reviewed job summaries, finding changes in a set of tasks around data collection. Step 4: Created and coded job arrangement descriptions, identifying three primary arrangements around data collection. Step 5: coded data collection dynamics, finding coevolution of tasks and expertise.Data Analysis Process.
Step 1: Reviewed transcripts and field notes. Each of the authors reviewed the transcripts and field notes multiple times. Our goal in this review was to understand Sage’s evolution. In our review, we noted numerous changes in work over time.
Step 2: Constructed and reviewed events timeline. To better see Sage’s evolution, we created a timeline of events from Sage’s creation to its death using the transcripts and field notes. We noted the movements of people in and out of the organization and the events happening around them. It became clear that much of the activity centered on three jobs – developers, analysts, and data-entry operators.
Step 3: Wrote and reviewed job summaries. We used the transcripts, notes, and timeline to write role descriptions for the three central jobs. The summaries included information on who was hired to do what work, how that work was done and changed, who interacted, and what expertise was needed. Based on these, we observed that the tasks associated with data collection and entry appeared in several arrangements across the three positions. We noted that with the shifts in arrangements, there were also shifts in expertise, in terms of its distribution across roles and the precise expertise associated with each role. Our next task was to understand more about those arrangements.
Step 4: Created and coded job arrangement descriptions. We reviewed our analytical documents to understand more about the evolution of tasks and expertise across these arrangements. In doing this, we learned that what is commonly referred to as data collection included five tasks: mapping the data points that needed to be collected, collecting that data from online sources, adding data to the database, validating the data, auditing the validated data, and the training of people to perform those tasks. We then created detailed descriptions of the three primary arrangements observed, including what work was being done, by whom, what expertise was invoked, and what the intent was. Once we created these detailed descriptions, we noted that looking at the five sub-tasks here would make it difficult to see the important action. Data collection was the most central to these activities with the richest dynamics around it. It seemed to be key to understanding the coevolution of tasks and expertise.
Step 5: Coded data collection dynamics. We returned to the data and further analyzed the dynamics associated with data collection. We observed that there was expertise required to do data collection and that performing that task refined that expertise. However, we also observed that performing data collection, at times, produced other forms of expertise that, in turn, became core requirements to do still other tasks. Finally, we noted that the data-collection task and expertise were distributed across jobs and that there was further differentiation within jobs.
The Data-collection Task and Expertise, and Their Coevolution
In this section, we describe the evolution of tasks, expertise, and jobs uncovered through our analysis. This co-evolution is depicted in Fig. 2. It begins in the upper left with the various jobs where people collect data in each phase based on the core expertise brought to the positions and developed through training and practice (lower left). It then shows that doing data collection led to newly produced expertise. This produced expertise facilitated analysts performing tasks other than data collection: training, creating guidelines, and supervising. We describe each of the figure’s boxes and arrows below.
The diagram presents the evolution of tasks and expertise. Data collection begins with proto analysts and first analysts in the pre A I pilot stage, moves to analysts in the post A I pilot stage, and expands to junior analysts and data entry officers in the post hiring stage. Core expertise is developed through starting knowledge, learning by doing, training, and feedback, including skills on where to find data and how to enter data. Produced expertise is grouped into corporate governance, data structure, data collection process, and data quality. These outputs enable tasks such as training, creating guidelines, supervising, validating data, auditing, structuring databases, analysing data, and developing products.Evolution of Tasks, Expertise, and Jobs.
The diagram presents the evolution of tasks and expertise. Data collection begins with proto analysts and first analysts in the pre A I pilot stage, moves to analysts in the post A I pilot stage, and expands to junior analysts and data entry officers in the post hiring stage. Core expertise is developed through starting knowledge, learning by doing, training, and feedback, including skills on where to find data and how to enter data. Produced expertise is grouped into corporate governance, data structure, data collection process, and data quality. These outputs enable tasks such as training, creating guidelines, supervising, validating data, auditing, structuring databases, analysing data, and developing products.Evolution of Tasks, Expertise, and Jobs.
Legend:
The rectangles represent tasks.
The parallelograms represent jobs.
The rectangles with rounded corners represent expertise
Arrows represent time.
How the Data-collection Task Evolved
We build a foundation for our findings with a detailed description of the data-collection task. This corresponds to the box on the upper-left of Fig. 2. Across interviews, those who did manual data collection consistently described two data-collection steps: finding the data and recording it. Finding the data started with pulling information from corporate annual reports. These reports varied in comprehensiveness, and, as a consequence, how much additional digging had to be done in disclosures, press releases, and media articles. As one DEO described:
The annual reports can be anywhere from 50 to 400-something pages and, depending on the client, I have to do quite a bit of web research. And a lot of times there’s just no information to be found, but I still have to keep looking until I determine that there’s just no information available.
Other DEOs and analysts described their data collection similarly. Once found, the data was entered into a database – initially an Excel spreadsheet and later a bespoke database. Often, this just meant typing a number or word into a pre-defined slot. However, this step sometimes involved more. For instance, they had to calculate annual CEO compensation from monthly data or age from birthdate.
When Advisors founded Sage, they appointed a Partner as CEO and he soon asked Karie, then a newly hired intern at Advisors, to join him on the project. Karie began manual data collection: “I joined this as an intern, which essentially meant that I was collecting all this data that we’re now collecting, just in Excel format.” She described the purpose of her data collection as going beyond simply finding and entering data; she was figuring out what data was available, what data clients might want, and what the product would be, and creating a roadmap that could be used when AI capabilities came online. She also created an Excel spreadsheet for data collection, which became the model for a bespoke database she developed with Sage’s CTO Bertrand. As Karie described it:
It became essentially working with Bertrand trying to figure out how to take these Excel files and to build something around it … We didn’t really have any products, it was mainly me, and Bertrand still working on kind of mucking out the data … And so, it became me and Bertrand more working on the product development.
The AI pilot aftermath. The intention at Sage’s inception had been that the data would later be scraped with AI. Toward this end, Karie and Bertrand were building an understanding of what data could be scraped from the internet. Sage’s developers would then create algorithms to collect massive quantities of data. In the meantime, Karie and other research-team members collected data manually as others at Sage worked to create algorithms. However, an AI pilot run by outside consultants produced disappointing results. It provided what Seth, the CEO, described as about five percent of the desired data at a remarkably prohibitive cost.
This pilot and the subsequent decision not to use AI as planned marked the transition to the next data collection arrangement. After this realization, the data collection and entry work continued to be performed manually by an expanding group of analysts under Karie’s direction. By this time, Sage had hired several analysts who in this period spent most of their days scouring the internet for data on bank boards of directors in much the same way their predecessors had before the failed AI pilot.
With this arrangement, data collection remained a goal, but planning for the AI transition slipped away completely, and the efforts to map data points fell primarily to Karie. The analysts’ primary focus was data collection. This was reflected by Violet, an analyst who also led analyst hiring in her description of the job to candidates she interviewed:
So, I would tell you that for the first six months, for the first month or two it will involve a lot of training, bank-specific training, and corporate governance-specific training; a lot of data collection and validation I would say for the first five or six months, which of course can be repetitive … going through these disclosures over and over again.
When we interviewed them at the time, many of the analysts expressed concern that they were doing so much data collection. They described the task as tedious, menial, too operational, below their level of expertise, and inconsistent with their expectations of the work that they would be doing. For instance, Grace, one of the early analysts, described her experience with data collection: “So I knew that I was going to do a lot of data collection and validation … but I have to say that after I’d done it for a few times it became really, really difficult to continue to do it because it’s such a boring task.” In describing her reasons for leaving Sage, Violet explained that she had taken an analyst job but was not doing “analyst” work. Other analysts offered similarly negative descriptions of data collection and its fit with their qualifications.
The arrangement with analysts doing all data collection was intended to be short-lived, a stopgap measure to keep data collection progressing. Seth, the CEO, described two reasons to transition from this arrangement. First, the costs of using analysts for data collection were high. Most analysts had master’s or law degrees, were based in London, and had salaries commensurate with that. Yet, as the task became more codified, it required less of the judgment and decision-making associated with the analyst position. Second, analysts’ frustrations about doing data collection reinforced his belief that this was not a good long-term solution and hastened a transition to the next arrangement.
Data-entry operators. Soon after the disappointing AI pilot, Sage began developing and implementing a new data collection model. Most of it would be performed by data collection specialists, eventually called data-entry operators, in a satellite office and outsourced offshore under the supervision of analysts.
The transition to this arrangement was gradual. Sage began to search for people to do this data collection. Initially, they posted for a junior-analyst position but realized the applicants were overqualified. The concern was that, like existing analysts, they would become frustrated. Sage then posted a Data-Entry Operator (DEO) position that would be filled by employees in a lower-cost satellite office and that did not require advanced degrees. In parallel, the analysts developed a DEO training process and tested it on temporary workers in the central office. Following this, much of the data collection moved from analysts and temporary workers to the newly hired DEOs in the satellite office and an agency in India.
Even as the DEOs came online, analysts continued to collect data but for reasons other than building the database. How much they did this task varied both over time and across analysts. For instance, Ella described weeks where she spent four days collecting data and weeks where she did none. There was continued evolution in what data would be collected and how it would be recorded. Karie explained that they would collect additional years of data, information on CEO compensation, other new variables, and data on non-bank organizations. However, the essential data collection task remained the same.
Core and Produced Expertise
Through observations and interviews, we identified two distinct types of expertise associated with data collection. There was what we call core expertise. We use this term to refer to the expertise required to collect data. This term is not used to refer to whether the task itself – collecting data – was core to the organization. Any task would have core expertise associated with it. Furthermore, this distinction is not based on the level, breadth, depth, or occupational domain of expertise; the nature of core expertise could range widely depending on the underlying task performed.
The second type of expertise associated with data collection was what we call produced expertise. We use this term to refer to expertise that is developed in performing a specific task but that, unlike core expertise, is not needed to perform that task as such. It is, however, needed to perform other tasks. Like the term core expertise, it does not indicate differences in level, breadth or depth, or occupational domain. Below, we described how each of these types of expertise evolved at Sage.
Core expertise. Through our interviews and observations, we learned that there was expertise required to do data collection, what we call core expertise, and that this remained constant across the arrangements. Whoever was collecting the data needed to know what data should be collected, where it might be found, and how it should be recorded. This expertise was produced in three main ways. First, at hiring they were screened for this expertise. They were expected to come in with some basic understanding of these elements from experience and education. Furthermore, once they start performing the data-collection task, they could augment or refine their understanding as they perform the task. Finally, they received some training on how to do this work, which varied over time as arrangements shifted.
Analysts, DEOs, and their managers described the knowledge sought at hiring for data collection. Most analysts said they were asked about their knowledge of corporate governance. For instance, Ella, an analyst hired when the second arrangement was in place, said her interview was “focused on corporate governance, you know, specific terms about corporate governance and what’s my understanding about the field.” DEOs were also asked about corporate governance knowledge, though the expectation for the level of knowledge was lower. Violet described her expectations for the DEOs: “I’m not really looking for someone who has the same sophisticated skills.” Cheyenne, one of the DEOs, recalled being asked whether she knew what corporate governance was but nothing more in-depth.
Sage used a work-sample test to assess job-skills fit. Grace, an analyst hired just before the AI pilot, described the expertise evaluated in the work-sample test she did: “It was basically going through an annual report and writing out into an Excel sheet … And [the interviewer] just wanted to know whether I understood the contents of the executive board.” Other analysts and DEOs described the work sample test in similar ways. For instance, the DEO, Cheyenne, described her work sample as follows:
[The recruiter] sent me … a test on how they do corporate governance data entry within their own database. And it was a spreadsheet. She sent me an annual report for a bank and a spreadsheet and said, “Fill out this spreadsheet for this board of directors…” There was a little bit of calculation for how old they were … when they were on the board.
Analysts and DEOs also described learning more about how to do data collection after joining Sage. Through on-the-job and more formal training, interns, analysts, and DEOs learned more about what data they were meant to collect, and where to find it: for instance, CEO compensation might be available in a bank’s annual report, in the media, or through other online sources. The pattern of training, however, evolved as the work and training became more codified. In the early days, there was little formal training and guidelines. As the first person to collect data at Sage, Karie provided a model for how that expertise would be developed. When she started, she drew on expertise in data collection and corporate governance built during her master’s degree. She also had guidance from the CEO on what was wanted but, at that point, Advisors had only general untested ideas about client preferences. As a result, her expertise was largely developed as she did the work. At this time, she provided other proto-analysts and eventually some early analysts with basic guidance on what to collect and how to collect it but, like Karie’s their training was largely on the job.
By the time Sage moved into the third arrangement, the pattern of expertise development had shifted. While, for the most part, the expertise needed to do data collection was the same, the work became more codified as much of the work was shifted to the DEOs. Expertise was embedded in the collection database: for instance, the needed data points were clear; some errors were automatically flagged. Corey and Bella documenting the process and developing more formal training materials while training the temporary workers as reported by Karie in a group meeting:
Corey created the document in order to have a more standardized way of reporting and training everyone. Still, some additions and corrections need to be made. So, this is why Corey will be attending the whole week, taking notes. Bella will be training the newcomers and hopefully, we will use this for a trial for [satellite office] as well.
Over time, the training materials became more elaborate. Corey and Bella made and updated training videos that covered all aspects of data collection. Later, when those videos did not seem to fully address the questions and needs of the DEOs, another analyst, Raven, led the development of a more detailed training manual to which each analyst contributed sections on their areas of specialization:
It’s huge … It ended up being about I think 84 slides. And it’s still ongoing …. We are in discussions with the development team, and they need to integrate that into [the database] which should be like a Wiki page so people can … look things up, search things and I’ll be primarily responsible for updating them as we grow our products.
Analysts continued to supervise and advise the DEOs. Sage also established a Slack channel where DEOs could ask questions to an on-duty analyst. The DEOs also received training and guidance in weekly group meetings. Seema, a DEO at the head office, explained: “We have these DEO meetings where we would do training and stuff and discuss any issues that they have or anything which you don’t understand.”
The lead analysts had regular one-on-one check-in meetings with DEOs. At the start of one of these meetings, Grace described its purpose:
The purpose of this meeting is just to have a catch-up with you on how collections are going, what our expectations are, and how you feel about them and about our coordination and collaboration, communication and getting, receiving from you some feedback and how everything works and also from our side a bit of feedback.
In that meeting, Grace and Violet discussed data collection targets and quality with the DEO and asked whether there was any help she needed. They also described the various channels that they used to get help.
Data collection, however, never became an entirely codified and straightforward process. Analysts and DEOs both described areas where they found the work challenging and where they needed to make decisions and exercise discretion. Matthew, a DEO, put it succinctly: “Sometimes, the reality and our rules do not match.” Jane, another DEO, elaborated: “You need to read through first and you need to think over because each bank’s way of conveying the message and making their rules is different.” Another DEO, Lacey, described variation in the difficulty of doing data collection: “So, there’s easy and not so easy … The disclosure is easy to find if it’s not scanned …Then the hard part is when it’s scanned. You really have to read everything because you cannot do a search.” An analyst offered a similar description of data collection challenges:
It’s not as straightforward as I expected it to be … and sometimes [the data] is not even there. So, it’s kind of like trying to figure out okay, should I keep looking for this, is it somewhere hidden … or it’s just not there, they’re just not disclosed.
Produced expertise. For those performing the task, data collection led to the development of additional expertise that was not directly applicable to doing data collection but that could be applied when doing other tasks. They were building what we call produced expertise.
The pattern through which produced expertise was created took root in Karie’s early days. As she collected data, she not only refined her expertise in finding and recording data but also produced knowledge on data availability, how to orchestrate the entire data collection process, and corporate governance practices used across banks and time. This expertise did not make her better at data collection as such but allowed her to accomplish other work: for instance, creating a map of the data points that would be collected, and developing the Excel spreadsheet that would house the data and provide a model for the bespoke database. She also used this produced expertise to develop an initial vision for Sage’s product offering.
For most analysts, before the DEOs were hired, the analysts may have been developing produced expertise but had little opportunity to apply it. One analyst, Violet, described developing additional expertise when collecting data but not having opportunities to apply it:
I would make the most of this data collection by making sure that I completely understand what we are collecting and why we are collecting it, familiarizing myself with the disclosures …. I believe that this is how I can get ownership of my work, this is how I can develop through my role, and this is how I can get a thorough and deep understanding of … what corporate governance is in different jurisdictions, how banks work, what are the different risk metrics we use, why do the banks use these specific risk metrics and not others, what are the processes, what is the regulation in different jurisdictions …. I’m able to more substantially contribute to how our products can develop or they can diversify.
While this practice was unusual among the analysts at this time, it foreshadowed changes in data collection expertise.
Later, even as DEOs did most data collection, analysts continued to collect data although with a different intent than previously. Doing data collection allowed them to develop produced expertise, much like that Violet described above and this produced expertise, in turn, enabled them to do other tasks. For instance, Raven, the analyst who eventually led the creation of the more advanced guidelines, described how continuing to do data collection helped her gain expertise on how to do the tasks of data analysis: “To be able to write the research reports, it is recommended to understand the various data points which we collect and so I do … data entry.” Marco described gaining an overview of governance through data collection: “I’ve worked on the flags …. They highlight good or bad corporate governance practices …. It gives an overview of the governance structure.” Rina explained how data collection helped her write a report: “I wrote a benchmarking report … and I could understand why we’re connecting which data points, and it gave me a better understanding.” These descriptions echoed the earlier statement by the analyst, Violet, who had described using data collection to expand her understanding: “And I very much do agree … to be able to work as an analyst, you should have collected some data or at least familiarized yourself in the data.”
By performing the task, those collecting data learned about data quality and the overall process of collecting data and building the database. This expertise along with produced expertise on governance was applied in developing and delivering the training materials on data collection. Analysts also used their produced expertise to validate and audit data collected by others, to make improvements to the database itself like adding new data points and removing ambiguous ones; to suggest changes to the bespoke database; to inform developers what was needed; to write proposals, reports, and posts about corporate governance; to explore expanding the database to include more than banks and bank subsidiaries; to consider purchasing data and to develop a new business model around that. For instance, Raven described learning about differences in governance across organizations through data:
So, yes, it’s a similar structure [for FTSE 100 companies]. So, it’s just that when it comes to other civil firms, other industries such as emerging markets, and going into other countries like Afghanistan and other African countries, Kenya. They tend to have very limited disclosures. So, we might need to sort of weigh up the value of the data to our potential clients.
They also began to use produced expertise to revise the data points, removing ambiguous ones to accelerate task transfer to DEOs, and continued mapping the data points as Sage expanded to collect more companies and bank subsidiaries. Some DEOs described developing similar expertise as they did data collection. For instance, Matthew explained what he learned while collecting data: “The understanding of … how our big corporations work, so what’s behind, and that was my focus and what I was interested in at that time.” The main distinction was that DEOs did not apply this expertise in any tasks other than data collection.
While it was primarily analysts who discussed developing and using this produced expertise, there is evidence that those in other roles also developed it. For instance, DEOs described learning about data quality, corporate governance, and more. For the most part, this expertise remained latent for the DEOs. However, as described below, some DEOS were promoted to Junior Analyst or Analyst positions based, in part, on having amassed this expertise.
Implications of Evolution for Jobs
These changes to tasks and expertise took place within specific jobs in an organization and had implications for those and, in particular, on what work people did at a collective and individual level. While the data collection task and expertise co-evolved and were shared across jobs, they were not shared equally. The tasks for which produced expertise was applied were segregated both between and within jobs. The DEOs ultimately performed much more data collection. They may have accrued some of what we call produced expertise but only those in the analyst position performed the tasks associated with that produced expertise. The main exception to this pattern was data validation done by analysts and more experienced DEOs.
Fig. 3 shows the evolution over time of the tasks done by those in each job described in the paper for each of the three arrangements and the movement of people across jobs. The headings of each box are the job titles: Proto-Analyst, Analyst, Data-Entry Operator, Junior Analyst. The list below these headings are the primary tasks performed in that period. The double-headed arrow at the bottom indicates the progression of time from the start of Sage to the failure of the AI pilot, and finally to the hiring of DEOs. The arrows after a task indicate that it moves to another job.
Proto analysts collect data, structure databases, shape new products, and answer questions from new analysts. Analysts have broader responsibilities including collecting, validating, and auditing data, writing reports and proposals, creating marketing content, hiring and training analysts and data entry officers, changing data points, supervising data entry officers, tracking validation targets, answering questions, providing corporate governance knowledge, creating guidelines, comparing vendor and internal data, and structuring databases. Some tasks are marked as occasional or unrelated. Data entry officers focus on collecting and validating data and assisting in hiring. Junior analysts collect and validate data, assist with projects, report governance news, and support the hiring of new staff. The timeline shows how responsibilities shift across pre-A I pilot, post-A I pilot, and post-data entry officer hiring stages.Tasks Performed in Each Job for Each Arrangement.
Description: This figure shows the evolution over time of the tasks done by those in each job described in the paper and the movement of people across jobs. The headings of each box are the job titles. The lists below are the primary tasks performed under that title in that period. Bold-faced tasks are new tasks. Arrows after a task indicate it continues in the next period. The double-headed arrow at the bottom indicates the progression of time. The double-headed arrow at the bottom indicates the progression of time.
This shows that some tasks emerged within the proto-analyst positions at the start and that these tasks were carried over to the analyst position which emerged after the failed AI pilot. New tasks were added in this period and most of these tasks continued to be done by analysts even after the DEOs were hired. However, several new tasks (in bold) were added to the position, and these are the tasks enabled by produced expertise.
Proto analysts collect data, structure databases, shape new products, and answer questions from new analysts. Analysts have broader responsibilities including collecting, validating, and auditing data, writing reports and proposals, creating marketing content, hiring and training analysts and data entry officers, changing data points, supervising data entry officers, tracking validation targets, answering questions, providing corporate governance knowledge, creating guidelines, comparing vendor and internal data, and structuring databases. Some tasks are marked as occasional or unrelated. Data entry officers focus on collecting and validating data and assisting in hiring. Junior analysts collect and validate data, assist with projects, report governance news, and support the hiring of new staff. The timeline shows how responsibilities shift across pre-A I pilot, post-A I pilot, and post-data entry officer hiring stages.Tasks Performed in Each Job for Each Arrangement.
Description: This figure shows the evolution over time of the tasks done by those in each job described in the paper and the movement of people across jobs. The headings of each box are the job titles. The lists below are the primary tasks performed under that title in that period. Bold-faced tasks are new tasks. Arrows after a task indicate it continues in the next period. The double-headed arrow at the bottom indicates the progression of time. The double-headed arrow at the bottom indicates the progression of time.
This shows that some tasks emerged within the proto-analyst positions at the start and that these tasks were carried over to the analyst position which emerged after the failed AI pilot. New tasks were added in this period and most of these tasks continued to be done by analysts even after the DEOs were hired. However, several new tasks (in bold) were added to the position, and these are the tasks enabled by produced expertise.
Legend:
Table headings are job titles.
Tasks in bold are new tasks.
The lists below headings are tasks in that job.
A small arrow after a task indicates it moves forward.
The double arrow indicates time.
Arrows with figureheads indicate the movement of people between jobs.
Evolution of the analyst job. As expertise and tasks co-evolved, the job of the analysts also evolved. As the DEOs were hired and analysts developed produced expertise while doing data collection, analysts began to perform the additional tasks that required this new expertise. These included the training and supervision that they did for the DEOs, analyzing data, writing reports and posts based, in part, on that data, developing the website and other marketing materials, and more. This shift to doing these new tasks was facilitated by moving data collection work from analysts to DEOs which gave analysts more time to spend on other tasks.
While all analysts developed this additional expertise, not all applied it to the same degree and to the same tasks. There was significant task segregation even within the analyst position. For instance, while to a degree all analysts trained and helped DEOs, Corey and Bella led the initial in-person training, and then Raven developed the more elaborate training materials. Another analyst focused on assessing risk. Two others were recruiting leads. One explored collecting governance data on non-banks. Others worked on marketing and developing a social media presence. Still, others did more of the tasks requiring their newly expanded governance expertise and data validation. Corey, one of the analysts initially involved in DEO training and marketing, described how his role developed:
So, I tend to pick up tasks just because I know how it’s done. I know things basically which I’ve been doing …. So, I once did a leadership role in the team in terms of maybe leading some kind of content creation in terms of insights or social media and having a bit more freedom to sort of choose the type of topics that we’re going to cover and produce material for.
This pattern of within-job task segregation can be traced back to the early days when Karie began collecting data and was the only one to use the knowledge to design the database and develop the product offering and continued with tasks, sometimes unrelated to data collection, added informally to specific analyst’s jobs. It was formalized through an exercise where they worked through their responsibilities and accountabilities. This differentiation of analysts continued and even intensified just before Sage went under. Sage began exploring an alternative business model that included purchasing data and providing clients with analyses that could be used for benchmarking. Three analysts worked on the project. Marco, an analyst involved in this project explained that the old product was “just a bunch of data points” and that the focus of the new product “would be on data analysis and then group governance in terms of collecting data … It’s more of, what do we do with the data?”
The tasks of those analysts shifted dramatically away from data collection though their core and produced data collection expertise remained relevant. Julia, one of the analysts on this project, described her work on the project:
I’ve been doing [everything] from product design to product management, to product mock-ups …. We currently have a chart section where clients can benchmark themselves against their peers and we wanted to redesign that. So, I thought of the new content that should be on the page, how the tabs should be structured or what is the organization for the chart …. I’ve been liaising with a company that helps us do the implementation … and, also, liaising with people from the Dev Team.
Another analyst on the project explored what data might be purchased. The analysts on this project did almost no primary data collection.
There was only limited mobility of analysts into other positions. Karie joined as an intern and became an analyst, a senior analyst, and eventually the head of research. Two became leads but left quickly. Others were given a senior designation.
Evolution of the DEO job. The evolution of the DEO job differed from the analyst job. To start, the DEOs’ orientation toward the work differed. While analysts described data collection as menial and beneath them, the DEOs described it as better than expected, involving discretion in finding and interpreting data, and making quality judgments about it. Jane, a DEO in the satellite office, compared the Sage data collection to work she had done previously:
There’s a huge difference because when I worked with [Bank] it was data operating or data entry …. I agree there [are] a lot of entries being made [at Sage], but you need to read through first and you need to think over because each bank’s way of conveying the message and making their rules is different. So, you need to just analyze them.
In contrast to the analyst job, the DEO job changed little. They continued to collect data and to do little else. The only other task DEOs took on was data validation once they had gained more experience with and expertise in data collection and to help with DEO hiring. One DEO imagined that eventually she might take a lead role or spend more time answering queries from other DEOs, but this never materialized. What did change for them is that the guidance they received became more structured and more tailored to what they needed, thus further codifying the work.
The level of differentiation within the job also differed. DEOs all did essentially the same thing though some were promoted to other positions within Sage. Four DEOs who differentiated themselves in performing data collection were promoted. Two DEOs in the satellite office were promoted to the analyst role in the satellite office because, as Karie explained, they “were ready.” Two other DEOs who had started as interns in the headquarters were promoted to junior analysts and began doing additional work to assist analysts. For instance, Seema described how her work changed:
And I think now I’ more into helping different people. For example, there might be a ticket to help a [developer] … or right now, I’m helping the Marketing department. So, I guess in terms of that, I think, a little more variation across departments …. It just depends on who actually has anything very important to do.
Like analysts, she became involved in training for the offshore office:
So, I was interacting a lot with Mumbai and also training them, making sure that everything was collected properly, giving them feedback. So that took, I would say 70 to 80 percent of my time …. I was the one who was validating all their work …. I was giving them feedback and answering their questions on a day-to-day basis.
We now turn to discussing the implications of these observations for research on tasks, expertise, and jobs.
Discussion
We began this paper by arguing that for many reasons tasks and expertise should be studied as coevolving: the two are closely linked in practice and yet there is scarce theory or empirical research that considers them as coevolving; a small body of research hinting at their coevolution provides strong evidence that this is a serious omission; and the environment of work is ever-evolving, which means that tasks and expertise will also be changing. Knowledge of this coevolution is limited by several tendencies in the study of tasks and expertise. Expertise and tasks are most often studied in the aggregate – in occupations and jobs – and as relatively stable. Based on this, we considered tasks and expertise at a less aggregated level: for example, looking at single tasks and related expertise in a context where they are not part of highly-institutionalized occupations. We traced the task of data collection and the associated expertise across jobs and over time in a single tech-enabled startup.
We observed that this task and related expertise were redistributed and transformed at multiple junctures and that this process reverberated through the system of tasks, expertise, and jobs. At times, this coevolution was led by tasks that moved and changed. At other times, the task transformations were responses to shifts in expertise. At first glance, it might seem that the story of the coevolution of tasks and expertise ends with the movement of the data-collection task and associated expertise into the newly created DEO job. However, this co-evolution was much more complex. Not all data collection moved to DEOs, and its movement provides only a partial explanation of how the task and expertise coevolved. The analysts continued to collect data in a more limited way and with additional goals. For instance, one reason analysts continued to collect data was to gain what we call produced expertise that they could then apply to other tasks. The produced expertise they gained included the understanding of data availability and reliability, of corporate governance, and this allowed them to do other tasks including structuring the database to capture this data, training, and supervising others on data collection, improving their analysis of the data, and writing reports.
In tracing this process at a detailed level, our study builds from others who have documented the more subtle ways that tasks and expertise coevolve. For instance, Anteby and Holm (2021) show that tasks and expertise changed when puppeteering shifted from being performed to a live audience to directors. The audience shift here was a literal one. However, there may be other important types of audience shifts. In our case, while the expertise was performed for the same individuals in the organization, that audience shifted their expectations and why they wanted it to be performed. We also build on Anthony (2021) who shows differences in the expertise developed and applied by junior bankers across two units: based on how they performed their tasks, some developed advanced analysis skills and others did not. In our study, we see differentiation both within jobs and across them: those performing the data collection tasks developed and applied different expertise depending on how they did it and how they applied that expertise to other tasks which was shaped both by how they did their work and by what job they were in. More generally, we build on insights from these papers and others showing the importance of looking at tasks and expertise at a more molecular level. Examining bodies of expertise and tasks aggregated to the level of occupations or jobs would have missed the details of how they changed.
We focused in this study on a particular task in a particular context. It was a task that, while seemingly menial, was central to the organization’s business. The organization itself was rapidly growing with little established structure. These factors allow us to observe the coevolution without occupational influence, but it is not likely that these factors are the only ones that could account for observations of coevolution. It is hard to imagine a scenario where either tasks or expertise would change without the other also changing. It seems that doing any task requires expertise and can produce additional expertise that can be applied to other tasks and, as a result, changes in either part of the system of tasks and expertise will bring changes in the other. How this process plays out for other types of tasks and in other contexts is something that should be explored further. Specifically, one question that should be examined in future research is how this dynamic differs depending on the nature of the task being examined: for instance, what happens if the task is less central to the business model or if it is one with core expertise that is at a higher level or specific to one domain. Another question is how this might play out in more established organizations with established structures. Indeed, evidence suggests that accrual mobility and idiosyncratic jobs – phenomena that resemble what we saw – emerge even in highly bureaucratic organizations (Miner, 1987; Miner & Estler, 1985).
Our findings contribute to research on expertise, on tasks, and on jobs. In the sections below, we discuss three of our more specific contributions – we introduce the concepts of core and produced expertise, elaborate on the dynamics of hiving-off, and develop understanding of the job structuring process – and offer further ideas about how scholars might expand on our work to shed light on other processes.
Core Versus Produced Expertise
One of our central contributions in this paper is to develop the distinction between task-level core and produced expertise. Core expertise is directly required to perform a specific task; produced expertise is gained by performing the focal task and applied in performing other tasks. This distinction is based, in part, on how the expertise is gained and, in part, on the relationship of the expertise to doing the task. Core expertise precedes performing the task and is applied in the performance of that task; produced expertise comes from doing the task and is applied in the performance of other tasks.
The distinction between core and produced expertise does not align with the many previous categorizations of expertise based on level, content, domain, type of task, and breadth versus depth. For instance, produced expertise differs from process expertise (Barley et al., 2020; Treem & Barley, 2016, 2018). The main difference is that produced expertise emerges from performing tasks that draw on core expertise, and so it is contingent on people continuing to do core tasks. Process expertise by contrast is the expertise that facilitates the coordination of work, which may be either core or produced as we define these terms.
Furthermore, the distinction between core and produced expertise is not based on the difficulty or level of the expertise applied. We cannot differentiate them based on whether one is simple and the other analytical. Nor is produced expertise the equivalent of Collin and Evan’s (2008) contributory expertise – the ability to recognize and adapt to contextual cues that cannot be attained by novices through rules and guidelines. Like contributory expertise, all produced expertise results from doing expert tasks. However, in contrast to contributory expertise, not all produced expertise involves recognizing and adapting to contextual cues.
Finally, the distinction we make between core and produced expertise is not based on whether the task being performed is itself core or periphery. It happens that the task to which both core and produced expertise was applied in our study was core to Sage: data collection was the reason the company existed. However, this idea might apply to tasks that are not central to the organization.
Examining this phenomenon at the detailed task level allowed us to uncover the distinction between core and produced expertise. This might have been missed if we had, for instance, looked at the set of tasks done by data analysts or even the broader set of tasks around data collection and entry. Based on this distinction, we could show how it takes expertise to produce expertise. It is not a case where expertise from one domain is transferred to another (Kahl et al., 2016). Indeed, there is considerable evidence that this sort of transfer is not easily done. Instead, we see that one form of expertise allows people to perform tasks that, in turn, produce expertise that can only be applied to other tasks.
Hiving-off
Our observations also help refine understanding of hiving-off – members of an occupation pushing menial tasks to lower-status occupations (Abbott, 1988). While most of the data-entry work was moved from the analysts’ job to the lower-status DEO job, there are crucial differences between what we observed and the more typical version of the hiving-off narrative. First, we show that hiving-off is not absolute and that there are benefits to not completely hiving-off low-status tasks. Analysts continued to do data collection because it helped them to build and maintain expertise in other domains that allowed them to perform higher-status tasks. This finding builds on research pointing to the value inherent in performing tasks seen as not inherently meaningful, menial, boring, or otherwise mundane. For instance, Huising (2015) documents that not hiving-off menial work helped lab technicians build relationships and eventually maintain their territory. Ranganathan and Shivaram (2002) found that woman supervisors can motivate greater productivity in women workers by engaging in scutwork. Others have documented how doing mundane work is inherent to and, in some cases, beneficial for creative work (Bruns & Long Lingo, 2023; Elsbach & Hargadon, 2006). Even after doctors passed the task of giving shots to nurses, medical students continued to give shots to build their expertise (Abbott, 1988). Consistent with this, we found that continuing to perform menial tasks not only held positive implications for professional authority and task performance but also for expertise itself.
Typically, the work passed on through hiving-off is assumed to be viewed as low status and menial for both those hiving off the work and those receiving it. We show that this is not always the case: the DEOs who received the seemingly low-status data-collection task did not view it this way. This observation dovetails with recent evidence that the same work is not viewed the same way by all who do it. For instance, Bourmault and Anteby (2020) examined two sets of recently promoted managers in the Paris Metro – one set who had worked as station agents and one who had worked as subway drivers – and showed that in contrast to their responsibilities in their previous position, station agents viewed their new managerial tasks as a positive increase in responsibility while former subway drivers did not.
Another difference from the typical hiving-off narrative is that this was not a case where a strong occupation willfully pushed tasks to a subservient one to improve their status or their daily experience. That story fits part of what we observed: analysts did not want to do data collection. However, analysts alone could not make this happen. In large part, it was a product of organizational evolution and managerial actions: the task was always intended to be removed from their job.
This suggests several avenues for advancing understanding of hiving-off. We observed hiving-off outside of the occupational domain, but our findings suggest that more research on this phenomenon is needed even within the context of occupations. Are the dynamics we saw different from what we would see in an institutionalized occupation with more self-governance and outside regulation? Furthermore, more research is also needed to fully understand the role of the various actors in this process across contexts. We saw that hiving-off was not simply a process instigated by those doing the task which raises questions about the roles of other actors in hiving-off. To what degree do managers and other actors influence the process and in what conditions? Rather than consider that those doing the task agree about hiving-off and have the power to unilaterally move it elsewhere, we should consider cases where those doing the task do not view it uniformly or when the targeted recipients of the hived-off task do not want it. What role do the targets of hived-off tasks play here? While we provided evidence that the DEOs offered no resistance, there is evidence that not all efforts to hive-off will be welcome or successful. For instance, when human resource professionals in one organization attempted to transfer some of the more transactional work, the targets resisted it with claims that they lacked expertise (Sandholtz et al., 2019).
How the Interplay of Tasks and Expertise Shapes Jobs
Our findings provide further insights into the forces that shape jobs – the assemblies of tasks under administrative job titles. As other research has shown, the shape of jobs is subject to influences from multiple sources at multiple levels, but this research has yet to discuss how expertise shapes job design (Cohen, 2013, 2016). We show that the interplay between tasks and expertise influences the allocation of tasks into and across jobs. When doing data collection generated produced expertise, analysts performed new tasks and those new tasks became a more permanent part of their jobs. It is notable, however, that the development of new expertise alone does not lead to job changes. DEOs did not take on these tasks within their current role, though a few who demonstrated this expertise were promoted. Nor were analysts able to routinely apply this expertise to new tasks before the DEOs were hired to do much of the basic data collection.
We also contribute to growing evidence that job design can occur without grand occupational influences. In our case, there were influences related to strategic and operational decisions, the failure of technology, and the dynamics across different jobs. While the preferences of those doing the work had some influence, this was not a case where the job or job holders could determine what unfolded. In other words, those doing the work did not have an overriding influence in shaping their jobs.
While occupations were not a guiding factor, our observations have implications for occupations. In our case, the coevolving dynamics of tasks and expertise shaped jobs. Given that occupations often attempt to claim tasks and expertise to build their jurisdictions and authority, it seems likely that similar dynamics could be observed in tracing detailed tasks within even highly institutionalized occupations. This, of course, could and should be explored in future research.
Implications for the Study of Work
We end this paper by connecting our detailed findings on tasks and expertise to the larger body of research on the future of work. In the face of monumental institutional changes surrounding it, the work that individuals do within jobs, occupations, and organizations is under constant revision. That means there will be fundamental changes at the level of tasks and so in expertise. We hope that our detailed observations on the coevolution of tasks and expertise can help scholars to understand how those changes happen. They start at the minute level of the task and ripple through these larger units.
Acknowledgments
We thank Jillian Chown, Kasper Elmholdt, Ruthanne Huising, Elina Makinen, and Karla Seyegh for lending us their expertise on expertise. We also thank participants in the Rough ‘Riters writing group, the conference on Expertise in and around Organizations, and the Desautels Organizational Behavior working group, and our anonymous reviewers for insightful comments on earlier drafts. Finally, we thank Sara Mahabadi for her extensive contributions to creating and then making sense of the dataset on which this research is based.

