The Sociological Review Volume 43 Issue 2 1995 [Doi 10.1111%2Fj.1467-954x.1995.Tb00603.x] Janet...

8/12/2019 The Sociological Review Volume 43 Issue 2 1995 [Doi 10.1111%2Fj.1467-954x.1995.Tb00603.x] Janet Rachel; Ste

1/24

The discursive structure of thesocial technical divide: the example ofinformation systems development^

anet Rachel and Steve WoolgarAbstract

The social and technical are commonly defined in opposition to eachother. Yet technology practitioners are often quite comfortable withthe idea that the technical is constitutively social. Drawing on anethnographic study of a computerised information systems develop-ment project, this paper examines various usages of notions of 'techni-cal'. Attempts to situate the study at the 'technical core' of the projectwere met with a series of rebuffs. 'Technical' talk is to be understoodas a categorising device which does boundary work. Technical talkinvokes and performs a disjunction between networks of social rela-tionships and stipulates a moral order with associated norms foracceptance and transition.The difficulty of penetrating the intelligibility of technical talk isunderstandable as a struggle in familiarising oneself with the routinesocial actions of a separate community. In addition, the private sphereof the technical is often distanced in time. The costs involved in jour-neying into the future are analogous to those of penetrating alien cul-tures. Ideas of progress and advance are often associated with theinvocation of 'the technical'. These connote a notion of timing whichreinforces the distance and difference of - and hence depicts the costsinvolved in penetrating - removed sets of social relationships.Technical a. Appropriate or peculiar to, or characteristic of, aparticular art, science, profession, or occupation (OED).


2/24

JanetRacheland Steve Woolgar1989). This basic distinction is central to discussions of theimpact of technology on society (Marien, 1989), the technicalconstraints on users (Orlikowski, 1990), how IT transforms socialrelations (Bolter, 1989) and work (Dunlop and Kling, 1991), howUsers might become more involved with the design or implemen-tation of a System (Mumford and Hensall, 1979), how to matchhardware capacity to users' needs and so on. The way in whichwe deploy the distinction can also provide a marker of discipli-nary affiliation, for example whether we are to be heard talkingas sociologists rather than, say, software engineers.It is common practice to counterpose the social and technicalas a dichotomy, each term of which takes its sense in oppositionto (and exclusion of) the other. This tradition means that wehave a tacit understanding that things 'technical' are not things'social'; that software engineers are definitely not sociologists.One consequence is that when a 'social' discipline begins toaddress issues usually reserved for a 'technical' discipline (or viceversa), the boundary between the two is maintained. For exam-ple, discussions of the organisational determinants of successfultechnical development; the exercise of power during systemsdevelopment (Markus and Bjom-Anderson, 1987) and the powereffects of the introduction of systems into organisations (Duttonand Kraemer, 1980; Kling, 1980) all reaffirm a distinctionbetween 'technical characteristics' of a system and its 'socialdimensions'. As Bloomfield and Best (1992) point out, thesearguments rest on the a priori separation of technical and social;they do not consider the difference as part of the achievement ofsystems development. However, you would also probably regard it as commonplaceif we were simply to make the point that technical systems arethemselves thoroughly socially constructed. If we documented allthe arguments, discussions, and debates that occurred throughoutthe development, implementation, and use of a system you maywell say 'but what did you expect?'. If we presented clear exam-ples of the moments of compromise and choice, or detailed theclever schemes devised to persuade Users to accept this instead of


3/24

The social-technical divideevidence of the thoroughly social nature of information systems(IS) development. Instead, it will examine the use and currency ofthis particular point of view. Our aim is to document the pres-ence and absence of this point of view, to describe the occasionswhen the 'social' is present and when it is absent; in short to doc-ument the ways in which the social-technical divide is managed.Our puzzle is that although the presence of the social in technicalwork is an unremarkable piece of common sense, that this issomething 'everyone knows', there are occasions when the com-mon sense is denied. How can we best characterise the circum-stances under which this happens?

