Leading Transformative Change | Erika Lenz

56

---

In this conversation, Erica Lenz, co-founder and strategic change officer of Kinetic Change, discusses organizational transformation, system thinking, and process visualization.

Erika is a seasoned consultant, educator, coach, and entrepreneur with over a decade of experience in improving organizational performance and operational excellence through lean, flow, systems thinking, and agile methodologies. Erika leads and mentors technical, product, and business teams, driving innovation, value creation, and strategic leadership. She guides leaders through transformative shifts using systems thinking, process visualization, quantitative measurement, and iterative development. Erika is a principles-driven, pragmatic, and framework-agnostic expert with multiple agile certifications. She also shares her knowledge through teaching, speaking, and writing.

Takeaways

• Organizations are dealing with an increasing amount of change, and many employees lack the skills to navigate it effectively.
• Kinetic Change focuses on optimizing organizations for rapid change by being human-centric, adaptable, and employing iterative and incremental change plans.
• System thinking is a powerful approach to understanding complex systems and identifying areas for improvement.
• Visualization techniques, such as causal loop diagramming and flow mapping, can help teams and organizations gain insights and improve communication.
• Metrics should be tied to the specific problem being addressed and should focus on flow and efficiency rather than vanity metrics. Metrics should not only focus on flow but also on quality to avoid shortcuts and ensure zero-defect software.
• The iterative approach involves building and improving something through feedback and continuous improvement methods, while the incremental approach involves working in small pieces.
• A blame-free culture is crucial for driving productive behaviors and problem-solving conversations.
• Staying updated in the field of agile and lean system thinking requires constant reading, networking, and seeking out educational resources.
• To promote organizational change, it’s important to stay motivated, take care of oneself, and reach out to inspiring individuals and communities.

Connect with Erika

• Website: https://www.kineticchange.com/
• LinkedIn: https://www.linkedin.com/in/erikalenz/
• X: https://x.com/Erika_L_Lenz
• Substack: https://substack.com/@erikalenz

Connect with Vit

• Website: https://vitlyoshin.com/ 
• LinkedIn: https://www.linkedin.com/in/vit-lyoshin/ 
• X: https://twitter.com/vitlyoshin 
• Other: https://linktr.ee/vitlyoshin 

Timestamps

00:00 Intro

04:18 The Vision Behind Kinetic Change

07:40 Choosing Methodologies for Change Management

10:35 Implementing System Thinking in Organizations

14:17 The Power of Visualization in Process Improvement

19:45 Tools for Process Mapping

22:46 Iterations for Work Refinement

28:47 Metrics to Measure Success

34:14 Understanding the Iterative Approach

38:02 How to Apply Iteration and Increments to Change Initiatives

41:39 Driving Productive Behaviors through Feedback

51:55 Staying Updated in Agile, Lean, and System Thinking

54:40 Advice From Erika Lenz

57:56: Connect with Erika Lenz

Transcript (Edited by Vit Lyoshin for better readability)

Vit Lyoshin (00:01.224)

Hello everybody. Welcome to the Vit Lyoshin Podcast. Today we have a new guest, Erica Lenz. She’s a co-founder and a strategic change officer of Kinetic Change, which is a company that helps organizations with transition and performance, and operational excellence. And they use agile, lean and flow frameworks and system thinking.

Welcome, it’s nice to have you here.

 

Erika Lenz (00:33.102)

Thank you, Vit. It’s really great to be here. Thanks for asking me.

 

Vit Lyoshin (00:36.84)

Thanks. Today I invited you to talk about organizational transformation, system thinking, and also process visualization. But before we jump into the topics, if you’d like to share a little bit of your journey and the work that you’re doing and what got you started in this field.

 

Erika Lenz (01:01.582)

Sure. I always wonder where I should start with this story because I did a lot of work before I ever engaged in the Agile community that I use every day. So I was in publishing. I did a lot of adult tutoring and education, which I certainly still tap into. I did project management. And, I was a web administrator. And I studied biology. I jumped around on mountaintops looking for little tiny grasshoppers so that I could study their genetics.

And all of this, it sounds like I’ve done a lot of different things and maybe couldn’t make up my mind, but I see a very real thread through it all that ultimately led me to work with Agile.

So I’ve been doing Agile for, I don’t know, over a decade, I think we’re at 13 or 14 years now. Started as a scrum master, got really lucky, and worked on teams of coaches. So I got good training as I was coming up. And now I’ve worked as a transformation coach and enterprise coach.

I have this long educational thread around social behavior and adult learning. And so that’s what that’s turned into is an obsession about how groups work and change. I love observing that. So there’s a little bit of the biological scientist in that for me too. I love observing how groups are working and then figuring out how to make things better. And over my time, I’ve worked at dozens of different organizations in different industries and probably in some way or another impacted tens of thousands of people which is a little daunting. I hope I’ve done a good job and I haven’t hurt anyone along the way. But it’s been really great for developing a deeper understanding of how groups grow and change.

 

