‘So, how’s your week been?’
‘Not bad. The project is going pretty well, the client seems happy.’
‘Sounds like it’s going well. Do I hear a but in there?’
‘Yeah, there’s a couple of people on the team who are a bit difficult as always.’
‘Ah. What do you mean?’
‘Well as an example, one of the Android developers never turns up to stand ups and I never really know what they’re working on or what they will deliver at the end of a Sprint. We’ve had a couple of run-ins about it to be honest, and I think it’s affecting the whole team. It’s a risk.’
‘Yeah, don't people always hate meetings. But what you said about the developer being a risk to the project, is that true?’
‘Yes, I reckon so.’
‘But you started off by saying the project is going well. So how do you know what you’re currently thinking is true or is it an assumption?’
‘Well, no, when you put it like that, you’re right, I can’t say for certain. They do seem to be a good developer and the tech lead is happy with how the code reviews are going. They get on well with the rest of the team and overall the dev work is on track.’
‘So can we say this is a fairly low level problem, but it's creating friction in the project team and it's clearly bugging you. So let me ask you something else. How would you react if your assumption is true? That they don’t really care about process and are messing up the project?’
‘Ah, deep frustration, I guess. That they don’t respect the process and I am wasting my time. Also that we’re working really hard and they might affect delivery, which sucks.’
‘Fair enough. So…what if your assumption about this person is not true?'
‘Hmm. That would be good. I’d be relieved. Definitely less stressed. Confident the team is doing a good job. I’d feel I didn’t have to chase the developer the whole time or think about what they’re doing.’
‘Right. So try this. Flip your assumption on its head. What’s the opposite of what was your original thought?’
‘Err. Well I guess the first part is that the developer is going a good job. That they’re not purposely ignoring my meetings, but might have their own style of working. That they're not a risk to the project. Something like that.’
‘It’s not particularly easy to think about the opposite, as all our brains are interested in doing is convincing us that our original thoughts are true. But next time you get a ‘tricky moment’ on a project, try taking a step back and look at the problem through those questions I just asked you. It’s a really, really simple technique, but it can have quite a bit impact on how you behave and how smoothly the project and project team runs. It can get rid of ‘friction’ on projects without anyone even noticing.’
‘Nice. I like that. But just to go back to the situation I mentioned - so what do I do?’
‘Well, test out some ways to solve it based on the opposite of what you originally thought. I think we’re saying the developer is good, contributing to the project, but isn’t really thinking about prioritising their work or that you might need that information. Could you prioritise all of the backlog together? Could the dev lead help the developer select the highest value tasks? There’s quite a few options which you could try out. Can you change the format or time of the meetings to make sure the developer is more actively involved?’
‘Nice. That’s actually really helpful. I will try that out.’