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