Three software development team archetypes

While it is obvious to say that social engagement is an underlying dynamic in teams, the `obvious' is often ignored or even thought of in terms of a problem that must be overcome. Consider instead if we start from the assumption that team structure arises as a consequence of social relations rather than the other way around. Under these assumptions then, the activity of management (not necessarily the job title) can be seen as the act of fostering the social relations of a team rather than manipulating them.

Sawyer's analysis offers some paradigmatic filters to view and manage systems development, as a diagnostic lens and a tool to intervene.

"The sequential team archetype of software development team social structure draws on the work design tradition in industrial engineering. Work is seen as a set of discrete tasks that can be measured." 

"The group archetype draws its intellectual roots from theories of social psychology, such as 'work redesign'. Work redesign arose in response to such issues as personnel motivation, retention, and productivity that typically occur in a work design approach." 

"The network group archetype draws on concepts of social network theory. In this archetype a group of people is linked by the relative 'strength' of the social ties among them. Work is seen as the use of these links to deliver and receive information; these uses both span and define tasks."

Certainly Sawyer's archetypes are just that, archetypes or caricatures. All teams are hybrids but we easily recognise elements of the archetypes at different times and in our own behaviour. Perhaps a key insight is that our individual personalities and temperaments incline us towards one mode or another, perhaps at different times and regardless of the organisational structures in place. And each archetype invokes a specific remedy (communication can overcome the limitations of silos, groups often need direction and control, networks need opportunities to interact and bottle-necks can be a problem).


Reference
Sawyer, S. (2004) Software development teams. Communications of the ACM, 47, 95 - 99.