Introduction

Work systems are means for people to perform coordinated tasks and employ resources in pursuit of organizational objectives (Alter 2013). Historically, the definition of tasks and resources in organizations has emphasized technical elements such as facilities, technologies, and processes (Strauss and Porto-Bellini 2008) while, it is currently known, organizational performance is not limited to these aspects, since they respond—at most—to an expectation of efficiency, or a certain degree of potential efficiency. The transformation of potential efficiency into tangible results is possible through the active involvement of people, who apply their efforts following specific coordination (Emery and Trist 1978).

In a work system, people perform tasks using information, knowledge, skills, technology and other available resources to produce products and services that meet internal or external demands (Alter 2019). That is, work systems deal with large-scale, complex systems problems (Jaradat et al. 2020). In this sense, work systems can be instantiated at different analytical and operational levels, from a basic information system at departmental level, up to a set of integrated enterprise resource planning (ERP) systems that supports a multi-organizational work system––multiple organizations composing a system of systems.

The socio-technical approach is a theoretical perspective that describes such multi-level work systems through the interdependence of ‘technical’ (tasks and technologies) and ‘social’ (people and structures) subsystems, simultaneously, for the design of holistic work systems (Leavitt 1965). Through a socio-technical perspective, an “efficient and innovative workplace” must be accompanied by “humanistic strategies” (Mumford 2000; p. 127), which implies a design able to balance internal economic goals and quality of life for stakeholders (employees, customers, users, owners) (Sarker 2000).

Notwithstanding the theoretical and practical interests inspired by the socio-technical approach, designing and implementing work systems with such characteristics implies considerable challenges. Appelbaum (1997; pp. 454, 461) highlights the stress and uncertainty experienced by the teams and suggests the need for a “transition structure”—between the old system and the new, socio-technical design—that favors the development of knowledge and skills by the teams involved. Baxter and Sommerville (2011) discuss the “compatibility” socio-technical principle (which provides for the participation of people in the design of their own task) and the counterpoint that people are not always willing or interested in participating. Cherns (1987; p. 155) recognizes that there are possibilities for the occurrence of “power conflicts” and the reinforcement of burocraticFootnote 1 structures; Baxter and Sommerville (2011) also describe difficulties in understanding socio-technical concepts (due to its high level of abstraction), significant differences between values ​​and world views, and imprecise criteria for success in socio-technical projects.

In the software industry, challenges are amplified by the continued insertion of concepts such as “agile”, “lean” or “data-driven” (Oriol et al. 2020) which in one hand adheres to some socio-technical principles (Nerur et al. 2010) and at the same time put pressure on socio-technical principles to adapt to organizational innovations, without considering the possible distance from their original intention (Alter 2019). For example, Anguelov and Angelova (2016) refer to “multifunctionality” as a fundamental principle in agile methodologies since the agile “development process is built on the multifunctionality of each team member” (p. 2); and Nerur and Balijepally (2007) refer to “minimal critical specification” as a key concept in agile methodologies, defined as the identification of “the smallest set of requirements to initiate a project” (p. 83), but in both examples there is no reference to socio-technical approach as the root for these agile principles.

So, little is known about the conceptual relationship between terms like “agile”, “lean” and “data-driven performance”, and socio-technical principles, as well as about the understanding and incorporation of socio-technical principles by companies that adopt agile, lean and data-driven processes. Alter (2019; p. 2) argues that socio-technical principles have been “diluted” since the original conception (in the 1960s). Such a dilution, it can be assumed, explains the decreasing explicit adoption of the socio-technical approach in the design of work systems and the increasing explicit (or at least espoused) adoption of new concepts that seem to overlap. It is not that the socio-technical approach has been abandoned; is that its adoption has occurred tacitly, “diluted” in other terminology. In fact, the socio-technical approach––and specifically the socio-technical systems perspective––has been object of renewed interest, as in the case for challenges related to digital technology, SARS-COVID-19, and precarious employment (Guest et al. 2022), or the impact of information and communication technologies on the higher education system (Navarro-Bringas et al., 2020), to mention a few. This renewed interest is explained by the socio-technical systems’ potential to enable stakeholder involvement, inter-disciplinary partnerships and organizational support, resulting positive outcomes for people in organizations, as well as society (Guest et al. 2022).

Another explanation for the decreasing explicit adoption of the socio-technical approach in the design of work systems may also stem from its academic origins. Historically, the socio-technical perspective has evolved within a somewhat insulated academic environment, potentially limiting its integration into practical, industry-specific applications. This does not seem to be an isolated case, as much of what is produced academically in terms of research, development and innovation (RD&I) cannot be transferred to the productive and business sector (Novickis et al. 2017). In an effort to respond to this criticism and to fill the knowledge gap presented, this technical report describes the design and implementation of a socio-technical work system in an information technology (IT) company through an action research perspective. The research question is as follows: what socio-technical principles may be effectively understood and incorporated by a software development company in the design and practice of its work system?

This report is organized as follows: the next section describes our literature review and theoretical background on the socio-technical approach and principles, as well on their relationship to agile values. Then we present both the academic and professional contexts of the research, the problem aimed to be solved, and the research design (briefly, a manager of a software development company asks for academic support to help find an appropriate solution for designing a new work system for the company). The following two sections describe the research itself (divided in two stages), the resulting recommendations, as well as the evaluations realized. Finally, we discuss results and the impact verified after the implementation of proposed changes.

Literature Review and Theoretical Background

Socio-Technical Approach and Work Systems

The socio-technical approach emerged in the mid-1960s, as a consequence of research carried out at the Tavistock Institute of Human Relations, aimed at better meeting social demands (Trist and Murray 1993). In addition to fulfilling its purposes in relation to society, the approach contributed significantly to the development of existing fields of study, as well as the creation of new fields, such as quality of work life and organizational change (Mumford 2006). The socio-technical approach advocates that in order to achieve improvement in an organization’s performance, it is necessary to make efforts to integrate and empower workers, the way they organize themselves, technologies and organizational processes (Leavitt 1965; Trist 1981).

