When learning fractures teams: Do individual interests ... - CiteSeerX

Draft When learning fractures teams: Do individual interests negate the organisational benefits of collective work organisation?

Abigail Marks Heriot-Watt University Cliff Lockyer The University of Strathclyde

Acknowledgements The paper is based on data collected as part of an ESRC project funded under the Future of Work Initiative (award number L212252006) – ‘Employment and Working Life Beyond the Year 2000: Two Emerging Employment Sectors’ (1999-2001). The full research team at Strathclyde, Stirling, Aberdeen and Heriot-Watt Universities is as follows: Peter Bain, Chris Baldry, Nicholas Bozionelos, Dirk Bunzel, Gregor Gall, Kay Gilbert, Jeff Hyman, Cliff Lockyer, Abigail Marks, Gareth Mulvey, Harvie Ramsay, Dora Scholarios, Philip Taylor, and Aileen Watson.

1

Introduction

Occupations at the cutting edge of modern technology are seen to be good indicators of future trends in the workplace (Frese, 2000) and hence warrant substantial empirical research. Software employees are frequently seen as representative of work futures. Furthermore, studies of software developers often depict them as ‘new professionals’ or ‘knowledge workers’ (Barrett, 1999), and highlight the importance of collaborative work arrangements in terms of problem solving and learning (Brodbeck and Frese, 1994) for this group of employees. Yet, beyond these broad categorisations there is little discussion of the implications of these classifications of work on the development of knowledge-related skills or careers. Moreover, there is no research that examines how the definitions of these workers as professionals, knowledge workers and ‘team members’, indicate varied and sometimes contradictory learning processes

This paper undertakes a full examination of software employees and their learning process and attempts to integrate the classification of software workers as professionals, knowledge workers and team members, in order the understand how these employees develop skills. Previous research indicates that software workers are expected to be responsible for their own career development (Amakawe, Hall and Schor, 2000). However, this can lead to conflict between the organization’s perception of software workers as being self-developing professionals, and the employees’ view of the organization needing to take responsibility for worker’s development (Scarborough, 1993). Nevertheless, due to the level of co-dependence and interaction in software development work, learning frequently occurs, where

2

workers learn by depending on each other’s strengths, recognising mutual interests and sharing learning experiences (Fletcher, 1996). The development of software systems takes place mainly in project teams. The team-based nature of software work is therefore key for workers in the development of a portfolio of experience, new languages (see Barrett, 1999 for further details), skills, and added value in the labour market.

This paper uses qualitative and quantitative techniques to explore four propositions regarding the development needs of software employees the relationship between skills aquisition and team-based patterns of software development and maintenance. Specifically we are concerned with the multiple roles of software workers as ‘professionals’, ‘knowledge workers’ and ‘team members’. In addition, we consider the potential clashes between collectivist work process and the necessity for employees to balance team and project requirement with individual development needs. We draw on research conducted in five Scottish based software organisations between May 1999 and December 2001. The companies included one medium-sized independent software house (Omega), one software division of a large national communications company (Beta), and three independent, single product software firms (Pi, Lamda and Gamma). This was a multilevel study including workplace diaries, questionnaires, workplace observation and semi-structured interviews with over 300 employees.

3

Professionals, Knowledge Workers, and Teamwork

Software workers have frequently been described as a good indicator of future trends in the workplace. Indeed, as we noted, they have regularly been described as the archetype of ‘new professionals’ or ‘knowledge workers’ (Barrett, 1999). Both of these descriptions have a particularly individualistic position on knowledge acquisition. Yet a study of work of software developers (Broadbeck and Freese, 1994) concludes that the nature of work leads to a more collective construction of skills development due to a high degree of working in groups, high degree of communication with co-workers and high degree of interdisciplinary work. Consequently, these differing perspectives produce contradictory understandings of activities, knowledge and knowledge acquisition processes. The next sections will consider how viewing software workers, as ‘professionals’, ‘knowledge workers’ or ‘team members’ impacts on the realities and perceptions of the knowledge acquisition process.

Software workers as professionals

The term profession refers to a moderately vague concept. There are broadly three theoretical perspectives on the concept of professional and professionalisation, the functionalist perspective, the theory of closure and the interactionist perspective. The

4

