Emancipating feedback

This post is a case study, applying ideas related to dynamic nominalism to the practice of giving and receiving feedback on teams with shared goals.

Dynamic nominalism is a term I learnt from reading the writing of Ian Hacking, it is the view that:

• The properties and relations we use when we talk about people or groups of people are primarily constructions of language, they are not fixed and often imperfectly describe reality at first.
• These labels play a causal role, and in doing so interact with reality in ways which result in them gaining more descriptive power as they evolve.

Some alternative views would be:

1. Realism about social kinds - there are fixed types of person and group, and we can perhaps discover these through increased scientific understanding.
2. Nominalist pragmatism - we use language to invent ways of describing people and groups of people; no particular way of carving up the world is especially privileged over any other, except insofar as it is more or less useful.

Dynamic nominalism is only a possible position to hold because humans are aware of the labels that get, or could get assigned to them. As a result, the concepts that that we use to describe human behaviour are an immanent part of the territory of human behaviour itself - rather than an abstract part of a transcendent map being drawn somewhere from a God's eye view.

A few of my recent posts, on this topic¹ have been quite abstract. One reason for this is that the literature I've been reading about them often deploys examples from human sciences about which I don't have many object-level views to share. Nevertheless, I've personally found that this way of thinking is applicable to a variety of concrete areas of my life. One of those areas is the practice of giving feedback on software engineering teams.

Software engineering is a field where it is possible to get a lot of your feedback directly from machines, without having to deal with the messy business of interacting with other people. Computers are infinitely patient and highly responsive: you can keep throwing bad work at them and, in many cases², improve that work into excellent work simply by observing the output and iterating on what you learn.

In the ideal case, feedback from your peers³ would be similarly abundant, actionable, and forthcoming. But there are a number of reasons why this isn't always the case. Many of these are fixable by trying to create what in management speak is often referred to as "a healthy feedback culture" on the team. I won't discuss the standard advice here (this post is not intended to be guidebook for implementing good feedback culture on teams), but normally this involves two categories of activities normally delivered as part of some kind of workshop:

1. Object level training for the team on how to be direct, how to structure feedback for clarity, how to avoid common ways to be misunderstood etc.
2. Creating shared knowledge for the team that regular feedback is something that is encouraged; and that feedback interactions are a "type" of conversation they should expect to take place regularly in the healthy course of business. Also socializing that these interactions are good and helpful. This may involved sharing made-up examples, doing role plays or splitting the team up into pairs to practice giving and receiving real feedback with each other.

These two sets of activities might look very similar, they both look like educating the team about some set of concepts and facts about those concepts. However, on closer inspection, the second set of activities turns out to be quite strange. Are feedback conversations really a distinct "type" of interaction? By the end of such a workshop they will be. Do they really have all the properties being ascribed to them? Again, the workshop makes it so.

The reason for this is that the introduction of the shared concept of a feedback interaction into the team's lexicon is part of what makes the team actually behave in ways in which the concept describes. What's more, the feedback interaction itself becomes a part of the process for maintaining and shaping future feedback conversations. This can happen even through things as simple as "I am worried that we aren't exchanging enough feedback", and "a number of new people have joined the team and don't know how feedback is done here, we should run another feedback workshop", becoming a part of the practice.

I think this is a good example of dynamic nominalism in action.

Note that activities in the first category are not clear instances of this phenomenon in the same way - e.g. training the team on how to be more direct. A team doesn't need to have a concept of "direct communication" introduced to them in order for the communication that takes place between them to be more or less direct. For this reason I think "directness" is better understood as a more ordinary kind of predicate.