The pioneering study applying the socio-technical approach took place in the coal mines of Durham, England (Scarbrough, 1995). Companies supplying coal––raw material for several industries at the time––were experiencing difficulties in their management. Despite the high investment in mechanization, the scenario was one of absenteeism, high employee turnover and frequent contention (Trist and Murray 1993). That pioneering study analyzed and interrelated technical, organizational, social and psychological aspects, and after changes in the work system through personnel arrangement it was possible to perceive a better organizational climate, and some performance gains from multifunctional and independent groups (Trist & Murray, 1993). In other words, after the rearrangement led by researchers at the Tavistock Institute, the group worked to find a balance between technical and social elements.

In fact, the socio-technical approach emerged as an alternative to counteract work systems that favor centralization and authoritarianism in vogue in the decades before 1960 (Mumford 2006). The socio-technical approach contributes to counteract that by emphasizing the need for complex systems thinking to understand intricate, interrelated, problems (Fischer et al. 2021), related to decision-making in teams (Pasmore 2006), supplying of work force (Mumford 2006), information system development (Baxter and Sommerville 2011), human-computer interaction (Abdelnour-Nocera and Clemmensen 2019), and health clinical practice in emergency departments (Austin et al. 2022), to name a few.

Socio-Technical Principles

In order to organize existing ideas and offer a systemized set of “distilled” experiences on how to design a socio-technical system, Cherns (1976; p. 4) defines the assumptions that must precede the design of work systems through nine socio-technical principles:

  • Compatibility: people must participate in defining the task they will perform; compatibility between processes and outcomes;

  • Minimal critical specification: focus on ‘what’ should be done, without unnecessary emphasis on ‘how to do it’; minimal critical specification of tasks, the minimal critical allocation of tasks to positions or of positions to functions, and the specification of objectives with minimal critical details about the methods to obtain them;

  • The socio-technical criterion: the quality of what is produced at each action point must be verified; i.e., variance––any unexpected event––, if cannot be eliminated, must be treated as near to its origin as possible (there are always some variance that must be handled by the team), “thus allowing people to inspect their own work and learn from their mistakes” (p. 7);

  • The multifunctionality principle––organism vs. mechanism: the versatility of skills should be prioritized, since there are several ways to achieve the same goal, i.e., the same as equifinality, one of the properties of complex and dynamic systems;

  • Boundary location: there must be means for intensive communication between internal and external organizational units; “boundaries which interfere with the desirable sharing of knowledge and experience” (p. 10) must be avoided; The more control of tasks within the department becomes the responsibility of its members, the more the supervisor/manager is focused on boundary activities, ensuring that her/his team has adequate resources to perform its functions;

  • Information flow: there must be means for preventing noise and communication interruption; information systems must supply information––exactly the right type and amount of––first to the point where action occurs;

  • Support congruence: top management support such as “do as I say and do as I do”; systems of selection, training, performance measurement etc. must be specifically designed to reinforce behaviors that the organization’s structure is designed to offer;

  • Design and human values: ​​there must be means for continuous learning, decision-making spaces, social support, and recognition to provide a high quality of work; and.

  • Incompletion: it must be recognized that any system is in continuous improvement; “[a]s soon as design is implemented, its consequences indicate the need for redesign” (p. 14).

The corollary of a socio-technical work system designed according Cherns’s principles is the focus on “exploiting the adaptability and innovativeness of people in attaining goals instead of over-determining technically the manner in which these goals should be attained” Cherns (1976; p. 3). Socio-technical systems have been continuously defined, partially or totally, based on Cherns’ socio-technical principles (Alter 2013; Appelbaum 1997; Pasmore 2006). For example, Pasmore (2006) applies the principles of “compatibility”, “boundary location” and “design and human values” in the judgment and decision-making ability of workers in teams, highlighting the interdependence between tasks, the definition of roles and tasks in teams, the level of delegation of responsibilities and the level of confidence. Therefore, Pasmore (2006) describes a way of work in which teams are able to implement self-management and, thus, can adapt to specific situations and problems, dynamically changing their structure and tasks definition.

After years of publishing his seminal ideas, Cherns (1987) reviewed the nine principles using the experience acquired during such an interim (from 1976 to 1987). Through this review, “the socio-technical criterion” is now called “variance control”; the “power and authority” principle emerges to establish a necessary balance between onus (commitment) and bonus (resources and rewards), i.e., “the power and authority needed to accept responsibility for their performance” (p. 157) as the team has the power and authority to handle the variance that cannot be controlled outside the team; the “multifunctionality principle––organism vs. mechanism” is now called “the multifunctionality principle”; the “design and human values” principle is now considered a “value” to be promoted by any socio-technical project design, not a principle itself. In Cherns’ words: “human (and social) values underpin all of these ten principles” (Cherns 1987; p. 160); and the “transitional organization” principle emerges as a necessity to explain situations of redesign of work systems during its operation, i.e., during a certain period of transition. Despite changing names, the main contributions of this review were the clarification of misunderstandings regarding some of the original definitions, and the need for a tenth principle––“transitional organization”––, fundamental when considering the changing and dynamic essence of socio-technical projects. In this study, we adopted the nomenclature and definitions updated by Cherns in 1987.

Socio-Technical Principles and the Agile Movement

Strongly structured methodologies for project management and work systems design––generally considered “traditional” because well-defined, formal and impersonal (Morand 1995)––have received criticism due to the “heaviness” of their implementations (Conn 2004). On the other side there are adhocratic structures (Mintzberg 1989), i.e., flexible, adaptable and temporary. In this sense, agile methods emerge as a lightweight alternative, offering less time to deliver solutions to customers while promising a shorter development cycle, lower cost and greater ability to adapt to change (Kaur and Khurana 2021; Nerur et al. 2005). Currently, organizations are adapting and adopting existing agile frameworks to expand agile methods from project to wider organizational levels, in many distinct business areas (Mordi and Schoop 2021).