functionalist perspective views a profession as group if individuals that have a shared code of ethics, single qualifying entry route and certification, a strong professional association, technical, political and/or economic control of knowledge and monopolisation of a particular market (Alvesson, 2000: Parsons, 1951). The theory of closure (Collins, 1979, Parking 1979) focuses on the strategy adopted by occupational groups to achieve closure and control is more closely associated with managerialist perspectives. However, we tend to view professions based on the interactionist perspective. As opposed to looking at the traits of a particular occupation, the interactionist approach looks at the everyday actions and interactions of professions, how they construct their social worlds as participants and how they construct their careers (Abbott, 1988; Crompton, 1990; Fitzgerald and Ferlie, 2000). The interactionist approach acknowledges ambiguities in the concept of a profession.

Although different audiences and researchers will employ different approaches and different sets of criteria in defining whether or not certain areas of work are a profession, this paper follows other work on IT professions and views professions as the way that occupational groups set out to fashion themselves, so as to be regarded as professional by themselves, other professions, industry, government and the public (Shapiro, 1994; Sonnentag, 1995; Waterson et al, 1997). Thus, although software workers do not possess the features ascribed by functionalists as a profession, software workers can be described as a profession in so much as they have an implicit set of professional codes, common beliefs values and ceremonies (Alvesson, 2000). Importantly, by this rationale, software workers are viewed as a profession by employing organisations.

5

Yet, many researchers within the field have argued that the diversity of software work reflects distinctions and differences in professionalisation of the occupation. Almost half of software workers are based in non-dedicated organisations rather than professional IT firms (Information and Communications Skills Dialogue, 2001), and the variety of occupational setting is reflected in the diversity of work in which they are engaged, ranging from the routine to the cutting edge (Barrett, 20001). Indeed the difference in complexity of work has led to competing theories of how software workers are positioned in the organisation.

The first position is a functionalist concern with the integration of the software worker into business organisations, which classifies software workers as professionals, with perhaps an eccentric and piecemeal pattern of occupational development (Scarborough, 1993), and a division of labour based on knowledge and expertise. The second view is a more critical perspective, which sees the management of software expertise as part of a horizontal division between managers and software workers (Greenbaum, 1979; Barrett, 2001). Within this labour process view, the division of work into development work and lower level ‘dirty work’ of data inputting and operations, is seen as evidence for the specialisation of work and fragmentation of the occupation, including the de-skilling of jobs and extension of bureaucratic control (Barrett, 1999; Scarborough, 1993; Kraft and Dubnoff, 1979)

Yet, irrespective of the nature and sophistication of the day-to-day work, diversity of qualifications and employment policies, constant with the interactionist perspective on professions, organisations view this group of employees who have a collective notion

6

of professionalism through conscious schemas learned either through the formal education route of the on-the-job socialisation that occurs through working with other software workers, as a professional group (Bloor and Dawson, 1994). By viewing software workers as a professional group organisation tend to isolate them from the broader management of knowledge within the organisation (Waterson, Clegg and Axtel, 1997).

By making this assumption, importantly for this paper, organisations are also absolving themselves to a larger or lesser extent from the training and development of this group of employees. Organisations assume that software employees, as professionals, are self-directed and motivated in terms of pursuit of knowledge and development of their own skills (Scarborough, 1993), and by implication should manage their own careers.

The changing nature of software work, particularly in terms of the development of new languages, means that it is imperative that employees do keep up to date with skills development. However, unlike the traditional professions such as law and medicine, for software workers there is an absence of central institutions setting training routes, controlling academic qualifications and professional standards. This leaves software workers with a problem. There are no formal development routes, yet organisations assume that employees will take responsibly for their own development and will not invest in employees’ training. Foote (2000) found that IT workers were indeed ‘desperate’ to discuss their career goals with their bosses, yet more often that not, did not have this opportunity made available to them. The level of discontent with training opportunities amongst software workers highlights the tension between

7

organisations assumptions and expectations of software workers than the organisation provides career opportunities and takes some responsibility for their development (Walz et al, 1993).

Software employees as knowledge workers

There is a belief within the organisational studies and management literature, that advanced western economies are becoming knowledge economies (Blackler et al, 1993; Drucker, 1993). It is also believed that expertise and specialist knowledge are increasingly important to corporate performance and are replacing capital as the basis of social status and power, and that management frequently rely on expertise for efficient problem solving and for provision of customised services (Tam et al, 2002; Bell, 1993). Expanding professional groups such as software workers, have emerged in response to the demands of modern corporations within these so-called knowledge economies (Scarborough, 1996), and have been labelled, rightly or wrongly as knowledge workers.

