This article is trying to help programmers and people like them, when they have conversations at work that are about understanding, explaining, deciding etc. It’s not so much about persuasion or selling, or mentoring or coaching. These are all important kinds of conversations, but I’m not the person to help you with them.
It might help non-programmers, but I’ll frame it in ways that I hope a programmer would understand. In that regard, it’s like what I wrote about writing documents that describe or explain things. As with what I wrote about documents, I’m not an expert in this; this is just what I’ve learned as I’ve muddled along, that I’m putting here in case it’s helpful.
Computers that play chess
Please humour me as I take what seems like a random detour into chess-playing computers; I hope it will become relevant later. One approach to getting a computer to play chess is the minimax algorithm. It assumes that there’s some way of giving a score to any arrangement of pieces on the chess board, so that you can tell how good it is for you or the other player. For the sake of argument, I’ll assume this scoring function is set up so that the higher the score is the better the board is for whoever is about to make the next move. It also assumes that each player will make the best move available to them.
The simplest way to use this algorithm is to look at all the moves I can make now, score each one, and pick the move with the highest score. This works, and is the quickest version of things, but probably the least likely to help you win.
The next most complicated way to use the algorithm is as follows:
- Look at all the moves that I can make now but don’t bother to score them
- For each move I can make, look at all the moves that the other player can make afterwards and score those (from the other player’s perspective)
- Once all the moves and follow-on moves have been worked out, each of the moves I can make now is labelled with the score of the best move that the other player can follow it with (as far as the other player’s concerned)
- I pick the move for me that gives the other player the worst version of their best follow-on move.
You can possibly see now why the algorithm gets its name. Steps 2 and 3 give me the maximum value of how good the other player’s next move will be for each of my moves, and I pick the option available to me that minimises this. In other words, I’m trying to paint the other player into a corner as much as possible, such that even their best option is poor.
This process can be extended further into hypothetical futures. Instead of thinking two steps ahead (my next move, then the other player’s next move), you could think four steps ahead or even further. The further into the future you look, the more likely you are to win – assuming your scoring function is accurate and your opponent acts as you assume. However, doing this makes it more expensive to compute, as the number of options to consider grows rapidly with each further step into the future.
Analysing conversations
We now return to the matter at hand – conversations. As a system, the important aspects are:
- There are two or more people;
- Each person has their own agenda (which can be thought of as their requirements);
- What people think and say is a function of their current context (which is a combination of many things such as their agenda, what they know, how they’re feeling etc.);
- This context can change over time, e.g. over the course of the conversation.
As I said, I’m no expert, and this is probably hugely simplistic and reductionist. But let’s see where this goes.
With this list of aspects, and inspired by the example of the minimax algorithm in chess, a conversation can be described as a collaborative multi-player game of chess with fuzzy rules. This is probably not the clearest way to describe things, so I’ll try to expand on it a bit.
Unlike a game of chess, there could be three or more people playing (the multi-player part). When I’m in a conversation at work, I try to help everyone involved get as much out of the conversation as I reasonably can. I.e. instead of one person winning (meeting their requirements) and everyone else losing, I’m trying to help everyone win as much as possible. This is the collaborative part.
Another difference between a conversation and a game of chess is the choice of what to do next. In chess there is a very clear set of rules that say what moves you can make next. Once you have learned the rules, the difficulty mostly comes from picking which move to make. For instance, it’s not legal for a pawn to jump from one end of the board to the other, but it is legal for a rook to do this.
In a conversation it’s not nearly so clear cut. Instead of a binary division into possible / impossible, the context someone is in will make some things they could say or do more likely and other things less likely i.e. the “rules” are fuzzy. As much as you’re able to affect someone else’s context by what you say or do, one way you could help them to win is by putting them into a context where the most likely things for them to say or do next will help them. I.e. you’ve painted them into a corner where their most likely next action is to win. (At the risk of overloading the metaphors, this action via massaging probabilities reminds me of quantum computing too.)
Using the model
I’ve explained the model of a conversation a bit, but how does it help?
There are a couple of simple things I’ll deal with to start with. First, if you insult someone or frustrate them, their context will probably be dominated by the fact that they’re upset. This will probably make it much less likely that they will move anyone (including themselves) in the direction of something useful. Instead, you have made it most likely that they will lash out, ignore the tasks at hand or something else understandable but unproductive in terms of the meeting’s agenda etc.
Among many other things, this is inefficient in terms of time, happiness etc. As programmers, one of the things we worry about is efficiency. Deliberately or accidentally annoying people can a source of inefficiency for the conversation, so keep an eye on this kind of thing.
Another thing to note is that, like minimax for chess, this algorithm depends on its scoring function. The scoring function is how you predict how each person in the conversation is likely to react given a certain context. The scoring function is implemented in your brain rather than in code, and it’s an area where you can improve its effectiveness. (Effectiveness is the other main thing programmers worry about.)
Getting to know people better, and appreciating how they’re different or similar to other people, will help you. Paying attention during meetings, even when you’re not e.g. asking or answering a question, can also help. Mentally reviewing meetings afterwards, to see what went well or not and why might help too.
Optimising locally or globally
One thing to consider is the scope of how you optimise things. It might be that you realise something like “Chris wants to understand X, so I’ll say something that explains X.” This is a nice local optimisation – you’re addressing the need directly via the next thing you say.
However, it might be that even the best way to explain X will be confusing to Chris. So even though you think you’ve ticked the Chris understands X box, you haven’t. Then you get confused because you think your work’s done, but Chris is still banging on about X and asks what seems to be the same questions again etc.
It might be that you need to lay some groundwork first, by explaining A, B and C. Assuming each of these explanations is understandable, and together they put Chris into the context where an explanation of X makes sense, then this is the globally optimal way of doing things. It takes longer to get to the first attempt at explaining X, but there’s no extra chunk of conversation on the end where people are confused about what issue we’re dealing with, clarifying questions are asked, further attempts are made to explain X etc.
This is something that is worth practicing – learning how to plot the most efficient path to help people get to where they want to be, especially if this goes through places that aren’t immediately obvious, where sub-goals are achieved on the way to a main goal. It’s things like identifying the thing that is most getting in the way of their understanding something. For instance, they need to see how X is different from Y, or X is enabled by Y etc.
Digging out the requirements
There are two important kinds of requirements in a conversation. There are surface-level requirements, such as:
- We need to decide what to work on next
- We need to agree the best way to do something
- Etc.
There are also more hidden requirements, which still influence the context of people in the conversation. This is things like the need to feel respected, the need to get a fair share of time or other resources etc. It might seem obvious that all people have this kind of requirement, but unfortunately too few people act accordingly. Who gets their turn to speak and when – who decides this? Who feels able to interrupt whom? Whose opinion seems to carry most weight and why?
You may have been in a conversation where you have something to contribute that you know would be useful, but Dave is hogging the conversation as per usual and he doesn’t realise he doesn’t know what he’s talking about here but won’t shut up. Or you’ve been in too many meetings where what you say is ignored, or you’re interrupted, or someone else takes credit for your ideas. So you stay silent. This is understandable but makes the conversation less effective (the contribution is missed out), less efficient (it takes other people longer to make them same contribution), or both.
If you have any power in a conversation, it’s in your organisation’s interests if you use that power to keep it as effective and efficient as possible. This includes correctly handling the hidden requirements. (This is on top of other consequences outside of conversations, such as people getting so fed up that they leave.)
Going back to the surface-level requirements, even these might be hiding better requirements underneath. What people think is a requirement might be a solution they’ve unknowingly landed on to more fundamental things that are their real requirements. For instance, someone might ask if a system can download some data as a CSV file. You say: no, it doesn’t. It might appear that the conversation has reached a dead end – you don’t want to lie about what the system does, and you’ve answered things clearly and correctly.
However, the person’s requirements might really be to get data from your system to another, and a CSV file is what they’re used to for doing this. Maybe your system supports an API that allows the data to be read. So you might need to ask questions that dig into what someone says, to clarify what their requirements are, and what are merely solutions that they’ve assumed into existence.
This is a skill in its own right – helping someone to get a proper understanding of their requirements and expressing them well. Note that this can include helping someone to realise what they don’t want, or what’s less important than other things.
You could think of this as a mini conversation inside the main conversation: what is the most efficient and effective way of unearthing the true requirements via a bit of conversation? Is there one question that would help them to unlock the knowledge that they want X rather than Y? Or do you need to get there gradually? Standard considerations apply here – if you avoid making the other person feel stupid, demanding or other stuff like that then everyone will get somewhere productive more quickly.
A warning
You might be feeling that this is all a bit manipulative – it’s almost like you’re trying to trick or manoeuvre someone. I think that this is a healthy but not completely valid reaction. It’s healthy because I think this kind of reaction points to a respect for other people, that wants them to be treated well.
I think it’s partly but not completely valid, because it depends on some context. If you’re trying to help people, then using these tools is OK to me. If you’re doing it because of a need to exert power or control, then I’m less happy with that. It’s like in web design – the same understanding of user experience can lead to a happy user or can turn into dark patterns.
Summing up
People go into work conversations with different requirements or agendas. The conversation can help them get closer to this or further away, and this process can be more or less efficient. Navigating the turn taking, identifying people’s requirements, and then plotting out the most efficient and effective way of nudging people to where they want to be is a skill that you can get better at with practice.
However, as I’ve said more than once before on this blog, people are complicated and messy! Conversations can be messy too. If you mess up, try to reflect how you could do better next time.
Random Tech Thoughts 