There is also a second, more subtle, way in which dynamic nominalism can help make sense of feedback interactions, and this is by thinking about the subjects of those interactions themselves. Such interactions will also contain descriptions of a person's behaviour or work, and the correctness of these descriptions will also sometimes be best understood in dynamic nominalist terms. I'll discuss two failure modes of peer feedback related to this (though I should note that I personally haven't seen them arise very often, mostly because the standard contemporary advice for implementing peer feedback has mechanisms for avoiding them baked in).

The first such failure mode with peer feedback is that it can sometimes blindly steer people away from what they are actually setting out to achieve, and towards the status quo of whatever is judged as most agreeable to the current discourse. Another blog post on feedback, by metabstract (who also finds their own way out of this trap) expresses this worry quite well:

I was overly eager to receive feedback and to act on that feedback to change my behaviour. Afterall, just receiving feedback isn’t enough to make you improve; you also have to integrate the feedback, let the feedback trickle through your entire being, let it change you! So, in all that over-eagerness, my ability to ask one important question started to fade away; whether the feedback was relevant to what I personally cared about.

Another failure mode of peer feedback is that it can backfire in the other direction. If people hear the same feedback from others again and again they can confuse contingent descriptions of their recent behaviour for immutable facts about themselves, and this can result in them changing too little (or doubling down!).

Both of these failure modes are especially dangerous because of the effects which dynamic nominalism predicts. Certain descriptors of people and their work can, even if they start out imperfect, still stick and end up sorting people in ways which become self fulfilling prophecies. A concrete example is e.g. the concept of a "non technical" employee. In one direction some people might change their behaviour to make it very clear the label does not apply to them, declining or hiding work they do on coordination or communication tasks. In the other direction they might accept that the label must apply to them, and adopt all its other implications as well, stepping back from technical challenges, or avoiding complex feature work. These updates continue until a label which was originally a fairly poor way of dividing up the world now actually has a lot of descriptive power.

Foucault had these kinds of effects in mind when he warned that there was a double meaning to the phrase "being a subject".

subject to someone else by control and dependence; and tied to his own identity by a conscience or self-knowledge. Both meanings suggest a form of power which subjugates and makes subject to.

I think this analysis is only half right and that the practice of exchanging feedback can be emancipated from these kinds of cynical effect.⁴ Feedback, when delivered well, is not a subjugating force, but one which helps individuals better achieve their own goals.

In my experience the way to do this is to train people to treat peer feedback as a source of information about the world and how it responds to their behaviour, rather than a source of information about the nature or possible nature of receivers of feedback themselves. It can certainly still be helpful for individuals to eventually infer things about themselves from this information, but as the receiver of feedback, they need to own the process of making this inference. Taking ownership of this process, and being critical about the inferences made whether the concepts being used are sufficiently nuanced interrupts many of the failure modes described above.

I said earlier that standard advice for implementing peer feedback avoids these failure modes in the first place. This advice includes things like training the people giving feedback to talk about specific examples of behaviours and the impacts those behaviours had, rather than making generalised statements about the receiver of the feedback or their body of work. The above way of thinking can still be helpful when this advice is not being followed. If someone receiving feedback finds themselves in such a situation, they can still apply the more general lesson. Firstly try to figure out what concrete behaviours might have led to those generalizations being made. Secondly figure out what they have learnt about the impact those behaviours might have had on the world.

You often see writers express a similar sentiment about how to respond to feedback about their own writing. Namely that, when people tell you to change some piece of your writing, they are almost always wrong about how you should change it. However, they are almost always right that something about your writing wasn't working for them. It remains your job as the writer receiving feedback to figure out what that thing is, whether it is something you care to change, and how to change it if so.

I think that the work of Foucault and his successors like Hacking is often unfairly maligned as being overly pessimistic. The accusation is often that they expose various ways in which power can act on us, but offer no advice on what to do about this. I think the take away is not that this means that there is nothing that can be done, but rather that all the advice is on what to do is highly specific.

Positive applications of the effects predicted by dynamic nominalism are very much possible, even when everyone involved is consciously aware what is happening; for example in the case of a team settling on a stable understanding for what feedback interactions should look like. I think that we can also be optimistic about the negative cases, like the worries about unhelpful categories such as "non-technical" being summoned into existence. In many cases the systems of power that reinforce and maintain these categories are scarily effective, but, fundamentally, they also not particularly crafty. The underlying belief of this kind of work is that we are capable of understanding, and perhaps therefore, out-thinking such forces.