Knowledge workers’ primary interest is the marketability of their own skills and knowledge in the external labour market, instead of the well being of the corporation. However, as we noted in the previous section, software workers do not rely on conventional occupational or organisational systems to gain knowledge and advantage (Tam et al, 2002). Although it is essential for software workers within a context of fast evolving software languages and a diverse range of work to keep skills updated in order for career progression, research has indicated that software workers cannot rely

8

on the organisation to formally attend to their development needs (Foote, 2000). Software employees as knowledge workers in particular, are expected to assume more responsibility for managing their own skills development, and be self-reliant for their own career development and employability both within and outwith the organisation (Tam et al 2002). Individuals are required to develop an accurate self-assessment of their own skills and abilities, a clear view of labour market opportunities, required skills and to know how to access training. The careers literature typically interprets this shift by highlighting the potential for more entrepreneurial self-management of career (duGay, 1996), employability rather than employment (e.g. Heckscher, 1995), and the changing or protean career (Hall 1976).

But, despite the expectations for software workers to become self managed, intelligent or portfolio career careers (Handy, 1995; Arthur and Rousseau, 1996; Hall, Briscoe & Kram, 1997), software workers as knowledge workers rather than professionals, are more concerned with the creation and application of knowledge rather than the monopolisation of a field of specialist knowledge and hence are more subject to variations in labour market conditions (Flood, 2001). Subsequently, these workers are more dependent on their employing organisation than other workers of this type, whether formally or informally, to provide access to the means of knowledge production (Scarborough, 1999).

As Alvesson (2000) notes, organisational contexts are critical for the creation of knowledge and the expertise status as knowledge workers, and they are therefore dependent on the organisation. Management therefore need to acknowledge the reliance of knowledge workers reliance on the organisation for resources (e.g. new

9

hardware and software tools) and meet these requirements in order that knowledge workers can not only develop the contextual knowledge for work in the existing form, but also create new knowledge for further work.

Software workers are nonetheless, able to apply their theoretical knowledge in other contexts, i.e. in other organisations, and this ability means that they are also able to pursue marketization (Tam et al, 2002; Barrett, 2001). Hence, the loyalty of software workers to their employing organisation depends on the extent to which their job expectations are met by the corporation and the options available to them in the external labour market.

Software employees as team members

Knowledge workers are expected to be self-reliant for their own career development and employability both inside and outside the corporation (Tam et al, 2002), but unlike professionals do not have access to the formal means to do this. This section will examine how teams are used as a forum for software workers to acquire and develop new skills.

The development of teamworking and the related academic literature largely reflects production processes within manufacturing. Research has tended to focus on manual workers undertaking routine and repetitive work, and this has provided the basis for

10

the majority of concepts and classifications around teamworking. The product of this narrowly constrained research is the question as to whether existing conceptual frameworks for analysing teamworking, such as high involvement, high commitment and high performance work systems can be translated to all but routine types of white collar work (Lloyd and Newell, 2000). Established models of teams are not rich enough to fully explain the complexities faced by software design teams, as they are based on tasks that are shorter and less complex than software work and do not require the extensive integration of knowledge domains that characterises software systems design (Walz, Elam and Curtis, 1993).

Although the popular view of teamwork in other areas such as medicine and sport is of a group that brings together individuals with complimentary skills, the teamworking literature and indeed the organisations in which the research is located has been largely concerned with the flexibility and multiskilling of short job cycle tasks (Proctor and Mueller, 2000). The former view of teamwork is however exemplified by software work, which involves multiple agents with competing goals and responsibilities, with greater degrees of specialisation (from programmers and analysts involved in designing and writing the programme to managers and team leaders responsible for the day-to-day management of the project) (Proctor and Mueller, 2000;Waterson et al, 1997; Curtis, Shen and Iscoe, 1987).

This focus on manufacturing teams has also led to a narrowly defined view of skill development within teams, which views any skill development within a team as meeting organisational requirements with limited concern for the advantages to employees. Whereas manufacturing teams are relatively stable both in terms of skills

11

required and composition, the reality of most organisational groups including software teams is that they are not stable entities and regularly fade, inter-mix, and are reconfigured (Engestrom et al, 1999). This fluidity of work, with collaboration across shifting boundaries leads to learning and skills development between organisational members (Blackler and McDonald, 2000). This process is clearly reflected within software work, with knowledge sharing, knowledge acquisition and knowledge integration being significant activities within software teams (Walz et al, 1993). Coworker relationships amongst knowledge workers are characterised by a high degree of interdependence. This emerges from the need for employees to supplement each other’s expertise in order to analyse complex work problems (Tam et al, 2002). Indeed, Sonnentag (1995) found that those software professionals that can be described as excellent, had no greater length of experience or enhanced training provisions than other employees, but they did have greater variability in their experience in terms of the projects on which they had been involved in.