One clue towards a way of addressing this problem lies in theway we couched our initial inquiry. We said we were impressedthat 'everyone already knew' that the technical (artefacts, techni-cal work, technological knowledge) included elements of thesocial. But who exactly is this 'everyone'? It is important toreconceptualise the issue on a local scale: 'everyone' can denotethe relevant community one is addressing on any particular occa-sion. In other words, the relevance of the social for the technicalwill depend crucially on the particular audience being addressed,and on the occasion of the address. More specifically, the claimthat the technical involves the social implicates particular sets ofsocial relationships between audience and speaker (cf Cooper andWoolgar, 1993a); it is tantamount to a claim about the social dis-tance between different communities.Our aim, then, is to draw upon and elucidate the notion thatdepictions of 'the technical' can implicate social relationships, inorder to make sense of experiences during participant observa-tion of information systems development. It has been widelynoted that the way we speak about technical objects (and aboutcomputers in particular) reflects some of our basic assumptionsabout differences between man (sic) and machine (for example,Barry, 1991; Bloomfield, 1989; Turkle, 1984; Woolgar, 1987). Inthis study, we are interested in the ways that 'technical' suggestsdifferences between domains of social relationship. In particular,we wish to explore the sense in which deployment of the 'consti-tutive' repertoire (Collins and Pinch, 1979; 1982; Mulkay et al.,


4/24


5/24


6/24

JanetRacheland Steve Woolgarand the Systems Team. He suggested that we choose one of theseteams to join for the study. We chose the Systems Team.^We had been offered the standard dichotomy, so we seized thechance to locate the research at the 'heart' of the technical pole.We are trying to avoid the kinds of 'fobbing ofP experienced byother social scientists who set out to study science or technology.For example, in a previous participant observation study of asolid state physics laboratory (Woolgar, 1990), despite his protes-tations, the researcher had been directed towards what partici-pants regarded as the 'social end of things': introduced first to ascientist who ran the University's Gilbert and Sullivan society;immediately told that a senior professor in another departmenthad recently thrown a kettle at a junior colleague; and so on.

Our choice produced consternation among project members.Over the course of a series of initial visits to the CIS project, ourintrepid researcher repeated her chosen location to a row ofincreasingly blank faces down through the hierarchy:You're doing what? an anthropological study ofSystems Howdoes that work?You want to look at the human dimensions, but you want tojoin theSystemsTeam? HmmYou're interested in the people issues, right? Well, there'splenty of oddballs round here.

The office manager was just baffled by the request to join theSystems Team. 'You'll be bored' he said. But we kept pluggingon. Gradually, the Head of the Systems Team came round to theidea that this was where we really wanted to be, and slowly hebegan to think about the implications:

maybe you could join the training courses that we send ournew recruits on.It looked like the tracks were in place for our research to roll


7/24

The social-technical divideject. Grace, his deputy, was busy inducting new recruits into theSystems Team. But Janet was not a 'new recruit'. The Head ofChange Management was off sick, and her deputy was out of theoffice. Finally, the secretary suggested it might be a good idea totag on to the User Testing this morning.Although you might expect User Testing to comprise technicalwork, nothing about the testing that day bore out this expecta-tion. For example. User Testing was carried out in the comer ofanother office elsewhere in another building. It was run by aWoman who had been seconded into the team as a User. Two ofthe 'Users' doing the 'Testing' were large ladies who usuallyanswer telephone queries (with the help of computerised recordkeeping systems) in the Customer Accounting office (their bodies,clothes, and hairstyles, their demeanour and conversation wereall very different to the sharp dressed, slim, youngsters in the sys-tems team).A brief meeting with Grace over lunch revealed that theSystems Team were 'all very busy now with the last phase ofdevelopment'. Janet was told that 'most of their work was techni-cal', so perhaps she should instead join the Change ManagementTeam. She could help them with the Implementation Roll Out.So that afternoon the researcher found herself part of theImplementation Team, a sub-team of the Change ManagementTeam, with responsibility for preparing a handbook and presen-tation material (complete with 60 overhead slides) to be deliveredto the outlying operational sites, the work of which was to bechanged with the advent of the new system. Despite our bestefforts, Janet had become a member of Change Managementrather than Systems. Thus, the first attempt to penetrate what weimagined to be 'the technical core' had failed.Three points can be drawn from this initial experience. First,the organisation of the Customer Project already assumes thatSystems Development is separate from Change Management.You become a member of either one, or the other. As theresearch progressed, it became increasingly obvious that thisboundary between the 'Teams' was not easily overcome. In fact,


8/24

JanetRacheland Steve Woolgarobserver not only found it problematic to join 'as a spare pair ofhands' - as envisaged in the original research proposal. Shefound it almost as difficult just to just walk into the System'sTeam office space and talk.Third, the assumption drawn upon to deal with a sociologistwho says she wants to study the human dimensions of systemsdesign, is that she must be interested in what some members ofthe company referred to as 'people problems'. This categoryseemed to refer to the personalities of members of differentgroups, the politics of inter-departmental negotiations, and so on.In particular, 'people problems' were said to arise when people(that is Users) do not want to use the new system in the formproposed by the Systems Team. On this view, it was felt naturalthat the observer would want to be with the Change Manage-ment rather than the Systems Team, since the latter's concernwith the actual business of 'building' the system involved theapplication of standard logic which could only be undertaken byspecially trained people.Technical boredom and routine: howcan Ichallenge this army?Our observer thought she had discovered another sense of the'technical' when she came across William. As a member of theSystem's Team, he spent a good deal of his time yawning and sit-ting slumped, staring into his computer screen. This was a fairlycommon posture on the System's side of the room. A highlystructured 'case tool' lays out documents and work sequences forhim to follow and divides up his time into accountable chunks. Itall seemed to produce in him a defeated lethargy. The researcherhad been warned that life in the Systems Team would be boring.At last. Had the observer finally reached a participant-validatedunderstanding of the technical? No When the observer reportedthe above interpretation back to William, she was dismayed to betold she had got it wrong. The things she had described - theoverwhelmingly structured character of the work - were not tech-nical. It is not the technical which is boring, he explained, it was


9/24


10/24

JanetRacheland Steve Woolgarsignalled that responsibility for LAN printing belonged to (yet)another group of Contractors. When the Head of Imple-mentation talked of technical problems, he was referring to BTengineers bringing lines into various parts of the business forphones and fax machines. Or he was talking about the failure ofanother Company to provide all the necessary boxes and wiresand air conditioning to enable the computer terminals to work.In short, this usage of technical usually denoted some kind offailure or deficiency that lay outside the speaker's immediatesphere of responsibility, and for which they themselves cannot beblamed.

Job descriptions in the System's Team themselves embodiedand displayed a distinction between technical knowledge andbusiness experience. The Consultants had brought the mainorganising principles for the development of the information sys-tem (the Case Tool), and they stipulated which specific phaseswithin the development of the system were to be referred to asTechnical Design. As well as organising the office into Systemsand Change Management, they also divided responsibilitieswithin the System Team between Functional Architecture andTechnical Architecture. One of the System Team membersexplained the split as follows:the Functional Architect decides on what screens to have;Technical Architects figure how to do it underneath.

The Functional-Technical distinction enabled the Consultants toargue that their technical design did not dictate the shape of thesystem to the client organisation.^ This was said to be an impor-tant advantage of engaging this particular consultant. It alsoreinforced the distinction: Technical was to be understood as theCore, the underlying logic, whereas Functional denoted the taskof tweaking the interfaces (particularly identified as the Screens)to fit the specific characteristics of the business.^In all these cases the invocation of 'technical' does boundary


11/24

The social-technical divideinvolved) comprises many variations on the underlying uniformity.Whereas we have to live with this slightly perplexing fact we can,nevertheless, plug on, gallantly, trying to persuade people (others)to see the error of their ways; we can gradually bring them aroundto living their hves (at work, at least) without all this messy varietythat is so difficult to control. . . .

