This is a transcript of episode 188 of the Troubleshooting Agile podcast with Jeffrey Fredrick and Douglas Squirrel.
We discuss making radical change in an organisation by violating its norms in use and producing productive conflict.
Show links:
Listen to the episode on SoundCloud or Apple Podcasts.
Introduction
Listen to this section at 00:11
Squirrel: Welcome back to Troubleshooting Agile! Hi there Jeffrey.
Jeffrey: Hi Squirrel! We’re at the third of our three-part series, where I’ve connected from three of your tweets.
Squirrel: I’ve finally figured it out, I think I know why they’re connected now. You got me clear on it.
Jeffrey: As a reminder to our listeners. Two weeks ago we covered the observation that designers often find it difficult to adopt daily delivery, and moreso than developers. The question was ‘why?’ One of the reasons we identified was the norms within the group. Then last time we talked about norms that lead to people turning the same cranks all the time, and we said this time we would talk about how as a leader in potential or practice, how you can move people to a different way. The third tweet from you Squirrel, that inspired me, mentions that ‘consciously violating norms is often a (painful) route to productive conflict, reshaping norms, and more effective results.’ So tell me a little bit more. What do you have in mind here with ‘consciously violating norms?’
Shaking Things Up
Listen to this section at 01:38
Squirrel: Exactly what people hire me to do. When I come in as a consultant, I warn people that I’m a bit of a tornado: they should expect things to be upturned, people to be upset, some people to quit, and other things. I’m not a friendly, happy person who helps everybody feel better. I bring productive conflict and that can be painful. One of the ways I do that is I identify what the current norm is and tell everybody, ‘Hey, it’s time to do something completely different.’ It’s often very helpful to do something that’s exactly the opposite of what the norm is. Every one of my clients will recognise themselves in this example. A frim has the norm of a very academic approach to solving problems, to building software, and to working on new versions of the product. ‘Write papers make sure that everything works perfectly. Dot every I cross every T.’ The goal there is to get things morally or ideally right, rather than messily in the hands of customers, imperfect and learning quickly, and the frustration for everyone else in the business is ‘we’ve been waiting years to get results and this is glacially slow.’ So taking a leaf from your book Jeffrey, I said, ‘What’s stopping us releasing version two tomorrow?’ After everyone picked themselves up off the floor, they said, ‘Well, obviously Squirrel, there’s X, there’s Y, there’s Z, and so on.’ And I said, ‘just say those a little more slowly.’ We went through every one and we dealt with each of them, and it turned out that there actually was almost nothing stopping them from going live tomorrow. They didn’t go live tomorrow, but within a very short span of days we were able to disprove some of the long-held assumptions in the development team. Things like, ‘everyone wants us to get it right. If we make any errors, we’ll be in trouble.’ You can see exactly how this norm would then reinforce the academic approach. Then by violating this norm and saying, ‘we’re going to release this tomorrow. What will go wrong?’ I was able very rapidly and with a lot of conflict to identify what the actual barriers were. It turned out many of them didn’t matter. For example, the customer service people were over the moon with the idea that we might release a feature that didn’t work perfectly, and they would have to do some manual work to fix errors and problems and explain it to customers. They said, ‘That’s wonderful. Please give it to us. We’re ready for that.’ The developers were shocked at this response. ‘What do you mean? Don’t they hate it when we make mistakes?’ Well, the difference was here that they were being warned and they were getting a tremendous benefit. They were getting new things rather than waiting forever. They said, ‘Look, as long as it doesn’t take the whole system down for weeks, we can handle anything. Throw it at us. We’re ready to to stay here for hours and type things in manually and do other workarounds if it means that we can resolve these terrible issues that have been plaguing us for years.’ I’m happy to report that customer is now live with new changes and very proud of it, and it has had a very salutary effect. That’s what led to this tweet, this observation that if you look at what’s holding the organisation in place and consciously kick the supports out, you will produce total chaos for a short time. And from that chaos—if it’s done productively—you will get a lot of learning very quickly about whether the things that are holding the organisation stuck are valid or not. Most frequently, they’re not.
Improvement is Always Change
Listen to this section at 05:45
Jeffrey: Two thoughts come to mind in hearing that: for one, you can’t be better without being different. The second thing is not quite so pithy but an observation. I’m sure that for some people hearing this, negativity bias will make it sound crazy. ‘There are things we know we can’t do, and we can’t just ignore that.’ People might have this picture of you as a total cowboy throwing away information that is already known. I imagine that in reality what you’re doing is testing ‘which of these things do we actually have data to back up and which of these are just stories we told each other?’ These are different levels of knowing. Is that how that happens?
Squirrel: Absolutely. There’s also another level, which are things that we think we know which are true, but with lots of other factors we weren’t aware of. One firm provides a service for customers relating to a one-time event that will not come again. If you mess it up, you cannot go and do it over again, so there’s high stakes for customers who receive this service: if you mess up the one-time event, those customers will be very angry with you. That was the sort of message that the developers had gotten. ‘Hey, you caused our customers to miss this one thing that they can never do again, and they’re furious and they’re never going to work with us again.’ The developers generalised that and said, ‘Ah, we need to avoid all types of error because they’re all catastrophic.’ It turned out that there was much more nuance to that. The customer service people said, ‘Well, look, if we know these things might happen, we can mitigate them. We can go and look for bugs we know about. We’ll do a manual workaround to fix that.’ That was a step that the customer service people were perfectly happy to accept, but the developers had not validated their generalisation. They had just heard errors were catastrophic. ‘Our customers need everything to work perfectly for their one-time activities, so never make a mistake.’ That lesson was incorrectly learnt.
Jeffrey: What’s great there is you have the opportunity for this alternative path outside the hands of the developers, and maybe that was part of the issue: they were discussing the story amongst themselves and it was only when you had them talking with other people, when you had cross-silo communication, that when they shared that story it was challenged by alternate stories. I find that all the time. Alternatives come out in communiaction that don’t when people are left to themselves to make assumptions about what other people want. But backing up a bit, we’re talking about deliberately and violently violating norms as a leader. I think when people hear your description, they might say, ‘Well that’s great for you, Squirrel, because you’re this high-price consultant, you’re being brought in with explicit permission to make these things better. I could never do that because I’m not the executive or I’m not the consultant. I’m just a member of the team. How could I possibly apply this advice in violating norms?’ I don’t accept that because I have experience doing it where I’m not the executive and not the person being brought in. But I’m curious, do you have a response?
Can an IC Lead?
Listen to this section at 09:55
Squirrel: Oh, certainly. I was coaching someone on this today. She’s just come into a company and is still on probation, so she’s interested in keeping her job. I was advising her to really violate a norm, to do something in a way the company just never did before. In this case, to people uncomfortable, something I really like to do because it helps get to productive conflict and gets to a faster and better resolution. I was saying, ‘Yeah, so make them uncomfortable. Tell them that this may be worse for a short time, but that they will learn and that then life will be better.’ And she said, ‘That’s not how we do things here. I’ve only been here a few weeks, but this is a company that wants to make sure that everyone’s included and everyone’s happy and that we’re all one big happy family all together,’ and I said, ‘that’s not what you have come in to do. They haven’t hired you to make that happen. They’ve hired you to make these improvements in the team. My recommendation to you is mitigate wherever you need to be to protect yourself and feel comfortable. But if you’re so constrained by the norms of the company that you can’t take any radical step, that you can’t change anything, then why are you there in the first place?’ So I was pushing quite hard. I don’t know what she’s going to do. I’m going to find out. But I hope she’ll look for opportunities to shift the norms and maybe just change her own behaviour and be an exemplar for others and allow the rest of the organisation to see that there are alternatives. This is really challenging. I’m not suggesting this is easy at all, but the benefits are huge if you can find a way to do it that feels safe for you. You can implement what we’re talking about just by demonstrating that the norms of the organisation are not the only possible norms.
Jeffrey: I think we have two specific pieces of advice for how to go about this tactically. One, we had an episode about several weeks ago, how will the company decide. This was about how to handle when you are proposing something new that has trade-offs,how will the company decide which to do? I think some of the devices in that episode are applicable here. This second part can be combined with that, which is recognizing the two different kinds of norms at play. There is the normal behaviour people have, but there’s also the espoused values and methods that the organisation has as a whole. These things are often not totally aligned. Companies might say, ‘Oh, we’re Agile’ or ‘we want to be customer-focussed’ or anything else the company says they want. Frequently these are in conflict with the norms in use amongst the developers. Look for these mismatches and be able to talk about both of them and even be able to hold both of the norms as good. ‘Look, we do want people to be happy. That’s really important. We also say we want to be high-performing. Is there a conflict there? I think there’s the happiness that comes from being comfortable and familiar, and there’s the happiness that comes from being better and being effective. Those two things might be in tension. I’d like us to try to work on being more effective, and I think that would be happy for me and I think others would be happy with that also. But it might also be uncomfortable. How do we go about deciding what level of discomfort we want for what level of improvement?’ That’s a way of comparing norms. That example is not the only pair of norms, it could have been anything. But very often the question is about trade-off between different items which are both good things. The discussion is about this moment. ‘How do we want to shift the trade-off between these different elements?’ And I find that aproach of hilighting contrasting elements between fundamentally good values makes the conversation more productive than saying, ‘what we’re doing is bad. I have a good thing to do instead of this bad thing.’
Squirrel: Absolutely. This is advice I didn’t give my client, but maybe I should: she could look for ways to help promote greater happiness and satisfaction through better delivery rather than the simple satisfaction of ‘yes, I’ve managed to do the same thing today that I did yesterday.’ That’s a good thought. I will consider that for her when I see her next.
Jeffrey: I think this is one of the big elements of leadership, the storytelling of the things we value. In these examples, the leaders are the ones who are saying not just ‘these are the norms,’ but also why we have these norms and build alignment: they create a shared vision of why these trade-offs are ones that we would value. So that’s what I had in mind with our three-part series. To walk people through it, we started with designers who were uncomfortable going to daily delivery, and guess what, discomfort is often part of what happens when you want to get higher performance. That got into our our second part, which is about moving away from turning the same old cranks towards the desire for improvement. That left the question how you go about building that desire, and that was our topic today: how you start violating norms and discussing violations of norms to hopefully start shifting towards a different approach. I think this has been a great topic for us, even though you didn’t tweet these ideas all at once and together.
Squirrel: Thank you for connecting them in this way. I hope that’s been helpful to our listeners. Thanks, Jeffrey.
Jeffrey: Thanks, Squirrel.