However, there may be problems for the organisation with employee’s adopting the team as a vehicle for knowledge acquisition. The development of individual expertise both improves the value and reputation of the organisation and enhances the individual’s reputation within the software expert community leading to offers of ‘more interesting’ work. As we previously noted, the changing labour market for knowledge workers has led to increased levels of labour mobility as staff change organisations to broaden and deepen experience (Amakawe et al, 2000). This leads to significant tensions for the firm between the organisational logic of using teams to efficiently undertake work, employee requirements to develop skills by moving

12

between teams and projects and at worse moving to another organisation in order to develop further skills. Indeed, the consequences of this in its extremity are illustrated by the practice of head hunting individuals and even teams to acquire expertise or bring new clients to the firm (Rasmussen and Johansen, 2001).

Based on this review of the literature we have developed a number of propositions

Proposition 1: Software employees in general, express discontent with the development opportunities provided by their employing organisation

Proposition 2: Software employees do not believe that their organisation provides them with the skills required for

a. advancement within their current organisation b. for a career within a different organisation

Proposition 3a: Software employees rely informally on project/team based work in order to acquire new skills

Proposition 3b: Employees move between teams and projects in order to develop new skills and knowledge

13

Proposition 4: Software employees will remain within an organisation so long as their development needs are accommodated

Method

Background data on company history, operating procedures, employment policies and staff characteristics was gathered as part of an intensive process of case study analysis and observation involving four researchers in each of the five companies for approximately four months. An employee questionnaire, which was distributed to all employees in the five workplaces, was embedded within the case study process with the researchers directly involved in distribution and collection. This process resulted in a high response rate to the questionnaire overall (mean = 69%). The single company where direct contact with employees was not possible because they worked a significant proportion of time off-site (Gamma) returned a substantially lower response rate (25%) compared to all the other companies, where the rate ranged from 72% to 88%.

All the organizations studied were representative of the sector by employing a combination of contractors (16% of sample) and permanent employees (84% of sample); a majority of males (72% overall) although Omega, Pi and Lamda employed between 32% and 41% females; and a generally young workforce, with 73% under 40. From the surveys returned, 9 were not used in the present analysis as they represented employees in a support role or non-technical role to software professionals. This provided a total of 327 useable questionnaires. The questionnaire included a number of key measures relevant to the propositions above.

14

Quantitative Measures Control variables. Two variables represented personal characteristics: gender (males coded as 1 and females as 2) and age (represented by an ordinal scale where 2= 21-30, 3=31-40, 4=41-50 and 5=51 or over).

The analysis also controlled for the following work-related background variables: tenure with company (measured in months); whether the respondent worked full time or part time (full time coded 1 and part time coded 0); contractual status (permanent employees coded as 1 and contractors and temporary employees coded as 0) and job complexity (respondents were asked how important, on a scale of 1 to 4, five key software tasks were in their present job. The mean of these tasks were found for each participant and formed a measure of job complexity; α=0.87).

A comparison of means on the dependent variables for all five organizations showed these groups to be broadly comparable.

Independent and Dependent variables. Perception of skill acquisition was measured using three items on a four-point scale of agreement adapted from Sturges, Guest and MacKenzie-Davey’s (2000) Organizational Career Management scale. Two items were used to measure skills acquired for a career in the current organization ‘I receive the training I need to perform my current job well’ and ‘the training opportunities I have had here will allow me to get a better job in the company,’ (α=0.77). Only one item was used to look at skills acquisition and employability in general, as the other items in the scale focused on skills acquired for a career in the existing organization. The one item was, ‘Things learned on this job will make me more employable 15

elsewhere’. We also used a single item to look at satisfaction with career within the existing organization ‘I am satisfied with my career prospects company name’. Although based on Sturges et al’s (2000) scale, this item was on a seven point scale of agreement from ‘extremely satisfied’ to ‘extremely dissatisfied’.

Actual training received was measured by asking what training respondents what training they had undertaken with the last 12 months or since joining the company if it was more recent. This was measured using a four-point scale representing amount of training undertaken.

Intention to remain with the company was measured by asking how respondents viewed their current job in the company. The measure was coded 1 if this was a longterm job they would stay in or if they saw the job as an opportunity for career advancement in the present company. If the job was not part of a career in this company, or part of a career in other companies the measure was coded 0.

