This is a transcript of episode 315 of the Troubleshooting Agile podcast with Jeffrey Fredrick and Douglas Squirrel.
You know investing in skills or tech advancements will speed you up, but how to make it happen? Convincing your boss is all kinds of wrong!
Show links:
Listen to the episode on SoundCloud or Apple Podcasts.
Want to Slowify? Find the right person
Listen to this section at 00:14
Squirrel: Welcome back to Troubleshooting Agile. Hi there, Jeffrey.
Jeffrey: Hi, Squirrel.
Squirrel: So, Jeffrey, I think you have a story for us, related to our old friend Gene Kim.
Jeffrey: Yeah. That’s right. We just had the Christmas holidays, came back to work, and, one of the people who worked to me, he didn’t listen to our podcast, but instead he read the book. He read Wiring the Winning Organization. We just talked with Gene Kim, just before the Christmas break,about the book. And in one of the things we covered in there, was we covered the three methods in the book they talk about for rewiring the organization.
Jeffrey: And the person who works for me. He said, ‘he really liked the book,’ and he says, ‘it really sounds great, but the question I have is, one of the methods is slowification. It’s like, how do we ever get management- How do we get the business, the executives, to buy off on the idea of slowification? Because, as you might imagine, our executives are very much about time to market, getting things out fast, getting things done.’ And and that phrase, slowification, you can see why people’s immediate reaction from the business might be like, ‘go slow? On my watch? Never.’ And I just thought that was a great formulation.
Squirrel: I gotta say, I’m not sure that was Gene’s absolute most brilliant moment was coming up with that particular name, but it got our attention and it obviously got your team members attention. But we better tell listeners what it means so that they don’t all switch off and say, ‘Squirrel and Jeffrey have gone mad. They want us to go slower,’ because I don’t think we do.
Jeffrey: Not at all. Not at all. And if you want to hear the explanation, it’s in that second of the three part series with Gene and I will remind people that it’s a the idea is about doing your sort of problem solving and experimentation, taking that out of production and doing it as a deliberate experiment. Rather than trying to do it while also delivering at the same time. And my favorite example in the book is the MIT sailing team, where they go to Regatta. most of them had never been on a boat.
Squirrel: MIT, not known as a major sports university here.
Jeffrey: That’s right! Exactly. And they’re in their first race and they encounter some problems. And what they did, rather than trying to muddle through, is they stopped and they say, ‘okay, we’re going to stop sailing badly or disastrously, and we’re going to and we’re going to figure out our immediate next steps that we think will be an improvement over what we’re doing now.’ And that idea of like, we’re going to stop and improve right now and then get back to sailing, is a good example of the idea behind slowification.
Jeffrey: You’re changing kind of the nature of work. You’re changing the hat you have on from I’m going to try to get something done, I’m going to try to paint the walls and learn and problem solve at the same time, versus let’s go ahead and have some deliberate focus, experimentation and problem solving and then apply it quickly. And that’s what he meant by slowification.
Jeffrey: That’s the question is though, is how do you make that case to business stakeholders who really just care mostly about speed? And that’s the challenge. I thought it was a very worthy one and very appropriate for the podcast.
Squirrel: Oh, certainly. And I’ll say one thing that strikes me about it, but it’s not the thing to start with. I just want to make sure I’ve understood it right. If I understand it with a non-technical hat on, I’m thinking of things like in-service days for customer service representatives who will go and have some training on a new product or something. They don’t do that by answering phone calls from actual customers trying to use the product, and they go, ‘oh yeah, let me flip to page 94.’ They go away and they read whatever the new thing is, practice with each other, and then they go back on the phones and they actually support the new product. So I think that way of thinking about it is helpful, but it’s not the place to start.
Jeffrey: Okay.
Squirrel: And the reason it’s not the place to start, is that if you’re worried that an executive who is in charge isn’t going to trust you enough, isn’t going to understand it well enough for you to go and do whatever your slowification task is, learn Docker, or get better at unit testing or whatever it is that you want to do. Then you have a bigger problem, and going and explaining it to them more is unlikely to help.
Jeffrey: Hahaha…
Squirrel: I’d say there are a couple of things that I would counsel your team member to do. The first one is, make sure you’re talking to the right executive, because when I have clients come to me with this kind of question and they say, ‘how can I take this initiative?’ I say, ‘are you talking to someone who is responsible for the profit and loss of your salary? Because that’s what you’re trying to improve.’
Squirrel: We want to take the utilization of my salary and my teams and whoever else it is. And make that greater, we’re going to get more profit from that activity. There are people in the business who don’t care about that, and who probably shouldn’t care about that. They might be your peers in another organization, or they might be other parts of the same technology organization or somebody who’s just a little further down the food chain. And that person says, ‘hey, look, I just got to make my sales quota-‘
Jeffrey: Yeah hahaha.
Squirrel: ‘-And you know what you used to be doing? You know, where you got out a paddle and you paddled the boat, and instead of trying to do the sail thing? That was fine! Just keep doing that.’ And you’re not going to get very far with that person. However, the person who says, ‘I’m spending all this tremendous amount of money on technology and it sure doesn’t seem to be going as fast as it could, and you come along and say, I could make it faster.’ Then you’re talking in their language. You’re talking about something that matters to them. So that would be my first one. I got more. But, Jeffrey, how does that sound to you?
Jeffrey: I think you’re exactly right in what you described is very much the approach that I use. And that I also canceled other people who were talking about this, which is, I you notice what you said was, ‘hey, I can help make this go faster.’ You’re selling the result, not the activity.
Jeffrey: And I think one of the things that you’ve times talked about many in the past, and certainly in your newsletters and in your workshops, you’ll talk about how the technologists have the obligation to connect what they’re doing to the business and not just use a lot of technical jargons and say what they’d like to be doing. They need to explain what the business impacts are. What I tell people is, I never use the phrase technical debt with the business. You know, I don’t say ‘we need to pay off technical debt, because that doesn’t mean-‘
Squirrel: Or refactoring! Please don’t say refactoring! Could everyone please stop saying that!
Jeffrey: To the executives!
Squirrel: Yeah, yeah, exactly! Talk about it amongst yourselves!
Jeffrey: Yeah, exactly.
Squirrel: Pity’s sake, it sounds like it sounds like the bare meaning of slowification. It sounds like, ‘oh my God, I’m not going to see them for six months!’
Jeffrey: Yeah. That’s the concern, and even the experience that some executives have had in the past. So they’ve kind of built up a negative response to people who use these phrases, in part because they haven’t delivered. And so what we’re selling here, even though it’s slowification, the outcome is, we’re doing this to go faster. I might say to people, and certainly have said to executives, I’ve quoted, Colonel Boyd with the line, ‘slow is smooth and smooth is fast.’ We’re doing this because our ultimate goal here is to go faster.
Jeffrey: Completely agree with you, that’s where you start as the first point that you’re making. And your point was, you make that to the person who cares most about it, which is the person who has the penal attached to your salary. I love that that’s the connection I hadn’t thought of before.
Have the trust conversation
Listen to this section at 08:03
Squirrel: And then after that, after you’ve identified the right person, the next thing you have to check is not whether they understand the analogies about ships and sailing and so on, or whether they do this in their own customer service department. That’s coming later, because the first thing you got to check is exactly what you said, Jeffrey, have they been burnt? Do they trust you? Do they even know who you are?
Squirrel: Because if you haven’t had the trust conversation and we’ve talked about that tons on the podcast, it’s chapter three of our book. I mean, we can we can go on about test driven development for people, if listeners would like us to. But if you haven’t had that conversation so that you understand what their motivation is, and what their language is, and their reasoning that has led them to ask you, for instance, to deliver much faster or to paddle the boat or whatever it is, you’re going to be in a lot of trouble! Because you can’t you can’t use their language, and you can’t describe how what you’re proposing will solve their problem. In fact, what you’re proposing may not solve their problem! It may actually be that they’re right.
Squirrel: I had a client who had a conference. They had bought the balloons, they booked the ballroom and so on. And they had told everyone that the API would be ready. And the engineers were saying, ‘oh my God! The API can’t possibly be ready for that. I don’t know why you did that. That’s impossible.’ But they couldn’t phone up their major customers and say, ‘we can’t do it.’ The solution they came up with was not to build it on time, nor was it to go away in a corner and figure out how to build it faster. It was to build a simple demo version of it, which they could show on the stage, which turns out to be all they actually needed to do.
Squirrel: So by building trust and understanding what the marketing department actually needed to do for the conference, they got to a stage where they could deliver something that actually built a lot of trust, and then they were able to do more of this investment. So we’ll come back to how you talk about the investment and where you get with that. But I’d say the very most important first thing to do is, once you found the right person, is build the trust. And if you’re not sure, go talk to them! Have a trust conversation. Make sure that they are actually interested in making a greater profit from your salary. As they might have a very rational reason not to.
Jeffrey: Yeah. Absolutely. So understand context, have that conversation. All right. Now what? I love this. This is great. Part one, part two, part three! What’s next?
Be accountable, communicate effectively
Listen to this section at 10:23
Squirrel: So maybe we should have done three episodes. But the third part for me, is then being accountable. Now long time listeners will know that every time somebody says ‘hold somebody accountable,’ my face turns green and I start vibrating and alarms go off and on my forehead. Because I don’t like the idea of being ‘held’ accountable because it sounds like blaming someone, and you want to hide under the table when when you’re being ‘held’ accountable. But if you are ‘being’ accountable, it’s coming from you, to the other person. If you’re rendering an account about your progress, I think that’s absolutely valid and vital.
Squirrel: And the danger I see sometimes when someone has figured out, I got a real business case here, I’ve got a profit and loss reason to do this. I’ve got other people on board, maybe I twisted their arms, maybe I use their language, somehow I got them to agree. Hallelujah! Now I can disappear for three months and go and read a whole bunch of academic papers and hold a lot of meetings and think about it. It’s as if those folks on the boat kind of sailed the boat or paddled the boat to shore, got off, went and had a whole bunch of really nice lunches, and met for a while and discussed it, but never showed anyone that, you know, using this sail in a slightly different way would actually make the boat go faster!
Squirrel: So the thing I would strongly counsel your team member to do, and listeners who are in the same situation, is make sure you structure things so it’s really clear and there’s a simple, easy to follow mechanism by which you can say, ‘we may be doing a technical task over here, but rather than blind you with science, we’re going to show you the first result or we’re going to give you information about how far we are, or we’re going to give you the early tests that show that we can make our website this much faster.’.
Squirrel: Whatever it is, you want frequent and clear communication about your progress because you don’t want to erode the trust.
Jeffrey: Yeah. And I’ll say the thing when I hear you describe this, is that the saddest case for me isn’t the time that people have maybe lost focus and gone in more of an academic exercise where they’re really not making progress. But the saddest case has been when people have been very effective but bad at communicating. So they’re making changes that-
Squirrel: To be clear, both of those are sad! We’re not counseling you do either of those, but the second one is worse than the first.
Jeffrey: It’s worse than the first. And there’s been times where then the management or business team come along and have lost patience and are like, ‘okay, you’ve had your time. We’re done. We need to get back to the way we were working,’ and undoes changes that, that were being worked through because they just lacked visibility. So in other words, it’s not-
Squirrel: Forget those unit tests! They just slow you down so much. Nobody can ever get better by writing unit tests. Let’s just write some old style code, alright. But meantime, you’ve got just to the stage where writing tests is actually making you more productive.
Jeffrey: That’s right. And that’s been the saddest case, is when people have done the right thing as far as what they are working on, making real progress on solving the problems. They just have missed this stage of sharing in a way that, and this is the key part, in a way the business would understand and value it. And even if you say like, ‘oh, yep, we’re up to 100 test points, you know, we now have 5000 assertions. Our code coverage is now 70-‘
Squirrel: How many customers have bought code coverage from you recently. Zero!
Jeffrey: Not a lot, but so finding the things that people will value, that’s part of your, in my belief, your responsibility in this exercise is understand what other people value, making the effort to understand that, and then communicating in ways that they will understand and value. So completely agree that being accountable in this way is is essential.
Squirrel: Well, let me tell you just one other, and tell listeners, one more client story because it kind of brings these together, particularly the final point about being accountable. I had a biotech client, really innovative, doing amazing stuff to discover new drugs, curing really important diseases that kill lots of people. So really, really important work and highly visible to the board of directors who were very interested in making sure these drugs actually came to market.
Squirrel: One of the people I was coaching was in charge of the lab. Now, I’m no biologist, right. I did not do well in biology in high school, but, I got to know a lot about how people test drugs, which involves animals and giving them diseases and then curing them of the diseases and doing all kinds of complicated toxicity checks and all kinds of other things. And they had, I kid you not, a 47 page, 79 step flowchart to end all flowcharts that showed all of these complicated steps that were between, ‘gee, this drug might be good,’ which is the innovative part. They were discovering the new drugs. And ‘yes, we should give this to some humans to see if it doesn’t kil them and makes them better.’
Squirrel: And it was impossible to follow this thing! But the person in charge of the lab who understood it intimately, had drawn it, and lived it, and breathed it. She was constantly referring back to it and saying, ‘well, you’d like to know where we are, well, we’re hard at work on step 47, and for that, we’re going to need these resources. And, you know, we’ll see in next quarter when we get to step 72.’
Squirrel: And the rest of the business was just unable to follow any of this. And unable to help, which is where really paid off because she was doing a lot of not necessarily slowification, but of investment and improvement, across these steps. But nobody could see it. So we simplified and created a incorrect- mostly correct- directionally correct summary, that was like four steps. And so it was very easy to see where each drug was, and which ones were ahead, and which ones were behind, and which ones maybe we should drop and so on. And she would report regularly against that.
Squirrel: We also found all kinds of places where we could help her to invest and slowify and do other good things, like maybe we should order more mice for lab number two, or maybe the person who’s bored in lab number three should switch over to lab number one, because their skills are needed. And we could move faster on these three very promising drugs. So, what she was able to do with a little bit of help was to define much more clearly what she was doing, be accountable for it and get help. And I think that’s one of the big benefits that your team member could get by talking to the right person, making sure that trust is present, and accountability is present, and then that person could actually help you and give you more of the resources or the training or the people that could actually help you get the benefit from the slowification you want to do.
Jeffrey: That’s fantastic. And I can kind of say this conversation I had with my person was earlier, but we’ve since moved ahead and I could effectively say we’ve been putting your- without having heard it, we’ve largely put your playbook into practice in the past week, and we are seeing the kind of results you predict. And I think one of the things I want to focus on about what we do, is we have a daily meeting where we’re talking about progress. And one of the things we’re saying is, that there should be visible flow coming out of it, because essentially, in this idea of being accountable, we can kind of say day by day, ‘this is the progress that’s being made. And here you’ll know it’s working because you’ll see things coming out the end. And can you see the things that have happened over the course of even this week.’ And we will have regular accountability week by week on the progress.
Squirrel: So, so glad to hear there’s frequent cadence there, that you’re making visible progress. You’re on the boat saying, ‘gee, if we pull on that cable, what happens? Oh, it slows down. Great. Our progress is: we slowed it down more. Alright. We know not to pull on that cable again.’ Even negative results are very confidence building and trust building because they show that you are being accountable for the things that you’re trying. I’m really pleased to hear that.
Jeffrey: Yeah. That’s right. I’ve had this conversation with many people over the course of the week, where I was emphasizing this point of daily cadence and that because it seems like there’s a lot of things that come up every day. Something comes up every day. It’s like, ‘wait a minute, this is not right!’ And it’s like, ‘good! Yes. That’s why we have this way to look at it daily, so we find mistakes daily, and can fix them daily.’
Jeffrey: That’s the process working!
Jeffrey: And they’re like ‘oh!’ It was like a light bulb going on. ‘Right! That’s why we have this focus and daily accountability is, we get a little bit more insight every day.’ And other people can come up with ideas and, and volunteer them and add value to what’s happening. Whereas if it had been in that sort of off in the corner, it could not have been as effective because we wouldn’t have had the input from everyone else, and we wouldn’t have had the trust building element as well. So, I’m glad that before having had this conversation, we’ve put something in place that I think follows the guidelines you’re describing quite well.
Squirrel: Well, fantastic. And uh, maybe the way to summarize that is to say that slowification should happen outside production, but not out of sight.
Jeffrey: Yes, I love that.
Squirrel: Great! Come back next Wednesday when we’ll have another edition of Troubleshooting Agile. Thanks, Jeffrey.
Jeffrey: Thanks, Squirrel.