The boundary consti tuted in virtue of reference to (and desig-nation of) the ' technical ' thus suggests a disjunction in networksof social relationships, a break between those outside and thosewithin. The suggestion is rhetorical in the sense that it does not,of course, prevent the physical traverse of the divide. Rather, itstipulates a moral order: the ways in which behaviour shouldoccur. Crossing the boundary, getting inside the technical,requires the i t inerant ethnographer (and anyone else who wishesto effect the transition) to relate to different entities and to relateto them in different ways. Thus, although it is relatively easy tocome in, sit down at a keyboard and start pressing keys, thecompetent display of 'pissing about of the mainframe' requiresan altogether longer apprenticeship. The invocation of ' technical 'is thus an invocation of a different community. Participation inthis different community is said to have all kinds of attractionincluding, as we saw in the last example above, the promise ofleaving 'messiness' behind.

Amongst the technical architectsChasing the most technical.The ever present, yet illusive category of ' technical ' continued toattract the researcher. She became convinced that if she didn'ttrack it down somewhere and write about it , she couldn't claimto be doing good research. So, she decided to stalk it around theoffice until she found it. She began asking people directly, whereshe should situate herself to do her research if she wanted to seetechnical work being done. To some, this was straightforward.One of the System's Team, defining himself as a Designer, said:


