Applying Organizational Routines in Analyzing Organizations:
Methodological Issues and Analytical Contributions
Markus C. Becker, Pasquale Salvatore & Francesco Zirpoli
Abstract
The concept of organizational routines was introduced to help understand organizational
behavior and organizational change (Nelson & Winter, 1982; March & Simon, 1958; Cyert &
March, 1963). Previous studies that have applied organizational routines as analytical
perspective to understand these issues, however, have shown the task is not trivial. Many
seem sceptical of the contribution an analysis employing organizational routines can make.
While much has been written on organizational routines, empirical research employing
organizational routines as analytical perspective is still at a relatively early stage.
Accordingly, methodological questions still create stumbling blocks in applying the concept
of organizational routines. We are convinced such problems are directly responsible for the
limited analytical potential of organizational routines that has been realized so far.
The objective of this article is to advance and strengthen organizational routines as analytical
perspective for understanding organizational behavior and organizational change. In order to
do so, the article tackles two questions: (1) How to apply organizational routines as analytical
perspective so they make a contribution to understanding organizational behavior? (2) What is
the contribution that organizational routines as analytical perspective can make to explaining
organizational behavior and organizational change? We develop answers to these two
questions by applying organizational routines as analytical perspective in analyzing the
product development process at an engineering center.
Keywords: Organizational routines
1
Applying Organizational Routines in Analyzing Organizations:
Methodological Issues and Analytical Contributions
Markus C. Becker, Pasquale Salvatore & Francesco Zirpoli
1. Introduction
From the beginning, one of the key motivations in introducing the concept of organizational
routines was to help understand organizational behavior and organizational change (Simon,
1947; March & Simon, 1958; Cyert & March, 1963; Nelson & Winter, 1982). More recently,
organizational routines have also been proposed as analytical perspective for analyzing how
work is carried out in organizations (Hutchins, 1991; Pentland, 1995; Orlikowski, 2000;
Barley and Kunda, 2001; Pentland, 2003a; 2003b), including the their performance
implications, and to capture how organizations change the way in which they carry out their
tasks (Feldman, 2000; Feldman & Pentland, 2003; cf. Winter & Szulanski 2001; Zollo &
Winter 2002). Previous empirical studies that have applied organizational routines as
analytical perspective to understand these issues, however, have shown the task is not trivial
(Cohen and Bacdayan 1994; Pentland and Rueter 1994; Knott and McKelvey 1999;
Edmondson, Bohmer and Pisano 2001; Feldman 2000, 2003; Narduzzo, Rocco and Warglien
2000; Szulanski and Winter 2002; Winter and Szulanski 2001). Many seem sceptical of the
contribution an analysis employing organizational routines can make.
While much has been written on organizational routines, empirical research employing
organizational routines as analytical perspective is still at a relatively early stage.
Accordingly, a number of methodological questions are still open, creating stumbling blocks
2
in applying the concept of organizational routines. We are convinced that partly unsolved
methodological problems are directly responsible for the limited analytical potential of
organizational routines that has been realized so far.
The objective of this article is to advance and strengthen organizational routines as analytical
perspective for understanding organizational behavior and organizational change. In order to
do so, it tackles two questions: (1) How to apply organizational routines as analytical
perspective so they make a contribution to understanding organizational behavior and
organizational change? (2) What is the contribution that organizational routines as analytical
perspective can make to explaining organizational behavior and organizational change?
The paper is structured as follows: It first briefly introduces the notion of organizational
routines. Section three responds to the first research question, identifying practical problems
in carrying out an analysis by using organizational routines as analytical perspective. The case
study is presented in section four. Section five develops the contribution of organizational
routines in explaining organizational behavior and organizational change, thus answering to
the second research question of this article. Section six presents discussion and conclusions.
2. Choosing a definition of organizational routines
The first issue to be faced in applying organizational routines as an analytical perspective, is
to select one of the several available definitions of organizational routines. Three different
definitions can be found in the literature: as (i) behavior patterns (recurrent interaction
patterns), as (ii) rules (standard operating procedures, rules of thumb, etc.), or as (iii)
collective dispositions.
3
(i) Currently, most scholars think of organizational routines as repeated behavior
patterns (see Becker 2004 for a review of the literature on organizational routines). By now, it
has also become standard practice to use the term ‘routines’ for collective (multi-person), and
the term ‘habits’ for individual (single-person) behavior patterns (Dosi, Nelson & Winter,
2000). The term ‘recurrent interaction patterns’ thus provides a more precise term for
organizational routines understood as behavioral regularities.
(ii) Understanding organizational routines as rules (standard operating procedures), on
the other hand, captures a different phenomenon. At least implicitly, the idea is that rules
(standard operating procedures) give rise to recurrent interaction patterns. (Note that rules do
not, however, specify the causal mechanism, i.e. how precisely they evoke recurrent patterns
of behavior. As Feldman and Pentland (2003) have recently argued, at least the role of human
agency in rule-following would need to be considered, and probably also the governance
system that provides incentives and constraints for applying rules.)
(iii) Some recent articles argue that organizational routines should be understood as
collective dispositions to engage in previously adopted or acquired behavior, triggered by an
appropriate stimulus or context (Hodgson & Knudsen, 2004; Hodgson & Knudsen, 2003).
Rather than patterns of behavior itself, routines are ‘stored behavioral capacities or
capabilities. These capacities involve knowledge and memory. They involve organisational
structures and individual habits which, when triggered, lead to sequential behaviors’
(Hodgson & Knudsen, 2003: 9). Routines are therefore repertoires of potential behavior that
can be triggered (Hodgson, 2004: 652).
Faced with this three-way split of current definitions of organizational routines, we choose a
definition of organizational routines guided by our interest in understanding organizational
behavior and organizational change. Recurrent interaction patterns describe the organization’s
behavior. They also describe the processes as they are implemented – and it is the processes
4
that directly generate performance implications (Penrose, 1959). Moreover, a description of
the processes as they are implemented will enable identifying organizational change, the first
step towards understanding it. For these reasons, we decided to focus on ‘recurrent interaction
patterns’ and used those as analytical perspective.
3. Practical problems in applying the concept of organizational routines
Having chosen a definition of organizational routines, the next step is to describe the
processes observed in terms of recurrent interaction patterns. As it turns out, however, that is
not at all a trivial exercise. A number of practical questions arise, that have an impact on what
a description using recurrent interaction patterns as analytical perspective will capture. These
questions therefore represent stumbling blocks for the empirical analysis, dampening the
analytical power of the concept of organizational routines. We now turn to examining each of
these questions, thus making a methodological contribution that hopefully should smooth the
road for other scholars.
3.1 Choosing the process to be analyzed
By now, it is commonly accepted that organizational routines are collective, not individual
phenomena (Dosi, Nelson & Winter, 2000). The distinction is important because it
distinguishes two ontologically different phenomena.1 In carrying out an empirical analysis,
the distinction helps to narrow the focus of analysis down to the more interesting processes to
be observed. It also helps to steer clear of blending different phenomena together, which
1 These can sometimes be linked. For instance, collective routines are often seen as consisting of individual-level building blocks (a conversation between two persons, for instance, invokes individual habits of forming sounds with the mouth, and sentences according to the grammar of a particular language).
5
usually creates problems in interpreting data. It eliminates processes not directly relevant to
the analysis2, a problem if one spans the net of recurrent behavior patterns too wide.
However, even having narrowed down the recurrent behavior patterns to collective behavior
patterns, many different kinds of such patterns can be observed. Some are more relevant for
the research question at hand, others less.3 What criterion tells us which collective behavior
patterns to focus on and which ones to discard? At this point, we want to argue that the
answer lies in taking the term ‘organizational routine’ serious.4 The term ‘organizational’ in
‘orgaizational routines’ so far seems to have been strangely neglected, or at least, been
lumped together with ‘collective’. If the term ‘organizational’ has any meaning, however, it
should help us distinguish subsets of collective behavior patterns.5 If it cannot help us do that,
we should probably wonder whether the meaning of the term ‘organizational’ is just
equivalent to ‘collective’. So, what constitutes the ‘organizational’ character of a collective
behavior pattern?
We develop an answer to this question based on the distinction between tasks and the way in
which they are carried out (cf. Becker, forthcoming), which builds on literature on the
organization of work.6 The behavioral level of an organizational routine (as distinguished
from the level of rules or dispositions) can then be understood as recurrent interaction patterns
2 For instance, individual recurrent behavior such as Mr. X drinking coffee at his desk at 9.00 every morning. 3 To take an extreme example, if two employees have the habit of drinking coffee, each at his desk , at 9 a.m. and of stepping into the bathroom an hour later, they might regularly bump into each other there and exchange a few words. Although that is a recurrent interaction pattern, it is probably not a terribly interesting one for understanding how the organization accomplishes its tasks and how that changes. 4 In this context it is noteworthy that one of the key foundational contributions (cited, e.g., by Simon, 1947) introduced the concept of routines not only in an organizational context, but also used the term ‘organization routine’ (Stene, 1940). There is therefore a historical basis for the attribute ‘organizational’. 5 Not all collective behaviour patterns are organizational. For instance, think of a couple of people queuing at a bus stop, then boarding the bus. They interact (for instance, in attempting to get into the bus before the others, blocking the door somewhat), and they might do so more or less every time. But it is difficult to see anything ‘organizational’ in that, other than the fact that multiple persons are involved, they interact, and the interaction is somewhat structured – maybe in a rather chaotic way. 6 Other possible candidates for how to define the organizational recurrent behaviour patterns would be, for instance, that these take place inside an organization, with the participation of an organization, have an ‘organizational’ character, etc.
6
that accomplishes a task of the organization. Accordingly, we shift the level that carries the
attribute ‘organizational’ from the level of behavior patterns to the level of tasks. What, then,
makes a task organizational? One of the fundamental tasks of organizations, we argue, is to
deal with interdependencies (Thompson, 1967). Organizations enable specialization. In so
doing, however, they also create the necessity to coordinate interdependencies between
specialized organizational units. To coordinate interdependencies is thus a fundamental task
of every organization. Organizational tasks, therefore, are tasks that deal with
interdependencies. Recurrent behavior patterns that are organizational, therefore, are such
recurrent behavior patterns that implement and carry out tasks that deal with
interdependencies.
There are different kinds of interdependencies between tasks, however. Accordingly, some
will merit the attribute ‘organizational’ more than others. As is well known, Thompson (1967)
distinguishes generic, sequential, and reciprocal interdependence. Generic is the weakest
form, referring to interdependence between, say, the marketing and purchasing departments in
a firm. Interdependence between them is weak, as the performance of one has very little direct
influence on the performance of the other. It does, however, apply because because both are
part of the same firm. Sequential interdependence refers to an input-output relation, where the
output of one is the input of someone else and direct implications therefore exist, usually in
the form of knock-on effects. The strongest type of interdependence, however, is reciprocal
interdependence. Here, the outcome of a process depends on both parties (such as in
teamwork, negotiations, etc.). Based on the argument that a fundamental trait of organizations
is to deal with interdependence, and that by picking the strongest type of interdependence one
captures the most important class of interdependence, we decided not to observe tasks whose
interdependence is just generic. If there is no interdependence in the task that a particular
activity carries out, according to the above argument, such a task is not of highly
7
organizational character. We therefore selected processes that implemented tasks, which are
subject to sequential or reciprocal interdependence. In pragmatic terms, picking these kind of
tasks seems to go a good way towards capturing organizational, not just collective recurrent
behavior patterns.
3.2 Processes implementing technical and organizational tasks
In our empirical study, we studied a design center in the automobile industry. Many tasks
accomplished there are technical tasks, such as designing auto components, running
calculations to check tolerances etc. In a pilot run, we considered a couple of tasks as
candidates of object of analysis, according to the criterion of a reciprocally interdependent
task that implements an objective of the organization. Those tasks, however, were quite
different from those implemented by routines as often described in the empirical literature.
Upon reflection, many empirical studies of routines have predominantly studied processes
that solved problems of organization (as opposed to technical problems), such as hiring
routines, answering calls, etc. (Feldman 2000, 2003, Pentland & Rueter 1994; Pentland
2003b). Problems such as hiring staff or answering questions on the phone are predominantly
questions of organization – what to say, who should say it, how etc. Designing a suspension
or a bridge is a very different task.7 It solves technical problems, such as how to keep a car
even-level on a rugged surface, or how to span a valley. The issues here are not so much what
to say and how to say it, but applying a (more or less codified) body of knowledge in
particular ways in order to arrive at a (codified) design. The technical tasks whose
accomplishment we observed not only differed in several ways from those many other
empirical studies describe; these differences also created at least one methodological problem:
7 More dimensions in which tasks that solve problems of organizing and technical problems could be identified. For instance, they differ with regard to competences (more technical, social), visibility, possibility to be creative etc.
8
Judging from our case, technical tasks seem much more difficult to observe than tasks of
organizing. To observe a technical task, technical competence on part of the observer is
required. If one observes a reasonably small (chunk of a) process, a considerable degree of
specialization is likely to be involved. In order to be able to know what exactly is going on, an
observer very soon might need considerable technical competence just in order to be able to
follow and describe the processes observed. For instance, what does it mean when someone
punches numbers into a spreadsheet? Technical competence is required8 in order to know
what the particular calculation does, whether it has been carried out correctly, and so on.9
A second difference between technical problems and problems of organizing is that for
technical problems, the complexity of the procedure appears to be negatively correlated with
the possibilities that actors have to diverge from the technical standard operating procedure.
Technical processes (such as how to carry out a particular calculation) are often very strongly
structured, path-dependent and intertwined. Changing the structure, the sequence, or
substituting elements of the procedure often simply means one will not get a result. For
instance, by running through the standard procedure in calculating the strain on a particular
part of a bridge, one knows one will get a result that will allow constructing a bridge of
sufficient stability. Inventing a new calculation procedure, one might not arrive at the result at
all. The matter is further aggravated by the fact that often, technical processes involve tightly
intertwined inputs, resulting in even greater difficulty in changing (parts of) the process. This
adds further evidence that observing organizational tasks is not only more feasible but also
more relevant to organizational studies.
8 One of the authors is a mechanical engineer by training and thus had the required technical competence. 9 The argument might also apply to what is observed: because engineers are usually more competent in technical skills than organizational skills, they might well be less aware (sensibilized) to organizational processes and organizational aspects intertwined with technical processes. For this reason, they might attach less weight to organizational aspects than, making it more difficult to ‘uncover’ those in interviews.
9
3.3 How large a chunk of the process to observe (‘Grain size’)
Most processes in organizations can be decomposed into steps and sub-processes, which can
be decomposed in turn. We here meet the problem of determining the level of granularity. As
Pentland (1995: 552) writes, it involves a difficulty that should not be underestimated. The
problem is how to make sure one does not take a chunk too large (a process too much
‘macro’) or too small (a process too much ‘micro’) to be useful for analysis. In the first case,
the problem is complexity, leading to problems in the analysis. In the second, that one might
have isolated the ‘smallest’ elements of the process (such as pressing individual keys on the
keyboard of a computer), but at the cost of losing the context, depriving the description of
much of its meaning.10 Once more, the criterion ‘reciprocal interdependence’ is useful in this
context, too. It seems appropriate to select a ‘grain size’ of a level at which there is some
meaningful reciprocal interdependence. If the ‘grain size’ is too small, there might not be any
interdependence. If it is too big, then the interdependence is probably not any more reciprocal,
but just generic interdependence.
3.4 Period of observation
To identify recurrent behaviour patterns as actually realized, one obviously needs to observe
recurrence. If a short period of observation is chosen, one might only observe one iteration of
a particular process, resulting in doubt on whether the process is recurrent or one-off. The
problem of choosing the length of the period of observation can be dealt with pragmatically
by selecting a core task of the organization, where ‘core’ means directly linked to the
organizational objectives (see discussion in section 3.1). Rare exceptions apart, the core tasks
of the organization should be rather recurrent. Additional practical indicators of core tasks can
10 The example of punching numbers into a keyboard and knowing which calculation is carried out and whether it is carried out correctly is a case in point.
10
help guide researchers to selecting such tasks. For instance, core tasks often command an
important budget and important resources are devoted to it.
4. The case study
4.1 Methodology
Section 3 has already dealt with many methodological questions related to organizational
routines. One more consideration that relates to our case study, however, has to be added at
this point. As described above, there are several definitions of organizational routines.
Notably, the two most commonly used definitions are routines-as-rules (standard operating
procedures) and routines-as-behaviour (recurrent interaction patterns), referring to two
different ontological levels. Feldman and Pentland have recently proposed a framework that
sets them in relation to each other, with persons (agency) holding the key (Feldman &
Pentland, 2003). They describe the ostensive level of a routine (how it is described), and its
performative level (how it is implemented), and how agents contribute to transforming
organizational routines slowly by adapting the performative to the ostensive and vice versa.
What concerns us here is that both levels of analysis are required because, as Feldman and
Pentland (2003) argue, their interplay matters. For this reason, the methodologies chosen need
to include both document and archival studies (standard operating procedures) and
observation (to identify the recurrent interaction patterns).
As far as the data gathering method is concerned, the consideration of process-related,
historical, and contextual features and the need to explore ill-defined and sensitive issues in
depth called for longitudinal research by means of a case study. The nature of the research
questions made the choice of the exploratory case study method the most appropriate
(Eisenhardt, 1989, Pettigrew, 1990, Yin, 1994).
11
The empirical material presented in this paper was collected at a European research centre
specialized in automobile design. It was established as a “green field” research centre close to
plant of a major European car maker in 1988, and today employs around 750 employees,
mostly engineers. The research centre is organised on the basis of seven functions: Engines,
Vehicle, Technologies (production processes), ICT (information and communication
technologies), Control Systems, Mobility and Road Safety, and Product Development
Methodologies. Our field study involved employees responsible for the development of the
vehicle engineering (in particular all the mechanical systems except for the style). The major
client of the Research Centre has recently confided the development of a whole car model to
the research centre, a novelty due to the fact that earlier, the research centre would only
provide much ‘smaller’ inputs to the car manufacturer.
Three data collection methods were used. The first was the study of archival sources. About
2000 pages of company official documents (norms and procedures) were analyzed. The
second, has been based on extensive semi structured interviews. More than 60 hours of
interviews were carried out by the authors individually and in various combinations, both to
explore and to get a deeper understanding of particular issues. Interviews involved the head of
the vehicle department; head of project management for vehicle department; vehicle
development function manager; head of human resources; chief engineer of “packaging”; one
“packaging” team leader; three “packaging” team members; head of “project SUV”. Finally,
one of us spent 8 months working at the research centre. During this time, he regularly took
part in meetings, participated in some of the tasks, provided support, and so on.
In order to increase the consistency of our data, we decided to focus our interviews and direct
observations on one project. For confidentiality reasons we cannot use the real acronym of the
12
project and name it “project SUV”. The project was the most important one the research
centre was carrying out at the moment of observation.
The methodology has been defined in order to observe the same units of analyses from
different angles. This confirmed the reliability of the data in those instances in which they
were consistent and induced a new round of interviews when inconsistent. The comparison of
quantitative and qualitative data, and the fact that managers from different departments and
functions were interviewed according to the same unit of analysis made triangulation possible
and extremely effective. In addition to the intrinsic limitations of case study research (Miles
and Huberman, 1994), the sample could be partially biased by the fact that only one project
has been observed. This could represent a limit to the generalizability of the findings despite
the fact managers interviewed confirmed us that the project was highly representative.
4.2 The task selected for observation: packaging
In accordance with the criteria for selecting processes as presented above, we choose a task
characterized by reciprocal interdependencies and closely linked to the organization’s
objectives. After a preliminary phase in which a number of such tasks were considered, we
picked a task called ‘packaging’. In the course of a new product development project,
packaging refers to checking whether individual components actually fit together when
assembled in their final positions. Imagine all the elements that an engine is made of, and
checking whether it actually fits in the precise space there will be under the hood (see figure
1).
13
Figure 1: Example of virtual packaging
In the packaging check, particular attention is on such things as minimal distances between
components, which will avoid them touching each other at high speed or on rugged surfaces,
resulting in noise and possibly damage of components. Packaging therefore contributes, in a
major way, to a core objective of the organization and its product development activity – to
assure a high quality standard of the product. Packaging also qualifies as a core task, its
purpose being to eradicate sources of product failure, which can generate negative customer
reactions of very high impact (recall of car models from the market). The budget devoted to
the activity of packaging makes up 5/10 % of the overall budget of the development of a new
car model at this engineering centre, making it one of the most costly activity in the course of
the development of the car model. Twenty employees are dedicated to the activity of
packaging on a permanent and full-time basis, constituting a team of an important dimension.
Moreover, packaging is an on-going activity during almost the whole development project.
Packaging check results are, in fact, important inputs into several stages in the new product
development process. In many instances, a green light from packaging is a necessary
condition in order to move into the next phase of the development process. Packaging is
therefore an essential part of the development process.
14
Our selection of this process as an adequate object of observation was confirmed by the firm’s
management, who agreed that the task of packaging is a typical activity of the engineering
centre and is tightly linked to its objectives. The packaging task, most importantly, is a task
built up to manage the reciprocal interdependencies that exists in complex products
development. Single component development teams, in order to design the product leveraging
on concurrent engineering need to align and fine tune their development work through many
gates (checks). In particular, the kinds of checks that are run in packaging can be summed up
as follows:
• Checks of project objectives
• Checks of absence of static and cinematic interferences, compliance with minimum
distances
• Functional and esthetical checks
• Checks on safety, and ease of maintainance
• Ergonomic checks and checks of manufacturing ergonomy
• Checks of manufacturability
Figure 2 shows how development teams are involved by the packaging teams and divided in
packaging for mechanics (engine, suspensions, etc.) and packaging for the chassis. For both
mechanics and chassis packaging activities two kind of checks have to be performed: virtual
checks and physical checks. In virtual checks, the individual components are described by
CAD/CAM files stored in the Product Data Management system (PDM). These files are then
set in interaction by software that simulates their interaction (Digital Mock-Up, DMU).
Virtual checks serve to check the feasibility and coherence of the designs early on in the
design process, either substituting for physical checks or complementing them. Note that the
virtual prototype (Digitial Mock-Up, DMU) constitutes, over most of the development
project, the reference point and the object on which development efforts focus. Physical
15
checks are usually carried out at late stages of the process. They involve physical prototypes.
In what follows we refer to activities carried out via DMU for the packaging of mechanics.
Figure 2: Who is involved in packaging and how packaging is structured
4.4 The standard operating procedures for packaging – how the packaging task is
supposed to be carried out
Packaging activities are described in a very comprehensive and detailed way by a whole set of
‘procedures’ (which in this firm refer to how to organize tasks) and ‘norms’ (setting
technological standards, such as cut-off values). Amongst others, the following selection of
‘procedures’ and ‘norms’ are pertinent to packaging:
16
‘Norm on the product development process’
‘Procedure of vehicle packaging’
‘Procedure on virtual checks via DMU’
‘Check-lists of virtual check via DMU: chassis, mechanics, manufacturability,
ergonomics’
‘Procecure on use of knowledge management system and use of CAD in the product
development process’
‘Norm on the lay-out of drive-train and engine’
The list could be continued but illustrates that packaging is a highly ‘regulated’ activity in the
sense that some very comprehensive and very precise instructions exist for how to carry out
packaging. Some of the ‘procedures’ and ‘norms’ have close to 100 pages.
At this point, a brief overview of the packaging process will help to get an idea (a detailed
description follows below). The ‘raw material’ for the packaging calculations (we focus on
virtual packaging checks) are the CAD files of all the components that the car is decomposed
into. These components are developed by development engineers, which are grouped in 26
teams (as are the components), chassis, drive-train, steering, etc. (see figure 2). The CAD files
they work on are kept in a database that is called product data management system (PDM).
Designing components often takes many months, considering adaptations required to
accommodate changes in other components. It is an on-going activity. Packaging is carried
out by the packaging team, which consists of 20 employees that do nothing else than
packaging. Once a packaging activity is triggered, they transfer the files that correspond to the
components they are checking to another computer system (and file format), and use a DMU
(Digital Mock-Up) virtual simulation software to run calculations that simulate interaction
between the components to one can check what are the effects in the various dimensions
(ergonomy etc.). The output of this activity for all the performances listed above
17
(manufacturability, space limits, etc.) is a list of anomalies. The list of anomalies specifies all
instances in which the requirements were not met.11 One member of the packaging team then
filters this list for anomalies that do not create practical problems or whose cause is known to
have already been taken care of. A meeting between all the heads of the different engineering
units (engine, interiors, etc.) is then called to discuss the remaining anomalies. The anomalies
list provides the base of the coordination between the packaging team and the engineers who
are the ‘owners’ of the problem (i.e., the component that exhibits anomalies). The anomalies
are also registered in the log-book, the official document used by the development platform in
order to keep track of the evolution of the project, record and monitor the resolution of the
anomalies and the technical solutions adopted, and to be able to discuss potential
modifications of the objectives of the development project with the client.
The packaging activity follows a cycle with a regular rhythm, described in the written
procedures. The procedures prescribe fortnightly cycles of checks for most components (some
follow weekly cycles; in this paper, the object we follow was subjected to bi-weekly cycles)
(Figure 3).
Bi-weekly virtual verification cycles
11 For every check to be carried out, there are lists of technical norms (cut-off values such as minimum distances) as well as technical procedures for how to run the checks.
Day 1 of month Day 15 of month
~15 days (10 working days)
Virtual verfication nalysis and compilation of list of anomalies
Discussion of list of anomalies within the packaging team;
Registration of anomalies in log book and notification of team leaders
concerned
Evaluation of anomaly by responsible for the system
Discussion of anomalies in fortnightly meetings and division of
actions to be taken
~15 days (10 working days)
4 days
1 day NEXT LOOP
1 day
Discussion of feedback; generate updated parts and
official release 3
days1 day
18
Figure 3: Flow chart of virtual check cycles
4.5 The recurrent interaction patterns of packaging – how the packaging task is carried
out
In this section, we first describe how the task is supposed to be carried out according to the
procedures and norms, and subsequently, how it is carried out in practice. The description
below follows the eight-step structure of packaging as described in the procedures. In order to
bring out the contrast between the ostensive and performative level of the packaging activity
more clearly, for any step, we first present the ostensive level (as in the procedures), then the
performative level (the process as realized according to our observations).
First step: releasing the CAD files for use by the packaging team
The procedures and norms prescribe that each engineer responsible for a component should
release his or her CAD files periodically (for most components the rhythm is a fortnight).
There are 26 teams of engineers (see figure Y), whose teams leaders are responsible for
making sure their team-members release the CAD files on time. Typically, the delivery
deadline is set a day or two before the virtual check is run (some transformation of the data
has to take place, as the CAD system and the system used for the virtual checks are different
and files have to transferred into another format).
In reality, updated CAD files are often not delivered on time. This triggers a quite intense
activity, on part of the packaging team, of reminding engineers to release their files. The
formal measures to be taken in case updated CAD files are not released to the packaging team
on time are two-fold, depending on the cause of the delay. In case of hardware or software
problems, often the cause of delays, the problem is addressed by IT people (neither the
engineers nor the packaging people are much involved). In case the reason for a delayed
19
release is related to delays in the engineers’ activities, no particular action is taken. No
authorization for not releasing the updated files is required. Not even a communication of the
late release or lack of release needs to be made. Such obligations lacking, the practice that can
be observed regularly is to release the updated CAD files late or not at all without
communicating that fact, accompanied by an intense reminder activity on part of the
packaging team (with often mixed success).
Second step: Creating a reference base of files for the packaging software
The second step consists in creating a homogenous reference (in terms of the state of the
design) for purposes of the packaging check. To do so, (i) a point of time of reference has to
be defined, with regard to which the designs of all components will be compared. The CAD
files of all components are then (ii) transformed into files in the format of the packaging
software, which results – in simple terms – in a ‘snap shot’ of the whole vehicle at that point
of time. Packaging check calculations will be run on this ‘object’. According to the
procedures and norms, the person in charge of packaging should, after the point of time fixed
as reference, download the CAD files from the product data management (PDM) system
(where all CAD files are kept centrally). He or she identifies the CAD files that correspond to
the components of the vehicle (there might be more than one file per component, and several
components to realize an assembly), then uploads them into the DMU software. The
procedures also contain a back-up procedure for the case of late release. In this case, an
override folder has to be created. By default, the system then automatically downloads all
CAD files, picking the last available version previous to the point of time of reference.
In reality, as a consequence of late delivery of updated CAD files as described in the first step
(i.e., only ‘old’ files are available in the product data management system, which were already
used for the last cycle of the packaging check), the process in step two already diverges from
the process as described in the procedure. Moreover, however, more divergences build up in
20
step two: Ignoring the procedure on the override folder, the override folder is not created,
either. In fact, in our interviews with members of the packaging team, every single one we
interviewed told us he or she had never used it, some even saying they had not even heard of
such a thing. Rather, the packaging check is just run with the last available files (as identified
automatically by the system). At the same time, the packaging team attempts, by way of
informal communication with the engineering teams, to assess how serious the omissions and
their consequences are (and whether the overall packaging check might be feasible without).
This step of the packaging process has a second aspect to it, too. There are two ways in which
members of the packaging team can go about starting the packaging calculus. The direct way
is by transforming the CAD files into packaging software format, and saving them in the
product data management system (PDM). The result is the same data in two formats in the
PDM system. The packaging software then calls up the files in the PDM system. The indirect
way is by transforming the CAD files into packaging software format, and saving them in the
packaging system (VisMockUp), not the PDM system. Both ways are described in the
procedures. The direct way, however, provides a higher degree of control of the process
because the packaging calculus, run on the central server, leaves a record on the system that
can be useful. In practice, however, due to unstable IT performance, the packaging team
prefers using the indirect way.
Third step: Release of override folder
The procedures prescribe the release of the override folder, and communicating to the head of
packaging that it has been created. In practice, as the override folder is not created in the
preceding step, it can obviously neither be released nor announced.
Fourth step: Selection of the individual files to be used in the packaging calculus
21
In the fourth step the type of version of the product to be checked is selected (for example the
type of engine). Its correct execution is closely linked to the execution of the second step.
Fifth step: Uploading the files into the packaging software
At this point, there are two possibilities. Either the files that are required for a particular
packaging calculus can be uploaded in the packaging system, or all files for the whole vehicle
can be uploaded. In the procedures, this option is indicated as best practice for virtual
packaging checks. It is also what happens in practice. Obviously, as opposed to the partial
upload, the demands on IT resources are heavier.
Sixth step: Running the packaging calculus and generation of its output
The calculus itself is run by the software. Having run through the preparation described in the
previous steps, the action demanded from members of the packaging team at this point is just
to start the calculation. The member of the packaging team can choose between three
modalities of running this session: interferences and anomalies of one (group of)
component(s) against one, one against all, all against all. The norm on virtual packaging
suggests utilizing almost exclusively the modality ‘all against all’. This is precisely what we
observed in practice, too: no gap between ostensive and performative was observed. The
output generated by the software is a list of anomalies.
Seventh step: Analysis of anomalies identified
The output of the analysis is a list of anomalies which, as described above, can be very long.
In analyzing it, packaging team members therefore use filters. The norm on virtual packaging
suggests filtering the results according to type, status and result. In practice, we observed that
packaging team members filtered by sorting the column ‘result’, sorting by decreasing
criticality. Going through this list from the top, he or she then confronts each potential
anomaly (the list gives a kind of ‘theoretical’ anomaly, indicating where limit values have
22
been crossed) with a checklist contained in one of the norms in order to determine whether the
anomaly is likely to be only of minor impact (for instance, a minimum distance could not be
kept, but the two parts are supposed to touch each other). For each line of the table, the result
of this check is recorded. It is here that a very small difference between the procedures and
practice can be noted. Employees do not usually note ‘p’ (positive) or ‘n’ (negative) outcomes
of this confrontation with the checklist, but only mark the cases that are problematic.
Eighth step: Following up on the relevant anomalies
For those anomalies that are considered relevant according to the check in the previous step,
the packaging team staff needs to individuate the components responsible for the anomaly
(remember there are always several components involved in producing an anomaly, but the
cause could be one of them, such as a part that has an uneven surface and rubs against another
one, causing damage). Once identified the component that caused the anomaly, the
responsible engineer is identified. Those anomalies that can not be attributed to one
component or one responsible are assigned to the team leader of packaging who then resolves
the identification of who is responsible. Furthermore, the packaging team member compiles
an anomaly record, in which the anomaly is described. Record of the anomaly is also taken in
the project log-book, and a link to the anomaly record is created in the log-book. The
responsible is then notified by way of an email with the complete log-book attached, which he
or she can filter to see the lines that concern him or her. At this point, a slight divergence from
the procedures can be noted. The procedures prescribe a notification of the responsible in the
official record of the vehicle platform. Rather, only the email is sent, leaving less on record.
The effect is that organizational memory is weakened.
Ninth step: Reporting on packaging
23
This step consists in compiling indicators on the packaging activity, anomalies found etc. This
phase is usually not carried out completely.
5. The contribution of organizational routines in explaining organizational behavior
and organizational change
Section 3 has dealt with the first research question addressed in this paper, how to apply
organizational routines as analytical perspective so they make a contribution to understanding
organizational behavior and organizational change. The present section addresses the second
research question: ‘What is the contribution that organizational routines as analytical
perspective can make to explaining organizational behavior and organizational change?’
Analyzing the organizational behaviour of the engineering centre by using organizational
routines as analytical perspective has allowed us do a number of things:
(a) Capture how tasks are actually carried out in practice. The concept of routines-as-
behavior, or more precisely, recurrent interaction patterns, was useful for capturing and
describing organizational behavior. Moreover, the recurrent interaction patterns also capture
how tasks are usually carried out. They capture precisely what characterizes the firm (for
instance, how precisely assembly on a production line takes place, in practice, at Ford and at
Toyota characterizes the ‘Ford way’ or ‘Toyota way’ of producing cars). Organizational
routines as analytical perspective – more specifically, their behavioural aspect of ‘recurrent
interaction patterns’ – thus contribution a sharp and focused descriptive device. The power of
this device is to make visible what before remained invisible to managers. In the packaging
process, for instance, management was largely unaware of the lack of a systematic record of
which tests had been carried out on the list of anomalies (step 7). Management simply did not
24
know these practices even occurred (or did not), the consequence being that it only noticed
the effects, but without then being able to identify what caused them.
(b) Identify the ‘governance gap’ by contrasting how tasks are actually carried out in practice
with how they should be carried out according to the standard operating procedures. Once a
description of how tasks are actually carried out in practice is available, it can be compared
with how these tasks should be carried out according to the standard operating procedures.
The gap that will systematically appear between these two levels can thus be described. Being
able to describe the gap between the ostensive level of organizational routines (routines-as-
rules, standard operating procedures, norms) and their performative level (routines-as-
behaviour, recurrent interaction patterns) prepares the ground for designing governance
mechanisms that can address it. A powerful description of organizational behaviour clearly
boosts the possibilities for designing interventions of organizational change and
organizational development that improve the governance structures that govern organizational
behaviour. In the packaging task, we identified significant gaps in case of the release of CAD
files late (step 1), what the packaging team used its time on (increasingly, running to convince
engineers to release their files) (step 1), and the (lacking) use of the override folder (step 2).
25
Organizational routine
Figure 4: Gap between performative and ostensive level of organizational routines
(c) Identify the performance effects of the recurrent interaction patterns, and of the
‘governance gap’. Providing a description of recurrent interaction patterns, and identifying
the governance gap provides the possibility to understand the drivers of particular positive or
negative performance effects and link these effects back to their causes). In packaging, for
instance, the benefits realized from concurrent engineering are to a considerable extent
determined by the release of the CAD files, and whether they happen on time for all 26
engineering teams.
The gap in step 1 has the most significant consequences for performance of the packaging
task: due to a lack of monitoring instruments and of the requirement to communicate lacking
or delayed release, behaviours result that remain hidden or ‘invisible’ to management (which
relies on summary indicators or results to follow the process). Moreover, the process is
structured in such a way that it becomes the responsibility of the packaging team leader not
only to chase the CAD files, but also to identify the cause of the delayed release. This
structure confers a hidden de facto power onto the engineers who design components, as their
(non-)compliance with the release deadline has immense organizational consequences. If one
Processes (performative
level) Performance
Norms and procedures
Agents
interpretation
Goals Coordination mechanisms (ostensive
level)
IT systems
26
or more of the 26 engineering teams do not release their CAD files on time (maybe even after
postponing the deadline of the virtual packaging by some hours or days), the effects are the
following:
• The packaging check as a whole has a much lesser significance, as it is based only in
part on the latest version of all the components. In the extreme, it is close to useless or
already outdated, as the design teams that have not released their latest set of files will
most likely have changed the designs over the past two weeks.
• The teams who did not release their files (on time) will work for another two weeks
without feedback on whether their designs interfere with any of the other components,
or show any other anomalies. If that should be the result of a later packaging check,
time will be lost, and it will be much more costly to reverse the design changes made
in the meantime. Furthermore, there is a risk that anomalies have ‘increased’ in the
meantime and might now require changes also on part of other design teams.
• There are important effects on employees as well: tensions between the engineering
teams and the packaging team, distraction of resources and time of the packaging
team, danger of de-legitimation of the packaging check’s results, and the risk of
demotivation of the packaging team.
The gap between ostensive and performative levels in this step has serious consequences
because of the importance of running packaging checks (their lack might cause serious quality
problems, for instance), and because of the multiplicator effect of errors and deficiencies over
the following iterations of the packaging check. In our case, there is not even a mechanism to
know how many CAD files were not released on time, which aggravates the problem. This
factor alone could seriously dampen the benefits of concurrent engineering.
Step 2 also creates significant performance effects: Not creating an override folder has severe
consequences: it substantially reduces the capability to control the process in real time, the
27
capability of monitoring it over the whole life of the project, as well as the capability to
reconstruct it later and recall it from organizational memory to learn from earlier experience.
Without the override folder, it is difficult to know on what basis the packaging was carried out
(which files were updated and which ones were not). All these details remain invisible to
management because they lack profound and detailed knowledge on how tasks are carried out
in practice (including informal variations on the official procedures, which are tolerated and
have stabilized). Because packaging team members spend time communicating informally
with engineering team members to convince them to release the latest version rather than use
the override folder, the workload shifts to informal communication that is less powerful in
terms of organizational memory, remedying problems, and lead time. It also involves higher
resource requirements, an increased exposition to potential sources of error, and possibly an
increase in the number of anomalies that are identified by the packaging check (some might
already have been taken care of in the meantime).
In step 6, in consequence of choosing to check interferences in ‘all-against-all’ mode, in
combination with the choice of uploading the complete files describing the vehicle (step 5),
the calculus becomes very time- and resource-consuming. It also produces a very long list of
interferences and anomalies. The effect on the analysis of the anomalies is negative, as more
attention on part of the packaging team is required to go through the list, increasing the rate of
error in assessing it.
(d) Identify potential causes of (the shape of) recurrent interaction patterns, and of the
‘governance gap’. In the preceding paragraph we have argued that a description of the
recurrent interaction patterns and the gap to standard operating procedures help identify
performance effects, and also to identify the causes of particular performance effects. In the
packaging process, the analysis of step 2 identifies some causes for why employees chose to
28
create direct, rather than indirect VisMockUp session for running the packaging calculations.
The transfer of all CAD files into the packaging software takes a long time because the
network is somewhat slow for such purposes. If there are problems, the workstations have to
be rebooted, which takes even more time. Furthermore, a software bug on the server does not
allow recalling checks that were run in the direct mode. Similarly, in step 5, uploading all files
into the packaging system, rather than just the files needed for the check to be run, enables
running checks for things were not planned at the outset, without leaving the active session
and starting a new one (which requires starting again from step one).
(e) Generate governance solutions to improve the performance outcome of organizational
processes. In a corporate context, the ultimate goal of analyzing processes is to improve their
performance in accordance with corporate objectives. Performance being the object of
management efforts, performance indicators have a crucial role for manager’s efforts to
govern the firm and the processes carried out inside the firm. A key question, however, is how
directly the performance indicators used are linked to the processes, in which performance is
generated.12 For instance, turnover, pre-tax profits, or lead time for developing a new car
model are performance measures that sum up the influences of many factors. In order to take
corrective action, they need to be decomposed into performance indicators that can be
immediately linked to organizational processes that generated them. In fact, the case shows
that a set of indicators focused on milestones, cost, and quality, for instance, are limited in
their capacity to help managers improve performance. Neither does it help management make
choices on governance mechanisms. Ideally, one would want to identify what detail in how a
task is carried out impacts on performance (such as using a tool in a particular way, timing,
etc.). Then, governance mechanisms can be designed that address these performance drivers
directly. The analysis of organizational routines helps precisely to identify performance 12 Such processes are the part the firm can actively influence; of course there are also exogenous influences such as customers, competitors and regulators that cannot be influenced directly by a firm’s managers.
29
indicators that are directly linked to the performance drivers of particular processes. Thereby,
such an analysis provides managers with the key to designing corrective actions, on a level of
detail that usually remains largely hidden from their view. In the packaging case, we have
identified some such processes, which also had very important performance implications.
The packaging case also provides an illustration of how an analysis of organizational routines
enables understanding performance effects. Let us take the gap between standard operating
procedures and recurrent interaction patterns in step 1. Not releasing CAD files on time has
grave impacts on several dimensions: reduced significance of the packaging checks as a
whole, negative impact on the development activity as a whole (the engineering teams will
work without feedback on potential interferences in the subsequent two-week period), and
risk of demotivation of those engineering teams that have released their CAD files on time).
The analysis of packaging by using organizational routines as analytical perspective has also
allowed to propose concrete corrective measure management should take, such as
constructing an indicator that measures the number of late releases, by type of file and team;
monitoring this indicator closely; drawing conclusions based on this indicator, regarding the
resources allocated to the teams, the behaviour they expose, their interrelations with other
teams; introducing a system of sanctions, also utilizing the same indicators.
In summary, applying organizational routines as analytical perspective in analyzing how the
engineering centre carries out the virtual packaging task has been very helpful in uncovering
important details that would otherwise have been largely hidden to management. This has
enabled contrasting how tasks are carried out in practice with how they should be carried out.
On the basis of the ‘governance gap’ analysis, performance effects could be linked to their
causes. The examples are very rich, and clearly illustrate how organizational routines as
analytical perspective identify concrete performance drivers, which summary measures often
30
do not provide. This analysis thus provides concrete levers for designing corrective measures
that directly attack the problem and enable implementing focused change by designing
interventions that directly address the drivers of performance effects. In the example of
packaging, our analysis was received positively by management, which was convinced of the
analysis and its conclusions13. Thanks to the ‘governance gap’ analysis and the possibility of
linking performance outcomes to their concrete causes, we were able to generate simulations
of the outcomes of different set-ups of one step or another in the packaging process. The
recommendations developed in our analysis are currently being implemented. The packaging
case therefore demonstrates, rather convincingly, the usefulness of organizational routines as
analytical perspective in analyzing organizational behaviour and in providing a basis for
designing governance structures that allow guiding organizational change and organizational
development.
6. Conceptual insights from an empirical application of the concept - Discussion and
conclusion
Limits to an analysis of organizational behavior by analyzing recurrent interaction patterns
Analyzing the packaging activity by applying organizational routines as analytical perspective
– along the choices made – clearly was useful for identifying the sources of inefficiencies in
packaging. By describing the ‘governance gap’ between the ostensive and performative levels
of the packaging routine, the exercise also provided a basis on which to design governance
mechanisms that can address the cause of inefficiencies, in order to improve the outcome of
the packaging process.
13 Perhaps most surprising of all, senior managers were also convinced of using organizational routines as analytical perspective, too.
31
As mentioned, the board of directors we presented to was convinced of the analysis and
decided to implement its conclusions. The CEO, however, also presented us with the
question: ‘How do I know whether I can generalize these insights to other processes in my
firm?’ The question actually brings to the fore a limit of the analysis of organizational
routines if they are understood as recurrent interaction patterns (and considered alongside
standard operating procedures). While it provides insight on the particular task analyzed,
generalizing such insight will, however, be difficult. After all, the causes of inefficiencies
identified in such an analysis are quite particular details, such as choosing to upload all files
rather than only the ones required, to convert files into another format on one system rather
than another, and so on. Even where a large number of processes have been analyzed, this
difficulty will not go away. For a different phase of the product development process, say,
concept development, very different details might turn out to matter. Even collecting many
such insights for a very large number of tasks therefore does not seem to easily build up to a
more general conclusion. Any generalization would be made on the basis of intuition, be
somewhat arbitrary and ad hoc unless based on a theoretical fundament.
The very practical question the CEO put us therefore captures not only a crucial issue for the
usefulness of the organizational routines concept in empirical research. It also brings a
substantial conceptual issue to the fore: Does the limited generalizability of results of an
empirical analysis of organizational routines – interpreted as recurrent interaction patterns,
following current practice in the literature – mean the concept provides nothing but a
‘magnifying glass’ for analyzing business processes, even though it is appealing in theory?
Are organizational routines doomed to become mere tools of analyzing business processes?
This possibility indeed appears to loom large – with the understanding of organizational
routines as recurrent interaction patterns, that is. Upon reflection, the problem behind the
32
question of the generalizability14 of insights from an empirical analysis that uses recurrent
interaction patterns as analytical perspective is the theoretical framework that provides the
base on which to generalize. For generalizing about behavior and the expression it takes, it is
necessary to reach the level of causes of behavior that is exhibited. Recurrent interaction
patterns obviously describe behavior that is exhibited, and therefore cannot also describe its
causes at the same time. In the context of analyzing organizational behavior, interpreting
organizational routines as behavior, or more precisely, as recurrent interaction patterns, is
therefore subject to limits. The insights gained by such an analysis are highly idiosyncratic.
In our own analysis of the packaging process, we did, however, trace some causes for some
recurrent interaction patterns. In step 2, for instance, we identified causes for why employees
chose to create direct, rather than indirect VisMockUp sessions for running the packaging
calculations. Those causes were of practical nature, i.e. the time needed to run certain
calculations in different modes. In step 5, the motivation for uploading all files rather than the
ones required was that doing so enabled running other, unplanned, checks without having to
start a new session. Clearly, our analysis did not penetrate to a deep enough level of causes of
recurrent interaction pattern that we observed. It just picked up immediate reasons that lead to
the behaviour observed. These do not, however, link into any theoretical framework of the
causes of (regular) behaviour. The limit, in terms of practical analytical power of an analysis
of recurrent interaction patterns, therefore still remains.
Some theoretical frameworks of the causes of (regular) behaviour are implicit in works on
organizational routines. Many articles on rules, for instance, at least implicitly imply that in
14 Our understanding of ‘generalizing’ always takes into account the context. For instance, generalizing within the context of a business unit, a firm, an industry, a cultural space etc.
33
some way or another, and more or less strongly, rules influence exhibited behavior.15 There
are several problems with reducing the causes of expressed behavior to rules, however. They
start with ambiguities and open issues in rule-following behavior, which are reflected even in
philosophy (Becker, forthcoming). They include the critique of having neglected agency
(Feldman & Pentland, 2003). They are often contradicted by everyday experience (see the
gaps between standard operating procedures and recurrent interaction patterns evidenced in
the packaging case). At the very least, it has to be admitted that a gap might (and often does)
exist between rules and behavior. In this gap, at the very least the volition of agents and
governance structures have an impact on how rules will influence behavior.
Following that line of thought, however, leads to consider:
• the interplay of institutions (rules, standard operating procedures, but also wider
institutions such as conventions etc.),
• the governance structures,
• and agents’ decision-making mechanisms and volition. Such causes are certainly very
complex.
The immediate purpose of the present discussion was to identify a theoretical framework on
the basis of which insights from the analysis of recurrent interaction patterns could be
‘generalized’ in order to be able to have some wider insight into performance impact of the
organization’s processes. Considering the ensemble of rules, interpreted by agents and
influenced by governance structures, seems to be a weak basis for generalizing insights
gained by analyzing a couple of concrete tasks in an organization.
15 Note that our focus is on organizational routines, and thus on collective behaviour that involves reciprocal interdependence and strives to fulfil the organization’s objectives, allows us to pursue with an organizational discourse, and not have to switch to a psychological discourse at this point.
34
The next step: organizational routines as collective dispositions
As it turns out, a theoretical basis for the causes of recurrent behavior (recurrent interaction
patterns) that is strong enough to warrant generalization at least in the sense of going beyond
the idiosyncratic level, has indeed recently been provided – understanding organizational
routines as collective dispositions to engage in previously adopted or acquired behavior,
triggered by an appropriate stimulus or context (Hodgson & Knudsen, 2004; Hodgson &
Knudsen, 2003b). The difference between understanding routines as behavior patterns, or as
dispositions to engage in a particular behavior, is precisely that when triggered, dispositions
are the causal mechanism that brings about behavior (Hodgson 2004: 653)16. Conceiving of
organizational routines as behavior (recurrent interaction patterns) only allows describing the
behavior patterns themselves. The analytical level is hidden from view and not accessible in a
systematic way, as we have seen in our example. Conceiving of organizational routines as
collective dispositions therefore provides a theoretical basis for identifying the mechanism
that causes behavior patterns. The conclusion from our experience of applying organizational
routines – interpreted as recurrent interaction patterns – in analyzing organizational behavior,
is therefore a very strong and reasonably innovative one: Recurrent interaction patterns are
only the part of the story (of organizational routines). They matter because it is the behavioral
level that decides on performance outcomes (Penrose, 1959). But precisely because recurrent
interaction patterns describe behavior, they do not describe its causes. It is therefore necessary
to also include the identification and causes of the regular behavior exposed in a description
of organizational routines. The most promising concept for describing such causes is that of
collective disposition (Hodgson, Knudsen). It therefore seems appropriate and indeed
16 The idea that habits (defined as dispositions that are actualized by triggers) are causes of repeated behavior can already be found in Max Weber’s work, where Weber identifies ‘traditional’ rationality as one of the four motives for social behavior (the others are instrumentally rational, value-rational, and emotional driven social action).
35
necessary to add collective dispositions as a deeper ontological layer to our framework of
organizational routines.
Methodological issues regarding collective dispositions
How, though, can we describe dispositions? Are collective disposition an untraceable entity
that will lead us into a metaphysical fog? The question obviously can be very tricky. We
argue, however, that a pragmatic answer that seems quite reasonable for our purposes is
available: Imagine facing the same problem a number of times. For instance, purchasing
teams have to choose a supplier for a component that it has not bought so far. The way the
team approaches this problem17 provides information about how the team members react to
particular situations when faced with, for instance, comparing prices. They might have a
tendency, as a team, to stop soliciting offers after two days precisely and then take a decision,
no matter how many offers they have received by then; to always solicit three offers, no
matter how long it takes; to follow the purchasing guidelines by the letter, no matter what the
effect; or to let the most powerful member of the group impose his or her decision on the
others. Whenever one of these responses to the problem is seen to be activated repeatedly, we
can conclude that the team has a disposition to address that problem in this particular way.18
In other words, one way to identify collective dispositions is to ‘read them off’ from recurrent
interaction patterns. This is why the description of recurrent interaction pattern is not futile,
but an important step to arrive at the level of collective dispositions. In order to ‘read off’
17 The analysis could be done for each step of the problem-solving process. 18 A problem that might occur in identifying collective dispositions is how to distinguish between a mere collection of individual dispositions and a collective disposition. The discriminating criterion is whether the interaction produces an emergent result, i.e., a result that is more than just the addition of the individual inputs. This will systematically be the case for interdependent tasks. For instance, in the example of the purchasing team, there will usually be specialists, for instance for pricing, quality, different groups of suppliers and so on. The input that each provides to the team has an impact on the quality of the inputs of the others, for instance, if the person in charge of assessing the quality is the first to discard potential suppliers that subsequently will not be judged any more by the others. A counter-example would be that three of the team members have a disposition to drink a cup of tea around 4 o’clock, each one at his desk.
36
collective dispositions from recurrent interaction patterns, it is necessary to compare a series
of recurrent interaction patterns that have been formed in response to the ‘same’ situation. For
identifying collective dispositions, ethnographical work (or other types of observations) is
therefore required.
Clearly, such a requirement represents a disadvantage of the collective disposition approach in
terms of time- and resource-requirements.19 On the upside, the payoff of observations is much
higher if these observations serve to identify collective dispositions, rather than recurrent
interaction patterns. The reason is that identifying a collective disposition will allow to
understand better how members of the organization will react to a situation of a particular
kind, at least in principle. Observations of recurrent interaction patterns only serve to identify
pathologies and ineffiencies of the recurrent interaction patterns observed.
So far, our ethnographic observations have been focused only on interdependent tasks, and we
could draw empirically grounded conclusions only on the specific processes under
investigation (packaging). However, anecdotal evidence drawn from other recurrent
interaction patterns within the firm confirms that only observing a set of recurrent interaction
pattern, collective dispositions can be detected. Further empirical work can add more
evidence to this.
19 At this point, we need to leave the question whether there are other, less resource-intense ways to identify collective dispositions, to be treated later. Attitude psychology, after all, provides tools for identifying attitudes by using other methods (including questionnaires). It should be clear, however, that any direct question on a disposition is problematic due to differences between what the respondent declares and what he or she does. Observation seems the method that is most reliable in order to capture collective dispositions.
37
Conclusion
It is worthy emphasize that our conclusion that adding the causal layer of collective
dispositions to the layer of recurrent interaction patterns is necessary, arises from empirical
work while Hodgson & Knudsen, who introduced the concept into the discussion, argue on
theoretical grounds, historical grounds, from other sciences, and with simulation results. The
present paper therefore strengthens Hodgson’s and Knudsen’s argument for defining
organizational routines as collective dispositions. Such a definition, however, also makes
much sense from the point of view of empirical analysis of organizational behavior, and
considerably strengthens the analytical power of empirical analyses employing organizational
routines as analytical perspective.
One reason why it strengthens analytical power is that understanding organizational routines
as collective dispositions allows an explanation of behavior (recurrent interaction patterns)
that is not unidirectionalist. It is neither an exclusively ‘top down’ explanation of individuals
in terms of cultures, structures or institutions, nor an exclusively ‘bottom up’ explanation that
focuses exclusively on the individual and ignores the institutions it is embedded in (Hodgson
2004: 658). Such a bidirectional explanation also fits well to the ‘structuration explanation’
proposed by Feldman & Pentland (2003) and develops it further. Their explanation suggests
that ‘by performing particular patterns of action, members tend to reinforce and reproduce the
underlying structures. Organizational routines are then considered as the product of action that
occurs in the context of the enabling and constraining structures (Barley, 1986; Feldman,
1989; Pentland & Rueter, 1994; Orlikowski, 2000). The organizational context makes some
actions easier, and therefore more likely, and other actions harder, and therefore less likely.
Repetitive patterns of action will tend to emerge as organizational members choose to take the
easier actions and avoid the harder ones’ (Feldman & Pentland 2003: 98). Understanding
38
organizational routines as collective dispositions allows us see how the enabling and
constraining structures lead to particular behavior patterns – via dispositions. Dispositions
serve to channel choice. Agents have the power of choice, but their choice is channelled by
the disposition they have to consider some alternatives more readily than others. Collective
dispositions, moreover, channel individual choices into overlapping same possibility spaces.
It is important to note, however, that the causal mechanism that gives rise to (recurrent)
behavior consists in the disposition plus the trigger that activates and energizes it. Without
being triggered, a disposition can exist, but without being activated (such as an assault drill of
an army corps in a period of peace, which might last a soldier’s lifetime). The particular
behavior that will be actualized thus depends on two elements: the dispositions (the repertoire
of possibilities, or capabilities to do something), and the triggers that activate and actualize a
particular option in the repertoire. Identifying the ‘governance gap’ (and the role of recurrent
interaction patterns in doing so) therefore has yet another important function: identifying the
triggers provided by the governance structures in place. The concept of collective disposition
helps recognize that designing triggers that match collective dispositions is a crucial task of
the design of governance mechanisms.
39
Level
Object Results
Habit
individual
task prediction of how a person will react to a particular situation
Recurrent interaction pattern
collective and organizational / single pattern
reciprocally interdependent task
having mapped the gap, managerial implications on the particular tasks observed
Collective disposition
collective and organizational / multiple pattern
set of recurrent interaction patterns
causal mechanism behind the particular recurrent interaction patterns observed; generalizable within the organization
Figure 5: Different ontological aspects of ‘organizational routines’
Figure 5 systematizes the theoretical insight derived from our methodological and empirical
work. It represents, from an organizational perspective, the concept of organizational routine
and shows how there are at least three levels at which it can be investigated and employed as
analytical perspective. As argued in section 2, we deliberately chose to use as starting point
the concept of recurrent interaction pattern. Being interested in organizational behavior, this
perspective allowed us to observe organizational phenomena. We choose as object of analysis
organizational tasks that were characterized by reciprocal interdependence and direct
relevance to firm main goals. Managerial implications on those specific tasks clearly
emerged. That top management decided to implement governance solutions we derived in our
40
analysis can serve as an indication that the analysis have been meaningful. However, in order
to grasp the underlying causal mechanisms behind the formation of the organizational
behavior that we believe is idiosyncratic to each firm, a further level of analysis was needed.
We found that the concept of collective disposition had the potential to help. In this paper we
contribute to the issue, not only by offering some empirical grounding for ‘opening up’ and
adding this level of analysis, but also by describing a way to operationalize it. The road to
describing collective dispositions runs via a comparative study of a sample of recurrent
interaction patterns. From those, collective dispositions can be ‘read off’ as similar reactions
to problems. In this sense, adding the causal layer of collective dispositions to the behavioral
layer of recurrent interaction patterns seems perfectly consistent, theoretically necessary,
augmenting the analytical power in empirical studies, and even uses the level of recurrent
interaction patterns in order to arrive at an identification of collective dispositions.
Bibliography
Barley, Steven R. (1986): Technology as an Occasion for Structuring: Evidence from the
Observations of CT Scanners and the Social Order of Radiology Departments. Administrative
Science Quarterly, 31: 80-108
Barley, Stephen R. and Gideon Kunda (2001): Bringing Work Back In. Organization Science,
Vol. 12, No. 1, 76-95
Becker, Markus C. (2004): Organizational routines: A review of the literature. Industrial and
Corporate Change. Vol. 13, No. 4, 643-678
Becker, Markus C. (forthcoming): Organizational routines: Some clarifications. Cambridge
41
Journal of Economics, forthcoming.
Cohen, Michael and Paul Bacdayan (1994), 'Organisational Routines Are Stored as
Procedural Memory: Evidence from a Laboratory Study', Organisation Science, 5, pp. 554
-568.
Cyert, Richard M. and James G. March (1963/1992), A Behavioral Theory of the Firm.
Blackwell: Oxford.
Dosi, Giovanni, Richard R. Nelson, and Sidney G. Winter (2000), 'Introduction: The Nature
and Dynamics of Organisational Capabilities' Pp. 1-22 in The Nature and Dynamics of
Organisational Capabilities, edited by G. Dosi, R. R. Nelson, and S. G. Winter. Oxford
University Press: Oxford.
Edmondson, Amy C., Richard M. Bohmer, Gary P. Pisano (2001), 'Disrupted Routines: Team
Learning and New Technology Implementation in Hospitals'. Administrative Science
Quarterly, 46, pp. 685-716.
Eisenhardt, K. M., (1989), “Building Theories from Case Study Research”, Academy of
Management Review, Vol. 14, No. 4, pp. 532-550.
Feldman, Martha S. (2000), 'Organisational Routines as a Source of Continuous Change'.
Organisation Science, 11, 6, 611-629.
Feldman, Martha S. (2003), 'A performative perspective on stability and change in
organizational routines', Industrial and Corporate Change, 12, pp. 727-752.
42
Feldman, Martha S. and Brian T. Pentland (2003), 'Reconceptualizing Organizational
Routines as a Source of Flexibility and Change'. Administrative Science Quarterly, 48, 94-
118.
Hodgson, Geoffrey M. (2004): Reclaiming habit for institutional economics. Journal of
Economic Psychology 25, 651–660
Hodgson, Geoffrey M. and Thorbjørn Knudsen (2003a forthcoming), 'The Firm as an
Interactor: Firms as Vehicles for Habits and Routines'. Journal of Evolutionary Economics,
forthcoming
Hodgson, Geoffrey M. and Thorbjørn Knudsen (2003b), 'The Replication of Habits', Mimeo,
University of Hertfordshire
Hodgson, Geoffrey M. and Thorbjørn Knudsen (2004), 'The Complex Evolution of a Simple
Traffic Convention: The Functions and Implications of Habit', Journal of Economic Behavior
and Organization, 54, pp. 19-47.
Hutchins, Edwin (1991), 'Organizing Work By Adaptation'. Organization Science, 2, pp. 14-
39
Knott, Anne Marie and Bill McKelvey (1999), 'Nirvana efficiency: a comparative test of
residual claims and routines', Journal of Economic Behaviour and Organisation, 38, 365-383.
March, James G. (1994): A Primer on Decision-Making. Free Press, NY
43
March, James G. and Herbert A. Simon (1958 [1993]), Organizations. Blackwell: Oxford.
Miles, M.B. and A.M. Huberman, (1994), Qualitative Data Analysis: An Expanded
Sourcebook, 2nd edition, Thousand Oaks, CA, Sage Publications.
Narduzzo, Alessandro, Elena Rocco, and Massimo Warglien (2000), 'Talking About Routines
in the Field'. Pp. 27-50 in The Nature and Dynamics of Organizational Capabilities, edited by
G. Dosi , R. Nelson and S. Winter. Oxford University Press: Oxford
Nelson, Richard R. and Sidney G. Winter (1982), An Evolutionary Theory of Economic
Change. Belknap Press/Harvard University Press: Cambridge.
Penrose, Edith (1959/1995): The Theory of the Growth of the Firm. Oxford University Press,
Oxford
Pentland, Brian T. (1995), 'Grammatical Models of Organizational Processes'. Organization
Science, 6, pp. 541-556.
Pentland, Brian T. (2003a): Conceptualizing and Measuring Variety in the Execution of
Organizational Work Processes. Management Science, Vol. 49, No. 7, 857-870
Pentland, Brian T. (2003b): Sequential Variety in Work Processes. Organization Science,
Vol. 14, No. 3, 528-540
44
Pentland, Brian T. and Henry Rueter (1994), 'Organisational Routines as Grammars of
Action', Administrative Sciences Quarterly, 39, pp. 484-510.
Pettigrew, A.M., (1990), “Longitudinal Field Research on Change: Theory and Practice”,
Organization Science, Vol. 1, No. 3, pp. 267-292.
Orlikoswki, Wanda J. (2000): Using Technology and Constituting Structures: A Practice Lens
for Studying Technology in Organizations. Organization Science, Vol. 11, No. 4, 404-428
Simon, Herbert A. (1947/1997), Administrative Behaviour. The Free Press: New York.
Stene, Edwin O. (1940): Public Administration – An Approach to a Science of
Administration. American Political Science Review, Vol. 34, No. 6, 1124-1137
Szulanski, Gabriel and Sidney Winter (2002), 'Getting It Right the Second Time'. Harvard
Business Review, January 2002, pp. 62-71.
Thompson, James D. (1967): Organizations in Action – Social Science Bases of
Administrative Theory. McGraw-Hill, New York.
Winter, Sidney G. and Gabriel Szulanski (2001), 'Replication as Strategy', Organization
Science, 12, 6, pp. 730-743.
Yin, R.K., (1994), Case Study Research, 2nd edition, London, Sage Publications.
45