Vit Lyoshin (03:13.864)

That’s a great journey. And you already have a lot of experience with what you’re doing. So, let’s talk a little bit about Kinetic Change and what’s the vision behind the company, and also who can benefit from the work that you do there.

 

Erika Lenz (03:32.11)

Yeah. So Kinetic Change grew out of some conversations I had with my co-founder, Robin Weldon-Cope. She’s a seasoned COO with operations experience across industries, including healthcare and software. And we started talking, we met through a friend and we just started talking about what we were seeing in organizations and what kind of challenges we saw people dealing with. The thing that bubbled to the surface was how much change people are dealing with in the workplace. And yeah, there’s a statistic, I don’t remember where I picked it up, but the assertion was that an individual employee is dealing with five times as many change initiatives as they were five years ago. And it’s just going up.

So that’s an individual employee. If you start thinking about the leaders of those individual employees, they are also dealing with lots and lots of change initiatives. And my experience and Robin’s experience is that often people don’t have the skills they need to navigate change. So we want to help that. And so it’s kind of a mission-driven thing for us, we want to make the workplace better for people who are dealing with change.

Together we have over 30 years of experience in myriad industries and different sizes of business. And so we take that background and focus on optimizing organizations for rapid change, which means being human-centric, looking at adaptable operations structures, and really focusing on adaptive leadership.

The other thing that we do is bring in a lot of what we’ve learned from Agile about building iterative and incremental change plans instead of software products. And what we find is that doing that, working iteratively and incrementally helps create rapid learning and lower resistance.

Change resistance is a huge thing. And what a lot of people don’t think about enough, in my opinion, is that the way that we are running change projects is creating resistance because we are pushing people into things rather than having conversations and helping align their vision with our vision. So we offer on-site assessments. We offer advanced facilitation and training for groups of change leaders, training for change leaders and their reports, and working with stakeholders. We also offer strategic coaching and mentorship for running large-scale change initiatives, which are some of the most complex things on the planet.

 

Vit Lyoshin (06:39.624)

Yeah, for sure.

When you start coaching and mentoring organizations, how do you assess and choose which methodology to use?

 

Erika Lenz (07:02.734)

So this is a complicated question. So we can look at a lot of different methodologies. If we’re looking at change methodologies, what comes to mind for most people are the change frameworks that are quite well known, ProSci or Kotter’s change method or ADKAR, and how those things fit together and how they help us develop change plans.

We are not focusing on change management at Kinetic Change. But I have a lot of deep respect for the people who use those frameworks. Those frameworks do tend to be linear. And so when we’re talking about iterative and incremental, we’re talking about something different than how these frameworks typically work. There is some iteration in them, but it’s not at the level that we like to talk about.

So when we go in and we’re working with an organization, there are many different methodologies that we might want to bring into play, and we try to align it with what kind of problem the client is trying to solve. Is it a workflow problem? Is it about creating better communication in teams? Or, is it about creating a culture that allows for more transparency? And so there would be a different methodology for each of those and multiple different potential methodologies. So we might be looking at different techniques in Agile, and there are thousands of agile techniques that we could bring to play. We might be looking at techniques from Lean, especially if we’re talking about optimizing workflow. And we might be looking at different ways of leading. So we might be talking about adaptive leadership, which has its own set of criteria and techniques.

So it all depends on what the client is trying to address and we never choose something and push it on the client. It’s about assessing what’s happening, looking at what specific problems they want to address, and then taking our expertise and telling stories about what failures and successes we’ve seen in the past and looking at what might work in a particular organization.

And most of the time we end up with a custom combination of techniques and guiding principles that resonate for both the client and their teams and us.

 

Vit Lyoshin (09:34.984)

I see. Okay, that explains it. What about the system thinking? How can organizations implement that? Because I personally find this one is a little bit complicated, maybe just because I’m new to this. So if you can help me understand that a little bit.

 

Erika Lenz (09:59.118)

Yeah, I’m moving things on my desk right now because I just want to show my very favorite book of all time. So this is a classic. It’s the seminal book on systems thinking. Systems thinking has been around for a long time. And yes, it gets incredibly complicated because if we’re looking at complex systems, we’re looking at systems that we cannot see with our human brains. There’s just too complex, there’s too much in the way, we have too many biases.

We like to focus on what’s in front of us and getting that systems level view is a challenge. It’s my favorite challenge. And so I don’t mind the complexity and I don’t mind that it can feel cognitively overwhelming when you start to do it. And so one of the things I do to deal with that is I like to start with simpler forms of it in smaller kinds of subsystems of the big system. So I use causal loop diagramming, for instance.