12/24

JanetRacheland Steve WoolgarYou need to be with John, Chuck and Charlie as they do UserRequirements.

John, Chuck and Charlie were young consultants who accompa-nied the new DC package when it first arrived from the States.User Requirements was the first stage in the DC packageMethodology. John, Chuck and Charlie were working with sev-eral Company nominated employees, known in the SystemsTeam as Users. They were trying to reach agreement on a docu-ment which would be required to stand as the Scope for theSystem when it 'moves forward into production'. When ourresearcher turned up at John's desk and explained why she wasthere, he said:

You want to look at thetechnical stuff? You really need to bewith Maheer and his team.Maheer is also a young consultant from Washington DC. He andhis team, are known as the Technical Architects for the DCSystem. 'What is it about their work that makes it technical?',asked the naive researcher.

Oh, well, they do all the technical architecture. They figure thesecurity levels and stuff like that, controlling who can accesswhich parts of the systemOthers were more hesitant in response to the researcher's ques-tioning. Sometimes the answer began: 'Well, it depends what youmean by technical'. Aha. So the researcher asked 'How wouldyou define the different types of technical then?' Felicity, aCompany employee working in the Systems Team, volunteeredthe following reply:

Well, I suppose, to Change Management, everything that goeson inside this [the Systems] team is technical. But I see Julie'swork as the most Technical. You see. Change Managementonly use computers on the surface. They use it as a word


13/24

The social-technical divideWhen Julie writes her program it matters, something happens.The machinedoes something.There's a big gap between Systems and Users. People likeGary should be working to bridge that gap. People don'talways follow instructions, they misread the procedures, ordecide to do something different. But the machine alwaysfollows exactly, you know it will do what you say. Unless thereare any bugs, of course.

Our researcher wondered whether there was in fact as large a gapas Felicity claimed. On the one hand, Julie writes detailed proce-dures which the machine will follow; on the other, Gary writesmore general procedures which people can manipulate. Theseactivities did not appear very different. Well, said Felicity, if youdon't like my definition, try Roy:

OK, it depends what you mean by technical. But I guess it's thepeople who look after the database. Yeah, Roy, people like that.Both Roy (the database manager) and Maheer (the TechnicalArchitect), independently maintained that if we really wanted tosee the social shaping of the technical, then we should go see theDesigners. These are the people who set out what the System willdo and how to do it. Roy said: 'We only take their ideas andmake it happen'.The researcher began to feel she was experiencing a recedinghorizon, that 'the technical', like 'the science' (Woolgar, 1985),was one of those illusive phenomena that 'was always elsewhere'(cf Moerman, 1965). Then, one night after work (at about 6.30pm), one of the Designers called the researcher over, and said:

