How to Tune your Lute
Use Opponent Processing with your teams to find areas for improvement
Welcome back intrepid explorers of Organisational Intelligence.
If you like the stuff I’m writing, pretty please could you leave me a like at the bottom of this post? It helps me know that you’re a) reading it b) enjoying it. Feedback with words also very welcome.
Last time we looked at John Vervaeke’s take on Opponent Processing, and how our cognition relies on tuning between different poles. Our mind is constantly and dynamically trying to work out balances such as:
Explore vs Exploit: Should I keep using what I already have and Exploit it (this pizza restaurant is great! Let’s stay here and order), or should I go and Explore to find new resources elsewhere (Na there’s no good options lets try a different place)?
Fight and Flight vs Rest and Digest: Should my body be activated, energetic and ready for action (tiger! run!), or rested, calm and restorative (this is a nice hot bath mmmm)?
Whole vs Particular: Should we be looking at something as a larger whole (the problem is with your car), or should I be zooming down into the details and its parts (the problem is with your spark plug)?
Fast vs Slow thinking: Should we make our decisions based on fast and error-prone intuition (this Daniel Susser is so smart, he’s probably right about all this cognitive science stuff), or should we make decisions emphasising slow methodical and more precise rationality (let’s think through this, are these ideas any good)?
There are many other examples. As a self-organising system, our bodies learn how to find the right tuning between the two poles depending on our context and environment. We do it instinctively, intuitively and all the time. If we do this well we are well adapted and will be good cognitive agents and solve the problems that life throws out in front of us.
Today I want to take a more practical angle and look at a tool I use with my teams in the wild. I call it the Opponent Processing Scales (if enough people use it I’ll start calling it Susser Scales but that also sounds like a skin condition…). I don’t love the name, feel free to suggest a better one.
This is the general flow I want from this Substack - explore some theory, work out its relevance to our agile teams and share tooling that can help you easily embed approaches based in Cognitive Science straight into your teams.
If you haven’t read Tuning The Lute I encourage you to do so. It will give you conceptual underpinnings and so you can get the most out of the tool. I also read it out as a Podcast in case you need to urgently chop some onions or walk the dog.
Opponent Processing Scales
I’ve made a (Free!) Miro Template to show how a workshop flow for Opponent Processing Scales works. I’ve added screengrabs here from the board with a couple of specific examples.
Don’t worry too much about the specific examples, they are there to illustrate. Here we go:
Step 1) Ask the team to list out problems they are facing, as many as they can in one minute. Dot vote or find another mechanism to find the most impactful or easiest to solve problems they are facing and prioritise maximum 4 problems.
This will give you something concrete to work with and hopefully hone in on a meaningful candidate for Opponent Processing.
Step 2) This might be the harder part but it will come with practice. Take teams’ problems and ask them to articulate them in terms of two opposing but legitimate poles. It’s important that they are both legitimate. There can’t be any suggestion of ‘the right answer’ because then that introduces weird incentives for the team to not share their real answer. Maybe they don’t want to be seen to rock the boat or don’t want to be negative. Or actively want to be negative because they are in a mood.
If both of the poles are legitimate things to aim towards in different contexts then the team can truly think through where they need to be. It’s also important to be careful as the facilitator to help the team articulate these poles themselves, especially if you are their manager or there is any issue of power here. You want to avoid the impression that there is a fait accompli where you the facilitator will get the outcome you want.
Step 3) Give the team a bunch of left and right arrows and dots (helpfully included in the Miro (hairflick emoji)).
For each problem and scale ask the team members to place one dot or arrow. A dot means ‘we are in the right place’, and arrow left means ‘we should move more towards the pole on the left’ and an arrow right means ‘we should move more towards the pole on the right.
Ask them also to place a dot or arrow on the scale in the place they think represents where the team currently is.
This gives you and the team a rich data display of how the team are feeling about the current ways of working and the impact. You can ask the people at different ends of the spectrum why they placed their arrow/dot where they did. This may allow them to share their perspective in a language they hadn’t thought of before.
Another benefit of this approach is that it might give some explanatory power to underlying disagreements. Vlad isn’t being stubborn and unhelpful, he just feels he does his best work alone and values that highly. He didn’t realise the impact of not being available to help out and will try to adjust accordingly.
As you facilitate the conversation around each problem ask the team ‘what can we try to help us tune better between these two poles?’
Then use whatever agreement technique you like to narrow down the team’s favourite solution (I like the Decider Protocol).
And Voila! You have some actions and ideas based on a judgement-free analysis of how the team wants to find the right cognitive tuning for their context.
Important to note is that the team might have picked ideas that make things worse! That’s why they are experiments to try, not perfect solutions to execute. The aim of Opponent Processing Scales is to find very sensible things to try, based in the team’s knowledge and perspective of how they should be working together in their context.
It’s worth checking in with the team shortly after implementing the experiments to see how it’s going, and as always if the team has given the idea a good try and it’s not working, try something else. Predict, Sense and Adapt and all that jazz.
And that’s it!
In other news from Daniel and Embodied Agility:
Upcoming Workshops
Team Lifecycles Retrospectives Class I’m running a class next week online to help you plan better retrospectives by using Team Lifecycles. It’s about finding the relevant retrospective tools for the team and their context whether you’re a beginner or an old hand at retrospectives.
Agile Mind Meetup If you want to talk about this kind of stuff with other people who are interested, you might like the Agile Mind Meetup. It’s a monthly conversation about agility and intelligence and cognitive science.