I have a favorite exercise that I love to share. I was asked to reduce conflict between a couple of VPs in an organization. And it’s silly to ask a coach to go reduce conflict between VPs. I mean, you can’t just go in and tell them to be nice. Stop being grumpy with each other in public. That’s not a good idea. So I took a different approach. And I brought in a causal loop diagram. We talked about the conflict that was happening on their teams. And we looked at all the dynamics and interconnections between all the players. Ultimately, it helped shift how they were thinking and to identify that their behavior was in fact contributing to the conflict that their teams were having. 

Then they came up with some ideas about how to work a little differently. And it did get better. But they resolved their own conflict because they were able to look at the system of communication between their teams and some of the emotional impacts, people were afraid of being blamed and afraid of retribution. And so diagramming that out on a board was really helpful for shifting those two gentlemen’s mental states about what was happening. I have success after success after success using systems mapping language. And that’s really what it is. It’s a language to help us see differently.

I have many successes just being able to shift people’s brains by getting a few people in a room and starting to draw on a whiteboard. So I am an advocate for not being intimidated by systems thinking. It doesn’t need to be perfect. It kind of by definition will not be perfect because we’re dealing with a lot of complexity. But there’s so much value in bringing people into a room together to talk about their perspectives and to get more shared understanding.

So one of my favorite things to do in software contexts is to combine flow mapping, like value stream mapping or process mapping from Lean, with causal loop diagramming or some of the techniques for causal loop diagramming. We spend a couple of days mapping out the actual flow of work. And I mean the actual flow. So we try to collect real metrics about how long something takes at each stage of the development process and identify areas where things slow down. This is classic process mapping in Lean. But then we draw a separate map of the variables and relationships where we see delays, where we have different perceptions of how the work is being done, and what kind of interactions are happening between people or teams or systems.

And so by putting those two things side by side, you get a much deeper understanding of the system of work. And then you can start experimenting, looking at where you might intervene to reduce some impediments or help improve communication in one area or another, or identify that perhaps your testing is too late in the cycle and you want to move it left sometimes drawing that out creates insights that help people come to those realizations that maybe that’s a good idea.

 

Vit Lyoshin (14:58.568)

I wonder how many people actually, what’s the right word, unexpectedly surprised with all these bottlenecks and any sort of improvements that need to be done by putting this into this map, basically visualizing all that. Sometimes it opens in their eyes.

 

Erika Lenz (15:26.254)

Yeah, absolutely. I’m so glad you brought that up because that has been part of the experience again and again. When you start to draw these things out, somebody’s always like, I had no idea. There’s a lot of stuff that ends up hidden at the team level because the teams are just living with it. And so when I’m coaching at the team level, I encourage them not to live with the pain, but instead to do what they can to start chipping away at it.

Creating more automation or simplifying a system where they can. But often people who are outside the team don’t see that. And so this kind of visualization can help create much more empathy across roles. I ran an exercise like this once with a client.

I was working at an organization where we had XP teams and these were such talented developers who were so used to working in a very independent sort of way that they sometimes needed a buffer with more traditional clients that we would be hired to build custom software for. So that was me. I played the buffer and did what I could to start productive conversations between the client and the teams.

So there was an exercise I was running like the one I just described. And one of the subject matter experts was a nurse. And she had come into the room pretty determined to have her say and her way. After we did this exercise, she kind of sidled up to me and she said, you know, I had no idea that software development was so complicated. And I’m going to be more careful about what I ask for.

And it was a wonderful moment because she was able to see into the secret layer of software development. These were very open and honest developers, so they were glad to share. And it created, I think it ultimately empowered her to get more of what she wanted because she knew to be careful. So she wasn’t going to be making requests that weren’t thought through. And because she would be making requests that were thought through, they were more likely to be implemented quickly.

 

Vit Lyoshin (17:56.14)

Yeah. Visualization certainly helps. Like even in Scrum, for example, or Kanban, let’s say, it’s a simpler version, but the team doing work day to day delivering something, they look at the board, they look at the progress, how much time is left or whatnot. So I think this company-wide value stream mapping or whatever other mapping technique or visualization techniques we can use, they really help at the global corporate scale show all these things and some people come to this realization. That’s funny how it happens if you don’t expose it, nobody sees it and you never know you have an issue, right?

Are there any specific tools that you use for this?

 

Erika Lenz (18:57.454)

Yeah, I’m messy when I do this. So I really prefer to work in a room with humans and to have a whiteboard, a big whiteboard, preferably a big long whiteboard so we can do process mapping, and to use pens and sticky notes because you can move things around. It feels more editable than even if you’re working on an online whiteboard, which somehow feels more formal.