Hey, Janet, I've been thinking about you. You should getyourself into this if you want to see the social bits of thetechnical.Duncan was working on 'PC20s'. This was the name of a doc-ument form, set out in the CASE tool. Each PC20 was supposed


14/24

Janet Rachel and Steve WoolgarAnother designer, Adam, remarked that he had already'selected out' some of the Functions which it 'would have beengood to have' because he judged that they could not possibly beachieved by the deadline fixed in the contract between the DC

and the Company. He emphasised the point:Some of the things tha t we [Freshwater] want aren't evenmaking it into the matrix. I'm not putting them in, because Idon't think they can be doneDuncan was defining technical work which could as easily bedescribed as senior level strategic decision making. While work-

ing through his categorising algorithm he was eliminating func-tions that another committee of company representatives haddecided they wanted in the final computer system. At this point,Michael, who is standing nearby, joined in the conversation anddescribed the problems he was having with the Coders (peoplewho write the programs) for the Out Of Hours (OOH) System.Michael could be heard as contributing to the 'technical' prob-lems talk between Duncan and the researcher. But Duncan dis-missed Michael's intervention: 'Oh programming is just a m atterof taking the detailed design specification and churning the tech-nical handle, and out pop the programs'.The nature of 'the technical' had thus changed within a matterof seconds, during the course of conversational exchange.Duncan had spoken of the complexity of imagination and judge-ment that was needed in the highly technical work of writingPC20s, and in the next breath was using the word 'technical' torefer to mere routine rule following (turning the technical handleto produce programs from program specifications). Michael didnot dispute this latter representation even though he had spentall afternoon struggling to explain the spec(ification) to one ofthe programmers. This was the kind of work which disappearedfrom view behind the phrase 'just turning the technical handle'.Technical dreaming: the future in the present.Another DC Consultant suggested I attend a brainstorming


15/24

The social-technical dividefuture, and try to define the kinds of machinery needed in orderto drive (not support, nor enable, but drive) this vision into areality. The dream revolved around the certainty of a paperlessoffice, where Users would need neither to move away from theirworkstation, nor to refer to paper, nor ask another person.Instead they would be able to consult a Geographic InformationSystem (GIS) which would hold full details of all properties,streets, water mains, and sewerage plans within the entire domainof the company.Participants were urged to free themselves to dream of a per-fect future, from which technical imperatives could then bedrawn: that is, how many machines of what kind would need tobe purchased to make the dream come true, and what other soft-ware would have to be written. On the basis of the musings ofthese young men, a potential investment plan was being draftedwhich would have major consequences for the working patternsof many future Freshwater employees. It seemed curiously appro-priate that these young men knew virtually nothing about theoperations of other parts of Freshwater. Their ignorance andlack of experience was apparently their qualification to dream ofthe company's future.Complete unintelligibility: technical as a foreign language.Just before this last meeting began, there had been some veryanimated talk between the technical architects and the databasemanager. This gave our researcher her first real sense of achieve-ment. At last Real uninhibited technical talk She could smellthe technicalities bubbling away. Luckily, she had turned upearly to the meeting, and had brazenly switched on the taperecorder there and then. This produced a temporary halt in thetalk, a joke at her expense, but then the happy continuation ofwhat must be, we are sure you will agree dear reader, beyonddoubt, real, technical talk. Here is an excerpt:

CONl You know the list of Contact Retrieval, Work Request


16/24

JanetRacheland Steve WoolgarCO Nl You know, when you PF7 itselects the data again,does it in reverse sequence. All this complex logic inthere to say that you've selected 12 rows on the way

