When we draw systems diagrams, we usually draw boxes with labels in them and lines between the boxes which detail the communication between different functions or services. Software development is then a process of turning these labels and boxes into interfaces, functions, user privileges and so on. When the software is implemented, inevitably it has a subtle effect in changing the human organisation of whatever process it is designed for. One of the problems with the design process is that it exercises a kind of tyranny by programmers and systems designers over the existing practices of individuals in an organisation: putting it crudely, it is the geeks who determine what everyone else’s job should be.

Individual job functions are distinctions which emerge naturally in the pattern of transactions those people have with other people in the organisation. Often the nature of these transactions is hard to codify – particularly in a work environment already full of technology, where each individual can see themselves doing many different kinds of things and switching from one thing to another all the time.

Transactions of this sort are usually communications or conversations. Extending the logic of Coase’s theory of the firm, each job function exists by virtue of the transactions which others have with them.

Transduction is a technical term for a process which maintains a distinction between two different forms of representation: for example, between the environment of light and the images in the eye, or between the vibrations in the air and the perception of a melody. All distinctions – including the distinctions which are made in systems modelling diagrams – are the product of transduction processes. More importantly, transactions are the outward sign of transductions: we can look at the words of a conversation, or the accounts ledger of a business and know that these signs of communication indicate a deeper process of coordination going on.

I’m increasingly convinced that our software design processes start from the wrong end: inevitably, software design models the transduction processes of the software designer and then impose those transduction processes on everyone else. What it we were to model the actual transductions within an organisation? What if we were to look at the way distinctions are actually maintained within a business?

All transduction processes can create organisational problems. Every transduction maintains a distinction, and in so doing determines the inside and outside of that distinction. Sometimes, what is excluded in a distinction is the source for more distinctions to be made, and quite often we see that there is a conflict between different organisational functions at different levels. To be able to analyse the transductions in an organisation is to have a map for possible interventions which might look to change the configurations of transductions in the organisation.

A simple example is self-publishing. I’m self-publishing my book, and have decided to do so because the transductions created by publishers are pathological (retaining copyright, setting outrageous prices, doing very little in terms of editorial control, etc). To understand the pattern of these transductions in the publishing system is to identify the intervention point where problems that arise from those transductions might be addressed. Equally, I am interested in the transductions of assessment in education. I’m interested in things like Adaptive Comparative Judgement precisely because it is a way of reconfiguring the transductions of assessment which then affect other transductions in education (for example, educational quality). Or we might look at the transductions of the curriculum. My interventions in Vladivostok are precisely about overcoming the transduction between different subjects in the curriculum, and targeting the primary transduction on the relationship between the individual and the phenomena of the world, rather than the individual and specific ‘subjects’.

The key to being able to specify existing tranductions is to consider each distinction as a means of managing uncertainty. If the distinction concerns somebody’s job (e.g. academic quality, teaching) then the transduction will perform the function of managing the uncertainty of that person maintaining their job. The key question in redesigning the transduction is whether there is a better way of managing uncertainty in the organisation. Obviously, designing a system which removes a person’s job (which is what software designers often do) only increases uncertainty in the organisation; the trick is to reorganise things so that everyone is able to manage their uncertainty better. The pathology of current approaches to technology are that it ramps up uncertainty, and as a consequence, it creates the conditions for increasingly complex technology which tries to fix the uncertainties generated by the previous technology.