In the software industry, agile methods argue in favor of four main values: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan (Beck et al. 2001). The relationship between the four agile values and the socio-technical approach––in general––have been noticed (e.g., Alter et al., 2019; Nerur et al. 2010). However, the same does not occur about the relationship between agile values and Cherns’ socio-technical principles. So, the following presents our rationale to establish such a relationship. First, we consider that the philosophy behind the agile values is grounded on Kant’s deontological approach, i.e., people behave according “a morality of principles, not of consequences” (Van Staveren 2007; p. 23), which means that each action must be valuable, fair and good itself, leading in tandem to a valuable, fair and good end. In our understanding, this explains why the agile movement values human discretion to self-organize and cooperatively and rapidly find solutions to organizational problems. Second, we consider the general systems theory (Bertalanffy 1950) as the basis for the socio and technical subsystems interdependence, according to the socio-technical approach, which implies that a socio-technical work system poses properties as permeability (level of opening/closing for interaction with the environment), homeostasis (tendency to recover from turbulences and reestablish balance), and equifinality (several ways to achieve the same end). So, put together, those assumptions allowed us to propose a relationship between agile values and Cherns’ socio-technical principles. Figure 1 illustrates such a rationale.

Fig. 1
figure 1

Relationship between agile values and socio-technical principles. Note: Spheres represent agile values; ellipses represent socio-technical principles; doted lines represent the relationship between them

Full size image

In Fig. 1, the “compatibility”, “boundary location”, “multifunctionality”, “information flow”, “support congruence” and “power and authority” socio-technical principles are related to the “individuals and interactions over processes and tools” agile value, since these principles establish means for people to participate, interact, collaborate, share experiences and knowledge, and self-organize to deal with tasks and challenges. The “minimal critical specification”, “variance control” and “transitional organization” socio-technical principles are related to the “working software over comprehensive documentation” agile value, since these principles establish priority to “what to do” over “how to do”, in both situations of design or redesign of work systems, in order to keep the organization on the track. The “minimal critical specification” socio-technical principle is also related to the “customer collaboration over contract negotiation” agile value, since it presupposes the extra cost of dense and rigid contractual clauses, specifically their restrictions to absorb changes, and the difficult to manage such particular details (Solli-Sæther and Gottschalk 2008). The “variance control”, “information flow”, “transitional organization”, and “incompletion” socio-technical principles are related to the “responding to change over following a plan” agile value, since these principles define ways to deal with both the organizational dynamism and organizational routines.

Context, Problem and Research Design

The social sciences in general, and business administration, in particular, have been targeted for criticism regarding the effective contribution of their research to organizations (Brydon-Miller et al. 2003; Huang 2010). Even offering a list of practical or managerial recommendations, typical research papers in the social sciences do not describe nor assess results of the deployment of such recommendations. An alternative to overcome this criticism is to make the researcher participate in the implementation of the proposed change, “as a path to generating knowledge and empowering stakeholders” (Huang 2010; p. 93), which characterizes the action research approach in academic-scientific research. Thus, in this study we consider the need to monitor the implementation of the proposed work system, not restricting the study just to the traditional recommendations for practice.

Context and Problem

This study focuses on a real management problem, experienced by a software development company that showed interest in analyzing, defining and implementing a new work system, with the support of academic action research. From the sum of the practical question posed and the theoretical support provided by the socio-technical approach, the following research question was defined: what socio-technical principles may be effectively understood and incorporated by a software development company in the design and practice of its work system? Underlies the research question the assumption of adequacy of dynamic and flexible structures (more adhocratic than traditional or bureaucratic structures) to IT companies.

The company that demands this research, hereinafter referred to as EmpA, is characterized by the development of enterprise resource planning (ERP) software for the health care industry in Brazil; employs around 70 professionals in activities of development, maintenance, service desk and consulting; and is active since 1996, in all regions of the country. Throughout its history, EmpA has experienced significant changes in technologies (e.g., new computing devices require specific technologies, responsiveness of interfaces to multiple screen sizes and formats), methodologies (project management, agile methods, coping with ad hoc demands), regulation (legislation and specific health care laws) and IT work force management (turnover, qualification, generational conflict, etc.). In line with Jácome de Moura & Helal (2019), such a dynamic environment often affects the organization’s work system, causing changes in roles, assignments, division of labor, hierarchy, and groups/teams building.

At the time of this research, EmpA had lost one of the oldest managers in the technical area (product development) and the general manager felt overwhelmed and had difficulties in meeting the accumulated demands. This general manager chose to request academic support to find a suitable solution to the problem. Heeding the invitation we prepared a work plan, originally divided into three stages with the following scope: (1) defining the structure of the organizational staff (organization of people in first level work units) covering areas of activity, list of general attributions and indication of training; (2) evaluating and refining the proposed structure; and (3) monitoring the implementation of previous steps, supporting adjustments and measurement of results.

Research Design

We followed three strategies for data collection, in order to know about the company and its problems: (a) available internal documents; (b) individual interviews; and (c) focus group. Data collected (originally recorded in audio and text) were treated and analyzed through content analysis (Bardin 1977), following the approach for data segmentation and categorization proposed by Jácome de Moura et al. (2016). After data analysis and discussion with the manager and his team, we chose to divide the research work in two stages, for prescription and monitoring of actions. Stage 1 had the general objective of defining the organizational structure of EmpA, divided into specific objectives: (a) staff dimensioning (redistribution of coordination/supervision); (b) definition of attributions of each new coordination/supervision; and (c) organization chart proposition and assignment definition for each coordination/supervision. Stage 2 aimed to critically evaluate results of what was recommended in stage 1.

Data collection was preceded by a seminar aimed to share general research concepts (e.g., action research vs. consulting, socio-technical approach, work system design, and the need for balance between social and technical subsystems) with the staff. During the seminar, the socio-technical approach was exhaustively discussed in order to evaluate with the practitioners its adequacy as the basics for the design of the new work system.

Stage 1: Activities Performed and Discussion