down, and when you go and, and you say, you hitPF7,you've selected nearly 13 rows ( ) it doesn 'tneedto be that dynamic.DBM Not especiallyCONl I was saying to [CON2]. It's slowing the system downsomuch having that functionality in there and I can'tsee the benefit, the cost is enormous, and the benefit isjust . . .((Cross talk by all))(Acting System Team Leader (TL) walks in and joins us))CONl All the list processing, work request list, retrieval list,contact retrieval list, ( ). What we're actually doing atthe moment is when we select the information we selectit and we go away and get the first page of informa-tion, hit PF8, and go away and get the second page ofinformation from the data base, and when they hit PF7we go away to the data baseagainand get the firstpage of information againfrom the data base but inreverse sequence and if there was 12 rows the first timewe displayed this and then there was only now say 11or there's 13 the second time. We've got a differentscreen. Hell of a different. I can't see that the benefitsis there. The necessity for that is there. They can't need

it that dynamic.TL They can't need what? the paging ( )((Cross talk by all))Certainly the researcher was clear about this being technical talk.This excerpt itself was delivered with such speed, and overtalking,and used so many words that seemed to make no sense. Shereally had no idea what they were talking about and yet she sup-posed that the participants understood what was going on.Subsequently, however, after having taken the tape away, listened


17/24