So messy is good because it makes it accessible and less intimidating. And so it creates more of a collaborative feel. We’re going to build this map together. We’re going to figure this out together. Everybody can take a sticky note and move it somewhere. And so it gets people’s brains into a really productive state where they’re open to looking at things from a different perspective.

And I live in a different world now because I’ve worked remotely for almost four years. I’ve had very little in-person facilitations. They’ve been delightful when I’ve had them, but I’ve been doing a lot of facilitating online.

A tool like Mural or Miro or LucidSpark, which is the online version of, so there’s Lucidchart and then there’s LucidSpark and LucidSpark is the facilitation. And there are other tools out there, some of them less easy to use than others. But the ones that have a lot of bells and whistles and facilitation tools and allow you to pull people’s attention here, pull people’s attention to another spot, can get a good result.

What I tend to do is limit the time online and have folks work offline in person when they can or in their team room so that we have a kind of a back and forth and people have the experience of working together as a big group on an online whiteboard, but then they can go away and think about it and then come back for another round. So some of my most successful versions of this have had three iterations. It builds on itself. 

And so the first round is pretty simple and they go away and I give them an assignment and they put new stuff in and then the second round gets a little more challenging. And the third round, we summarize and look for insights. So what did we learn? What did we see? Where are the big delays or where are the big interactions that we want to start to address?

 

Vit Lyoshin (21:51.08)

Something interesting you just said that made me realize, that I don’t do this enough. We preach to do these iterations and increments for when we’re building something, right? But we don’t usually do that. At least my team, I guess I can, you know, blame it on myself. We don’t do that enough during the refinement when we’re trying to figure out how to do this, because maybe today we’re thinking about how to solve the issue. But tomorrow we have a better idea. Or by the time we get to it, we have a better idea. And it may be even simpler. So I just came to that realization, that maybe we should have these refinements and iterations just like you said, so we can pick the best idea, the best solution.

 

Erika Lenz (22:36.526)

Yeah, I love this and I love that I inspired you to think that way. So keep it up. You need to give people time to take a shower and have a brilliant idea come to them or even for people to dream. I sometimes am awakened in the middle of the night by an idea. I have a notepad by my bed because I have to capture it before I turn on the light or even wake up too much or it just kind of disappears. And those are often really good ideas, even when I’m awake. And so you do need to give people time to digest.

Can I tell another story? So there was a time when I was a consultant for a law enforcement agency in Missouri, the State Highway Patrol and it was a small development team, there were about 50 people and a handful of leaders around those 50 people. And they had a lot of challenges around how work was flowing between the teams, in particular the development teams and their production support teams. So they had, they’re sitting in the same room and they’re having challenges about flow and communication.

And I have been studying value stream mapping. And so I took over a conference room. They had whiteboard paint on all of the walls in this little, it couldn’t have been more than a 12 by 12 conference room. And so I grabbed a bunch of sticky notes and a bunch of pens and I started bringing people in to help draw the flow. And it rapidly was no longer value stream mapping.

Value stream mapping has some very specific things you need to do, to do it well. It became process mapping and there were lots of interconnections and it was very messy, but it took up two big walls, kind of turned to the corner.

I was forced to do it in iterations because I was coming in as a consultant every other week for four days and they were working so they weren’t able to sit there and do it with me for hours and hours. I had to take the time they had and not burn them out. But it turned out to be a brilliant way to do it. I would bring people in, I’d say, okay, we’re going to work on this part today for a little bit and we’d do our thing. I’d go away and they would start walking into the room and looking at it and adjusting it a little bit here or there, having conversations. Then the next time I came, there would be a whole new thing that would show up. And we diagrammed that and people would start to see how to use it.

And by the time we were done, we had a really beautiful solid map going all the way from that moment when a police officer, maybe a lieutenant or someone at a higher level says, we need this. Then it flows into these casual but closed-door conversations with leaders where they’re deciding all the things about what’s going to be built. We had that visualized so that everybody knew what was happening. They discovered that it was happening on a cadence. And they discovered that it was not happening frequently enough. And so maybe they should increase the cadence.

So what it turned into was a lot of really important conversations about how they were working. And it reduced all the frustration and anxiety. It allowed them to figure out where they wanted to optimize some things. And they asked me to create a big version of it, a cleaned-up version of it that they could walk their stakeholders in front of and say, here’s how we work.

So I made it really pretty. I’m sure it didn’t change for years, but it ended up being a great way for them to communicate with the police officers who would come in with guns on their belts and knew nothing about software. So they could say, this is why it takes a while. And here’s where we need you to engage. And so that was a really formative experience for me. I just kind of lucked into how powerful iteration could be.

And it was in a very small context, so it was easy. But I try to apply that same kind of thinking when I’m working in other contexts and larger organizations as well. And it works. Creates conversation that makes things better.

 

