On Co-creation & STS Theory

The estimable Daniel Jones recently wrote about estimation and why teams who create software should do it. Dan asserted that the act itself of estimating has benefits that are sufficiently positive that it’s still worth doing even if the output data, (e.g. story points), aren’t then used. The benefits are derived from increasing alignment and comprehension about the work that team will perform.

I have also been thinking about estimation and other activities we do when creating software, that we perform ostensibly because they produce a particular useful output, but that have an additional effect because of the way they are performed, or by the fact that they are performed at all.

One of those is the act of writing down the work that developers will perform, also known as ‘story writing’. Story writing, like estimating, is an act of co-creation.

An act of co-creation involves multiple people or groups collaboratively contributing to the design, development, or production of a shared outcome, such as a product, service, or idea. Unlike processes where one person dictates either the creation process, the output, (or both), co-creation invites active participation from multiple stakeholders.

Each participant in an act of co-creation brings unique perspectives, whether from their lived experiences, professional expertise, or creative intuition. This diversity enriches the outcome by pooling insights and expertise. Participants in co-creation feel a sense of ownership over the result. This leads to higher engagement and often results in more innovative and resilient solutions because contributors are invested in the success of the outcome.

Co-creation typically involves iterative cycles where ideas are proposed, refined, and adapted based on ongoing feedback from participants. This is often seen in agile methodologies, design thinking, and participatory design practices.

Unfortunately, co-creation is not free, it requires effective facilitation to balance input and ensure productive collaboration, which can be time-consuming, as reaching consensus or gathering feedback across a wide group can slow down decision-making. Ensuring equal participation and managing differing opinions can be challenging, but the cost of managing facilitation and associated challenges seems to me to be worth the benefits.

We should therefore recognise that some activities in software development are acts of co-creation and be intentional about treating them as such, to maximise their potential.

?

This also highlights that while software development involves a creative process and complex technical activities it is also a social activity. It can be described as a socio-technical activity. Socio-technical systems (STS) theory describes an approach to understanding how complex systems operate by examining the interactions between people (social systems) and technology (technical systems). It emerged from the work of researchers in the mid-20th century who were studying productivity, particularly in industrial settings, and saw the need for a more holistic framework that accounted for both social and technical elements within organisations.?

STS theory holds that neither the social system (people, roles, relationships, and culture) nor the technical system (tools, processes, and technologies) can be understood in isolation. Instead, they are interdependent, and their interaction must be managed holistically to optimise overall system performance.?

The social system includes the individuals, teams, work culture, communication patterns, organisational structure, and leadership. It focuses on human needs, motivations, skills, and collaboration. The technical system consists of the tools, technologies, workflows, procedures, and physical layout that people use to complete their work.

The effectiveness of a socio-technical system depends on how well the two systems align and support one another.?

The theory advocates for the joint optimisation of both social and technical aspects rather than prioritising one over the other. A system that is optimised only from a technical perspective may fail due to user frustration, resistance, or lack of engagement. Conversely, a system optimised solely for social comfort might under-utilise technology and miss out on efficiencies.

If some of this sounds familiar it’s because Agile and DevOps practices in software development reflect STS principles by emphasising cross-functional teamwork, continuous communication, and adaptive technology systems.

I’ve come to believe that in software development the difference between anything less than great and great is the recognition of the value of, and disciplined adoption of co-creation techniques and resistance to anything that creates an imbalance between the social and technical aspects of the activity, (informed by a good understanding of socio-technical systems theory).

I discussed some related ideas in a series of blogs on platform engineering earlier in the year, but I'm planning to unpick this some more - DM or comment if there's something you think I should focus on.