The social-technical divideexplanation is that the transcriber had to listen hard to make outunfamiliar (technical) words. As conversational analysts haveshown us, however, parties to the interaction are not attending tothe 'meaning' of the words themselves, so much as to the socialactions being performed by their co-conversationalists. (All kindsof grunts, mutterings and ungrammatical utterances pass as sensi-ble social actions ). In other words, transcription (like conversa-tionalists' sense making activity itself) depends on attempting tomake sense of the interaction. (What action was DBM performingin first replying to CONl in the way she did?). The process of lis-tening, transcribing and trying to 'make sense' of the conversationis thus a process of trying to figure out what kinds of socialaction are taking place in this foreign environment. (Was thatutterance a snub, a rejection or what?). Coming to an understand-ing of the talk is thus not just a translation of inherently difficultwords. It is a process of familiarising oneself with what passes associal interaction within this particular set of social relationships.As the transcriber became more familiar (literally, if you will, asshe became a tentative member of the family), she began to tra-verse the social organisational boundary constituted by the 'tech-nicality' of the talk. Traversing the passage is hard work: a directrefiection of the costs involved in penetrating an alien network ofsocial relationships.

Producing the technical: creating private space in timeOne of the most striking things about the work done by theSystem's team is that it is done so far in advance. Friedman andComford (1989) talk about 'a general problem in the computingliterature of advancing the clock' which they refer to as the 'prob-lem of tenses'. Time was differentially manipulated by the twoteams comprising the Customer Project. The work of the System'sTeam was scheduled to be done in advance of the ChangeManagement Team: the technical work had to be done in advanceof the system implementation. We have already described how the


18/24

JanetRacheland Steve Woolgarentiating time. We were able to watch the effects of this processslowly unravel during the course of Out Of Hours design.A small sub-team within the System's Team has been workingon Release 2 of the Contact Logging System which they calledOut Of Hours (OOH). In December 1990, one of the men, callinghimself a Design Analyst, visited various parts of the business,interviewed a number of key managers about the current practiceof operating Rosters during the night, weekends, and other non-office times. Throughout January and February he and two oth-ers used this interview material to devise data flow diagrams, andto work out 'entities' and data elements. Quiet discussions wereheld with the DataBase manager and the Technical Architect atcasual moments during the normal working day. A 'prototype'was constructed and a presentation was delivered to a few care-fully selected senior managers. Commitments were made.Documents were written.Only then were the Change Management Team brought in tobegin their own process of interviews and designs. By this timethe Systems Team were firmly established along the path laidout in the pre-structured methodology. As they were entering atime phase they called Technical Design, the ChangeManagement Team were just beginning to get a feel for the sizeof the problem. As far as the System's Team were concerned,they had got what they needed to write a computerised system.It was for the Change Management people now to go out andinterview again, to find out what else must be done (what proce-dures should be written, what training given, what practiceschanged, what new forms to be designed, what new RadioSystem to be developed, how many new voda-phones should bebought . . .) to allow the system to work. The ChangeManagement Team were charged with creating the new worldinto which the computer system can gracefully slide, dignity andintegrity intact. In her field notes, the observer succinctlyrecorded her reaction to this state of affairs:

it is a constant source of amazement to me that the Change


19/24

The social-technical dividebecomes clear is that 'technical' reasons for not changing are alsotiming reasons. It is now too late, in general, for the commentsof Users to be encompassed in the design of the machine.

Why then is timing so important in technological development?Why is it that, particularly in an area like information systems,development seems to have an unstoppable momentum, to bepart of a vision of unending progress? One answer arises from anextension of our understanding of the boundary work in techni-cal talk. We have likened the effort required in negotiating thisboundary to the work needed to travel to, and understand, a for-eign culture; 'technical' is a reflection of the costs involved inpenetrating an alien network of social relationships. But the past,as they say, is (also) another country. In other words, there arecosts involved in journeying in time which are directly analogousto the costs in penetrating alien ('technical') cultures. Perhaps thecosts are even greater when the journey is forward in time: thefuture is another country as yet unknown, except by a few (usu-ally highly paid) experts (often called Visionaries or Gurus). Toput the point another way, timing (or the 'problem of tenses') iscrucial to the discourse of information systems developmentbecause it depicts the distance and difference - and hence impen-etrability - of removed sets of social relationships.

ConclusionWe began with the puzzle that while the social and technical areregarded as quite separate domains, it comes as no surprise toanyone that what turns out to be technical can be described as athoroughly 'social' accomplishment. Accordingly, we set our-selves the task of examining the ways in which the social-techni-cal divide is managed in the specific arena of information systemsdevelopment.The general conclusion of this exercise is that 'technical', is adistinctive form of social accomplishment: it is a special accom-plishment of a private space; a restricted, perhaps even secret


20/24

JanetRacheland Steve Woolgar'technical' is what people in this company would claim as thatwhich avoids deconstruction. The key to this special persistenceof the technical lies in the ways in which discourse on the techni-cal manages the twin concepts of audience and social distance.We have seen that technical is used to connote a particular com-munity (the System's Team do technical work) and to apportionresponsibility and blame ('It's a technical problem' means some-one else has to fix it). Thus a sphere of action can be technicalfor one particular audience but not another. To tell someone thatthey can't be helped because theirs is a technical problem, is to'perform' their membership of a community which is distantfrom the relevant sphere of expertise (Cooper and Woolgar,1993b). At the same time, we see that the maintenance of socialdistance can be achieved through control of the future. TheChange Management Team lag behind the 'actual technical'work of the Project because their role is to service developmentalong a predefined course. They are, in other words, permanentlydistanced from the technical work because they have inferioraccess to what the future holds.

We thus come to an understanding of the discursive structureof the technical. Technical work is construed and displayed insuch a way that it acquires a robustness which defies deconstruc-tion. This is not just a result of the amount of conspicuousresources expended on technical work. The point is that suchexpenditure commits people to a course of action whereby theydisplay and reaffirm the separateness and distinctiveness of thetechnical from the human world which necessarily creates, main-tains,and uses it in all aspects of its existence.Brunei University Received 1 June 1993Accepted 7 October 1993

Notes1 Earlier versions of this paper were presented to a PICT (SPRU) conference on


21/24

The social-technical dividetaken by Janet Rachel, This produces some stylistic awkwardness for the pre-sent discussion which we have solved arbitrarily as follows, 'We' generallyrefers to the au thors of the paper, 'The observer/researcher' refers to JanetRachel , asdoes theoccasional T in excerpted field notes,

3 Although it turned out that 'Systems Team' was written as such within theCo mp an y , our early (nus?)apprehension, based on the frequent use of thisdes-ignation in oral discussion between participants, was that the term denoted asense in which team members belonged to theSystem: the 'System's Team ',Wehave found it useful to retain this latter version where our discussion empha-sises the issue of relations (in this case, ownership) between non-humans andhumans (cf Callon, 1986; Johnson, 1988;Law, 1986; Latour, 1990),

4 The contrasting idea that the technical referred to routine aspectsof work arosein relation to CA, a 'consulting' company largely comprising women, CAenjoyed a large presence in theCo mp an y , and were present in varying numberthroughout the Customer Project, Mostly they were engaged to write the com-puter programs after the design work had been completed. One of the SystemDesigners described this process as 'just a matter of taking the detailed designspecification and churning the technical handle,and out pop thep rograms ' . Itdoesnot matter that thisis not a descriptionof thepractice, which turnsout tobe a complicated process of interpreting documents, and then a long conversa-tion with the machine, which did notappear to boreany of the CApeople theresearcher met. The important point is that this version of technical could bemade to work alongside a much more complex version,

5 Theestablishment of these two domains also allowed theConsultant to createastructure which defined a 'partnership' between themselves and their client.There werenow two pools of 'expertise' over which control could be claimed.The Consultant maintains prime control over the Technical and allows theclient tocontrol the Functional ,

6 It is also possible to understand this split as a version of managing the differ-ence between ' theory' and 'practice' . The theory represents what theConsultants think a business should do, and the Practice represents what theClient thinks its business should do. From this perspective, the TechnicalFunctional divide manages the differences between discoursesof howbusinessesshould be organised.

eferen esBarry,J,A,,(1991), Technobabble, Cambridge, Mass, :MITPress,Bloomfield, B,P,,(1989), 'On speaking about computing' Sociology23 (3)409-426,Bloomfield, B,P, and Best,A,, (1992), 'Management consultants: systems develop-

ment, power and the translation of problems' The Sociological Review 40(3)532-560,


22/24


23/24

The social-technical divideSystems Design, London: Associated Business Press.

Orlikowski, W., (1990), 'Using Tools and Forging Reality: exploring the culturalimplications of systems development methodologies and tools' , draft paper,Sloan School, MIT.

Tr au th, E .M . and O'C onn or, B., (1991), 'A Study of the Interaction B etweenInformation, Technology and Society: An Illustration of Combined QualitativeResearch Methods' in Nissen, H-E, Klein, H.K. and Hirscheim R., InformationSystems Research: Contemporary Approaches and Emergent Traditions, N o r t hHolland: Elsevier.

Traweek, S., (1988), Beamtimes and Lifetimes: The World of High EnergyPhysicists, Harvard University Press.

Turkle, S., (1984), The Second Self Compu ters and the Huma n Spirit, New York :Simon and Schuster.

Woolgar, S., (1985), 'Why not a sociology of machines? - the case of artificialintelligence'. Sociology 19557-572.Woolgar, S., (1987), 'Rethinking Man and Machine: a note on sociological cri-

tiques of cognitivism', 311-328 in Bijker, W., Hughes, T. and Pinch, T., (eds).The Social C onstruction of Techno logical Systems: new directions in the sociol-ogy and history of technology, Cambridge, Mass. : MIT Press.

Woolgar, S., (1990), 'Time and documents in researcher interaction: Some waysof making out what is happening in experimental science' in Woolgar, S. andLynch, M., (eds). Representation in Scientific Practice, Mass: MIT Press.

Woolgar, S., (1991), 'Configuring the user ' CRICT Discussion Paper No. 19. Also57-102 in J. Law (ed.), A Sociology of Monsters: Essays on Power, Technologyand Domination, London: Routledge.

Woolgar, S., (1993), 'Rethinking requirements analysis: some implications ofrecent social science research into producer-consumer relationships in IT devel-opment' , 197-212 in M. Jirotka, J. Goguen and M. Bickerton, (eds).Requirements Engineering: Social and Technical Issues, London: AcademicPress.


24/24

The Sociological Review Volume 43 Issue 2 1995 [Doi 10.1111%2Fj.1467-954x.1995.Tb00603.x] Janet...

Documents

Transcript of The Sociological Review Volume 43 Issue 2 1995 [Doi 10.1111%2Fj.1467-954x.1995.Tb00603.x] Janet...