The stage 1 was carried out from October to November 2016. As the researcher in charge, I had access to a EmpA self-diagnosis, previously and autonomously carried out by the company, containing manifestations of individual perceptions of managers and coordinators in relation to difficulties, threats, strengths and opportunities at work. We understand that the self-diagnosis corresponds to an initial and autonomous effort by EmpA in the search for a solution to their own problem. Without an academic foundation, they apparently faced limitations in data analysis and interpretation, but these limitations do not invalidate the content obtained through self-diagnosis. That is why we chose to incorporate it as a data source to be analyzed in light of socio-technical categories. Excerpts of the self-diagnosis were tabulated in a spreadsheet and then classified according to subsystems (social and technical) and socio-technical variables (people, structures, processes/tasks and technology). Considering the priority defined by EmpA for the definition of its new organizational structure, 26 items of the self-diagnosis were selected because they relate, directly or indirectly, to the socio-technical variable structure. These 26 items dealing with structure were classified according to emerging thematic category (not defined a priori). All detailed categorization steps are documented and available upon request to the author. Five categories emerged: (1) formal/informal structure (definition of scope, roles and tasks), (2) communication/integration (at the individual, team and departmental levels), (3) dimensioning (capacity to meet demands), (4) knowledge management (expertise, documentation), and (5) variance control (conformity check).

We complemented the EmpA self-diagnosis with in-depth interviews, being two individual with the EmpA manager, and another one as a focus group (López and Pascual 2008) with the participation of five coordinators/supervisors representing all the company’s areas (services, help desk, development, tests/approval and business) for discussion of the topic “the efficiency of the work organization in the company”. The individual interviews lasted two hours on average and were recorded through field notes, and supplemented with internal documents related to the topic. The focus group interview lasted one hour and twenty minutes and the discussions were audio recorded.

The combined text from the in-depth interviews and the focus group was segmented into 279 sentences tabulated in a spreadsheet. Each of the sentences was classified according to (1) the nature of the quote (emphasis, contradictions, concepts, examples, repetitions, ) and (2) the socio-technical subsystems and variables. Considering the priority defined by EmpA for defining its new organizational structure, 49 sentences were selected as they relate, directly or indirectly, to the variable structure. Finally, these 49 sentences dealing with structure were classified according to the emerging thematic category. Table 1 summarizes the eight emerging categories and provides perspective on the emphasis given by respondents to each of them.

Categories present in Table 1 referring to “sizing”, “knowledge management” and “geographic location” were not considered in this report, as they are not within the scope of the priority defined by EmpA. Likewise, there are references in data to the lack of knowledge on the organizational strategy (or reluctance to accept it) in statements such as “our work is largely driven by demand”, “the director called, changed the priority” or even “this is missing, this issue of having a strategy and aligning the teams so that everyone is looking in a single direction”. Due to the relevance to the definition of structure, data of this nature were considered.

The need to incorporate the discussion on strategy seemed evident, since there are indications of misalignment in the perception of organizational strategy between coordinators/supervisors and the board/management. It was observed that EmpA is inserted in a political environment, with intense power struggles and search for management legitimacy. It can be said that this is a clientelistic context, i.e., individualized negotiations overlap institutional norms (Gonzalez-Ocantos and Oliveros 2019). This is, to a large extent, why the board and management opt​​—according to their statements—to meet the demands of customers, according to their (of these customers) priorities. Such a strategic approach extrapolates the internal level of the organization by involving multiple stakeholders in codesigning the work system, elevating the system design to an ecosystem level (Winby and Mohrman 2018).

This approach adheres more directly to adhocratic structures (Mintzberg 1989), i.e., flexible, adaptable and temporary structures. At the other extreme (if one considers a continuum) would be bureaucratic structures, well-defined, formal and impersonal (Morand 1995), which seem to be preferred by the staff. A quote such as “we need to meet the minimum requirements to produce within a satisfactory level of quality” illustrates the staff’s preference for conditions of predictability and stability.

Table 1 Categories identified
Full size table

Assuming that EmpA has traditionally adopted a bureaucratic operational structuring and, at the same time, there is an interest to adopt a strategic orientation for personalized service, it is inferred that the adhocratic-bureaucratic hybrid model (an organic organization, according to Morand 1995) is indicated to define the new organizational structure of EmpA. Such a decision and its implementation must be permanently monitored, as bureaucratic values ​​and principles tend to persist, even after formal ruptures with bureaucracy (Peeters 2015). In addition, if the organization’s objective is to design a system capable of contemplating dynamism in its structure— adapting to change and making use of the individual’s creative capabilities—then the organization must promote increased participation (compatibility between ends and means), stimulating people to participate in the design of the task they will perform. This decision adheres to the principle of “compatibility” (Cherns 1976) and implies inviting individuals to participate in the redesign of tasks, which in turn generates shared responsibility between managers, staff and researcher on proposed changes.

The category “communication/integration/alignment” (Table 1) emerges from quotes about the distance between individuals and between departments, which produces, among its effects, misalignment of actions, duplication of efforts, ignorance of the tasks and difficulties of others, and corrosion of the company’s image, which occurs when customers realize that there is no communication and integration inside EmpA. Quotes like “we don’t have a strategy, let’s say, nor an alignment that says ‘everyone has that goal and the goal is for everyone to communicate and achieve” or “we are working in opposite directions, for example, because there is a lack of communication” indicate that the focus has been internal, limited to departmental boundaries. Traditionally, boundary location is defined as a function of technology (equipment operation), territory (supervision, control) or time (schedule) (Cherns 1976). These are pragmatic and defensible criteria in many situations. However, sectors that demand intense exchange of information about requirements, specifications, data, parameters, regulation or standardization—as is the case of the creative industry and IT—these traditional criteria may impose obstacles. As the control of activities in the department is shared among its members, the manager starts to focus on ensuring that the team has adequate resources to carry out its tasks (internally), while coordinating activities with other departments (externally), trying to foresee changes and ways to face them. This decision adheres to the principle of “boundary location” (Cherns 1976) and implies a change in the role of coordination and supervision, since they start to delegate much of the control of the execution of the tasks to their self-managed teams (Pasmore 2006; Peeters 2015), while dedicating themselves to integration with their peers in other departments. It is this dual change that will enable staff to have the conditions to dedicate themselves to the necessary intra and interdepartmental communications.

