This is a transcript of episode 316 of the Troubleshooting Agile podcast with Jeffrey Fredrick and Douglas Squirrel.
How can you do risky experiments even in the most risk-averse organisations?
One-Way vs Two-Way Doors
Squirrel: Welcome back to Troubleshooting Agile. Hi there, Jeffrey.
Jeffrey: Hi, Squirrel.
Squirrel: So we got something that always gladdens our hearts and makes us very pleased and excited, which is an email from a long time listener! And as I always say at the end of the podcast, we love hearing from listeners. And this one, Roland, had some really interesting new concepts for us. So, Jeffrey, do you want to summarize?
Jeffrey: Yeah, absolutely. So in our last podcast we were talking about slowification. And before that we talked about butterfly ideas, we may have mentioned them in there as well. And the idea of having shared language you could use to kind of tell people, to put them a certain mindset. And we asked listeners to give us their examples of shared language that could be used to kind of change the mindset of the room.
Jeffrey: And Roland offered these, and he actually was borrowing it from Jeff Bezos. And it’s the idea that decisions could be like one way doors, or they could be like two way doors. And it’s important to know which one you’re dealing with, because one way doors are kind of irreversible. This is maybe like, you know, jumping off a cliff or something like that. You know, you’ve made your decision, you hope it’s going to work out, but it’s kind of hard to go back. And we’re thinking here-
Squirrel: Just to be clear, because it may not be cross-culturally consonant that we’re talking about a door that might, you might have like leaving a building and you can’t get back in because you have to go back through security. So the door kind of locks behind you. That’s a one way door. A two way door is like a normal door that isn’t super secure, and you can just go through it either direction whenever you feel like it.
Jeffrey: Yeah. That’s right. There are other decisions that are like that, that are two way that you can you can walk through to one side, decide if you like it or not. And if you don’t, then you can go back. And the key insight here is: don’t spend a lot of time debating decisions that are two way doors. You don’t need to agonize about it because there’s low cost to come back. And so the kind of first order benefit from this concept is to save time.
Jeffrey: And I can think of an example where we were at a company and there was a big debate about how some feature should work. And the debate went on for about two days until finally, in frustration, one of the engineers said, ‘you know, okay, fine, you know what? We can go try it!’ And then the question is, ‘well, how long do you think it’ll take?’ And he said, ‘well, probably about four hours.’.
Jeffrey: So we had just debated much longer than it would have taken to just go try the change and see what happened. And that’s a great example of treating a two way door like a one way door. We just should not have debated. We could have been much easier to go try it and then come back. So that’s that’s the word, the special language, the key word from from Roland. I think that’s really useful. What what do you think, Squirrel.
Squirrel: Well, certainly very useful. I’ll start using it immediately. One thing that I often have to clarify for people is that even more extreme than the example you gave where you said, ‘hey, we could just go try it.’ As long as there’s some way to undo the change and you’re not going to have some permanent effect on the universe, that’s worth doing.
Squirrel: But you can also do a lot to make that simpler. The the kind of classic thing to do is something called feature flags, which is, for those who are less technical, it’s a way of putting something in the code that allows even ideally non-technical users, administrators, to turn something on and off. You can say, ‘oh, give Squirrel the new experience, but don’t give it to Jeffrey. He’s too nervous. He’s doesn’t like new things. But Squirrel, he’s willing to try new stuff!’
Squirrel: So you can turn it on for particular users. You can turn it on and off for individual groups, or clients, all the users at company X, or everybody in North Dakota, that kind of thing. And because you have that finer grained control, it can often turn something that seems big and scary. ‘We’re going to change the login experience for every user’ to ‘we’re going to change the login experience for this user who’s only going to be using it in tomorrow’s sales demo.’ That’s much less scary.
Squirrel: So I’m often counseling folks to do that, but I’ve even done much more radical things that I’ve mentioned here on the podcast. Such as, at one company where I was CTO, we put in place a huge red button and the huge red button would undo whatever we had most recently done in development. It would switch back from our previous release. And because we had this button, it meant that we could release new stuff that broke our website! It meant that nobody could buy anything from our e-commerce website.
Squirrel: The reason we felt brave enough to do that is, first of all, our users were really committed, so they would keep trying. They wanted the cheap deals that we had on our website, so if it was down, they’d just blame their Wi-Fi. And in that few moments of it being down, we would get all kinds of alerts. The customer service people would start shouting, we would know that we had broken it, and we could hit the big red button, and instantly it would come back for all users. Now that was some technical investment we made. Just like you might make an investment in feature flags, but when you make that investment, you make a lot of one way doors or things that seem so into two way doors.
Jeffrey: Yeah, I love that. And I like this because it has both that sort of technical application, where you can do things to make it technically easier to convert the things into two way doors.
Creating Social Two-Way Doors
Jeffrey: And I think you can also do it kind of socially, I think that’s one of the things that happens when you start talking about the language of experiment. You say, ‘well, let’s go try this, let’s experiment with it.’ You’re talking about a process change, is the kind of thing I have in mind. And you say, ‘well, let’s let’s have a daily stand up’ or ‘let’s have a retrospective’ or ‘let’s change our design process, the way the collaboration works,’ or ‘let’s have breakdowns and bring product and design and developers together.’
Jeffrey: The difference between saying, ‘I want to change our process,’ which may people may feel is like a permanent one way door kind of change. If you say, ‘I’d like to experiment with it, and we can review after four weeks and decide what to do next,’ you’re kind of explicitly making it a two way door. So there’s kind of these social elements as well. I like both sides of it. You know, one thing is, as you’re describing the technical side, I’m actually for the last several months been experiencing this on a very big scale, which so people don’t think this is just like a startup kind of thing, but, at our work, we use Microsoft Teams, and Microsoft has a-
Squirrel: I’m really sorry, Jeffrey. I’m sorry you have to put up with that. Zoom is so much better.
Jeffrey: I actually- Well, people have strong opinions about these things. Some people are very wedded to slack or whatever, but, you know, it’s it works. But the thing about it that’s relevant here is, they have this new version and they’ve been very explicitly offering this sort of two way doors to users. Saying ‘there’s a new experience coming for teams. Do you want to try it?’ And you can opt in and you try it. And then if you have problems, the next time you restart teams, it asks you, ‘do you want to go back to the classic version.’.
Jeffrey: And so you you always have that kind of option of moving backwards and forwards while they kind of work things out. So they’re getting the ability to go and learn from the people who want to try it while not trapping anyone in it. And this is a this is a great example of taking something that feels like it should be a one way door. ‘We’re going to move all of our users to a completely different experience! The UI is entirely different!’ And, in fact, making it two way.
Jeffrey: And I’ve done the same thing. We’ve had updates to UIs that radically change the UI. And so we started by offering a,’hey, here’s this new tab, and if you go there, you get the new UI, but you can always go back to classic.’ And so lowering that switching cost explicitly makes it a two way door. And so this is a great concept. I’m really glad that Roland sent this in because it’s something you can start using immediately. Just asking, what kind of decision are we making it, is it one way or two way? And then beyond that, you can start saying, how can we make more of our decisions two way doors rather than one way doors. So really fantastic.
How to Manage One-Way Door Fear
Squirrel: And let me close with just one more story, which is more about the people than it is about the either the process or the code. I’ve got a client who is really resisting some of the new ideas that I’m bringing with the help of the technical leadership who’ve brought me in, and I’m bringing them this idea of elephant carpaccio, where you release new software every single day.
Squirrel: And this terrifies certain people, both within the technology organization and in the rest of the business, because they it’s almost as if the door has a big sign on it that says, ‘one way! Do not open. Only one way! Cannot go through this door! Danger!’ But when you go look at the hinges, it actually works both ways.
Squirrel: So they have had for a long, long time a company culture, a company philosophy, of not breaking stuff. And they believe, falsely, from all evidence that exists that their users will quit en masse if anything is broken, at any time because they exist in a sort of sensitive area of their users’ software. They work with large enterprise clients that do a particular thing that’s kind of important. And these folks slot into thag, if they break the larger component, then they think that these folks will, will fire them en masse.
Squirrel: But there’s two reasons not to think that. There’s two reasons to think that the sign on the door that says ‘do not go through’ is wrong. One is: they break stuff already! And the users haven’t haven’t all quit, so there’s some evidence to suggest that the current users aren’t like that.
Squirrel: And they’re trying to break into a new market! They’re trying to get to a new type of user, to a new type of person, who works at the company for whom the consequences of failure are much less. And in fact, a much more experimental part of the business. They’re moving to marketing instead of IT. And you know, IT folks tend to really want the stuff to work, and they really want to to make sure all of the technology keeps functioning just like it did yesterday. Whereas marketing folks are experimenting and trying stuff and throwing stuff at the wall to see if it sticks every day, all day. That’s what good marketing people do.
Squirrel: So their new users are much more forgiving, but they don’t know that, in their culture yet. So, one thing I’d counsel anyone who finds themselves in that situation to do, is to make sure you have the right executive backing and gone all the way up to the CEO who says, ‘yes, by God! Please experiment! Let’s break some things.’ And that’s a very helpful message. And then you have to repeat it relentlessly. ‘Yes, this is a two way door. This is something that we can experiment with. If we break it, we can always go back through. We can always go back to the old experience. Look at Microsoft. They’re doing it this way, and they’re kind of safety conscious. Let’s try this. It’s actually safe.’
Squirrel: Repetition and executive backing are really important for making that cultural change.
Jeffrey: Yeah, that’s a great point. And that actually, Roland did point that out, that in a lot of organizations, especially larger ones or older ones, kind of have built up a lot of scar tissue in their process. They they have stories they’ve told themselves about things that have happened in the past. Maybe they had a bad experience, and so they’ve built up a process that’s designed to avoid any of that happening again. In those cases, it’s really important to bring this in and start kind of massaging that scar tissue, start breaking it down to say like, ‘what do we really want here? Is it do we, do we do we really need all this protection? Are we getting the payoff from it?’.
Jeffrey: Especially when, I like your example, what you said is, we still already make mistakes even with the existing heavyweight process. So a lot of times people are nervous about the decisions they’re going to make, and they want to avoid those mistakes. And it leads them to be overly cautious, which slows the learning. And it avoids the fact that there’s also a limit to how good you can be at your decisions anyway. At some point you’re going to have to learn from experience. So better, better to be doing that more rapidly and have done so in a way that’s going to be safe, that’s very two way, than to force yourself to make it to read as like a one way thing. And to have processes that do make it like leaping off a cliff! So I like your story, both aspects of it, the cultural part, as well as the learning from experience part.
Squirrel: There we go. It’s one of those very natural cognitive biases. Jeffrey, you’re better with these than I am. But I’m thinking of things like loss aversion and and overemphasizing negative consequences.
Jeffrey: That’s right.
Squirrel: Whichever whichever one is, is operating, I’m not sure, but it’s that natural tendency for people to be conservative and cautious in environments where they don’t have to be. And to put up signs that say, ‘don’t go through this door,’ when in fact, going through the doors perfectly safe. So, let’s encourage listeners to try going through some one way doors, or apparently one way doors, the wrong way. We’d sure like to hear what experience you have when you try that. Come back next Wednesday when we’ll have another edition of Troubleshooting Agile. Thanks, Jeffrey.
Jeffrey: Thanks, Squirrel