The One Constant with Don Gray
Episode 25
Change is hard, unpredictable, and downright complex. Getting people or systems to change is not easy and certainly not done in a vacuum. In this episode of Programming Leadership, Marcus and his guest Don Gray enlighten listeners regarding the world of software development, the reasons for implementing software changes and why it’s not as easy as people may think. And while doing so, the pair attempt to arm their readers with a variety of change literature that will have them thinking of containers, systems and exchanges in a whole new light.
Show Notes
- Change is complex
- Reasons for change – need for improvement, conformance, changeability
- Software development is not linear and not deterministic
- A software change is invisible and not physical so it is rather difficult to visualize
- Prediction of how things will work is difficult
- Retrospective Coherence – looking backwards after a change has been made
- Thinking in Systems – people don’t tend to think in systems
- Containers hold focus
- People notice events and plot those events to see trends
Links:
Transcript
Announcer: Welcome to the programming leadership podcast where we help great coders become skilled leaders and build happy, high-performing software teams.
Marcus: Welcome to the show, programming leadership. I am so excited to have my close personal internet and in-real life friend, Don Gray here with me. Welcome, Don.
Don: Thank you. It’s it’s great to be here and to actually exist in space time.
Marcus: Space time. All right. Don, I didn’t tell you what this was going to be about, so I’m just springing it on you in real life. This is live without a net, people. So listen up. Don-
Don: Do not try this at home.
Marcus: Do not try this at home. Don, I hear so many leaders who want to produce change in their organization. And they think that producing change is something like producing software. But I feel like change is, it never really works out well. How should we think about change?
Don: Well, so in some ways, change happens, like producing software. You have an idea of what you’d like to have at the end, but you’re not really sure how to get there. There’s multiple people involved. Um everybody sees the final state slightly differently and wants their little piece of it, uh it takes longer than you think it’s going to. There’s usually a fair amount of pushing, screaming, yelling-
Marcus: Crying.
Don: … running around with your hair on fire. Actually, um I’ll have to look that up. Maybe, we can add it to the minutes after this as well. I have some friends from South Africa, and she told me about raspy running around with my hair on fire as a software development method. I forget what it was. I came across it the other day, and I was like, “Yeah, I remember that.” And that’s kind of how we developed software. There are people who would like to think software development is like a factory where you can just take some of this, some of that, assemble as you go along, that it’s linear, that is deterministic. And for those who have developed software, I think it’s a wonderful metaphor. It, unfortunately, does not fit what we actually go through. And remember your original question. We’ll come back to that in a while.
Don: There’s a reason why a change and software development resemble each other. And I’m going back to Frederick Brooks, the guy who wrote the Mythical Man-Month, has an excellent article that he wrote afterwards after the Mythical Man-Month called No Silver Bullet.
Marcus: Yes. Classic.
Don: Yeah. It’s a classic. And if you buy the 20th edition of the Mythical Man-Month, it’s like chapter 16 if I remember correctly.
Marcus: That’s where it is in mine.
Don: Do you have the original one?
Marcus: No, I have the 20th anniversary.
Don: I have both.
Marcus: I bet you do.
Don: I’m old enough. I have the original and the 20th anniversary. Anyway, let’s get back to work. Um so um in it, Brooks in back to the Mythical Man-Month … No, No Silver Bullets, Brooks talks about what are the essential difficulties of software development, the things that are inherent in the act of creating software that there’s nothing we can really do about. We just have to work with them, understand they exist and do our best when coping with them.
Don: I I think coping is possibly the correct verb. So he talks about complexity. Complexity means in software development, we never do the same thing twice. So if you’re going to write the same piece of software twice, you either don’t know about sub-routines, functions and the standard ways of reusing software or you’re ripping off your employer, you’re creating multiple opportunities for cut-paste errors and if there’s a defect, then, you have to locate that everywhere it is.
Don: So like software development, change is complex, we never have the same set of change where you want to do. We often make change … We make change when we buy stuff and give them a dollar bill and get coins back. We attempt to change because something has changed in the context. Something external to our situation has shifted, and we need to shift with it. So that’s one sort of change.
Don: A second sort of change would be when we want to improve something. We’ve got a base level of X we would like to have. We would like to get to X out. That means we need to do something differently. So that’s the second type of change. The third type of change would be to remove a problem. There’s something that’s bothering us. There’s some misalignment in our organization.
Don: The workflow is not smooth through the teams. The work product is defective. There’s one guy who knows how to run the build system. These are things that we would like to change to do away with these problems. Quickly, there are three types of change, and they’re all complex because there we’re always doing something different.
Don: In No Silver Bullet, Brooks talks about conformance. Conformance in this case means standardization. So, they used to have a phrase back when the British empire was existing or existed. And it was called something like a pounds of pound the world around. In other words, it was always the same. If you had a pound in England, it was a pound in India, it was a pound in Australia. It was the same thing. The speed of light is a standard. We can measure it. We know within a handful of micrometers how far light goes in a second.
Don: Gravity…Acceleration due to gravity, 9.8 meters per second squared. Any engineering student can tell you that one, or 32 feet if you were raised in America. But the point is there is a conformance to some level in the physical world. There is no conformance in software. There is nothing that says if you’re going to do create a database, you have to create the database in this structure with these fields, and it must be this way.
Don: This means, and think of an N-tiered application, so there’s no absolute definition of what the database layers should be, what the business logic layer should be, what the user presentation layer should be. It changes based on the skill, the tech stack being used and on the whim of the designer, the developer. That says anybody who comes along after them after the original creation has to figure all of this stuff out. What were they doing? More importantly, why did they do it this way? Why would a rational person do something that’s so obviously not rational? I’m going to say way off for a second and come back.
Don: Welcome to the introduction of time because what used to make sense when I started work in 1984 is we sit back and we smile and shake our heads knowingly going, “Yeah. That’s how they did it in the old days. We know better now.” So time changes things, and we’re back to change. So, back to conformance, how does that apply to change? Everything’s different. And with the progression of time, everything shifts. The context shifts. The people shift. The values that people hold dear shift. Organizational structures shift.
Don: But there is no set way of doing it. That says there is no right answer. We’ve covered complexity. We’ve covered conformance, changeability. The third thing Brooks talks about is changeability. That’s basically that software is infinitely malleable. It’s always subject to pressures, whether it’s technology pressures, user pressures, developer pressures, management pressures. Software is always at risk of being changed because it’s malleable.
Don: So my background for those who aren’t familiar with, it is actually from the chemical engineering control systems point of the world. And more than once, we wrote software because … Oh wait, the pump was supposed to be zero to 500 jet gallons per minute. It’s really only zero to 300 gallons per minute. And so we need to change something in the software to adapt to the physical system because the physical system didn’t arrive the way it was supposed to. And more than once, we have modified the software to conform to reality. Let me just say it that way.
Marcus: Mmm.
Don: So changeability is built right into the conversation. We’re having change.
Marcus: Yes, it is. And we have changed a lot.
Don: And we have. So the concept of changeability with respect to change is the same thing. There’s infinite number of ways to do this. There are a handful of models that are useful. There’s-
Don: Yeah, maybe we’ll actually get to the handful of models that could be useful, but there’s no right answer. I have this little diddy. As I’ve grown older, I would pick up these little sayings here and there. And uh one of my favorite is the hard and fast rule. The hard and fast rule is there are no other hard and fast rules.
Marcus: Mmhmm.
Don: It’s the only one I know of that it’s hard and fast. Now, there’s probably some really good ideas like don’t play in the middle of an interchange and where streets cross. Don’t play on the interstate. Try to stay current in your career, learn, keep learning. These things are really good ideas, but they’re not required. They’re optional if you want to make them that way. So, we’ve covered conformance, complexity, and changeability.
Don: Uh the last thing he talks about is invisibility. With respect to invisibility, the thought behind this is there is no representation of running software in space time. In a process plan, I can walk over to a pump that’s running and touch it. I can watch. I can look at a wire and go, “Yeah. That’s a single starts here, and it goes there while the plans running.” You cannot do that in change. There is no representation for change.
Don: Okay. I may have to back off this one just a little bit. Uh if you’ve got a really good artist, maybe you can make a drawing of the effects of change. But to know when actually change is happening, you would have to go inside people, inside groups of people, and inside the organization. And we have no way of, I mean culture is basically invisible. You know? The simple sets of rules in an organization, the we must always do this set of rules and the we must never do this set of rules.
Don: Those two sets of rules pretty much determine corporate culture and a lot of change, especially now that we’re getting into digital transformation and organizational transformation of all of agile transformations, transformation means change. You know we’re trying to transform
Marcus: Right.
Don: From whatever we are to whatever else we want to become, and we don’t really have good representations for that.
Don: We can show a new org chart on the wall for those who’ve been to the coaching beyond the team workshop or gone through human systems dynamics, uh which I believe you’re a part of right now.
Marcus: I am.
Don: Well, I saw you head shaking. I was going to give you a chance to say something because I’m not sure our audience can see your head shake. We use something called containers, differences in exchanges to represent the aspects of a complex human system. But once again, you don’t see it in action. There is no-
Marcus: They’re all just mental models that we come up with to try and make sense of what’s invisible.
Don: Invisible. And by the time you make that model and make the drawing, you’ve removed the dynamics. You have a static representation. It’s better than nothing.
Marcus: So it’s already wrong. That’s true. But it’s out of date.
Don: It’s out of date.
Marcus: I think also important to note here is that the map is not the terrain.
Don: Ah yes.
Marcus: You can make a picture of it, and you can feel like you’ve got some handle on it, but don’t get that confused with the actual terrain. Now, if you can’t see, and, of course, you can’t because this is a podcast, and Don and I are going over video, Don has gotten up and he has walked to a bookshelf where he has picked up the thickest book I’ve ever seen by Alfred-
Don: Korzybski.
Marcus: … called Science and Sanity. Now, Don has a way of doing this, which then provokes my Amazon account. Amazon loves my conversations with Don. But let’s pause for a second, Don. Here’s what I want to recap. A, the world is complex. B, we are all complex. C, any given change or initiative or pushing into a complex system has a very difficult … It’s very difficult to tell what the consequences of that are. We might have a goal in mind of what we hope to achieve, but because everything’s complex and emergent and generative and continually changing, the actual effect of these things is somewhat impossible to predict.
Don: As much as people would like to predict what’s going to happen, I agree with you. Prediction is difficult. Now, if you actually succeed and changes do succeed occasionally, I mean occasionally, we do manage to ship software, so it has happened. I’ve shipped some in my life. It does happen. It just doesn’t always happen the way we think it’s going to.
Don: And that leads us to a wonderful phrase called retrospective coherence, which means when I am done, and I have completed the software, the change, whatever, I can look back in time go, “Yes, and yes and yes.” And this is how it all connected. And it was obvious that this would be, but it only works when you’re looking backwards.
Marcus: Is this the same as hindsight is? What is it?
Don: 20/20.
Marcus: 20/20, right. Hindsight is 20/20 confirmation bias. We look backwards. We say, “Well, yeah. That’s what I thought would happen or something.”
Don: Uh I see confirmation biases slightly different than that.
Marcus: That’s a little bit different. Biases are typically forward facing.
Don: Well, it’s something that we all carry. We all do um confirmation biases. I’m used to hearing it is around, well, uh this is my view of the world and I notice all of the data that supports my worldview.
Marcus: Oh yes.
Don: I do not see the other data, which disagrees with my worldview.
Marcus: I had the wrong bias. Yes.
Don: Well, I have a bias against people who don’t have the right biases, but you would know that.
Marcus: Well, I feel biased against right now. So you called it retrospective-
Don: Coherence.
Marcus: … coherence. So looking backwards, it seems coherent. It makes sense.
Don: It makes sense. It’s a phrase, I believe, I got from Dave Snowden of the Cynefin model for thinking about systems. Are they obvious? Is the system obvious? Is it an ordered system, an unordered system and so on and so forth? No, the point of the book is Alfred Korzybski is actually the guy who originally said, “The map is not the territory.”
Marcus: Ah okay.
Don: So I mean I’ve heard it attributed to the Norwegian army and to various people in NLP and whatnot. And it’s very true. But he said it first back in the 30s.
Marcus: That’s good to know.
Don: And the value of this book is basically at 800 pages, 832 pages, sits on the bottom shelf and holds my bookcase to the floor.
Marcus: It looks like an excellent book to put your monitor on in case you need it.
Don: Well, yes. And it does have other great things because I talk about non-Aristotelian systems and general semantics.
Marcus: Well that actually sounds quite interesting. So this will go into my Amazon cart when we’re done here today because I need yet another large book.
Don: Yeah. I can see some books on your bookshelf that are a little slanted. This will put them straight up.
Marcus: This will get them straight. That’s good. So Don, if somebody who is listening besides wanting to change the channel on this conversation or change to a different podcast, if there’s anyone still with us and they are thinking, “I really need this person to change, or I need this system to change, and yet everything is so complex, it’s very hard to predict,” how do we know what is a reasonable action to take? Now you and I had warned each other not to get too abstract. Have I gone there?
Don: Uh no. I’m thinking about the response and especially around the thought of we want someone to change. Um yeah, good luck with that.
Marcus: I threw that in there. That may have been maybe I shouldn’t have.
Don: But what you can do is the one thing that you have absolute control over is your response.
Marcus: Well, absolute might be a little strained, but you have some control.
Don: Well, you certainly don’t have any control over the other person.
Marcus: That’s right.
Don: Even as a manager who has the ability to fire somebody, you still don’t have that much control. I mean they may look at you and go, “Fine, I’m happier a lot. Gone.”
Marcus: Absolutely. I don’t mean to derail you. I agree. We can control ourselves and our response to situations.
Don: So change is best made in small chunks and looking at the system as opposed to the people, the system processes, the structure of the system, and I’m going to go on a little loop de loop here. I detest certain words used in certain contexts, one of which is drive. So when I’m working with a or interviewing with a potential client, when I hear words like drive behavior, drive success, drive the team, I go back to what does drive mean? Well, let’s see. What can we drive? We can drive a car. We can drive cattle. We can drive a nail. We can drive a golf ball. All valid uses of the word drive.
Don: But once you start to put drive together with people then, unless you’re putting them in a car and taking them somewhere, drive just drives me nuts which is another use for drive.
Marcus: Which is another use for drive. I have a feeling most of the time people mean it like cattle.
Don: Well, most of the time, I would think it’d be like cattle. For some people who are stuck in a Newtonian linear world, they might think of driving a car, you know go two miles, turn left. So my loop de loop is I generally avoid using the word drive when I’m dealing with people. I don’t think people are that drivable, but I’m going to … Remember my hard and fast rule?
Marcus: There are no hard and fast rules.
Don: Here’s an exception.
Marcus: Okay.
Don: System structure drives behavior. This is one of those rare occasions where I’d go, “Yeah, actually, research has shown that you can take and experience shows that you can take a person who is not behaving well out of a system, put somebody else into that exact same system, exact same part, exact same role and they will also behave similarly.”
Don: And this is because the system dynamics, the reward structures, the information flows are such that it’s the structure of the system that creates the behavior, not necessarily the individual. And they are doing the best they can, but they’re working against multiple factors that are degrading their ability to perform to their best capabilities. So back to the question, see, I did remember to come back to the question.
Marcus: You did.
Don: What about change? Um change the system. Change the structure
Marcus: HSD talks about again containers, differences, and exchanges becoming .. And you’ve mentioned now that those are some of the systemic pieces that uh that shape patterns, which are the system at play.
Don: Yeah.
Marcus: So are those some things? Like you said, change the system. Sometimes, the system feels really invisible. Is it valuable to map or try and visualize the system in some meaningful way?
Don: So working back to the … I think there was an embedded question that I’m going to answer whether it was there or not. Yes, the containers. So containers are things that hold focus. It’s HSDinstitute.org uh recommend highly that you go read up on some of the material. There’s a great book called Influencing Patterns for Change by Royce Holladay and her sister, I forget what her sister’s name is. Glenda Eoyang and Royce are sisters, but there was Royce-
Marcus: Glenda Eoyang, I think.
Don: … I think there’s a third sister that wrote this little book. I mean this book is thin. It’s uh maybe, it’s less than a hundred pages. And I tend to highlight in my books, and this is one of those books that I basically highlight. There’s a highlight on every page, and all of some pages are highlighted. That’s how good this book is.
Marcus: Influencing Patterns For Change: A Human Systems Dynamics Primer For Leaders, Royce Holladay and Kristine Quade.
Don: And actually, it’s a primmer. A primmer is a short book that introduces a topic. A primer is used for detonating explosives.
Marcus: Good to know. I’m going to say I think most bullets have primers, but you’re right. It’s a primmer. Okay.
Don: Yeah. Yeah. Well and if you read my… And actually, this is the only book I have ever done a review on on Amazon. I make that point. That’s the only reason I knew the difference.
Marcus: I want to take just a moment and thank my sponsor, GitPrime. GitPrime sponsored the show, not just because they’re fantastic people, but because they really believe that leadership and engineering is about people. It’s about conversations. GitPrime is a platform that allows you to have better conversations with people.
Marcus: Yes, it has lots of other benefits. You can probably plan better. You can see metrics about individual performance, but let’s just take that one idea about individual performance. Whenever I talk with a GitPrime user, and by the way, lots of my clients are GitPrime users, they always tell me how surprised they were at what was really happening on the team.
Marcus: See, it’s really easy for you as a manager to observe generally how people are working. You can look at PRs. You can look at who’s assigned what tickets. You as the CLM, the software engineering manager, you get a notion for what people are doing. But there’s always these beautiful surprises about who is really performing well and who’s secretly struggling about who’s the person that’s saving everybody’s bacon through fixing a lot of stuff behind the scenes and who is absolutely doing all the PRs. This kind of data lets you move from looking at people as just, well, they’re all engineers and they’re all kind of doing engineering work to seeing exactly where each one of them is strong and has opportunities to grow.
Marcus: That’s why I love this tool so much. I believe that new and surprising conversations come out of data that when you can sit down with somebody and start to understand and intuit why things are happening, you’re going to create even better quality of exchanges. By the way, you know here on this show, we talk about the fact that leadership is what keeps people connected to their work and prevents turnover and keeps them motivated. It’s about the relationship. I like to say the GitPrime not only lets you build better software and lets you build a better relationship with your team members. Start a free trial today at gitprime.com.
Marcus: Now, in case you’re wondering when Don and I get together and talk, it’s exactly like this, just want you to know these are the kinds of rabbits we chase.
Don: Uh yeah. But we usually come back out of the holes fairly quickly. So yeah. So containers are something that holds focus. It can be a team. It can be a room. It can be a division. Uh it’s these sorts of things that hold focus, a career.
Marcus: Okay.
Don: That would be a type of a container. Differences are exactly that. Differences occur within containers and between containers. Sometimes, you want to amplify differences. Sometimes, you want to dampen differences. And then, exchanges are the flow of value between containers and within containers.
Don: So those are the types of things that are levers that we can adjust and then see how the patterns of behavior shift, which gets us back to your question about change.
Marcus: Okay okay. I’m going to put a completely real scenario in front of you. Okay? And of course, I won’t do it justice. So again, this is live without a net. We’ll see if this works. So I’m talking to somebody, a client of mine, and he is saying that his developer, just “doesn’t pay attention to detail.” Yesterday, they did a deploy. And one of the builds had failed, and he didn’t notice that the Jenkins job had failed, and he’d deployed it anyway.
Marcus: And he says, “I don’t think I’ll ever change him, but this person just … He just doesn’t pay attention to detail. It’s an inborn trait. And I guess if I don’t want this, I need to find someone who pays more attention to detail, but I’d really like this person to change.”
Don: Lots in there.
Marcus: Lots in there.
Don: I would look at exchanges. I would start with exchanges. So exchange is a flow value. Knowing that the Jenkins job died, that’s an exchange. That’s valuable information. What else did it reach them?
Marcus: It didn’t reach them.
Don: That would be my first thing. Let’s see, what else? Containers. Is this a developer who works by himself only by himself? I don’t know. These are questions. How does the work flow into person, into the container as a part of a team? How is the work flow? Is the work flow uh smooth? Or does it just kind of fall through a hole in the floor from above him and it’s now on his work list and it’s his job to figure out what’s involved? How well is he connected to whatever support he can get? It’s these sorts of things. And you asked the question, is it worth exploring these things or something to that effect drawing?
Marcus: Yeah. I mean, in this case, the person I was talking to felt it was an innate trait as though it was the person’s height or hair color, you know just they’re not born with a lot of attention to detail.
Don: I have a different view of innate traits. Obviously, it has been argued that I do not have an attention to detail. And yet, I worked for 20 years in a domain where my good mistakes caused lost revenue because of machine downtime. My next worst mistake destroyed equipment and machinery. My third possible mistake would injure or kill someone. All right. So for a guy to work in that domain with a poor attention to detail, the two don’t seem to align, at least in my case. And it’s easier to notice a person in that person’s behavior than it is to notice the system around them, which is why there’s actually, I think it’s a bias maybe, called the identified patient pattern. And it’s the, oh, if we just replaced Marcus, this podcast would go so much better, or Don or Kim or whoever. And if you work-
Marcus: Whatever the broken part is-
Don: I’m sorry?
Marcus: … is that like saying whatever the deficient or defective part is, we could replace it and everything would be better?
Don: Yes. Yeah identified patient pattern, you can read about it on Wikipedia. Jerry and I wrote a series of articles in like 2004, ’05, and ’06 and it starts with the liars contest in somewhere towards the end we wrote an article on the identified patient pattern, which can be found on my website if you’re interested.
Marcus: We’ll see if we can get it for the show notes. But you mentioned this.
Don: Okay, now you started talking. I lost … I had a thought. It was beautiful. Oh, drawing pictures. Yes. When I work… Generally, when I go in to a new client, I usually start with a container drawing just because that shows me the big pieces. And I did this once. This was few years ago. I had access to a meeting room with four white walls. This client had teams scattered across the globe, and I’m trying … 47 at them when I joined, I think it peaked around 54, 55. It’s like I’m trying to figure out how this all connects.
Don: And so I worked with a very nice project manager. And he came in with me one day, and we went to stickies because, come on, we’re agile, can’t be agile if you don’t have stickies. We put all the teams on stickies, put them on the white wall. Then, we started drawing circles around the wall. This set of teams are located in the United States. This set of teams are located in France. This set of teams. So, we located them geographically.
Don: Then, we started circling them by product line. And as you can imagine, given the organic nature of growth, it was a mess. And I just left it there for six months. And people would come in, and they would just look at it, and they’d look at me, and I’d explain what it was. And then, they’d leave because nobody wanted to take it down.
Don: There was so much information about how screwed up the exchanges had to be given the time differences, the number of teams involved, the differences between work styles between the French and the Americans. And we even had left coast, right coast, East coast, West coast differences. They did actually reorg about six months before I left, and it looked a lot better. And they did it exactly with stickies and a white board, and they drew their own circles. So yes, using uh a model an explicit model such as HST, um the CDE model containers, differences in exchanges is an excellent way to start understanding what’s happening in an organization.
Marcus: I think the thing that strikes me about that story is when you drew it and just left it on the wall, people came by. And it had some effect on them just as though it were an x-ray of somebody. It was a different kind of picture of reality. And it showed something that we don’t normally see. So it sounds like it did have, even though you didn’t say, “Oh, now we have to make X decision from this,” just seeing it had some effect.
Don: It did. There was a senior director who came through and looked at it. And he sat there and pondered, I guess, for 5, 10 minutes. Then, he just left. And I didn’t have to say anything. You could look at it and see that this was possibly not an optimal way to design the workflow.
Marcus: And so in doing that, you didn’t come with judgment. You didn’t come saying this is terrible, these are problems. There wasn’t that framing. It was simply this is what it looks like here from the picture of containers and exchanges.
Don: Yeah. Yeah. It’s hard to help somebody. It’s hard to be useful in change if you’re judgmental.
Marcus: I want to go back to something you said because it’s just running around in my brain and that’s this idea that it’s easier to spot the person who appears to be not acting as you want them to than it is the system that has created that behavior.
Don: There’s reasons for that.
Marcus: Tell me more.
Don: Well, here you go.
Marcus: Don is holding up a pamphlet that says, “The thinking in system’s thinking.”
Don: Yeah. Very enriching. Notice I didn’t have to leave my desk to go get it.
Marcus: No, that’s true. So I’d like to include that in the show notes. We’ll make sure we get a link to that.
Don: Sure.
Marcus: Yeah. The thinking of system’s thinking, is that what it was?
Don: The thinking in system’s thinking, in that, we don’t tend to think in systems. So, let’s talk about systems briefly if we may.
Marcus: Let’s do that.
Don: What do we notice? We notice events. We notice that, we’ll call him Bob has poor attention to detail. Bob didn’t notice the Jenkins job failed. Bob deployed anyway. And so now, I have this event that happens. That’s what I noticed. Now, earlier on in the podcast, for those of you who are still with us, I introduced time into the conversation, uh the passage of time. Now, events over time give us behavior over time. You can draw a graph or you can draw a distribution chart.
Don: And so now, we’re starting to look at patterns. You know what does this look like over time? That’s another story. I was working with a client years ago and we were tracking … They were just going to scrum, so we were tracking story points per sprint. Now, I was tracking that. Nobody knew I was tracking it because if somebody knows they’re being measured, they will maximize whatever you’re measuring. Another great book, Measuring and Managing Performance in Organizations by Robert Austin. Excellent book. If you get anywhere near metrics and measuring and corporations, I recommend the book highly.
Don: So we would go along, along, along, along, along. And teams would be loosely tracking along, and then every team would crash for one sprint and then they would come back up.
Marcus: So again, you’re tracking story points. You’re graphing them over time. You’re graphing number of points earned per sprint.
Don: Yeah.
Marcus: And at some point, you see a big dip. You call it a crash.
Don: Uh yeah. Basically, output went to zero for, I guess, there were probably 8 teams, 9 teams at the time, across the development platform. And so I started digging back in time. And I was able to correlate um that all of the teams, the crash, the dip in performance happened when they did a release because-
Marcus: So they do a release. And what happens then?
Don: Well, it turns out that the testing might have missed a feature or two and … Oh, now, we have to go fix this right now. So you can see every quarter, bam, down it goes, down it goes. Now, the interesting thing was one team always maintained their story points. So,
Marcus: Maybe, they never released.
Don: Well, they released, but somehow, when everybody else’s story points went to zero, they were still able to maintain their standard 20 story points plus or minus two story points, something like that which led me to wonder how do they do that because they have some magic sauce that the rest of the other teams, the other eight teams need to get ahold of or they’re gaming the system, one or the other.
Marcus: And-
Don: And they were going into a merger, and they had to look good financially. So the external coaches got the boot. I’ll never know the answer.
Marcus: Oh, we don’t know. It’s still a mystery. So either they had some magic sauce or they were gaming the system.
Don: Yeah.
Marcus: And then, things were over.
Don: And then things ended.
Marcus: It’s like a cliffhanger here on the Programming leadership podcast.
Don: We’ll never know.
Marcus: Don, we’ve covered tremendous ground today.
Don: Well, we got started. We’re still on, we haven’t gotten off of systems and change yet. We still have a lot. We’ve got another three or four hours to go.
Marcus: Well, no, I know. And we’ll be doing all of those right now. So, buckle up and get some popcorn. Um I think that, you know, soon as we start talking about systems, I think you’re right, things get real, real confusing until we learn a language that we can use to talk about those.
Don: And understanding that the systems from Jerry are, the systems thinking has evolved since Jerry. Jerry’s, I think his actual PhD thesis was on control theory. University of Michigan 1963. I think I have a copy of it somewhere. But, we’ve added to our repertoire. We’ve added some views. Uh the one I’m interested in looking at now is something called DPSR DSRP? Help me out here.
Marcus: DSRP.
Don: DSRP which talks about distinctions, responsibilities, systems and differences, I think.
Marcus: It’s, yeah, distinction systems, relationships and perspectives.
Don: Which is, adds a certain layer of of multiple views all on the same thinking space.
Marcus: Yeah. And it’s interesting going through HSD because we could say, “Oh look, the D is in common. Both have a difference with CDE and DSRP.” Both are interested in, well actually no.
Don: But…
Marcus: See doggone it. I got all excited then I’m wrong.
Don: No, you’re not wrong. You just have a different view slightly. So, the thing about distinctions is it ties into neurology. Of you know, how do we, the distinctions we choose to make come from our brains, our mental models.
Marcus: Mm-hmm (affirmative).
Don: And distinctions are differences.
Marcus: Mmhmm.
Don: But the way, we’re now getting to, and I’ve got the book, I haven’t read it yet on DSRP. It’s in the pile. You asked what I’ve reading. Well, the pile contains, the pile I’ve got going right now as I’m working on a study hall for The Fearless Organization. I’ve got, I’m part way through Accounting for Slavery, which contains the origins of accounting as we use them in business today. Learn or Die, I think is the other book that I started reading, which is about organizational learning. I’ve got DSRP to go because there’s a lot of stuff out there. Oh and neurology. I’m trying to write an article on how do you know. The essence of, you know, we all, well I know this well. Well, how do you know you know? And so this gets into things like the neocortex, the amygdala biases. So, these are the things that keep Don awake at night. Just in case you were curious.
Marcus: I was curious about that. And I’d like to add on if you, you know, David Bohm’s work
Don: Yeah.
Marcus: On dialogue and thinking and wholeness and the implicit order. And David William Isaacson’s book on um on dialogue. Uh as well as there’s a wonderful book, oh, I can’t see it from here. Oh, called On Being Certain. Um I don’t know if you’ve read that book, but I have skimmed it.
Don: Have not. I have not. Now I get to go buy a book from Amazon.
Marcus: My point here, all of our points here, is if you’re listening to this and you’re still with us, first buy-
Don: Buy Amazon stock.
Marcus: Second, by yourself a treat because you have just sat through two old guys, you know, having a nice cup of coffee virtually over the internet. But if you’re feeling overwhelmed with change and complexity and trying to make sense of it all, you’re not alone. While there’s a lot of good books, I think that’s kind of the main message if anything, is I just want you to know this is hard stuff. There’s not a lot of obvious answers. Even though Don and I can quote you books until we both, you know, our heads pop off and roll around the room. There’s not a lot of really obvious answers out there, but our best guess is that working in complexity and becoming comfortable with systems thinking and complexity is probably one of the best ways to start thinking about change.
Don: Yes and so going, continuing with complexity. Dave Snowden talks, if you’re working in the complex space, which is an unordered system, but is, you can determine cause effect relationships retrospectively. He talks about experiments. You know, you want to nudge the system, you want to tap it, uh see what happens when you tap it. And if it’s something good, the question is how can I do more of this? And if it’s something not useful, how do I dampen the effects of this and try something else?
Marcus: Thank you for changing your language. You were using the word good and I thought you were going to say bad, but I think that you changed to not useful. So, the framing of useful and not useful seems-
Don: Yeah. Well, fit for function.
Marcus: Fit for function.
Don: Phrase from HSD. You know, what is the fit for function? Can I improve the fit for function?
Marcus: They also talk about there’s no naughty and nice, which I like. As well as what is true and useful?
Don: And then that gets into what is true. And that’s just a real hole that we could go down, couldn’t we?
Marcus: And we are not going to today though. In fact we are going to wrap up our show. But Don you are-
Don: Not yet.
Marcus: Not yet.
Don: Not yet.
Marcus: But before we do-
Don: Um one last book. This comes from my colleague and friend Esther Derby. 7 Rules for Positive, Productive Change: Micro Shifts, Macro Results. It’s available on Amazon.
Marcus: It’s a wonderful book. I have a copy. Um I actually owe her a, I promised her I would write my review because I really enjoyed it so I need to do that. Thank you for the reminder.
Don: You’re certainly welcome. And now…
Marcus: Now we can say Don, thank you for being with us, for entertaining us, for taking us through a journey called Don’s mind.
Marcus: This was the Programming Leadership podcast with Don Gray. Don, where can we find you online?
Don: Online? My website is Donald E as in Elliot. DonaldEGray.com. Um and then I hang out in a handful of Slack channels in your Slack workspaces including the software managers Slack space hosted by Mr. Marcus.
Marcus: There you go. If you’d like an invitation to software manager uh Slack, drop me a line at Marcus@marcusblankenship.com. And uh thanks for being on the show Don.
Don: Thank you for having me.
Announcer: Thank you for listening to Programming Leadership. You can keep up with the latest on the podcast at www.programmingleadership.com and on iTunes, Spotify, Google play, or wherever fine podcasts are distributed. Thanks again for listening and we’ll see you next time.
Announcer: This has been a HumblePod production.
Announcer: Stay humble.
You may also like...