The category “goals/indicators” (Table 1) emerges from statements about the existence of high-level goals (annual and valid for the organization as a whole) and the absence of specific goals (individual and departmental). Quotes like “internally we do not have internal goals, within our coordinations” or “there is also a lack of direction on our part”, point out that the departments face difficulties in permanently contributing to the achievement of institutional goals, since their everyday actions are not directed to these goals. It can be said that there are difficulties in strategic alignment between departments and the organization. Simultaneously, ambiguous perceptions regarding work evaluation indicators are also observed. Quotes like “in order to measure efficiency today, we’re not sure how to do it, it’s more of a feeling” or “we cannot measure”, suggest that intuition and heuristics prevail over data-driven decision making. On the other hand, statements like “the backlog… the amount of stuff there… so that is a negative indicator that we are not being efficient”, suggest that there are some subjective indicators. It is likely that the ambiguous perception in relation to indicators is due to the lack of multilevel goals (individuals, teams, departments and organization) and the nonexistence of the desirable link between goals and performance monitoring indicators. As decision-making spaces are stimulated, coordinators and supervisors can get involved, together with their teams, in the definition of departmental goals and respective monitoring indicators, with goals aligned to the organizational strategy, which is an assumption for the development of high performance work systems (Boxall, 2012). This decision adheres to the “multifunctionality” principle and “design and human values” (Cherns 1976) and implies a change in planning structures and processes, that start to consider the decentralization of part of the decisions.

The category “formal/informal structure” (Table 1) emerges from quotes about duplicity of command, lack of legitimacy, questioning of leadership and non definition of attributions. Quotes like “often the < coordinator > gives me autonomy to work, […] but the autonomy I receive from her, has no authority for the team”, “I realize they don’t feel safe. Often they say ‘ah, you can tell me one thing and the < coordinator > another and what can I do?” or “let’s define the roles better, explain to the staff what my real role is, what can I do, what can’t I do”, may indicate that (a) there are indefinite positions and attributions; (b) that there is no unity of command; and/or (c) that the leader is not accepted/legitimized by the team. Defining a new form of work organization requires, in addition to the hierarchical structure (positions and their relationships), definition of assignments and command line. However, the selection of leaders (as a function of cognition, behavior, experience, maturity, empathy with the team, etc.) seems to be more determinant of the acceptance/rejection of the leader than the formal definition of the position held (Graen 2009). As decision-making spaces are stimulated, the supervisory positions can be decided together with the respective teams, since the list of tasks to be performed must include other activities in addition to those directly related to daily production. This decision adheres to the “multifunctionality” principle (variety of tasks and versatility) and “design and human values” (Cherns 1976) and implies a change in planning structures and processes, which also depends on decentralization of part of the decisions.

The category “dynamic structures” (Table 1) emerges from quotes about collegiate decisions and consultation with internal experts. Quotes like “This P.O. [product owner], it was not interesting for one person to just say what the product should have […] and we created the analysis team, which was something that worked very well”, “we had set up a structure of having two analysis teams, one on the service side, the other on the development side, which discussed, several people involved, the product is immense, we know that not everyone knows everything” or “people who are more experienced developers, to discuss the matter and decide”, may indicate that (a) there is a legitimate interest in expanding spaces for participation; (b) there is recognition of multiple and distributed knowledge and skills; and (c) there is an overload of responsibilities on coordinators/supervisors and the adopted discourse implies a search for reduction/distribution of these responsibilities. In any case, the availability of dynamic adhocratic structures (flexible, on demand) would allow the building of teams by project, to meet specific demands. These teams would not have a predefined hierarchy, would not necessarily require formal training and would be “empowered” to carry out the task (Mintzberg 1989). This decision also adheres to the principle of “multifunctionality” (variety of tasks and versatility) (Cherns 1976) and implies flexibility of the formal structure so that it considers the existence of dynamic complementary structures, which can be assembled and activated, depending on the demand/ project.

Finally, the category “variance control” (Table 1) emerges from quotes about failures of teams in the execution of their tasks, with consequences for the work of other teams. Quotes like “if I don’t do my job well, it’s because I wasn’t told what I should do well”, “someone from development who read it, or didn’t analyze it right, created something wrong, then it reflects on the approval” or “a novice person who doesn’t understand much about the system yet, then he keeps opening a bunch of corrections that aren’t real corrections”, indicate the absence of compliance point checks at specific moments of production/provision of the software. The work carried out according to pre-established criteria and the inspection incorporated into the place where the work is carried out are factors for mitigating unexpected events (failures or variances). Critical variances affect organizational results and, therefore, much of the administrative effort (supervision, management) is related to the identification and elimination of variances. The decision to reduce the variances adheres to the principle of “variance control” (reduction of variances) (Cherns 1976) and implies that, whenever possible, inspection should be built into production so that people can supervise their own work and learn from their mistakes.

Table 2 summarizes the findings and discussions of stage 1, from the perspective of what can be put into practice by managers, coordinators and supervisors. Each coordinator and supervisor was responsible to discuss the findings and recommendations with her/his team, resolve doubts, and collect suggestions.

Table 2 Socio-technical recommendations for managerial practice
Full size table

Stage 2: Activities Performed and Discussion

This section describes the activities performed and the results found in reference to stage 1, with the addition of emerging priority: analysis of the systems development backlog. Backlog is a repository of demands recorded for a development area (Fitsilis 2008), usually reporting software failures (bugs), regulatory requirements (regulation), and suggestions for improvement (ergonomics, new features, etc.). These demands originate mainly from customers, although they can also be the result of internal needs of the EmpA team, and have been accumulating in recent years. The priority of analyzing this backlog arose due to external pressures (customer complaints) and internal (how to interpret the backlog repository content? and what should be considered a priority? ). Peeters (2015; p. 131) highlights that in many cases the conflict of priorities falls on the employees who deal directly with clients (external pressures), causing them to distance themselves from internal restrictions (rules, norms, etc.).

Thus, in addition to reporting solutions and results of the original problem (working system redesign), this study also reports solutions and results of an emerging issue, diagnosed during the action on the original problem. Situations such that are usually not addressed in conventional research, where researchers are not responsible to follow their own recommendations and, doing so, are not present during change implementation (Coghlan and Shani 2017). Action research is expected to promote change and, eventually, organizational reality presents new problems and demands solutions during change (Grant 2007).

