I recently sat down for a chat with Marcus Blankenship of Programming Leadership. We talked about my book, 7 Rules for Positive Productive Change, and how change plays out for people and organizations.
You can listen to the full interview on Marcus Blankenship’s site and also check out many other interesting interviews.
For those who prefer to read, here’s the full 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 Programming Leadership podcast. I’m Marcus, and I am so excited today to have Esther Derby with me. Esther, thank you for being on the show.
Esther: I’m so happy to be here.
Marcus: Esther, today I am really excited to talk about your new book, Seven Rules for Positive Productive Change, available in all the places where fine books are found. And it came out just a couple of months ago, so congratulations.
Esther: Thank you.
Marcus: And my first question is why. Why is it important for us as leaders to understand change?
Esther: I think it’s a huge part of our jobs. You know, anytime we’re looking at making some sort of improvement, that involves change, anytime we’re bringing a new person into a team that involves change, anytime we’re changing projects that involves change. So, I think it’s a core aspect of our job as leaders and managers.
Marcus: What got you interested in this topic?
Esther: Well, I’ve been interested in it for a long time. So there’s a story right at the beginning about the first program I wrote as a professional programmer, and you know I’d worked really hard on it, and we’d done a lot of testing and it was finally approved to go live. And I overheard a conversation with the chief estimator. It was a program that estimated the manufacturer of decorative tape for cars. And he was not happy, you know and he acknowledged that the program was accurate, but it was going to change the way he did his work.
Esther: It’s going to change the way he did his job, and he didn’t like that. And so that made me aware early on that the work I did as a programmer was about changing the way people did their work. And so I got interested in it, and started watching. And when I went to work at a bigger corporation, I had a chance to make some of my own changes, you know trying to change small things from where I sat, and also looking at how change was approached in the larger organization. So, I’ve been interested for a long time.
Marcus: That’s really fascinating. It does remind me of the first time I, the first program I ever wrote as you said that, and the change it-
Marcus: Inflicted on the people who had to then figure out how to use it. And I guess in hindsight they weren’t always as excited about those changes as I was.
Marcus: I seem to always be quite sure that they were positive changes. And I think this is maybe one of the lessons from your book. Sometimes change is viewed differently from different people or different places in the organization.
Esther: Absolutely, and there’s always a negative space, almost. I can’t think of an example where there’s not, where there may be one, but there’s always someone who is not going to benefit from the change, who is going to perceive it as loss, who is going to be inconvenienced, maybe permanently, maybe temporarily. And we tend to lose sight of that in our enthusiasm for you know bright new ideas. There’s always a downside that we need to at least consider.
Marcus: Yeah. Since now the world has your beautiful book, how are people doing change before, or maybe if someone hasn’t actually read it, what is a typical way that people and companies “do change?”
Esther: Well, I think when people aren’t thinking about change with a capital C, they probably do some pretty sensible things, right? They try something out, they see how it works. They make, you know try different alternatives. They adjust things as they go, but when people get caught up in you know what they think about is an organizational change, or an organizational transformation, I think people approach it in a very different way.
Esther: And they tend to take a top-down approach, and they tend to try to plan things and you know essentially do big design upfront and then follow the plan.
Marcus: Well, doesn’t it seem sensible that we ought to have a plan for change?
Esther: It seems sensible to think about a lot of things related to a change, and it is sensible to do the planning. I think it is not always, depending on the type of change you’re doing, sensible to have a plan. Now if you’re moving a data center, I want a plan and I want a very detailed plan.
Esther: If you’re changing signage, I want a plan, and I want a very detailed plan. You know there are certain things that are amenable to that kind of planning, but when people start talking about transforming their organization, dramatically change the way people are approaching software development, or to be more responsive to needs outside the company, needs of the customers, needs for the markets, et cetera, I think there is very often possibilities for wonderful things that cannot be imagined from where you currently stand.
Esther: I think about a call I got a while ago from a company that had sent all their engineers to you know a few days of training about agile development methods. And then they decided that this is it. It’s been implemented, and we are going to codify this as a practice, and any changes now have to be approved by a central group.
Esther: So they were essentially codifying things when they knew the least about actually working with agile methods and agile development methods. And I think that in some ways that’s an analogy for making the sort of change that many organizations talk about wanting to make. It’s like they, by planning upfront, they are doing, they are solidifying things and codifying things when they know the least and when they aren’t able to see future possibilities. So they’re planning only based on what they now can see and what they now can know.
Marcus: I like that phrase so much, “We’re codifying when we know the least.” So what’s an alternative?
Esther: Iterative planning, being aware of scanning the environment to see what has changed so that you can take advantage of new opportunities. So, I have, I didn’t include this in the book because I thought about it later, but I’ve been thinking about forest succession as a metaphor for change. And if you think about how a forest comes into being, it happens over time as the conditions become amenable to a forest. So you can’t start from dry rocky ground, and just plant a whole bunch of pine trees and expect it to work. It’s not going to work.
Esther: What happens is that first, some plants will take hold, and they create a little bit more moisture in the soil, which makes it possible for another plant community to emerge, which might create some shade, which makes it possible for a yet another sort of plant. And then some animals will come in, and that will have an effect on the environment depending on what they are, which will allow something else to emerge.
Esther: And eventually, you get to a forest, but you don’t get there by planning a set of steps and activities. You get there by the conditions for the next stage of succession to happen. And I think we should pay a lot more attention to that when we are thinking about organizational change. What are the conditions that will allow the next thing to emerge? It might be training, you might have to do some tasks, but you really have to create the conditions for that new pattern to emerge.
Marcus: I like the ecological metaphor. I’m imagining I am in the process of trying to put in a small apple orchard,
Marcus: And at the end that I want apple trees, but maybe I have not considered all of the various small things which would make conditions for apple trees, something that is productive, that it would be the right place, and time, and moisture and soil. So what other things might I need? I feel like, let’s turn the conversation a little bit on that point.
Marcus: I talked to many software managers who want a change. They have a forest, but they feel frustrated trying to achieve change. They say, “As much as I try and change things, it seems like nothing changes.” Does this sound familiar?
Esther: It sounds very familiar. Well…
Marcus: What could be done? What can be done?
Esther: What can be done? Well, I think this is, I actually tweeted this morning that I think one of the overlooked questions of change is what holds the current pattern in place. Right? So, the current pattern is there because the conditions are correct for that pattern. They’re conducive to that pattern. So if we want a different pattern, we have to end up coming back to conditions again. We have to look at what is holding that pattern in place, and what do I have some control over or some means of influencing so that something else will emerge?
Esther: So I see this, you know I see this a lot in air quotes, “agile transformations” and kind of the classic example is people say, “Well, we want teamwork, but they still have individual incentives and individually focused job descriptions. And you know if you’re going to be a tester, you have to succeed on these skills, and you’ll be rated on them, and the individual task assignments, and all of these other things.” So just talking about wanting something different isn’t sufficient. You have to look at, “Okay, what is holding this current pattern? What can we create that will allow the next pattern or another pattern to emerge?”
Marcus: Let’s dive deeper here because I think this is just juicy, and I feel like there’s a lot of like … I’d like to make this really concrete. You’ve used the agile transformation and the tester, the individual job descriptions, but if somebody’s listening, how can they start to even see the patterns? Because so often I feel like we’re part of the forest, we’re part of the pattern, we as members of the organization, what patterns should we be looking for? Do you have any concrete examples?
Esther: So I think you have to look for patterns, which are events that … meaningful events that recur over time and over distance. And often, you can see those in the metrics that you already have in your organization. They can give you some clues about what the patterns are. So lead time, cycle time, misdeliveries, what the original commitment was versus how long something actually took. Those are all indications of patterns, right?
Esther: And from there you can start looking at, “Well, what contributes to those patterns? What are the factors that are present in the organization that is actually contributing to these patterns?” Unfortunately, I think people very often go first to blaming people. You know people aren’t being accountable,
Esther: Or people aren’t taking this seriously, or there have never been any consequences. So people are just you know not paying attention to deadlines, because it’s easy to see people. It’s hard to see systems.
Marcus: Mm. This sounds like, I think in the book you talk about skill or will.
Esther: Yeah, well people tend to think that it is a matter of individual skill and will, which of course is important. You want skilled, knowledgeable people who are, you know have some motivation to do their work, but you also have to look at what’s going on in the system. So I worked with a group that the teams kept committing and then kept missing the commitments.
Esther: And the senior leaders were saying, “Why aren’t these teams accountable?” And it was really focused on their character, right? Or their motivation, which speaks to will. So I started asking a bunch of different questions, and it turned out that there were a whole host of factors that were contributing to it. I mean they had some very deep technical problems. They were working with a brand new technology and you know people didn’t have deep understanding of it. There were some limitations to the technology. There were issues with their test environment.
Esther: And the teams who really wanted to do a good job would take in an amount of work that was reasonable given what they had been able to accomplish in the past, but they also knew that they would get stuck because of these technical issues. So they’d pull in a bunch of more work so they wouldn’t be sitting idle when they got stuck. So then they’d have this big commitment, and they would actually produce something that was consistent with what they had been producing, but because of the mismatch between what they had taken into the sprint and what they delivered, people were like freaking out all over the places going, “Why are they gone?”
Esther: So as long as they kept focusing on why aren’t these people accountable, it really just stopped them in their tracks on problem-solving. Right. They could push people harder, they could blame them, they could wonder what was wrong with them. They could tell stories about how accountable they were, but they didn’t actually make any progress on the actual problems. So, once they started looking at, “Oh well, here are the patterns,” Right? It’s not that they are inconsistent in their delivery, they’re very consistent. Right, it’s just not… You know you can’t tell where they’re going to get stuck, and what contributes to that while there’s these technical issues. So then we could actually do some problem solving and make some changes. Right. Did that example help?
Marcus: Yes, yes. In fact, it reminds me, it seems like another interesting example of the fundamental attribution error where we believe that other people do things because of the kind of person they are, will motivation, they just don’t care,
Marcus: But we see ourselves as primarily being very strong in those areas and it’s our circumstances that get in the way of our failures.
Esther: Sure. In that particular organization, it was almost every time it came up, you know why aren’t these people accountable? If I commit to something, I will raise hell and high water to get it done. And that was a really consistent theme there, but the truth was that the managers would commit to stuff and it would fall off the map too. So the pattern actually existed with the management ranks as well.
Marcus: Right. I just want to boil it down, if all you have is the idea of will,
Marcus: How do you change someone’s will? That problem has been, I mean that’s a very old problem. How do we motivate people? And we could have a lot of navel-gazing about theories about what motivates people. Skill is where a lot of companies invest in, and then they don’t get a lot of return I think, but then you’re talking about opening up and now there’s all these new places to start working, to start chipping away at the problem rather than just skill and will.
Esther: Sure, yeah. And training is kind of the classic mechanism for change, right. Because there’s a lot of focus on, “Well, we want behavior, so we want to train people in specific behaviors.” And training can be great, but until something in the environment changes, the patterns aren’t going to change. And I have a little thing about training behavior anyway. You know people may need to learn certain skills, but what I think we really want is not just behavior, we want knowledge, understanding and judgment, right? And the focus on training behavior I think doesn’t always take that into account.
Marcus: I want to take just a moment and thank my sponsor, GitPrime. GitPrime has 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. And GitPrime is a platform that allows you to have better conversations with people. 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.
Marcus: 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. See, it’s really easy for you as a manager to observe generally how people are working. You can look at PR’s, 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.
Marcus: 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 PR’s. 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.” And that’s why I love this tool so much.
Marcus: 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. And 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.
Marcus: I like to say that GitPrime not only lets you build better software, it lets you build a better relationship with your team members. Start a free trial today at gitprime.com.
Marcus: Let’s turn and talk about change on a really personal level for … And this, this is about when a manager wants an employee to change. Now in particular, I am thinking about a manager I know who has an employee that is not what they call, “detail-oriented.” That person is not detail-oriented, and I’ve just had to accept that they never will be. And so therefore, I can’t give them certain kinds of tasks. That idea, I have heard it from more than just one person, but it’s the idea that the person who I want to change can’t, and they won’t, and they can’t become what I need so therefore I should carve a path around them somehow, or I should only give them certain things.
Marcus: But I feel like there’s a variety of things in there that are problematic if we think about change. How do you think about that situation?
Esther: Well, the first question I have is have you talked to the person? Right. If the person is unaware that their level of attention just whatever is not meeting someone else’s expectations that, that tells me there’s a missing feedback loop. And there may be something in the environment that gets in the way of paying attention, you know, to details. If people are under a lot of pressure to deliver quickly, they tend to scan over certain details, and that’s true of just about everybody, right?
Esther: So I would be one, look at the environment, ask about what the conversations have been, and see if there’s a missing feedback loop because that’s part of the environment. So I think, you know I think it is possible for people to change. I don’t think they always choose to. I think it’s possible, but I think people often land on a label for someone that they think encompasses the entirety of that person where it may very well be situational.
Esther: You know maybe they’re very attentive to detail in some area and there’s other areas where they want. That might be a matter of interest, or it might be a matter of environment.
Marcus: Absolutely. As you were talking I was thinking, most of us seem to have an attention to detail when it comes to money. For example, if you get short changed when the cashier is counting you back your change from a $50 bill, maybe you’re paying a lot of attention then, and we do have an attention to detail, but maybe situationally a few pennies don’t matter if you’ve only spent $2.
Esther: Or maybe a few pennies don’t matter if you’ve … you know out of a thousand who knows?
Esther: For example, I pay a lot of attention to detail when I’m sewing. The seam allowance is off, the garment isn’t going to fit. Right, and if you happen to have a pattern, as I did once early in my sewing, there were like six seams that had to come together. And each seam was off by about an eighth of an inch,
Esther: Which adds up, right? So the garment didn’t fit and I had to pull it all apart and redo it because I thought, “Oh wait, an eighth of an inch, that’s not going to matter.”
Esther: So it can be very contextual. And in that case it was about knowing what the impact of those details was going to be. I guess that’s another thing I might ask in this situation is how important are the details? You know is it just that the manager likes details and therefore thinks everybody should? Did the details really matter in this situation?
Marcus: Maybe we could ask, “Which details matter?”
Esther: Yes, which details?
Marcus: To your sewing analogy, if you were focused on bringing a variety of thread lines, and I’m not a sewer, so I’m just going to reuse that term. Forgive me if it’s wrong, but if you’re trying to bring you know six thread lines together, maybe you are less focused on the speed, the detail of how fast you were doing it, or maybe you were overly focused on speed. And I, it makes me think that whenever we use phrases like, “not detail-oriented,” I feel like that’s a phrase that sounds quite specific, but it’s really not. Not very specific at all.
Esther: It’s not very specific. I mean it’s saying that this person is always not very detail-oriented in all circumstances without knowing what is meant by detail.
Marcus: And it’s funny because I’m imagining like, I don’t know, this is maybe, this is so silly, I’ll just say it, but I’m imagining a manager showing up at an employee’s parent’s house going, “When Bobby was four, was he very detail-oriented? Is this a long-term trade in little Bobby’s life?” And of course that’s pretty silly, but we do make that assumption.
Esther: And intrusive.
Marcus: Well of course, but we do seem to make that assumption that this person is that way, and has always been that way.
Esther: And will always be that way.
Marcus: Exactly. And so therefore, how could we possibly consider asking them to be, in fact, wouldn’t it be offensive to ask them to be any other way besides the way that they are?
Esther: Well, I don’t think managers get to ask people to be someone who they aren’t without some serious consideration, right. So it’s like, “How important are the details really? Is it just my personal pet peeve? Does it matter for the work? Is it affecting other people?” You know it takes some observation of the person in their context, but it also takes understanding the impact, because not very detail-oriented doesn’t say anything about the impact.
Marcus: It does sound like something you’d see on an annual evaluation.
Esther: Yeah it does.
Marcus: But not very helpful. Let’s switch gears. I want to ask you about your last chapter in your book, “Use Your Self.”
Marcus: And by the way, if you’re listening, I highly recommend this book. It’s got seven positive wonderful rules for change. And I like them all, but of course we’re in a finite amount of time today, so I want to go right to the end, “Use Your Self.” Can you tell us a little bit about what’s behind this chapter? Because it kind of surprised me.
Esther: Why did it surprise you? I’m curious about that.
Marcus: Well now I’m on the hot seat. Because the self as a component to be used is something I’m just stumbling on in other readings, and I think that, I’m not sure, I just, I thought changes about the system. It’s about others. It’s about even sometimes me, but the way you referred to it is just sort of a concept that I’m only starting to become a little bit comfortable with. And I think it’s very interesting.
Esther: Yeah. So there are kind of two threads behind that. One is, it’s just a beautiful, beautiful story I read in an article by Atul Gawande called, “Slow ideas” and in which he talks about bringing change to rural maternity hospitals in India. And they found that they had the most success when there was a group of people who went out and just formed relationships with the nurses that they were trying to influence to bring in new practices.
Esther: You know they showed them the practices, but they also helped get rid of obstacles, and they treated the maternity hospital nurses as people who had interesting lives, and they found a common ground. So it’s a beautiful story in that article, Slow Ideas by Atul Gawande.
Esther: But I’ve also been for a long time having conversations with friends of mine who are licensed clinical social workers. And something that has shown up in the research over and over and over again is that given a similar set of professional skills, what differentiates outcomes in all sorts of situations is your ability to show up, to connect and to be empathetic. So, it’s not just your technical skills and knowledge that make a huge impact on your ability to be effective. It is how you show up, how you are present. You know. Be present, be empathetic, show up and be there. Makes a huge difference.
Marcus: So, the English part of me says, “Use Your Self. It sounds like self is, it seems like an odd way to say it, but it’s almost like the self is a particular part of me. And I know there’s another book I’ve been skimming called, “The Self As An Other.” How would we define the self?
Esther: I don’t think it’s necessary to get into deep psychological theory here, but I’m just talking about who you are as a person. So your skills, your abilities, your resources, you know your internal resources, your ability to access external resources.
Marcus: Okay, and so it is not just about understanding how to program, or how to lay out a plan or the title you have.
Marcus: It is about something deeper. Your ability, and interest
Marcus: And willingness to connect
Marcus: To see things from other perspectives, to have empathy. Those are the factors. I liked that you cited the study and then maybe we can find it and include it in the show notes, or maybe there’s more than one it sounds like, that that really is what makes a huge difference given all of the things are equal.
Esther: Yeah. Well, I mean I can think of several examples where consultants have come in and said, pretty much verbatim who’ve said, “You’re doing it all wrong,” and they don’t get very far. And then I watch people, coaches who come in and sit with the team and understand what’s going on for them, who listened to their stories, who observe what’s going on, and they make small suggestions once they have some trust, and it’s you know it’s a really different outcome.
Esther: And in terms of the technical skills and knowledge, they may be identical, but it’s the way they use themselves, that that makes the difference.
Marcus: Fascinating. Let’s go back to your book for a minute. Do you have a favorite rule of the seven rules?
Esther: Oh man. You’re asking me to pick which children I love best. If I have to choose, I’ll choose the first and the last. And the first is strive for congruence, which means in any situation you need to balance your own needs and capabilities, those of the others, and consider the context you’re in. And those need to be roughly in balance. It’s never perfect, but roughly in balance.
Esther: So, if we think back to the managers who were saying, “Those teams aren’t accountable.” They were considering what they wanted to have happen. Right. “We want our product to be delivered on time,” but they weren’t thinking about what was going on for the team. They were considering the context. You know we made promises to customers, but they weren’t considering what was going on for the team.
Esther: So, they were not able to because they were just blaming these other teams, this other group of people, they weren’t able to access their problem solving. Though I think congruence is super important, because when we are roughly in balance and seldom perfect, right. But when we’re roughly in balance, we have much better access to our creativity, to our ability to solve problems, our ability to think clearly and to access our empathy. So, I would say that’s my favorite if I have to pick because everything else flows from that.
Marcus: Esther, I really like this idea of congruence. If someone wonders if they’re acting congruently with their insides, their outsides, the internal, the external, what kind of questions can they ask themselves to see this?
Esther: Well, I would start by trying to be aware of what’s going on for you. You know, “What am I feeling? What is my feeling state?” And if you’re not used to thinking about that, you can think about, “What is my physical state? You know am I all tensed up? Am I feeling flushed? You know am I feeling nauseated?” Those can be signs that you are out of balance, right?
Esther: “So what’s going on for me? How do I feel about this situation? What are my capabilities related to this type of situation? How do I feel about these other people? How do I feel about the change that we’re being asked to enter into together?” And then I might get curious about the people, and then I might try to learn more about the context. You know, “Why is this change important to the company? Why is this change important to this team? What is the animating factor behind it? What is the urgency behind it? Why does that exist? Why is it important? What are this team struggles? You know what have they been trying before? What are their skills? What do they think the problem is?” So just you know ask questions about each of those three areas.
Marcus: Very interesting. And I suppose the idea of congruence might tell us that where we see big gaps, big differences, we could start to find those really interesting. Esther, thank you so much for being on the show.
Marcus: Where can people find your book and where can they find you?
Esther: Well, the book is available on Amazon and wherever fine books are sold. It’s available as an eBook or an audiobook as well as a paperback book. People can find me at estherderby.com, or on Twitter @Esther Derby.
Marcus: Thank you so much for being on the show today.
Esther: It’s been my pleasure. Thanks 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.