The Discursive Structure of The Social-Technical Divide: The Example of Information Systems Development

The discursive structure of the
social-technical divide: the example of

information systems development^
Janet Rachel and Steve Woolgar
Abstract
The social and technical are commonly defined in opposition to each
other. Yet technology practitioners are often quite comfortable with
the idea that the technical is constitutively social. Drawing on an
ethnographic 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 project
were met with a series of rebuffs. 'Technical' talk is to be understood
as a categorising device which does boundary work. Technical talk
invokes and performs a disjunction between networks of social rela-
tionships and stipulates a moral order with associated norms for
acceptance and transition.
The difficulty of penetrating the intelligibility of technical talk is
understandable as a struggle in familiarising oneself with the routine
social actions of a separate community. In addition, the private sphere
of 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 the
invocation of 'the technical'. These connote a notion of timing which
reinforces the distance and difference of - and hence depicts the costs
involved in penetrating - removed sets of social relationships.
Technical a. Appropriate or peculiar to, or characteristic of, a
particular art, science, profession, or occupation (OED).
Introduction
A good deal of the talking, writing, and thinking about systems
and software development is based on a distinction between the
social and the technical (Trauth and O'Connor, 1991; Kranzberg,
The Editorial Board of The Sociological Review 1995. Published by Blackwell Publishers,
108 Cowley Road, Oxford OX4 UF, UK and 238 Main Street, Cambridge, MA 02142, USA.
1989). This basic distinction is central to discussions of the
impact of technology on society (Marien, 1989), the technical
constraints on users (Orlikowski, 1990), how IT transforms social
relations (Bolter, 1989) and work (Dunlop and Kling, 1991), how
Users might become more involved with the design or implemen-
tation of a System (Mumford and Hensall, 1979), how to match
hardware capacity to users' needs and so on. The way in which
we deploy the distinction can also provide a marker of discipli-
nary affiliation, for example whether we are to be heard talking
as sociologists rather than, say, software engineers.
It is common practice to counterpose the social and technical
as a dichotomy, each term of which takes its sense in opposition
to (and exclusion of) the other. This tradition means that we
have 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 to
address issues usually reserved for a 'technical' discipline (or vice
versa), the boundary between the two is maintained. For exam-
ple, discussions of the organisational determinants of successful
technical development; the exercise of power during systems
development (Markus and Bjom-Anderson, 1987) and the power
effects of the introduction of systems into organisations (Dutton
and Kraemer, 1980; Kling, 1980) all reaffirm a distinction
between 'technical characteristics' of a system and its 'social
dimensions'. As Bloomfield and Best (1992) point out, these
arguments rest on the a priori separation of technical and social;
they do not consider the difference as part of the achievement of
systems development.
However, you would also probably regard it as commonplace
if we were simply to make the point that technical systems are
themselves thoroughly socially constructed. If we documented all
the arguments, discussions, and debates that occurred throughout
the development, implementation, and use of a system you may
well say 'but what did you expect?'. If we presented clear exam-
ples of the moments of compromise and choice, or detailed the
clever schemes devised to persuade Users to accept this instead of
that design feature, you might congratulate us on our painstaking
work, may even be pleased that we have taken the trouble to
document a practice that you have known all along to be the
case. But, in the end, what difference would it make? Just as it is
implicit that social is not technical, it is also implicit that it is.
This paper, then, will not simply try to overwhelm you with
252 The Editorial Board of The Sociological Review 1995
The social-technical divide
evidence of the thoroughly social nature of information systems
(IS) development. Instead, it will examine the use and currency of
this particular point of view. Our aim is to document the pres-
ence and absence of this point of view, to describe the occasions
when 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 technical
work is an unremarkable piece of common sense, that this is
something '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 the
way we couched our initial inquiry. We said we were impressed
that 'everyone already knew' that the technical (artefacts, techni-
cal work, technological knowledge) included elements of the
social. But who exactly is this 'everyone'? It is important to
reconceptualise the issue on a local scale: 'everyone' can denote
the relevant community one is addressing on any particular occa-
sion. In other words, the relevance of the social for the technical
will depend crucially on the particular audience being addressed,
and on the occasion of the address. More specifically, the claim
that the technical involves the social implicates particular sets of
social relationships between audience and speaker (cf Cooper and
Woolgar, 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 that
depictions of 'the technical' can implicate social relationships, in
order to make sense of experiences during participant observa-
tion of information systems development. It has been widely
noted that the way we speak about technical objects (and about
computers in particular) reflects some of our basic assumptions
about differences between man (sic) and machine (for example,
Barry, 1991; Bloomfield, 1989; Turkle, 1984; Woolgar, 1987). In
this study, we are interested in the ways that 'technical' suggests
differences 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.,
1983) connotes aspects of audience and social distance. Our sug-
gestion will be that the constitutive (technical) repertoire is not
merely a disengaged set of words and descriptions for application
to a state of affairs (actions, behaviour and so on). Rather, that
its usage is constitutive in the more profound sense of performing
The Editorial Board of The Sociological Review 1995 253
community: the social-technical divide is a means of defining, dis-
playing and reaffirming the social relationships which make up
that community (cf Cooper and Woolgar, 1993b). In other
words, references to and uses of 'technical' provide a discursive
structuring of the community involved in the development of an
information system. In sum, we shall tell of the importance of the
technical category to this community, how we came to under-
stand their definition of technical as a discursive device which
created a private space about which only specially designated
people could speak, or act within. Furthermore, we shall discuss
how this space could resist attribution of 'social' characteristics.
It was a space which played an important part in defining what
this community knew to be human, what it was to be social.
The paper is organised as follows. The second section, the
main section of the paper, reports some experiences of a sociolo-
gist undertaking participant observation of information systems
development. This section relates these experiences in terms of
the sociologist observer's quest for the technical: it reports the
trials and tribulations of the observer in her efforts 'to get closer'
to the technical. En route, she experiences situations where the
common sense is denied; where social and technical are taken to
be different things, mutually exclusive, and opposite in meaning;
where what is and is not technical are defined differently by dif-
ferent people. In short, this section presents some of the different
understandings about what constitutes technical aspects of infor-
mation systems development in one particular community. We
describe how the distinction between social and technical is main-
tained, under what circumstances it does and does not work, and
for whom the distinction is made. The third section of this paper
uses the observer's experiences to summarise the work required
to achieve and sustain a definition of technical. Finally, in the
fourth section of the paper, we conclude with a conceptualisation
of technical in terms of what it takes to convince the locals that a
thing is or is not technical.
Looking for the technical
Our data arise from an ethnographic study with a computerised
information systems development project in a recently privatised
(public) utility (henceforth Freshwater pic). The participant
observation phase of the study extended over an 18 month period
during the development of a range of computerised machinations
brought together under the umbrella term: the Customer
Information Systems (CIS) project, or 'The Customer Project'.
Four days a week, every week, the researcher could be found 'on
site'. She was to be found 'with the team' (but see below - which
team?!) offering a spare pair of hands in return for access to
study the ongoing concerns of the office.
The primary research technique was that of participant observa-
tion, as adapted from usage by recent anthropological and socio-
logical studies of technical organisations (for example,
Knorr-Cetina, 1981; Latour and Woolgar, 1986; Lynch, 1985;
Traweek 1988). An outsider, come as a stranger to the technical
environment, undertakes intensive in situ observations of the
day to day activities of information systems developers. In the tra-
dition of the anthropologist visiting an alien culture, the observer
immersed herself in the concerns and practices of her subjects.
During the early phase of the research, when the researcher
first began to visit the project site, she was given a clear indica-
tion of the importance of the social-technical distinction for the
community. When she asked to be placed within the technical
team in order to do social science research, a number of bound-
aries were raised to deflect this apparent contravention. These
events provide an initial opportunity to describe some of the fea-
tures of the taken for granted nature of what is and is not techni-
cal for this community.
In reporting our ethnographic data, we have followed best
anthropological practice by trying to convey as much as possible
of the observer's experiences and, in particular, of the importance
of certain categories of person and object for members of the
Company. For this reason, our descriptions of certain terms
(System, User, Company) are capitalised in this text, perhaps
somewhat unexpectedly, in order to retain (and convey) their
apparent significance for participants in the study.
Joining the team: a social study of the technical?
Five months before the field work began in earnest, a team of
researchers from Brunei University met the Director of
Management Systems to discuss the practicalities of carrying out
research in his division.^ He described the CIS project, which he
thought would be an ideal location for our research. This project,
he told us, comprises two parts: the Change Management Team
and the Systems Team. He suggested that we choose one of these
teams to join for the study. We chose the Systems Team.^
We had been offered the standard dichotomy, so we seized the
chance to locate the research at the 'heart' of the technical pole.
We are trying to avoid the kinds of 'fobbing ofP experienced by
other social scientists who set out to study science or technology.
For example, in a previous participant observation study of a
solid 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 a
scientist who ran the University's Gilbert and Sullivan society;
immediately told that a senior professor in another department
had 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, our
intrepid researcher repeated her chosen location to a row of
increasingly blank faces down through the hierarchy:
You're doing what? an anthropological study of Systems! How
does that work?
You want to look at the human dimensions, but you want to
join the Systems Team? Hmm!
You're interested in the people issues, right? Well, there's
plenty of oddballs round here.
The office manager was just baffled by the request to join the
Systems Team. 'You'll be bored' he said. But we kept plugging
on. Gradually, the Head of the Systems Team came round to the
idea that this was where we really wanted to be, and slowly he
began to think about the implications:
maybe you could join the training courses that we send our
new recruits on.
It looked like the tracks were in place for our research to roll
into the Systems Team. However, Team members were still
mightily baffled by the request and the Head of Change
Management was becoming offended by our apparent lack of
interest in her Team's work.
But all was not what it seemed. On the first day of the field
work, the researcher arrived at the office and found that the
Head of the Systems Team had been seconded to another pro-
ject. Grace, his deputy, was busy inducting new recruits into the
Systems Team. But Janet was not a 'new recruit'. The Head of
Change Management was off sick, and her deputy was out of the
office. Finally, the secretary suggested it might be a good idea to
tag on to the User Testing this morning.
Although you might expect User Testing to comprise technical
work, nothing about the testing that day bore out this expecta-
tion. For example. User Testing was carried out in the comer of
another office elsewhere in another building. It was run by a
Woman who had been seconded into the team as a User. Two of
the 'Users' doing the 'Testing' were large ladies who usually
answer telephone queries (with the help of computerised record
keeping systems) in the Customer Accounting office (their bodies,
clothes, and hairstyles, their demeanour and conversation were
all very different to the sharp dressed, slim, youngsters in the sys-
tems team).
A brief meeting with Grace over lunch revealed that the
Systems Team were 'all very busy now with the last phase of
development'. Janet was told that 'most of their work was techni-
cal', so perhaps she should instead join the Change Management
Team. She could help them with the Implementation Roll Out.
So that afternoon the researcher found herself part of the
Implementation Team, a sub-team of the Change Management
Team, with responsibility for preparing a handbook and presen-
tation material (complete with 60 overhead slides) to be delivered
to the outlying operational sites, the work of which was to be
changed with the advent of the new system. Despite our best
efforts, Janet had become a member of Change Management
rather than Systems. Thus, the first attempt to penetrate what we
imagined 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 that
Systems Development is separate from Change Management.
You become a member of either one, or the other. As the
research progressed, it became increasingly obvious that this
boundary between the 'Teams' was not easily overcome. In fact,
as we shall see, the boundary was refiected in patterns of all
kinds in all places.
Second, it was extremely difficult for anyone to join the
System's Team who has not already been configured to fit into its
highly defined organisational structure (cf Woolgar, 1991; 1993).
The difficulty extended beyond the rebuff just described. The
observer not only found it problematic to join 'as a spare pair of
hands' - as envisaged in the original research proposal. She
found it almost as difficult just to just walk into the System's
Team office space and talk.
Third, the assumption drawn upon to deal with a sociologist
who says she wants to study the human dimensions of systems
design, is that she must be interested in what some members of
the company referred to as 'people problems'. This category
seemed to refer to the personalities of members of different
groups, 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 form
proposed by the Systems Team. On this view, it was felt natural
that the observer would want to be with the Change Manage-
ment rather than the Systems Team, since the latter's concern
with the actual business of 'building' the system involved the
application of standard logic which could only be undertaken by
specially trained people.
Technical boredom and routine: how can I challenge this army?
Our observer thought she had discovered another sense of the
'technical' when she came across William. As a member of the
System's Team, he spent a good deal of his time yawning and sit-
ting slumped, staring into his computer screen. This was a fairly
common posture on the System's side of the room. A highly
structured 'case tool' lays out documents and work sequences for
him to follow and divides up his time into accountable chunks. It
all seemed to produce in him a defeated lethargy. The researcher
had been warned that life in the Systems Team would be boring.
At last. Had the observer finally reached a participant-validated
understanding of the technical? No! When the observer reported
the above interpretation back to William, she was dismayed to be
told she had got it wrong. The things she had described - the
overwhelmingly structured character of the work - were not tech-
nical. It is not the technical which is boring, he explained, it was
the routine. Where, then, is the technical? He answered:
technical is pissing about on the mainframe.
Aah. Hmm. EhT*
Technical talk as boundary work
Our observer decided to monitor the occurrence of the term
'technical'. Whenever the word was spoken, or appeared in Text,
this would be taken as a sign of what counted as technical in this
community. In talk it appeared on certain occasions, and with
specific reference points. For example, it turned up regularly in
blaming talk amongst members of the Change Management
Team. The structure of work in the overall project predicts that
the small Change Management Team was always running behind
the much larger Systems Team. The work of the Change
Management people was thus highly prefigured by earlier deci-
sions made by their 'team-mates' in Systems.
Members of the Change Management Team had to visit sites
where the System was going to operate, and tell the staff what
they must do to let it work. Sometimes these sessions became
heated. Sometimes someone would ask why they had to change
their practice to accommodate the system, why couldn't the sys-
tem be changed to fit them? The technical nature of the system
was then explained by the Implementation Team to show why
this could not be done. The gathered community at the imple-
mentation session were thus safe in the knowledge that the guy at
the front of the room was not responsible for this technical
arrangement.
On these occasions, members of Change Management found
their use of 'technical' eased tensions and provided a rationale
for their role as buffer (or sponge) between recipients of the sys-
tem and its designers. Their use of 'technical' offered a portrayal
of social relationships such that the ultimate responsibility for
impending organisational changes lay beyond their own control.
It was outside their sphere of blame. It is fairly simple to see
Change Management here as the last line of defence on the
boundary between technical and social where technical is the pro-
tected central space. The System Team was never exposed to the
same degree, they always seemed to have a series of protective
mechanisms in place.
The term 'technical' was also used by anyone in the office to
refer to the work of someone quite outside the project. For
example, when the Technical Architect talked about a technical
problem he couldn't solve, it turned out he was referring to the
problem of getting the printer to work with the Local Area
Network (LAN). His use of the term 'technical' in this context
signalled 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 BT
engineers bringing lines into various parts of the business for
phones and fax machines. Or he was talking about the failure of
another Company to provide all the necessary boxes and wires
and air conditioning to enable the computer terminals to work.
In short, this usage of technical usually denoted some kind of
failure or deficiency that lay outside the speaker's immediate
sphere of responsibility, and for which they themselves cannot be
blamed.
Job descriptions in the System's Team themselves embodied
and displayed a distinction between technical knowledge and
business experience. The Consultants had brought the main
organising principles for the development of the information sys-
tem (the Case Tool), and they stipulated which specific phases
within the development of the system were to be referred to as
Technical Design. As well as organising the office into Systems
and Change Management, they also divided responsibilities
within the System Team between Functional Architecture and
Technical Architecture. One of the System Team members
explained 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 to
argue that their technical design did not dictate the shape of the
system to the client organisation.^ This was said to be an impor-
tant advantage of engaging this particular consultant. It also
reinforced the distinction: Technical was to be understood as the
Core, the underlying logic, whereas Functional denoted the task
of 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
work. Distinctions between the Technical and Functional architec-
ture articulated in the company's methodology, and the technical
and social forces articulated in academic debates, draw on the same
moral order. The implication is that, underneath it all, beyond the
boundary, there is a uniform logic, an objective best way. This in
turn supports the idea that Real Life (that is, when Humans are
involved) 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 around
to living their hves (at work, at least) without all this messy variety
that is so difficult to control. . . .
The boundary constituted in virtue of reference to (and desig-
nation of) the 'technical' thus suggests a disjunction in networks
of social relationships, a break between those outside and those
within. The suggestion is rhetorical in the sense that it does not,
of course, prevent the physical traverse of the divide. Rather, it
stipulates a moral order: the ways in which behaviour should
occur. Crossing the boundary, getting inside the technical,
requires the itinerant ethnographer (and anyone else who wishes
to effect the transition) to relate to different entities and to relate
to them in different ways. Thus, although it is relatively easy to
come in, sit down at a keyboard and start pressing keys, the
competent display of 'pissing about of the mainframe' requires
an altogether longer apprenticeship. The invocation of 'technical'
is thus an invocation of a different community. Participation in
this different community is said to have all kinds of attraction
including, as we saw in the last example above, the promise of
leaving 'messiness' behind.
Amongst the technical architects
Chasing the most technical.
The ever present, yet illusive category of 'technical' continued to
attract the researcher. She became convinced that if she didn't
track it down somewhere and write about it, she couldn't claim
to be doing good research. So, she decided to stalk it around the
office until she found it. She began asking people directly, where
she should situate herself to do her research if she wanted to see
technical work being done. To some, this was straightforward.
One of the System's Team, defining himself as a Designer, said:
It's the coding, yeah, you need to go to see CA [the consul-
tants contracted to code the programmes].
A Senior Manager from the Dominant Consultant (DC)
Company advised:
You need to be with John, Chuck and Charlie as they do User
Requirements.
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 package
Methodology. John, Chuck and Charlie were working with sev-
eral Company nominated employees, known in the Systems
Team as Users. They were trying to reach agreement on a docu-
ment which would be required to stand as the Scope for the
System when it 'moves forward into production'. When our
researcher turned up at John's desk and explained why she was
there, he said:
You want to look at the technical stuff? You really need to be
with Maheer and his team.
Maheer is also a young consultant from Washington DC. He and
his team, are known as the Technical Architects for the DC
System. 'What is it about their work that makes it technical?',
asked the naive researcher.
Oh, well, they do all the technical architecture. They figure the
security levels and stuff like that, controlling who can access
which parts of the system
Others were more hesitant in response to the researcher's ques-
tioning. Sometimes the answer began: 'Well, it depends what you
mean by technical'. Aha. So the researcher asked 'How would
you define the different types of technical then?' Felicity, a
Company employee working in the Systems Team, volunteered
the following reply:
Well, I suppose, to Change Management, everything that goes
on inside this [the Systems] team is technical. But I see Julie's
work as the most Technical. You see. Change Management
only use computers on the surface. They use it as a word
processor. But Julie really uses it, she works through the
computer. You know, she goes through and makes other
things work inside it. That's technical.
You see, Gary and his team [that is, the Change Management
Team] write their procedures, but nobody really uses them.
When Julie writes her program it matters, something happens.
The machine does something.
There's a big gap between Systems and Users. People like
Gary should be working to bridge that gap. People don't
always follow instructions, they misread the procedures, or
decide to do something different. But the machine always
follows exactly, you know it will do what you say. Unless there
are any bugs, of course.
Our researcher wondered whether there was in fact as large a gap
as Felicity claimed. On the one hand, Julie writes detailed proce-
dures which the machine will follow; on the other, Gary writes
more general procedures which people can manipulate. These
activities did not appear very different. Well, said Felicity, if you
don't like my definition, try Roy:
OK, it depends what you mean by technical. But I guess it's the
people who look after the database. Yeah, Roy, people like that.
Both Roy (the database manager) and Maheer (the Technical
Architect), independently maintained that if we really wanted to
see the social shaping of the technical, then we should go see the
Designers. These are the people who set out what the System will
do and how to do it. Roy said: 'We only take their ideas and
make it happen'.
The researcher began to feel she was experiencing a receding
horizon, 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.30
pm), one of the Designers called the researcher over, and said:
Hey, Janet, I've been thinking about you. You should get
yourself into this if you want to see the social bits of the
technical.
Duncan was working on 'PC20s'. This was the name of a doc-
ument form, set out in the CASE tool. Each PC20 was supposed
to represent a 'Function' that Users wanted to see in the new
package. There were hundreds of these PC20s. Once all PC20s
were complete, they would be added to a matrix, which would
then be 'fed through some mathematical algorithm' which would
specify how much time and effort was required to achieve it.
Another designer, Adam, remarked that he had already
'selected out' some of the Functions which it 'would have been
good to have' because he judged that they could not possibly be
achieved by the deadline fixed in the contract between the DC
and the Company. He emphasised the point:
Some of the things that we [Freshwater] want aren't even
making it into the matrix. I'm not putting them in, because I
don't think they can be done!
Duncan was defining technical work which could as easily be
described as senior level strategic decision making. While work-
ing through his categorising algorithm he was eliminating func-
tions that another committee of company representatives had
decided they wanted in the final computer system. At this point,
Michael, who is standing nearby, joined in the conversation and
described the problems he was having with the Coders (people
who 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 matter
of 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 matter
of 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 writing
PC20s, and in the next breath was using the word 'technical' to
refer to mere routine rule following (turning the technical handle
to produce programs from program specifications). Michael did
not dispute this latter representation even though he had spent
all afternoon struggling to explain the spec(ification) to one of
the programmers. This was the kind of work which disappeared
from view behind the phrase 'just turning the technical handle'.
Technical dreaming: the future in the present.
Another DC Consultant suggested I attend a brainstorming
meeting if I wanted to find the technical aspects. The meeting
commenced when he took up position next to the Flip Chart,
uncapped a pen, and began what turned out to be two hours of
dreaming. We (the technical architects, functional architect, data-
base manager and consultant) were to conjure up visions of a
future, and try to define the kinds of machinery needed in order
to drive (not support, nor enable, but drive) this vision into a
reality. The dream revolved around the certainty of a paperless
office, where Users would need neither to move away from their
workstation, nor to refer to paper, nor ask another person.
Instead they would be able to consult a Geographic Information
System (GIS) which would hold full details of all properties,
streets, water mains, and sewerage plans within the entire domain
of the company.
Participants were urged to free themselves to dream of a per-
fect future, from which technical imperatives could then be
drawn: that is, how many machines of what kind would need to
be purchased to make the dream come true, and what other soft-
ware would have to be written. On the basis of the musings of
these young men, a potential investment plan was being drafted
which would have major consequences for the working patterns
of many future Freshwater employees. It seemed curiously appro-
priate that these young men knew virtually nothing about the
operations of other parts of Freshwater. Their ignorance and
lack of experience was apparently their qualification to dream of
the company's future.
Complete unintelligibility: technical as a foreign language.
Just before this last meeting began, there had been some very
animated talk between the technical architects and the database
manager. This gave our researcher her first real sense of achieve-
ment. At last! Real uninhibited technical talk! She could smell
the technicalities bubbling away. Luckily, she had turned up
early to the meeting, and had brazenly switched on the tape
recorder there and then. This produced a temporary halt in the
talk, a joke at her expense, but then the happy continuation of
what must be, we are sure you will agree dear reader, beyond
doubt, real, technical talk. Here is an excerpt:
CONl You know the list of Contact Retrieval, Work Request
Retrieval,
DBM Yes
CONl Why do they need to be so dynamic? Why does it need
to select the data on the way back up
((pause))
DBM On the way back up
CONl You know, when you PF7 it selects the data again,
does it in reverse sequence. All this complex logic in
there to say that you've selected 12 rows on the way
down, and when you go and, and you say, you hit
PF7, you've selected nearly 13 rows ( ) it doesn't need
to be that dynamic.
DBM Not especially
CONl I was saying to [CON2]. It's slowing the system down
so much having that functionality in there and I can't
see the benefit, the cost is enormous, and the benefit is
just . . .
((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 at
the moment is when we select the information we select
it and we go away and get the first page of informa-
tion, hit PF8, and go away and get the second page of
information from the data base, and when they hit PF7
we go away to the data base again and get the first
page of information again from the data base but in
reverse sequence and if there was 12 rows the first time
we displayed this and then there was only now say 11
or there's 13 the second time. We've got a different
screen. Hell of a different. I can't see that the benefits
is 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. She
really 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
to it several times, struggled to transcribe it, and examined the
transcript several times, the researcher had the strange sensation
that maybe she was beginning to understand what was being
said. Only after all this, in other words, did the talk start no
longer to seem so 'technical'.
Why did the transcription seem such hard work? The superficial
explanation is that the transcriber had to listen hard to make out
unfamiliar (technical) words. As conversational analysts have
shown us, however, parties to the interaction are not attending to
the 'meaning' of the words themselves, so much as to the social
actions being performed by their co-conversationalists. (All kinds
of 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 to
make sense of the interaction. (What action was DBM performing
in first replying to CONl in the way she did?). The process of lis-
tening, transcribing and trying to 'make sense' of the conversation
is thus a process of trying to figure out what kinds of social
action are taking place in this foreign environment. (Was that
utterance a snub, a rejection or what?). Coming to an understand-
ing of the talk is thus not just a translation of inherently difficult
words. It is a process of familiarising oneself with what passes as
social interaction within this particular set of social relationships.
As the transcriber became more familiar (literally, if you will, as
she 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 direct
refiection of the costs involved in penetrating an alien network of
social relationships.
Producing the technical: creating private space in time
One of the most striking things about the work done by the
System's team is that it is done so far in advance. Friedman and
Comford (1989) talk about 'a general problem in the computing
literature of advancing the clock' which they refer to as the 'prob-
lem of tenses'. Time was differentially manipulated by the two
teams comprising the Customer Project. The work of the System's
Team was scheduled to be done in advance of the Change
Management Team: the technical work had to be done in advance
of the system implementation. We have already described how the
Technical Architects were encouraged to dream of the future and
imagine a world contained within computers. This dream was
then to be used as the basis of their planning strategy. There are,
of course, other aspects to attend to, like persuading key senior
managers to endorse the plans and make budgets available, but
for present purposes, we want to dwell on the simplicity of differ-
entiating time. We were able to watch the effects of this process
slowly unravel during the course of Out Of Hours design.
A small sub-team within the System's Team has been working
on Release 2 of the Contact Logging System which they called
Out Of Hours (OOH). In December 1990, one of the men, calling
himself a Design Analyst, visited various parts of the business,
interviewed a number of key managers about the current practice
of 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, and
to work out 'entities' and data elements. Quiet discussions were
held with the DataBase manager and the Technical Architect at
casual 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 to
begin their own process of interviews and designs. By this time
the Systems Team were firmly established along the path laid
out in the pre-structured methodology. As they were entering a
time phase they called Technical Design, the Change
Management Team were just beginning to get a feel for the size
of 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 and
interview again, to find out what else must be done (what proce-
dures should be written, what training given, what practices
changed, what new forms to be designed, what new Radio
System to be developed, how many new voda-phones should be
bought . . .) to allow the system to work. The Change
Management Team were charged with creating the new world
into which the computer system can gracefully slide, dignity and
integrity intact. In her field notes, the observer succinctly
recorded her reaction to this state of affairs:
it is a constant source of amazement to me that the Change
Management Team put up with this kind of crap.
We have already described how Change Management absorb
much of the aggravation caused by the new system during imple-
mentation, and how they counter appeals to change by invoking
the technical limits within which they are working. What now
becomes clear is that 'technical' reasons for not changing are also
timing reasons. It is now too late, in general, for the comments
of 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 be
part of a vision of unending progress? One answer arises from an
extension of our understanding of the boundary work in techni-
cal talk. We have likened the effort required in negotiating this
boundary to the work needed to travel to, and understand, a for-
eign culture; 'technical' is a reflection of the costs involved in
penetrating an alien network of social relationships. But the past,
as they say, is (also) another country. In other words, there are
costs involved in journeying in time which are directly analogous
to the costs in penetrating alien ('technical') cultures. Perhaps the
costs are even greater when the journey is forward in time: the
future is another country as yet unknown, except by a few (usu-
ally highly paid) experts (often called Visionaries or Gurus). To
put the point another way, timing (or the 'problem of tenses') is
crucial to the discourse of information systems development
because it depicts the distance and difference - and hence impen-
etrability - of removed sets of social relationships.
Conclusion
We began with the puzzle that while the social and technical are
regarded as quite separate domains, it comes as no surprise to
anyone that what turns out to be technical can be described as a
thoroughly '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 systems
development.
The general conclusion of this exercise is that 'technical', is a
distinctive form of social accomplishment: it is a special accom-
plishment of a private space; a restricted, perhaps even secret
space. For the actors in our research, this space was important in
establishing control over the Project, which in turn played a part
in distributing rewards for the 'success' of the project.
This space not only avoids intrusion by unconfigured entities,
but also slips away from attribution of social characteristics. A
special feature of this space is its persistence. In other words
The Editorial Board of The Sociological Review 1995
269
'technical' is what people in this company would claim as that
which avoids deconstruction. The key to this special persistence
of 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 apportion
responsibility and blame ('It's a technical problem' means some-
one else has to fix it). Thus a sphere of action can be technical
for one particular audience but not another. To tell someone that
they can't be helped because theirs is a technical problem, is to
'perform' their membership of a community which is distant
from the relevant sphere of expertise (Cooper and Woolgar,
1993b). At the same time, we see that the maintenance of social
distance can be achieved through control of the future. The
Change Management Team lag behind the 'actual technical'
work of the Project because their role is to service development
along a predefined course. They are, in other words, permanently
distanced from the technical work because they have inferior
access to what the future holds.
We thus come to an understanding of the discursive structure
of the technical. Technical work is construed and displayed in
such a way that it acquires a robustness which defies deconstruc-
tion. This is not just a result of the amount of conspicuous
resources expended on technical work. The point is that such
expenditure commits people to a course of action whereby they
display and reaffirm the separateness and distinctiveness of the
technical from the human world which necessarily creates, main-
tains, and uses it in all aspects of its existence.
Brunei University Received 1 June 1993
Accepted 7 October 1993
Notes
1 Earlier versions of this paper were presented to a PICT (SPRU) conference on
Software and Policy, Brighton, 18-19 July 1991 and to the 13th Discourse
Analysis Workshop, University of Exeter, 18-19 September, 1991. Thanks to
participants at these meetings for their comments and especially to Geoff
Cooper and Paul Quintas. The research reported here was supported by SERC
grant no. GR/H23917: Human Factors in Information Systems Development.
2 The research team from Brunei University comprised Pat Hall, Janet Rachel
and Steve Woolgar. The participant observation part of the study was under
taken by Janet Rachel, This produces some stylistic awkwardness for the pre-
sent discussion which we have solved arbitrarily as follows, 'We' generally
refers to the authors of the paper, 'The observer/researcher' refers to Janet
Rachel, as does the occasional T in excerpted field notes,
3 Although it turned out that 'Systems Team' was written as such within the
Company, our early (nus?)apprehension, based on the frequent use of this des-
ignation in oral discussion between participants, was that the term denoted a
sense in which team members belonged to the System: the 'System's Team', We
have found it useful to retain this latter version where our discussion empha-
sises the issue of relations (in this case, ownership) between non-humans and
humans (cf Callon, 1986; Johnson, 1988; Law, 1986; Latour, 1990),
4 The contrasting idea that the technical referred to routine aspects of work arose
in relation to CA, a 'consulting' company largely comprising women, CA
enjoyed a large presence in the Company, and were present in varying number
throughout the Customer Project, Mostly they were engaged to write the com-
puter programs after the design work had been completed. One of the System
Designers described this process as 'just a matter of taking the detailed design
specification and churning the technical handle, and out pop the programs'. It
does not matter that this is not a description of the practice, which turns out to
be a complicated process of interpreting documents, and then a long conversa-
tion with the machine, which did not appear to bore any of the CA people the
researcher met. The important point is that this version of technical could be
made to work alongside a much more complex version,
5 The establishment of these two domains also allowed the Consultant to create a
structure which defined a 'partnership' between themselves and their client.
There were now two pools of 'expertise' over which control could be claimed.
The Consultant maintains prime control over the Technical and allows the
client to control 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 the
Consultants think a business should do, and the Practice represents what the
Client thinks its business should do. From this perspective, the Technical
Functional divide manages the differences between discourses of how businesses
should be organised.
References
Barry, J,A,, (1991), Technobabble, Cambridge, Mass,: MIT Press,
Bloomfield, B,P,, (1989), 'On speaking about computing' Sociology 23 (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,
Bolter, J,D,, (1989), 'The Computer as Defining Technology' in Forester (ed,).
Computers in the Human Context: Information Technology, Productivity and
People, Cambridge, Mass: MIT Press,
Callon, M, (1986), 'Some elements of a sociology of translation: Domestication of
the scallops and the fishermen of St Brieuc Bay', in Law (ed,) Power, Action,
and Belief: A New Sociology of Knowledge, London: Routledge and Kegan
Paul, 196-233,
Collins, H.M. and Pinch, T.J., (1979), 'The construction of the paranormal: noth-
ing unscientific is happening' 237-270 in R. Wallis (ed.). On the Margins of
Science: the social construction of rejected knowledge. Sociological Review
Monograph, No. 27, University of Keele.
Collins, H.M. and Pinch, T.J., (1982), Frames of Meaning: the social construction
of extraordinary science, London: Routledge and Kegan Paul.
Cooper, G. and Woolgar, S., (1993a), 'Software is society made malleable: the
importance of conceptions of audience in software and research practice', PICT
Policy Research Paper 25, November.
Cooper, G. and Woolgar, S., (1993b), 'Software quality as community perfor-
mance' in R. Mansell (ed.). Information, Control and Technical Change,
London: Aslib.
Dunlop, C. and Kling, R., (1991), 'Computerization and the Transformation of
Work' in Dunlop and Kling (eds). Computerization and Controversy: Value
Conflicts and Social Choices, Academic Press Inc.
Dutton, W. and Kraemer, K., (1980), 'The automation of bias: computers and
local government budgeting' Society 17 (2).
Friedman, A.L. with Comford, D.S., (1989), Computer Systems Development: his-
tory, organisation and implementation. New York: John Wiley.
Johnson, J., (1988), 'Mixing Humans and Nonhumans Together: The Sociology
of a Door-Closer' Social Problems 35 (3) 298-310 June.
Kling, R., (1980), 'Social analyses of computing: theoretical perspectives in recent
empirical research', ACM Computer Surveys 12 (1), 61-110.
Knorr-Cetina, Karen D., (1981), The Manufacture of Knowledge: An Essay on the
Constructivist and Contextual Nature of Science, Oxford: Pergammon.
Kranzberg, M., (1989), 'The Information Age' in Forester, T., (ed.). Computers in
the Human Context: Information Technology, Productivity and People,
Cambridge, Mass: MIT Press.
Latour, Bruno, (1990), 'Postmodern? No, Simply Amodem! Steps towards an
anthropology of science' Studies in History Philosophy and Science, V21 Nl ,
145-171.
Latour, B. and Woolgar, S., (1986 [1979]), Laboratory Life: the construction of
scientific facts, 2nd edition, Princeton: Princeton University Press.
Law, J. (1986), 'On the Methods of Long Distance Control: vessels, navigation
and the Portuguese route to India', 234-263 in Law J. (ed.). Power, Action and
Belief: a New Sociology of Knowledge?,T\K Sociological Review Monograph 32,
London: Routledge.
Lynch, M., (1985), Art and Artifact in Laboratory Science: a study of shop work
and shop talk in a research laboratory, London: Routledge and Kegan Paul.
Marien, M., (1989), 'IT: You ain't Seen Nothing Yet' in Forester T. (ed.).
Computers in the Human Context: Information Technology, Productivity and
People, Cambridge, Mass: MIT Press.
Markus, M.L. and Bjom-Andersen, N., (1987), 'Power over users: its exercise by
systems professionals'. Communications of the ACM 30, (6) 498-504.
Moerman, M., (1965), ' Who are the Lue?' American Anthropologist, v67
1215-60.
Mulkay, M., Potter, J. and Yearley, S., (1983), 'Why an analysis of scientific dis-
course is needed' 171-203 in K.D. Knorr-Cetina and M. Mulkay, (eds). Science
Observed: Perspectives on the Social Study of Science, London: Sage.
Mumford, E. and Hensall, D., (1979), A Participative Approach to Computer
111
The Editorial Board of The Sociological Review 1995
Systems Design, London: Associated Business Press.
Orlikowski, W., (1990), 'Using Tools and Forging Reality: exploring the cultural
implications of systems development methodologies and tools', draft paper,
Sloan School, MIT.
Trauth, E.M. and O'Connor, B., (1991), 'A Study of the Interaction Between
Information, Technology and Society: An Illustration of Combined Qualitative
Research Methods' in Nissen, H-E, Klein, H.K. and Hirscheim R., Information
Systems Research: Contemporary Approaches and Emergent Traditions, North
Holland: Elsevier.
Traweek, S., (1988), Beamtimes and Lifetimes: The World of High Energy
Physicists, Harvard University Press.
Turkle, S., (1984), The Second Self Computers and the Human Spirit, New York:
Simon and Schuster.
Woolgar, S., (1985), 'Why not a sociology of machines? - the case of artificial
intelligence'. Sociology 19 557-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 Construction of Technological 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 ways
of making out what is happening in experimental science' in Woolgar, S. and
Lynch, M., (eds). Representation in Scientific Practice, Mass: MIT Press.
Woolgar, S., (1991), 'Configuring the user' CRICT Discussion Paper No. 19. Also
57-102 in J. Law (ed.), A Sociology of Monsters: Essays on Power, Technology
and Domination, London: Routledge.
Woolgar, S., (1993), 'Rethinking requirements analysis: some implications of
recent 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: Academic
Press.

The Discursive Structure of The Social-Technical Divide: The Example of Information Systems Development

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

The Discursive Structure of The Social-Technical Divide: The Example of Information Systems Development

Uploaded by

Copyright:

Available Formats

The discursive structure of the

social-technical divide: the example of

You might also like