Stage 2 begins with a posteriori evaluation of what had been recommended and implemented since the end of stage 1. This new stage required the holding of five face-to-face meetings, as described in Table 3. These face-to-face meetings focused on the continuity of the implementation of the new organizational structure (the result of stage 1, Table 2) and the support for the emerging analysis of the backlog.

Table 3 Summary of the stage 2 meetings
Full size table

In the second meeting (12/01/2016) there was also a report on difficulties in understanding, on the part of customers, about what should be treated as a contractual obligation (when EmpA is obliged, by contract to meet demands at no additional cost and as soon as possible), customization (when EmpA must meet demands, being able to charge for implementation within a negotiated term) or improvement suggestion (when EmpA should meet demands at no additional cost, but within a term at its discretion). It is opportune for customers, therefore, to preferentially characterize their demands as a contractual obligation. However, the service team states that it does not have subsidies to counter arguments in situations where the demand is not characterized as mandatory.

Also in that second face-to-face meeting, this researcher asked the staff to report on the most significant events since the announcement of the proposed changes (results of the stage 1). The person responsible for the service desk relationship subarea reported that he still feels that they are in a transition phase. The change has not yet taken effect and customers have not been informed. He chose to keep “things as they are” to avoid negative effects. In addition, he complained about customers still thinking that they “own” EmpA and that they should receive detailed information about everything that happens internally.

The person responsible for the product delivery subarea reported that there were advances in redefining configuration management tools, changes in the ticket registration system and that she intends to implement knowledge management systems (KMS). She stated that she feels more free, because her previous role consumed a lot of her time and effort. According to this coordinator, she used to spend all day sending emails. She agrees with the coordinator of the service desk relationship subarea about the fact that customers feel “owners of EmpA”. She cites a counter-example of a partner company, in which everything that is requested and that is not a failure/obligation of the supplier, is normally treated as customization.

The person responsible for the information systems area reported that (1) she structured a team with experienced developers to organize the backlog, with the objective of analyzing the tasks, closing what is not necessary, and returning for reassessment by the service desk relationship subarea what is questionable (from the perspective of experienced developers); (2) created an area for sorting the backlog, with the objective of receiving new demands from the service area and delivery subarea, “thus preventing new demands from entering the backlog directly without any prior analysis”; (3) integrated the workaround team (which was in another subarea and consisted of only one person) to the development subarea, for bug handling (may or may not trigger workarounds and include the final solution in the product); (4) reallocated one of the engineers to act as the data administrator, in the development subarea; and (5) allocated a developer to diagnose the current status of the delivery subarea (tests, documentation and delivery) with a survey of current processes, roles of each team member and identification of the positive and negative points of current processes. The purpose of this last action is to identify problems and redefine the processes, test automations and review team allocation in order to improve the result of the delivery subarea.

Table 4 shows propositions from stage 1 and those effectively performed actions verified in stage 2.

Table 4 Monitoring of proposed and performed actions
Full size table

The first meeting to deal with the analysis of the backlog took place on 12/07/2016, with the manager of EmpA and the coordinator of the information systems area. The manager requested support from this researcher in redefining the priority and participating in the backlog review process. There was agreement among those present regarding the momentary interruption of the research on the organization of work, avoiding obtaining new data and treatment of other socio-technical variables, but keeping the implementation of what had already been defined in stage 1.

Stage 2 (Detour): Activities Performed and Discussion

Although not initially planned as part of this research, this detour proved necessary as an urgent demand from EmpA, so we incorporated it into the work plan on an ad hoc basis. The relationship with initial planning, however, proved to be viable, as the problem can be linked to the Cherns principle of continuous flow of information. Wulff and Finnestrand (2023) discuss how data and information may be applied in organizations that strive to include data-driven processes into their socio-technical systems design. They found that there is a need to “upskill” or “reskill” employees so that they are able to design and use data/information for action (p. 65). Therefore, the use of dynamic data analysis techniques and making sense of the immense volume of data available in the organization proved to be a justifiable deviation.

EmpA structured three backlog repositories, classified at its discretion as priority, functional and structuring. This researcher received samples containing 10% of items from each repository for initial analysis. The first face-to-face meeting was followed by a series of e-mail discussions aimed at understanding the data content (meaning of the features), data quality (content reliability) and data analysis (development of specific analytical tools).

Data pre-processing indicated that, according to the sample, the data had sufficient quality for analysis (there were few exceptions such as record redundancy or missing values). There was still a need to review the quality of the content, but only the EmpA teams could assess whether this was really necessary, based on their knowledge on data. That is, if data reliability were considered satisfactory, there would be no need for a review. The problem would become the definition of which features to consider as a priority. We made two recommendations: (1) categorize each backlog item by module/subject (e.g., there are several items categorized as regulation or non-compliance in results, but what specific regulation topic? What aspect of the results? ); and (2) implement an OLAP application (online analytical processing; Kimball and Ross 2011) for dynamic data visualization. This application could be continuously updated with data from the backlog repository, facilitating analysis by the team for planning new versions of the product.

The coordinator of the information systems area acknowledged that while data is largely available for their needs, there are concerns about its reliability, particularly in terms of accurately classifying backlog items. There is a need for more experienced people to review the initial filling (which is done by the service analyst) and to adopt well-defined criteria and concepts to guide new fillings. The coordinator reported that it was being analyzed “if what was described makes sense, if the priority is correct, if it is feasible for the product and review the categorization, moving the task to the correct backlog”.

As for new incoming demands, the coordinator suggested that criteria should be defined and aligned immediately at reception, “with a review by a service analyst and then a review on the development side”. She understood that it would be possible to reduce rework and customer waiting time in cases where it would not even make sense to consider the demand. As for the suggestion of using the OLAP application, the coordinator informed that they had already tried to develop it, but it was discontinued, although she considers it “an extremely important tool for this work and for quantitative surveys to monitor the projects”.