Vit Lyoshin (27:31.432)

That’s a great example. Sometimes we find good approaches almost by accident, if you will, or by constraints that we have to work with, and then it turns out to be the very best approach, actually.

So let’s talk a little bit about metrics and how to figure out how to measure success and what are the best metrics your experience that you can share with us.

 

Erika Lenz (28:07.662)

So there are no best metrics, okay? Your metrics must be tied to the problem you’re trying to solve. I get really grumpy about vanity metrics. And I get grumpy because they’re a waste of people’s precious life energy. And I want people to be working with more meaningful metrics.

If we’re talking about a change initiative, the metrics are going to be very different than if we’re talking about a software organization that’s building mobile apps. Hopefully, that’s obvious. But sometimes people just get stuck on their favorite metrics and they want to be looking at productivity and making sure everybody’s busy all the time. And generally speaking, that’s not a useful activity for improving software delivery.

So let’s just talk about software for a second. The metrics that I go to first are the ones that tend to be used in DevOps because they are all about flow. And when we’re talking about developing software in an efficient manner, we want to be looking at things like how quickly an item moves through our work system. So cycle time. We want to be looking at that on average and looking at things that are moving slower or faster than average and seeing what we can figure out about our system. So cycle time, throughput, work in progress. That’s the triumvirate of flow metrics. There are more sophisticated flow metrics, but that’s where you want to start.

The DevOps metrics that are pretty standard are things like lead time for changes, change failure rates, deployment frequency, which is huge, and mean time to recovery, meaning you’ve pushed something to production, and it breaks. How fast does it take you to fix that?

And the nice thing about metrics like this is that they shape behavior. They encourage core practices like test automation trunk-based development and continuous monitoring. So you can use these metrics to motivate change. It also encourages things like making smaller items of work, writing smaller user stories if you’re using user stories, and making sure that they’re independently deployable. And they’re meaningful. Like, how long does it take us to get to deliver something is a meaningful question. It’s much more meaningful than is this developer 70% allocated or 100% allocated? How many stories are they working on this week? That’s not meaningful. We want to figure out which stories are getting delivered into production and what’s in the way.

There you go, that’s the soapbox on metrics. You also want to have any, it’s not, it’s insufficient to work with just flow metrics. You also want to be looking at quality metrics and making sure that if you overemphasize flow, sometimes teams will feel a lot of pressure and take shortcuts. So you want to make sure that they’re also building quality, hopefully, zero-defect software.

 

Vit Lyoshin (31:49.704)

Yeah, what I find about most metrics is that they’re relatively easy to cheat, basically, to game the system. And what you just said is really the key, I think, because when you set up the metrics to change the behavior, that’s where you improve things and reduce waste and things like that, and you march to success.

 

Erika Lenz (31:58.83)

Absolutely.

 

Vit Lyoshin (32:18.088)

Because if you have metrics just to measure something, people will basically game the system and they will make those numbers as you wish them to be. And that’s it, nothing else happens after that. We’ve seen this so many times.

 

Erika Lenz (32:31.598)

That’s normal human behavior. This is how humans behave. It’s totally predictable, but it’s very difficult to game mean time to recovery. So that’s why these metrics are so useful for driving productive behaviors. And people, if your mean time to recovery has gone up in recent months, that’s going to start some conversations. Okay, why is that happening? How can we keep it from happening? And so it creates problem-solving conversations instead of how can I game this metric so that this manager gets off my back.

 

Vit Lyoshin (33:15.368)

Yeah, that’s true. Okay, so you mentioned a few times the iterative and incremental approach. Can you explain what the difference is and how to best use those approaches basically?

 

Erika Lenz (33:37.358)

Yeah, so iterative and incremental, they’re words that get tossed around a lot in software. I think they both start with I. And so sometimes people get them confused. So it’s important to define them.

Iterative means building and ultimately improving something through feedback and continuous improvement methods, whatever that might be. So you build part of a thing, you get it out there, you get feedback on it, and then you improve and you build more of the thing. And the iteration is generally on a cadence. So every two weeks you’re putting something out, or every two hours you’re putting something out, which would be ideal.

Incremental means working in small pieces. So if you’re building a house, you build the bathroom first. Then you build the part of the garage. And then you build the back patio.

So these are not mutually exclusive. In fact, the power in software is using them at the same time. Because you can build in small pieces. If you’re doing it in increments, say you’re doing it in some sort of cadence cycle, and you’re building part of that small piece, let’s say you’re building part of the bathroom in the house or part of the garage, and you get that out there and you get feedback on it, then you’ve got this nice machine where you are, it’s a feedback machine, it’s a creation and feedback machine.

And so you can do both at the same time. In fact, when a software team is creating user stories in, some sort of cadenced system like Scrum. If they’re creating user stories that meet the INVEST criteria, they are using both techniques. Do you want me to explain INVEST to your listeners? Or they can Google it.

 