Finally, three items measuring the relevance of formal training, education from college/ university and support and advice from colleagues and team members in helping employees learn and develop the skills needed for their work was measured using a four point scale from ‘not at all important’ to ‘very important’.

Qualitative Measures. As Curtis, et al (1988) identify, the context of software work often displays a complexity that is beyond conventional classifications. Similarly, Guindon and Curtis (1988) indicate that the software development process is less than precise in practice, with opportunism tending to characterise the behaviours of

16

engineers and designers. In order to fully understand the complexity of the work, employees’ experiences of team and project work and to be able contextualise the quantitative findings and to answer propositions 3a and 3b with sufficient depth we obtained qualitative data through exploratory and semi-structured interviews. Where possible, we followed Yin’s (1994) recommendations for case study research. The data collection process involved a triangulation of methods, specifically the collection of archival records (company history, operating procedures, employment policies and staff

characteristics),

semi-structured

interviews,

work

observation,

and

an

organisational survey. Although all of these methods inform this research, we will specifically report the results of the interviews and the survey. However, when using triangulation we had to take account of the limitations placed by the implicit structures of organisations and could not always examine each construct with every research tool. Specifically, because of the relatively small numbers of participants within each team, we were prevented from undertaking meaningful intra-team quantitative analysis.

Exploratory interviews took the form of work observation and focussed discussions with key groups of informants (management, employees, team leaders) and provided an initial discussion of the work process and issues around collective work, skills and careers. The semi-structured interviews selected employees within 1-4 teams within in each company according to gender, age, job type and job/organisational level, and explored three themes in greater depth: (a) previous work and educational history and how it led to their present job (b) experiences of working in the present company (content and control of work, identity, commitment to company/peers/job, social relations) and (c) work-life linkages and the future (perceptions of job

17

risk/uncertainty, relative importance of work, perceptions of society/class/status). Between 17 and 26 semi-standardised employee interviews were obtained for each company, except for the small start-up (Lamda) where three employees representing one team were thought to adequately represent the company.

Analyses Propositions 1 and 2 deal with organizational learning and its impact on the broader career. Proposition 4 is concerned with the impact of development opportunities on retention within the organization. These predictions were tested by estimating two exploratory multiple regression equations, controlling for person and job variables. All equations were estimated using an ordinary least squares stepwise procedure, except for the equations predicting the dichotomous dependent variable intention to remain with organization where logistic regression1 was used. There was some evidence from these equations that the control variables, age and gender may have an affect on the results. Using a series of t-tests and ANOVAs we examined the differences found in terms of these two control variables and the affect of university education on the independent and dependent variables.

As we noted earlier, we felt that propositions 3a and 3b required more detailed examination of team processes. In order to do this we used the qualitative data to explore these propositions. Each interview was either transcribed verbatim or produced as research field notes and coded by the researchers. A qualitative data analysis software package (nVivo 1.2) was used both for data management purposes (i.e., to organise all hardcopy and electronic documents, including labour

18

market/industry statistics and the different types of case study notes produced by researchers), and for data analysis. The data was interrogated by using a key word search within the nVivo package.

Results

Descriptive statistics and comparison of means

The means and standard deviations as illustrated in tables 1-3 show some differences between gender, age and in terms of education, with reference to the main research variables. The sample as a whole all rated the actual training received a little above the midpoint of the scale (M= 2.35, S.D.=1.10), similarly they rated skills received for employability within their current organisation above the midpoint of the scale (M=2.38, S.D. = .64). Participants rated skills received from their current organisation for general employability relatively high (M=2.38, S.D. = .71). These three results indicate little support for proposition 1 and 2.

Although the mean for the variable ‘intention remain’ was low (M=.43, S.D.=.49), there was a great degree of variability in the response to this question, and the mean for overall satisfaction with their career in their existing organisation was above the midpoint (M=4.22, S.D.=1.27).

INSERT TABLE 1 HERE

1

All logistic and stepwise regressions were repeated removing one organization at a time. There was

19

Respondents viewed formal training (M=2.74, S.D.=.99), university/college education (M=2.74, S.D=.81) and team members (M=3.23, S.D.=.96) as important resources for gaining new skills and knowledge, and all three were rated above the midpoint of the scale. However, team members were seen as the most relevant resource, followed by formal education. This provides initial support for propositions 3a and 3b.

INSERT TABLE 2 HERE

There were a few differences found between groups of employees. Women had longer job tenure (t=2.52, p