The entire dataset was received by this researcher on 12/21/2016, containing records from the period Feb/2011 to Dec/2016. The software platform selected for development was QlikSense®, in a version free of licensing costs (restricted only to the application’s data volume). This researcher received also indicators to be implemented in the OLAP prototype, namely (1) number of requests per customer, to answer the question “who demands more?”; (2) number of requests per product, to answer the question “which product is in maintenance overhead?”; (3) number of requests by type (bug, story, analysis, customization), to answer the question “what type/category of demand in greater quantity?”; (4) number of requests per priority, to answer the question “What do we need to prioritize when planning/opening a new version project?”; (5) implementation complexity, to answer the question “Do X tasks ‘fit’ in the three-week time window of a new release project? What is the time window to ‘fit’ the X’s tasks in a new release project?”; (6) number of hours worked on the project, to answer the question “how much did the project cost?”; (7) number of hours worked by type of task, to answer the question “how much did adjustments (bugs), improvement (maintenance on existing functionality or new functionality) and customization cost?”; and (8) number of hours worked for each client, to answer the question “how much did the project cost to a client?”.

The second meeting to report the analysis of the backlog took place on 12/22/2016, with the manager of EmpA, initially focused on the variables provided in the sample. The third meeting to discuss the backlog analysis took place on 12/27/2016, with the EmpA manager and staff. At the time, the prototype was up to date with all data extracted from the backlog repository. The validity of the data presented and the need for further analysis were discussed. Figures 2, 3 and 4 illustrate the type of human-computer interface implemented for dynamic analysis of backlog data.

Fig. 2
figure 2

Projects and resources

Full size image
Fig. 3
figure 3

ABC Curve of backlog tickets by customer

Full size image
Fig. 4
figure 4

Backlog evolution in time

Full size image

Results

In this section we will present the findings and results observed during stage 2, ordered according to the perception of relevance mentioned by the manager and staff: “minimal critical specifications”, “transition structure”/“boundary location”, “compatibility”, “difficulties in understanding and abstracting socio-technical concepts”, “communication between coordinators and making departmental boundaries permeable”, “backlog analysis”/“information flow”. These topics do not always coincide precisely to our previous analytical categories or socio-technical principles, but resemble general concepts as perceived by manager and staff.

As for the implementation of the new work system, the reports of the staff and their teams initially suggest that the socio-technical principle “minimal critical specifications” (Cherns 1987) needs to be more widely discussed for implementation at EmpA. Although efforts to implement this principle are considered in the general design of the work system (e.g., definition of assignments without direct references to specific techniques or structuring of ad hoc teams), at the operational level, there is great concern with the volume of documentation produced and shared between development and delivery teams. We witness difficulties of transitioning from an organization of work based on bureaucratic principles to an organization based on adhocracy (or any other alternative approach), as reported also by Peeters (2015), which entails specific and in-depth academic investigation.

There are also reports of stress and uncertainty experienced by the teams during the implementation of changes, which corresponds to the “transitional organization” principle (Cherns 1987) and the “transition structure” described by Appelbaum (1997; pp. 454, 461). This transition structure could be identified in some interviews, when the manager reported: “the mood is good and there is collaboration, I think the motivation and focus are present. We are already in the midst of a transition that cannot take more than two weeks”. We observed, however, that the perception of the new staff about the still unofficial nature of the change was causing confusion at the operational levels, even though this same staff highlighted advances regarding the principle of “boundary location”.

As for the principle of “compatibility” (which provides for the participation of people in the design of the task), we observed the opposite of what Baxter and Sommerville (2011) mention when they state that people are not always willing to participate. In this regard, there was an intense participation of the staff in the redesign of their work flows. On the other hand, the intense use of business process modeling notation (BPMN) for the purpose of redesigning these flows (with a high level of detailing of specific situations), reinforces the possibilities alerted by Cherns (1987) about the implementation of the “compatibility” principle and strengthening of bureaucratic structures––adding the risk that the staff details too much of the process and thus making it harder to change when necessary––while, at the same time, there is difficulty in implementing the principle “minimal critical specifications”, in part for the reasons discussed by Peeters (2015).

Baxter and Sommerville (2011) describe the difficulties in understanding and abstracting socio-technical concepts, the significant differences between values ​​and world views, and imprecise success criteria in socio-technical projects. We observed that although the formal terms were not memorized (variance, boundaries, compatibility, etc.), most of the concepts were present in the actions of the manager and the staff. Even though they did not adopt the socio-technical terminology, they were willing to put them into practice, using substitute terms such as “quality” for variance, for example. The socio-technical dilution mentioned by Alter (2019) helps explain this phenomenon, since the socio-technical terms per se need a complementary explanation, which is highlighted by the difficulty of memorization and formal use of this terminology. As for the imprecision of criteria for evaluating the change, it was observed that only during the completion of stage 2 were some indicators defined, characterizing difficulty in complying with the change planning.

As for the organization of work, which provides for the formation of self-managed teams, capable of adapting to specific situations and problems (Pasmore 2006), we observed that the person responsible for the information systems department structured a team with experienced developers to organize the backlog. This initiative, although still in its infancy, illustrates EmpA’s willingness to allow coordinators and supervisors to delegate part of the control of the execution of tasks to their (self-managed) teams and also illustrates that the resources available from this delegation (time, mainly) have been dedicated to greater integration with their peers in other departments, intensifying communication between coordinators and making departmental boundaries permeable.

As for the backlog analysis, the OLAP prototype helped to identify (a) the customers that effectively demand the most effort from the EmpA teams (taken together, six (out of a total of 62) customers represent 52% of all registered demand); (b) the customers that register the highest volume of backlog items (together seven customers (out of a total of 62) represent 58.8% of the entire registered backlog); (c) the backlog has an average of 9.5 new items per month and has maintained an average growth of 50.8% year on year; (d) the backlog essentially concentrates items related to the ERP product and the most referenced modules deal with medical production (21.7%), process control (13%), and integration with the accredited network (9.7%) (e) the projects that consumed the most efforts were versions 3.0.0.0, with 11,585 man-hours, 621 items and 26 people allocated, and 3.1.0.0 with 13,667 man-hours, 2,318 items and 43 people allocated, while the average consumption of efforts per project is 686 hours, 87 items and 10 people; (f) there are significant correlations between items (features of a version) and people allocated (p = .88) and between people and hours consumed (p = .6). On the other hand, the correlation between items and people is moderate (p = .51), which creates uncertainty regarding the quality of the quantitative data that support these indicators; (g) the most usual themes in the texts (backlog descriptions) of the clients are “Error” (749 mentions), “Improvement” (556 mentions), “Import” (439 mentions), “Bug” (430 mentions), “TISS” (396 mentions) and “Archive” (390 mentions); and (h) if only the backlog items are considered, the themes most present in the clients’ texts are “Improvement” (112 mentions), “Import” (47 mentions), “TISS” (47 mentions), “Service” (45 mentions), " Error” (39 mentions), “Data” (36 mentions), “Demonstrative” (35 mentions), “Billing” (33 mentions) and “Archive” (30 mentions).