Vit Lyoshin (35:48.712)

Sure, yeah,  we can define what that is.

 

Erika Lenz (35:51.982)

Yeah, so it’s an acronym. I’m not going to go through all of the parts of the acronym because that’s just boring. But the basic idea is that you want to be writing user stories, which are a replacement for requirements, traditional software requirements. You want to be creating user stories that are independently deliverable. And the user stories should be solving a specific problem that your user is trying to solve. To be independently deliverable, they need to touch all parts of the stack probably. They need to be testable. And they need to be small. And so those things are in service of quickly getting something out there that gets feedback. If it’s independently deliverable, that means that it has some sort of function to it. And so you can get feedback.

I could have done better with that, but I think that’ll do for now. Google it.

 

Vit Lyoshin (36:54.664)

That’s okay, that makes sense. Yeah, I think many people have heard of INVEST and what this means in the context of user stories. So it’s one of the techniques to write them.

 

Erika Lenz (37:08.334)

So if you don’t mind, I’d like to talk about how you can use iteration and increments to apply to change initiatives, because that’s what we do. We’ve taken all that learning from software teams, and there’s a lot of stuff that goes into doing that effectively, everything from how people are thinking about breaking down work to how people create a culture, a learning culture, and a feedback culture that allows you to rapidly improve what you’re building.

So at Kinetic Change, we like to use those approaches to look at a change initiative. And so it is more efficient and productive. It feels like it takes more work upfront. But because you’re getting feedback from your customers, who in the case of a change initiative are your employees, and because you are having many frequent touch bases about how things are evolving, you’re having a lot of transparency about what you’re measuring and what success looks like, and you are trying to create change in small pieces instead of one grand change initiative, we see that it reduces resistance and other kinds of friction in a significant way.

However, it requires shifting away from a typically linear, structured, big plan upfront change management approach that you might see in more traditional change management. People have to change how they’re thinking. So it’s a mindset shift of sorts like we talk about in Agile.

I’m actually kind of irritated at the idea of a mindset shift because it’s very difficult to define. But it’s really about being willing to have some uncertainty towards the end of the change initiative and to learn along the way what’s in the way of your change and start to work directly with those impediments. And those impediments are often a lack of understanding or a misalignment of values or some sort of legacy technical thing that’s in the way that you want to learn more about in order to actually create change in your organization.

So emphasizing emergent feedback and learning is a very powerful tool, especially when we’re talking about human systems, which is the core of change. I mean, we may have a new ERP system that we’re installing for our organization, but really it’s going to come down to whether people use it effectively and whether they’re angry or frustrated because they liked the old system better.

When we’re talking about humans, focusing on understanding and leveraging from a kind of social psychology or anthropology perspective, the interconnectedness of people, processes, and structures gives us a lot more information to help us navigate the complexities of change and ultimately, hopefully, to foster an adaptive and resilient organization. That not only gets through the change initiative at hand but is ready for the next one.

 

Vit Lyoshin (40:39.4)

Yeah, that makes sense. And we mentioned, well, you mentioned a couple of times, the feedback. And I think when giving feedback and receiving feedback, it’s important to stay in a kind of blame-free culture, including retrospectives as well. When I say feedback, I’m not really talking about a survey from a customer. I’m talking about any sort of feedback between people, right? And sometimes a conversation can go a little bit in a blame fashion if you will.

So how is it important for organizational change and for any change basically, the blame-free culture and why?

 

Erika Lenz (41:33.998)

I love this question. Thank you.

So you can create pockets of blame-free. If you’re a Scrum Master working with a single team and you work really hard to bring in, say, the retrospective prime directive and help people understand that people are doing the best they can at any given moment, given what they know. And so it’s easy to do that with a small group of people. It’s not always possible, but it’s easier because it’s a manageable size of a human group.

When we’re talking about doing it at an organizational level, there’s a whole lot of stuff to think about. The tone and techniques used by leaders is huge because culture follows leaders. Leaders are the advocates and role models in culture. There’s also because we’re messy humans, we are filled with cognitive biases, just so many. I don’t know if you’ve spent any time deep diving into the cognitive bias codex or looking on Wikipedia about all the cognitive biases. It’s fascinating stuff. And it is, when you spend time there, you realize how fallible our brains are.

When we’re in a stressful situation with our fellow messy humans and something goes wrong, it’s very typical that people will get a little blamey. And that blame shuts other people down. So this is expensive for organizations potentially because there might be real problems that need to be talked about. And if you’ve got someone who’s shut down by blame, they are not likely to bring it up. And so this is kind of a point at all the psychological safety research that’s out there. Amy Edmondson’s work started with healthcare organizations and specifically teams of doctors and nurses. And if the nurses feel like they might get bullied or blamed by the doctors, they will not bring up things that they need to and there are poorer patient outcomes as a result.

