This paper uses cultural-historical activity theory to interpret the effects of bureaucratic standardization and formalization on software development work. I focus on the Software Engineering Institute’s Capability Maturity Model. Under a more “mature ” process, developers lose much of their traditional autonomy in deciding the methods of work, since these methods are largely standardized and formalized. Paralleling broader concerns about bureaucracy, some observers fear that process maturity will be experienced as coercive and burdensome, with negative consequences for staff motivation and development effectiveness. To explore whether these fears are well-founded, I studied four units of a large software consulting firm. I find that the fears are largely misplaced. It is true that process maturity replaced autonomy with a broad, tight web of interdependencies, and that sometimes these interdependencies were experienced as oppressive dependence. However, for most of my interviewees, interdependence took a more collaborative form. Most developers expressed a professional concern for the effectiveness of development, and embraced process maturity as an efficacious collective discipline. Compared to the traditional, individualistic, “hacker ” mode of software production, process maturity made for a more “socialized” production process. The organization form associated with high maturity fit the “enabling bureaucracy” model described by Adler (//). The subjective experience of work took the form of more interdependent self-construals and more directly socialized identities.

Abstract. In the contemporary world, engineers and designers face huge challenges as they shift towards novel organizational concepts such as ‘concurrent engineering ’ in order to manage increasing product diversity so as to satisfy customer demands while trying to accelerate the design process to deal with the competitive realities of a global market and decreasing product life cycles. In this environment, the coordination and integration of the myriads of interdependent and yet distributed and concurrent design activities becomes enormously complex. It thus seems as if CSCW technologies may be indispensable if concurrent engineering is to succeed. On the basis of ethnographic studies of cooperative design, the paper attempts to characterize cooperative work in the domain of design and to outline a set of crucial research problems to be addressed if CSCW is to help engineers and designers meet the challenges they are facing. On one hand, designers need highly flexible ‘coordination mechanisms ’ that can support horizontal coordination of large-scale distributed design projects, and on the other hand design organizations require versatile and ubiquitous infrastructures to be able to manage their ‘common information spaces ’ without sacrificing the critical adaptivity and concurrency. In order to be able to conceptualize and specify the support requirements of cooperative design, it is useful to make an analytical distinction between ‘cooperative work ’ and ‘articulation work. ’ According to this conception, cooperative work is constituted by the interdependence of multiple actors who, in their individual activities, in changing the state of their individual field of work, also change the state of the field of work of others and who thus interact through changing the state of a common field of work. However, since it involves multiple actors, cooperative work is inherently distributed, not only in the usual sense that activities are distributed in time and space, but also — and more importantly — in the sense that actors are semi-autonomous in terms of the different circumstances they are faced with in their work as well as in terms of their strategies, heuristics,