At the end of stage 2, these findings and results were discussed by this researcher, the manager and staff during two meetings. Table 5 summarizes the set of recommendations derived from the activities carried out during stage 2 and discussions of results from stage 1. The recommendations were related to socio-technical principles, according to the understanding of the manager and staff. Each coordinator and supervisor was responsible to discuss the findings and recommendations with her/his team, resolve doubts, and collect suggestions.

Table 5 Recommendations for managerial practice, after stage 2
Full size table

Conclusion

This study has its origins in a real managerial problem, experienced by a software development company that, after facing difficulties organizing its teams, chose to carry out action research for diagnosis, redesign and assessment of its work system. With activities distributed in two stages, this research investigated what socio-technical principles may be effectively understood and incorporated by a software development company in the design and practice of its work system; underlying the verification of the relevance of socio-technical principles to dynamic and flexible structures (more adhocratic/organic than bureaucratic, according to Morand 1995) in the area of ​​information technology (IT).

There was a partial understanding and incorporation of the ten socio-technical principles, as defined by Cherns (1987). The difficulty of incorporating the principles “minimal critical specification”, “variance control”, “information flow” and “support congruence” is highlighted, with probable causes related to attachment to bureaucratic principles strongly rooted in the organization. Additionally, dissonant and apparently unconscious discourse and practice are observed, which is close to the concepts of espoused theory and theory in use, as described by Argyris and Schön (1997). Conflicts between the manager and the staff also suggest misalignment between the effective IT staff and the business level, which could be mitigated with increased effective cross-departmental communication (Roses et al. 2014).

Despite the changes of plans and priorities that occurred during the research––the detour and changes in the action, during the action (Argyris and Schön 1997)––and having still partially understood and incorporated the socio-technical principles, EmpA’s efforts to redesign its work system in light of this theoretical approach promoted improvements in communication processes between departments, increased staff and team participation in the decision-making process, and deepened understanding of the relationship with customers.

A few months after the implementations described here, in mid-2018, EmpA was merged into another company in the software industry. The negotiation process started at the end of this work and lasted for several months, mainly with intense exchange of information between EmpA and the incorporator company. The EmpA head office was maintained, and became part of the development and services pool with other incorporator’s offices. There are currently no means to assess how much the socio-technical approach influenced the incorporator’s positive appreciation of EmpA.

To the supposed managerial/operational gain resulting from this research underlies the transfer of academic knowledge to the productive sector, a desirable result to reduce the theory-practice gap in the field of administration (Aguinis et al. 2018; Barrett and Oborn 2018). This transfer took place throughout the project, when data analysis, interpretation and solution development were processes negotiated between researcher and team, using specific academic terms.

Social, Theoretical and Technological Contributions

A social contribution of this research is the exposition to the staff of the need for balance between the technical and social subsystems, following socio-technical principles that provide for “humanistic strategies”, according to Mumford (2000; p. 127), promoting a work system design able to balance internal economic goals and quality of life for stakeholders (employees, customers, users, owners).

From a theoretical point of view, the contributions of this study is three fold. First, to the best of our knowledge, this report offers a first attempt to establish a direct relationship between agile values and socio-technical principles. Such a relationship is proposed diagrammatically, according to Fig. 1, and shows the existence of multiple cardinality between principles and values, which explains the assumption––so far anecdotal––of a relationship between concepts from the agile and socio-technical traditions.

Second, knowing that even agile methods––at least as implemented by companies like EmpA––demand detailed specification of the tasks to be implemented, the observed difficulty suggests that the socio-technical principle “minimal critical specification” is not always applicable by software development teams. Also of relevance, our findings suggest that the IT industry, despite the “agile movement”, is moving away from a socio-technical perspective while reinforcing a bureaucratic tradition. In this sense, Porto-Bellini et al. (2022) suggest that “opposing forces may exist among Leavitt’s dimensions of the work system”, which in our case may explain why espoused agile-based tasks do not coexist with adhocratic intended structure, but do coexist with bureaucratic forms. For now, it is clear that a theoretical contribution of this study is to reveal a gap in the relationship between the understanding and implementation of agile values and socio-technical principles in intended agile organizations. This gap may be explained by the concepts of espoused theory and theory in use, as described by Argyris and Schön (1997). That is, spousing agile values, but using them idiosyncratically, distancing themselves from the fundamentals due to lack of knowledge of the socio-technical principles that gave rise to the agile values.

Third, elaboration of complex process flows documented in detail also illustrates the tendency to maximize specifications, which seems contrary to the socio-technical principle “minimal critical specification”. This means that there is a belief in the predictability of the work to be done and the need to precisely define ‘how’ to do it. Such a preference opposes the espoused agile values against dense and rigid clauses, specifically restrictions to absorb changes, and the difficult to manage such particular details, and can be explained by a misleading understanding of the concept of equifinality, as stated by Bertalanffy (1950), which results in managers’ discomfort in managing teams involved in weakly defined processes, and employees’ discomfort in carrying out tasks that allow a broad range of strategies and creativity. Given the complexity of such flows, it’s also worth asking (a) to what extent is a process of this type followed by the teams? and (b) how is the conformity of actions to such formal norms verified?

From a technological point of view, the development of the OLAP prototype allowed EmpA to understand the nature of customer complaints, as well as who are the customers who most demand efforts. This study, therefore, aims to contribute to the improvement of decision-making in organizations by describing the “technical application of a work done with professional purposes, with the rigor of scientific research” (Biancolino et al. 2012; p. 296) for dynamic data analysis techniques, and making sense of the immense volume of data available in organizations.