So if we want to have transparency and everybody collectively openly admitting to mistakes or failures or concerns or things that they’re noticing, or if they’re having some divergent ideas about how to solve a problem, we need them to be able to talk about those things without worrying about the punishment of some sort, whether that’s social punishment or actually getting put on a pip or losing their job.

But this is hard. I think it’s easy to talk about creating a blame-free culture, but what you’re dealing with is a lot of messy humans. So, you know, it starts with leaders, and the leaders need to change their behavior. They need to not conceal mistakes. They instead need to talk about them so that they’re role models for being vulnerable. You want them to be explicitly talking about how there is a policy of no blame and then holding people to that. Because people are gonna have moments and they’re gonna need a little correction.

Like you’re being kind of blamey right now, why don’t you take a walk instead of letting it roll. So you want to acknowledge not only that mistakes happen, but that blame happens and that when it happens, something different needs to happen. And it’s really important that leaders investigate incidents or failures with an eye to what in the system allowed this failure to happen. And this is a big cognitive shift for a lot of leaders. Instead of blaming the person, instead of looking for the scapegoat, you need to shift your vision to, okay, here’s the system, here are all the operating procedures we have. Here’s where information is flowing in and out. Here’s the technology we have in place. What allowed this failure to happen?

And then you’re looking at your employee who was part of the failure as part of a system, and you can start looking for ways to support them and to keep it from happening the next time. In fact, there are organizations that celebrate this. Etsy is well known for its three-armed sweater award that they give to people when there’s a failure that teaches the organization something important. So there’s a story about a new software developer who came in and took the entire site down in this very catastrophic way because they pushed something to production. So instead of blaming or firing that software developer, they said, wow, thanks, you surfaced this big vulnerability. Now we can fix it.

 

Vit Lyoshin (47:07.976)

Yeah, that’s a very interesting approach. I think it’s maybe relevant here as well. I think it’s maybe a Japanese proverb or something like that that says it’s not the soldiers’ fault that we lost the war, it’s the generals. And usually, they resign first, right, leading by example. So they take that blame, if you will, or they acknowledge that they failed somewhere and they take action first to correct it and I think that’s great. And if more leaders like that exist, I think the whole organization will be a happy place to be.

 

Erika Lenz (47:49.262)

Yeah, it’s funny, I’m having a bit of a reaction to that because it’s so hierarchical and it puts all the responsibility on the shoulders of the general.

You know, the general is a messy human too. And if you’ve, I think that that kind of a mental model could help that general feel like they shouldn’t be talking to people, right? And instead what we want are leaders who are asking questions and showing their vulnerabilities so that the people beneath them not only show their own vulnerability but feel like they can lean in. So, you know, there’s another model in the military about how you distribute decision-making so that the soldiers in the middle of a crisis have the information and the training and the skills and the permission to make decisions on the ground because that’s where the fastest, most effective decisions are going to be made.

So yes, you don’t blame the soldier but you train the soldier and you make sure they have all the stuff they need to do well. The soldiers should be supporting the leaders as well as helping provide information to them and helping find the potential problems and surface them. So you want a really healthy flow of information and communication up and down that hierarchy so that folks have the information they need to make good choices.

I think at the senior executive level, they are often so separated from what’s happening on the ground that they don’t have the information they need. And it’s very easy to point our fingers at them and blame them for that. And yes, they should probably be reaching out and finding ways to get that information, but they’re also dealing with a whole lot of stuff at that level. So organizationally, we need folks to lean in all the way up or all the way down depending on what you’re looking at because we ask perhaps too much of our leaders sometimes.

 

Vit Lyoshin (50:10.536)

Yeah, okay, that makes sense, I agree.

What motivates you to keep working in this area?

 

Erika Lenz (50:20.526)

I’m pretty sure I can’t do anything else anymore. I’ve been doing this for so long and I’m so obsessed with these questions about how to get groups of people through the complexity and rapid change that is just becoming more and more intense. This is the problem I want to solve. So I’m motivated by the problem, I’m motivated by working with people and I’m motivated by the mission of helping people suffer a little bit less around this.

 

Vit Lyoshin (50:58.28)

That’s a good motivation.

How do you stay updated in the field with agile, lean, system thinking, and all those tools and methodologies?

 

Erika Lenz (51:13.614)

I’m training a bot to ingest all that information. No, that’s not true. I don’t think bots can do that.

I read constantly and reread constantly. The reason I pulled this book up is The Fifth Discipline is that I am rereading it for, I don’t know, the third or fourth time just to see what goodness I can glean this time around. I’m a little haphazard about that because I have a touch of ADD and so I bounce from book to book. I have literally books in my house that are sitting in different areas so that when I sit down I can pick it up.

I’m playing right now with lots of AI tools and summary tools for everything I look at digitally. And I’m working with LogSeek, which is basically a custom knowledge base for everything that’s digital. I’m still figuring it out. Anybody out there is really good at it and they want to get on a call with me and teach me how to be awesome. I will take that and I’ll send you chocolate in return.

But it’s a lot. We have so much information coming at us from all directions at all times and our brains are not evolving fast enough to keep up with it. So we have to figure out how to keep our brains from burning out. And it’s a constant challenge. It helps that I have over a decade of experience under my belt. And some of it is just about putting the time in and studying constantly along the way. I don’t know. I feel like I’m rambling a little bit. But does that answer your question, or do you want me to?

 

Vit Lyoshin (53:02.184)

Yeah, no, it does. It makes sense.

I read a lot as well. I just sometimes find that I read about the same maybe concepts in different books and I really have to pick and choose and go for sources that are really high rated or recommended by some people. Or I’m reading the stuff that I forgot already, like those iterations that we were talking about, right? We need to repeat a few times to get the juice out of it.

 

Erika Lenz (53:33.678)

It is very true that nothing’s new. So every book that comes out is, at this point, regurgitating something that was done before. So after you’ve read a lot, it becomes a little repetitious, which is comforting in a way. But it doesn’t change the fact that you need to keep digging and learning.

I think, to do well with this work, which is really about constantly solving problems in a bunch of different contexts. The more information you bring to the table, the better. And the better you can serve your client. Most people who are actually working for a living don’t have a lot of time to read. And so if you can become a bit of an expert and a librarian teacher, I get a lot of feedback that people always learn something when they talk to me. If you can bring that to the table, then you’re really useful.

 

Vit Lyoshin (54:38.216)

Yeah, absolutely. Well, I learned a couple of things at least today.

What would be your final advice to people who maybe want to get into this field or maybe who want to start promoting or pitching these organizational changes?

 

Erika Lenz (54:42.894)

Good. I did too. Thank you.

My big advice is don’t let yourself get discouraged. Being a changemaker of any sort, whether you’re a scrum master trying to grow a team or you’re trying to make some sort of very large change in your organization, it’s exhausting. It takes a lot of grit self-discipline and self-care.

Make sure that you’re spending time doing that. Reach out to people who inspire you. Keep feeding your inspiration part of your brain. And definitely get enough sleep, eat good food, and get enough exercise, because you’re doing hard work.

If you’re trying to get into the field, read, read, read, read, read, read, network, and reach out, the Agile community in particular is very good at providing a lot of free educational resources. And so just start that process right now and meet people and see what’s out there. The Agile community is in a bit of a difficult spot right now with all the tech layoffs. And it’s not just Agilists, it’s software developers, it’s testers, it’s all sorts of folks who are feeling the pinch. But I don’t think that the techniques and ways of looking at the world that we are very fond of in the Agile community, I don’t think those are going away. In fact, I think they are more and more important with every passing day. And so keep at it.

Don’t get discouraged. Get gritty. Reach out. Get support. Go hang out with Bob Galen. He’s doing a lot of interesting work on Agile coaching right now.

Come check out my Change Mojo classes, and see if that’s something that you’re interested in. Reach out.

 

Vit Lyoshin (57:01.576)

That’s great. And then how people can connect with you.

 

Erika Lenz (57:08.238)

I am very findable on LinkedIn. I’m very active there, so just search on my name. You can go to kineticchange.com, so that’s kinetic, and then another c on change .com. And check out what we’re doing there. We’re still building things up, so keep coming back and seeing what we’re up to this week.

I publish blog posts. I have a substack where I’m talking a lot about messy humans. So look at Erika Lenz on Substack and you’ll find it. I also am a co-facilitator of an Agile Denver AI meetup called the AI for Agilists Learning Collaborative. And we provide hands-on experience using AI. We’ve been focusing a lot on the LLMs, chatGPT, and friends, but helping people who don’t have time or who are a little bit nervous about AI to have a place where they can come and have a social experience while learning.

 

Vit Lyoshin (58:18.984)

That’s pretty cool. It should be pretty easy to find you. And you have a pretty cool website too. I checked it out. It looks great.

You have a wealth of knowledge and we talked about many topics. Thank you very much for your time today. I think that was great.

 

Erika Lenz (58:39.566)

Thank you. You’re delightful and this has been really fun for me. So I appreciate you reaching out.

 

Vit Lyoshin (58:48.328)

Sure, thank you.

Thank you, and I hope we can talk more in the future too. So thanks. Okay, bye -bye.

 

Erika Lenz (58:52.398)

I would love to. Thank you. Bye.