Most teams say they want to improve. Few actually build the habits that make it happen. In this episode, Brian and Lance break down what separates teams that learn from teams that stall—and what leaders do that quietly gets in the way.
Overview
What does it really take to become a learning team?
In this episode, Brian Milner and Lance Dacy walk through five habits that show up in teams that continuously improve—and the leadership behaviors that either support or shut them down. From psychological safety and truth-telling to short learning cycles and focusing on the right problems, they unpack what actually drives improvement inside real organizations.
Along the way, they challenge common assumptions about silence, metrics, and “heroic” problem-solving, and offer practical ways leaders can shift their approach starting immediately. If your team feels stuck, busy but not improving, or hesitant to speak up, this conversation gets to the root of why—and what to do about it.
References and resources mentioned in the show:
Lance Dacy
Blog: Why Teams Matter More Than Ever for Innovation by Mike Cohn
#143: What Still Makes Teams Work (and Win) with Jim York
#171: Why Agile Teams Succeed—or Don’t with Colin Fisher
Subscribe to the Agile Mentors Podcast
Want to get involved?
This show is designed for you, and we’d love your input.
- Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
- Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com
This episode’s presenters are:
Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.
Lance Dacy is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®. Lance brings a great personality and servant's heart to his workshops. He loves seeing people walk away with tangible and practical things they can do with their teams straight away.
Auto-generated Transcript:
Lance Dacy (00:00) Are we building in time in our day-to-day work to actually spend time and capacity on the improvements? Usually the answer is no. Teams have to work overtime or do things outside of the normal course. Leaders need to bring that in to the way that we're working, almost like technical debt for a product.
Brian Milner (00:16) I'm Brian Milner and this is the Agile Mentors Podcast, a show about both the personal and organizational journey towards agility. My friends and I will be sharing with you what we've collectively learned from seeing thousands of companies Agile implementations, apparels and pitfalls, as well as the secrets to success. We'll share our personal in the trenches experiences so that you can apply what we've learned
in a practical way in your careers. We also hope to hear and learn from you as well. If you're like us and are always in search of better ways of working together, you're in the right place. Join us, mentor, and be mentored. Let's get started.
Hey everybody, welcome back. This is the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today, I have friend of the show back with us, Mr. Lance Dacey. Welcome in, Lance. You? Yeah, it's a new year and we're off and running. We kind of have taken this approach of trying to think through in each of our episodes, some main points, some main ideas we're trying to focus on.
Lance Dacy (01:19) Hi Brian, great to be with all of you.
Brian Milner (01:32) We wanted to have Lance on because there's this one area that I know I've had a lot of conversations with clients about. I've had a lot of conversations in classes about, and that's about having teams that are learning teams, learning organizations, and why that's so important. So let's kind of start there, Lance. Why do you feel like it's so important for teams to be successful or organizations to be successful that they place a real emphasis on continuous improvement?
Lance Dacy (02:00) Well, let's talk about continuous improvement. We're talking about building learning organizations. I think a central theme to that is always looking for opportunities to improve. And that's the hard reality of life and anything that we do. If you're humble enough to say, hey, we could do better, you could always say that there's nobody out there that's perfect that I know of and no organization that's perfect. And so I think fundamentally continuous improvement, the central theme to that is building out an organization where people learn.
Well, what's the key ingredient to learning is to be curious, right? To kind of look around and say, how could we do this better? Or why did we do it that way? And I find, you know, this is, we've been grappling with this. have for a long time where I feel like the real barriers to that happening is leadership. Just plain and simple. And it's not necessarily, I'm not indicting leaders and saying they're just terrible. I just don't think there has been much evolution in leadership practices.
We don't seem to have a central focus on helping leaders learn how to create that environment. We kind of come from this command and control era of where industrialization happened 150 years ago. And I don't know about you, Brian, but I haven't seen a lot of evolution in leadership development. I mean, what do you think about that? I may have that wrong. So there's another part of learning is saying, hey, I might be wrong on this or what am I missing? But I'd be curious to hear, know, we both spend a lot of time in organizations, but what is your general feel
about leadership evolution at the rate of change that we're seeing and how organizations need to be hyper competitive and thrive and be nimble.
Brian Milner (03:39) Yeah, no, I think you're absolutely right because I think there's, I've never talked to a leader that says they don't want this, right? They all want their teams to be highly evolving and learning and self-sufficient so that they don't need to be ⁓ spoon-fed in their growth, but they actually mature and take that on their own. But on the other side of it, there's the pressure to deliver and deliver more.
That's where the leadership kind of has this disconnect or break is I've got pressure to get my teams to deliver. When do I stop down and stop doing that so that I can now focus on learning? And that just takes the back seat because the pressures for delivery are so high that the learning seems like it's a nice to have if there's time. There never is time.
Lance Dacy (04:34) You know, that's the other side is leaders kind of are used to these planning cycles where they're like, well, we need to go learn more. Let's get everybody together and go do that. But I feel like continuous improvement isn't a meaning, right? It's not where we get together. You know, we, we do a lot of scrum training and agile training, you know, as well as combine. And there's always these cadences where we get together and reflect and try to figure those things out. And I always say, I don't really think of those as meetings. Those are working sessions, right? But.
Leadership views that as a bunch of people, dollars sitting in a room and are we getting value for that? And I think the hard reality is that value is like planting an avocado tree or something. There's one of those trees where you plant a seed and you don't see the fruit of it for seven years. And I don't think businesses are patient enough to let leaders do that as well. So it's not always their fault, but I kind of want to, we could, for the risk of just, could go all over the board here. feel like.
Continuous improvement isn't a meeting. It's a reflex. It just needs to constantly happen. And I feel like if our teams are only learning, you know, after a production incident or something bad happened or leadership blows up and everybody becomes fearful, that's not really improvement. That's more of a trauma processing, right? The teams learn how to do that. And then that just starts a very recursive problem where people fly under the radar and don't want to cause a whole lot of waves. And that's the worst thing you can do.
So I feel like what actually embeds continuous improving, I've been thinking about this a lot, I've written some blogs on it, but I think the two things that we should focus on here are tone of leadership, the human side of it. And then of course the system design, which we spend a lot of time working with anyway, but I feel like the tone determines whether your people will tell the truth or not. know, structure of the system design will determine whether the truth gets told, you know.
and gets used, but the tone is like, will that truth come out? Will people feel safe? And so I hear a lot in the industry. love this catchphrase that if nobody ever brings you bad news, congratulations, you're the last one to know. And that's the most expensive place to fix it. So I feel like, you know, what separates teams from learning and stalling out is truth telling is safe. So people feel safe to say what they're feeling and call out bad problems as they see them.
And it has a cadence and that's the system design. I still believe in the cadence. I still believe like in scrum, you have a retrospective every two weeks, but the way you conduct that it could just be theater, which we see a lot of. I think leadership has a responsibility to grow that in their tone and then their interactions every day. And ⁓ that's where I feel like we should focus.
Brian Milner (07:17) Yeah, no, I agree. I think those two broad categories are the right ones. But we've kind of broken this down as well to think about in terms of habits. Like there's habits that teams that do this well have, because we talk about this as being something that should be part of the DNA of the culture, right? It's just kind of ingrained in what the team does or what the organization does. And I think you're right. That first kind of instinctive thing needs to be about speaking up. It needs to be about
It's safe to speak your mind and that when you speak up that your opinion is heard, it's listened to, it's appreciated. It doesn't have to mean that it's taken or that your idea is the one that we're going to go with, but at least it's respected. And when that's the case, then that team can start to form that habit of speaking up by default. When they see something wrong, they say something, you know? It's amazing. I don't know if you kind of feel this way as well, but
It's amazing to me how counterintuitive that seems in lot of organizations of just people recognize problems but don't say anything about them.
Lance Dacy (08:23) Well, they got to practice tone too, right? So I don't want to just say leaders have to be cognizant that it's just leaders have the responsibility, I feel like, to grow the psychological safety of the organization. Cause most people, if I'm responsible for your paycheck and your performance review, you're going to act differently around me. have some high degree of power over that position, not necessarily a person per se.
but people are gonna behave in a way that is malleable to me getting the highest pay raise and being amenable and all those things. So you do have to have the right tone. You don't wanna be in a position where when you do speak up, people are like, take it the wrong way. You say something five different ways and it can be taken that way. So I feel like what you were just talking about, the first habit of learning teams, I think is what you said is speaking up. I think we should talk about what happens when people stay silent. I think that's kind of the first indicator
for leaders, the first signal, if you will, is that people are silent. And I think a lot of times leaders think that silence means alignment. In fact, I hear, just did a coaching session the other day and I was asking a really poignant question that I was like, this is going to spur on some really good things. And everybody in the room was just silent or in the, in the zoom meeting. And one of the people spoke up and said, well, silence means alignment. I'm like, I don't think so. I think that's the problem.
is most leaders kind of think that way as well. And most of the time, really what it means is people don't feel safe to speak up or they don't think it's worth it to speak up. And I think the second signal is when leaders kind of see this beautiful dashboards and they're managing everything to these metrics, but it has an ugly reality, right? We can have metrics are green and everything looks good, but the delivery is chaotic. That's another signal that people aren't really bringing up the problems. And I think
That's what happens when people stay quiet is rework delays, risk, you know, that's the real cost of not having psychological safety. call it paying the truth tax, right? So if people aren't willing to speak up and bring issues earlier, by the way, that's the cheapest place to fix them is early. And the more time that goes through the more rework delays and all that kind of stuff, they become really expensive. And that's the truth tax you get.
more coordination to get more approvals, you get more theater, but fewer actual improvements. So I really think high learning teams, and we even kind of teach this in one of our classes, Google the Aristotle project, right? Google's Aristotle project, the number one predictor of a high performing and high learning team of psychological safety. I think they looked at 160 teams. So let that be a learning lesson to leaders out there that are listening, or even if you're a tech lead or something like that.
We need to foster an environment because the pain of it shows up in the truth tax that you pay over time. used to call things a release tax as well. Like we were doing really good at iterative and incremental development, but we weren't releasing to production. So we'd have all these 100 features we'd have to release to production. There's a tax that's hidden on that. And I think the truth tax is just as important when it comes to building learning organizations. And so to me, that's one of the big things as well.
Brian Milner (11:36) Yeah, I agree. I'll give a shout out to an old boss of mine, Dave Ellet, which I doubt he's listening, but he had this phrase that stuck with me through the years and that's bad news is not like wine. It doesn't get better with age. I think that's part of this as well as that we need to know, right? And we need to know what's wrong early so that we can do something about it. Cause we have options. We have more options the earlier we know, but the later in the process we find out, then the less options we have to actually do anything about it.
Lance Dacy (12:04) It's like that snowball, right? It keeps getting bigger. But I feel like that's a great analogy too. But the low safety is when leaders say, hey, let's get together and talk about this. It's a post-mortem, you know, our patient side, let's figure it out. Well, they check the box and they say, hey, we got everything together. Really what they're trying to do is be able to report back to their boss and say, here's what we're doing about it. You know, so the, the impetus of that meeting is not really about improvement.
It's about messaging in my opinion. I'm not trying to cast this across all leaders. I'm just trying to share my experience in corporate, I'll say corporate environment. When you have a meeting before the meeting and you have this messaging tax and all this other stuff and you're more worried about how it sounds, then that's not real safety. And so I kind of have this idea that low safety, you can identify this, that when the post-mortem meeting ends, the real meeting begins in the hallway.
People have read status. don't debate decisions. No one asks, you Hey, I've got a really dumb question. And when you start hearing that, you started saying, well, it's not just the leaders that have a responsibility, but the team as well. So I'm not trying to give them permission to act however they want either, but that's one of the things that we have this meeting and everybody kind of stays quiet and okay, well that's alignment. walk out leaders now have their message. So they got their checkbox, but no improvements really happened. The improvement is how can I fly under the radar? Yeah.
That's it. You know, some of team members are like, how can we delay getting an issue that's blown up? And it just sounds so elementary when I hear it that way. But I just feel like that's one of the root problems in corporate environments today is leaders are not fostering an environment where I can speak up and say something and have fear of retribution of what I just said. That's really what psychological safety is, is I'm not worried about what other people think when I'm just trying to help. So that's where I feel like low safety actually looks like day to day.
Brian Milner (13:54) Yeah, I agree. the second one I think is a big one as well. And that's about short learning cycles, beating longer.
planning cycles. I think still there's a lot of leaders who rely on those longer planning cycles. So Lance, why do shorter learning cycles work better?
Lance Dacy (14:11) Likely say when we practice Scrum, we say, well, the work that we're doing is really complex. The way you break through complexity is to chop the problem up into smaller pieces and prioritize it. And I think improvement has the same problem as technology or knowledge work that we apply agile practices to is we really don't know we've solved the problem until we've solved the problem. So when you have, you know, which Stephen Wolfram kind of refers to that I use a call computational irreducibility, it's like, we really don't know until we know.
Y'all know that, but we all try to put all these plans in place to mitigate that. And I think the hard truth is not only in product development, we don't know if we've solved the customer's problem until we've solved the problem, which means they use it and they see it and they say, I forgot this. we say, we engineered it incorrectly. You know, we can go back and the smaller that problem is, the less of a tax it is to rework it. So we were just talking about the rework cycles and all of that good stuff, but
I think the shorter feedback loops give you a better opportunity to carve a path and say, here's our biggest problem right now. Let's try this. Did that work? Well, if you try something and wait six months, it's too late. What other things have changed? You know, I remember listening to Jeff Sutherland one time, he gave a great analogy for the system design process that we're talking about, how you tune and improve a system. You want to try to find one small thing to do at a time.
because you might fix that one thing and expose a bottleneck somewhere else that you least expected it. And if you try to change everything all at one time, it's hard to troubleshoot. So imagine all of you who are technologists when you start trying to figure out where your computer is. So you don't just change out all the components. You're like, well, let's start with the bus speed. Let's start with this. Let's start with the graphics card and you do it and then you see how it does. And so I really think those small feedback loops, not only in product development, we've proven that out, but why don't we practice the same
cadence when it comes to solving organizational problems. And I think it just becomes overwhelming is the thing. It's like people feel like they really can't fix something. That's the other problem is like, you know, I just want to come in and do my job and I want to contribute. I want to do great things, but the organizational design and the way that the organization works is out of my purview. And I really feel like that's another thing that leaders have to correct is like, no, those changes are going to happen on the front line of value creation. It's not going to be the
The head of HR, somebody says, we need to make these nice culture changes. It's to be the day to day, small impactful. We go to this meeting and a leader leads with what am I missing? Or man, that was that, you know, we failed publicly and it's on me. How can I help? You know, it's like when leaders start using that tone, I'll go back to tone, then that system flow and that cadence will even be more of an impact. So I think chopping the problems up into smaller pieces and then investigating whether that worked or not.
applies to product development but also organizational improvement, continuous improvement.
Brian Milner (17:08) I mean, we're talking about learning cultures and learning teams. I mean, just imagine in another realm, like in school, let's say that you started to take a course and basically the instructor gave you a book and said, all right, I'll see you at the end of the semester. If there's no check-in, if there's no actual. Right, that's what we do, right? That's a lot of what we do in organizations is we set aside these big projects.
Lance Dacy (17:27) I'm gonna that.
Brian Milner (17:35) And we can't figure out why we don't learn anything because there's this long gap between when we started and when we actually analyze what we learned. But the shorter the learning cycle, the more learning that can take place. And I think those long planning cycles really give this illusion of certainty, illusion of an assumption even, that we know more than we actually do.
Lance Dacy (17:59) And the focus becomes on, need to write whatever you use. Like you need to write this paper rather than learn. So I feel like that's the other problem is when we do these long planning cycles, the plan becomes the solution. It's like, ⁓ I just need to meet the milestones of the plan. Well, what if those are completely wrong? So, you know, I feel like the, ⁓ the structures that we can use, you know, as coaches, as leaders, you know, whatever position you might be in the organization that create.
Safe feedback loops. That's really what we're looking for here. Short, quick, safe. Let's use that word as well. Is blameless learning reviews. So we talk about retros and post mortems, whatever name fits on that. Talk about contributing conditions, not pointing blame. know, most of those meetings start with who is to blame and what are you going to do about it? Okay. So I feel like we want to take that away. There's no blame here. We're all in this together.
what happened and how can we do better? Small and simple and so many people are worried about the messaging that we lose sight. That's again back to the planning that we lose sight of what's the real outcome we're trying to achieve. And I think small experiments help. We talk about experiments in product development. Why don't we talk about experiments in continuous improvement? We believe that if we do this, it will do that. And so I feel like what leaders can do is fund
the capacity to do that. That's the other problem we have is it's just, you know how we do in product development, new feature, new feature, new feature, new feature. Well, we also want to emphasize that the engineering and maintenance of a technical product is a large cost of making a great product. And that gets ignored. I think that's the same problem with organizational design is you start paying a tax by not improving the organization and the flow. Let's use the word flow.
of the teams and so I feel like leaders need to fund capacity for that improvement even if it's 10 to 20 percent. We'll give that lip service but are we really doing that? And demand learning metrics not just delivery metrics. So I did a blog post just recently on this where why doesn't our dashboard include learning metrics? Like here's what we're trying to learn. We believe if we do this it'll happen here. Why is it always just delivery, delivery, delivery? Well, leaders create that environment. So there's another message to leaders and I think make it
safe to surface constraints, you know, and problems and issues. And you're not the bad guy or Eeyore, you know, it's like, Eeyore over here says, I can't do anything. like, no, no, you got to have a good tone about it. It's like, here's what I'm concerned about. Or here's what I feel, you know, we teach all this different language as well as coaching on how to deliver information in a manner that's less defensive, you know, and when you're working with a lot of different people, you have to be mindful of that. I think.
When we talk about short learning cycles beating the longer planning cycles is one of our habits. Number two is creating those structured feedback loops and building learning into the system. More importantly, leaders funding it, making it okay to do it and giving a good tone about it as well.
Brian Milner (21:05) Yeah.
on it?
Lance Dacy (21:06) Well,
so we, I feel like, you we teach different agile methods of managing work like Scrum and Kanban and extreme programming and all of those things. And they all have one central theme that I don't think we often as leaders do a good job reinforcing with teams, which is limiting work in progress. When you talk about this primary habit of swarming the constraint, you're looking at the flow of work.
and you're building out feedback loops that you say, here's what's slowing us down. We have psychological safety that allows us to actually say those things. That's great. But then the next problem is, are we trying to fix too many problems at a time? I'll go back to that Jeff Sutherland analogy where he was talking about how to conduct a retrospective is to only pick one, two or three things, every retrospective that you can actually fix the very next spread. And I think what happens is
teams get inundated with the organizational problem. So there's just too big. can't fix it because we're not chopping the problem down. Right. So there goes back to that other habit of small short feedback loops. So we don't feel inundated with the gravity of the problems that we have in the organization. mean, families have this as well. You know, if you're married, you have kids, you can sit around and say, I've got a hundred problems. Which one's the first one I do. We tend to try to do that pretty well in families, but in organizations, it just feels like it's out of our control. So.
I feel like when we talk about swarming the constraint, what we're really saying is just limit the improvements we're trying to make at a time as well. What's the most agilely we want to deliver the highest business value item with the least amount of costs, with the least amount of friction. Why not practice that with improvements? So go find the improvement that gives us the highest value for the least amount of costs and reduces friction in the organization. Go fix that before you do anything else. And if that's too big, chop that up.
You know, so you have epics and stories and all that stuff related to your, I call it the improvement backlog. And so if leaders aren't funding that, by the way, this doesn't matter. So remember we go back to, we building in time in our day-to-day work to actually spend time and capacity on the improvements? Usually the answer is no. Teams have to work overtime or do things outside of the normal course. Leaders need to bring that in to the way that we're working, almost like technical debt for a product.
Brian Milner (23:29) Yeah, absolutely agree. I like the Jeff Sutherland quote that you talk about because, you know, one of the things he says in that quote is, you know, you don't know how the system's going to react when you remove that one big barrier. And we're talking about this in the terms of a learning organization. Well, that's where the learning comes in is, once you remove it, what's going to happen next? We don't know. We got to learn. If we don't give the time to that, then if I make a list of our top five problems right now, and we just
start off on those five. Well, after I fixed the first one, the next most important thing may not be what I thought it was gonna be, right? It could be something entirely different and that's where the learning needs to take place. It can't just be a big improvement backlog that I come up with at one time and never actually adjusted or learned from.
Lance Dacy (24:16) or somebody's just sitting there managing it like a product manager is just managing JIRA tickets. It's like that's not improvement. So building out a learning organization goes back to these habits of, well, I'll just talk about the two, leaders creating a tone that we can even talk about improvement so that we actually surface the right issues. And then what you're just focusing on here, the last two habits are building those short feedback loops and limiting work in progress. Let's swarm it and...
stop starting and start finishing. We say that a lot about product development work. Well, drink your own champagne when it comes to making improvements. And so that might be where you have two separate work streams if it becomes overwhelming. But I think the leaders again set the tone on that by making it a priority. And if all they focus on are their metrics and their dashboards and delivery output, this kind of just takes a secondhand theater, if you will.
Brian Milner (25:10) Yeah. Our fourth one then was talking about how we need to run learning reviews that change the system. I'll throw that out to you, Lance. What does that mean to you about having things, learning reviews that change the system?
Lance Dacy (25:23) Well, I mean, I think I'll go back to tone and truth. If you have leaders that are asking the good questions that actually drive people to surface problems, then I think this becomes less of a meeting and more of a working session. So when we have learning reviews, I keep going back to product development because that's kind of what we talk about on this show a lot.
When you do product development, you want frequent check-ins with your people that are using your product to say, is this what you wanted or not? Well, why aren't we doing the same thing with learning reviews and say, Hey, this quarter, you know, I'm not saying they have to be one, two, three or four weeks sprints or something like that, but do we even have a process in place to manage the logistics of the improvement tone and all this other stuff is more feeling.
But at some point you have the project management aspect of let's look at it, let's prioritize it and let's review it. And I think in order to actually do that, you have to have, you know, the leadership tone is what we were talking about earlier. Let's use the word psychological safety. That's what a lot of people think of with that. And I think a lot of leaders kind of feel like when they hear that term, they dismiss it they think it means kindness. And so I want to
kind of draw that out first is psychological safety is really more about the ability to surface problems early, which is literally like we've been saying, the cheapest point in time to fix them. But people hear psychological safety, they think it means no accountability or you're just trying to be nice. It's not softness, you know, it's more of a signal. so high accountability with with low safety creates silence. I think that's what we're going to go back to and talk about with tone.
And how do you tell if your teams have psychological safety, there's a sign up, there's low accountability with high safety will create these support groups. And we're after high accountability and high safety and honest signals. And so I feel like part of conducting learning reviews, the only way to be successful with that is to have a high degree of psychological safety, because you have to be able to call out that the learning didn't take place. You know, and a lot of times you're.
You'll say, well, we tried this and it worked and I'm going to message it in a way just to get you off my back. So I think psychological safety is not kindness. It's part of this that we feel safe to say we tried to learn this, we didn't. And I think the leader's tone has everything to say about that. So, you know, if the tone is heat, they'll perform and they'll manage the optics and the messaging and they'll optimize for not getting blamed. That's the thing we want to call out is we don't want that.
If the tone is steady curiosity, which we just said at the beginning of the program, curiosity is the secret ingredient or the ingredient of learning, then they're going to surface reality a lot quicker and you can actually improve the system. So the learning reviews are more about to me the safety to bring them up and the safety to say whether the experiment worked or not. And if you don't have the, leadership tone to foster that, this isn't going to work to me.
Brian Milner (28:28) Yeah, I agree. And it's so important, I think, to actually make change. When we learn from these things, they're not just lost in the ether, but there's actually people can see that there's change occurring, that it's happening, that they're being listened to, that builds to that psychological safety that you're talking about. If I keep saying the same things and nothing changes, then I don't think it matters. I don't think people are listening to me. But if I see that what I say actually translates to real change,
then yeah, think it's probably a more, more likely I'm gonna speak up in the future.
Lance Dacy (29:01) There's this product out there called Kai Nexus that is a continuous improvement type platform to help you track some of these things. they had something on there. read not long ago that leaders should respond to problems like gifts and not threats. And I think there's a lot of leaders that see problems as I got to cover that up or I don't want to say covered up, but you know, the mentality of the organization is the theater of everything's going okay. You know, watermelon projects, everything's green, green, green until you cut into them and then they're red.
You know, we play those project chicken theaters where I won't highlight a problem until somebody else's problem affects me. Well, that's not real improvement. You know, that's just, that's like, call it theater. So leaders respond to problems like gifts and not threats that sets the tone. And so what should leaders do? You know, a lot of times they'll say, well, how do I do that? So some of the ways that you phrase this in these learning meetings, you know, these learning reviews is I might be missing something, walk me through it. That's an open invitation.
to tell me what you're thinking and that doesn't happen overnight. Or when you're looking at a system, say, what in the system made this likely? I'm not pointing blame at a person or a team. I'm saying, what in the system? I'm taking ownership as a leader that part of my responsibility is the system. And that's usually the single focal point of problems is the system, not the people. People typically want to do a good job. And then instead of saying, here's all the metrics to try to make sure I uncover everything.
Let's fix detection and prevention, not punish the reporting, but fix what we should be looking at. You can't have a learning review if you're not, you know, I hate to use the old adage, you can't manage what you can't measure, but there is some truth in the sense that you have to have something in place when you run these experiments to see what needle needs to be moved. The leaders have to stop modeling this public disappointment as a motivational strategy. You know, it's like, I'm on this side of the fence, you're on that side.
And they need to stop worshiping heroes, you know, the people, the one person that can fix everything. That's not a way to run a great team and interrogations. need to have curiosity over, you know, interrogating people.
Brian Milner (31:09) That's a great segue because our last habit here is about leaders rewarding early signal, not late heroics. And you mentioned, you know, celebrating the hero. That's part of that, I think, but a lot of organizations celebrate kind of those last minute saves for things. Why do feel like that can be a killer to a learning culture?
Lance Dacy (31:28) Well, like we were saying earlier, the longer a problem festers, the harder it is, it's going to fix. And then that just starts snowballing all these other attitudes that we've been talking about. The problem's too big. can't affect the change. We all have been there, by the way. This is not, you know, I'm not trying to indict any of I've been part of that group as well. That's like, I just give up, you know, it's just too big for that. And so I feel like if leaders can model the behavior of celebrating early signals of problems, you're going to get more up.
And we can't do any of this other stuff until we have those signals that are coming early. So that starts out like we were talking about earlier with blameless learning reviews. Let's take the blame out of it and talk about how can we fix the problem. Small experiments with explicit hypotheses like we do in product development and then visualizing that work in the way of, you know, not interrogating metrics, but visualizing did we move the needle and having good conversations about that. So I think
What we talk about is rewarding early signals is more of a tone. Like we separated the two at the beginning with tone of psychological safety leaders need to build that and then create a system that provides a cadence for these things to happen. So if we have all of those come together, those signals will start coming out a lot earlier. Then we can chop them up. Like we talk about in roadmap planning, the closer you are to delivery, the more you should know about the problem. Well, the same way is with our improvement backlog. Let's prioritize it.
and the things that are causing us the biggest problem, let's spend more time trying to build out the metrics and the signals for that. But it doesn't matter if people won't bring it. So I think it's a recursive issue that psychological safety is of paramount importance. And I think in 2026, if this is a theme for the year, I think we need to focus on leaders, you know, trying to create that environment because it doesn't happen overnight. It takes a lot of time and energy, but it can be small things just with how you ask questions.
and how you reward those signals coming early. Like, thank you so much for bringing us this problem. And I just don't see a lot of that. And I think that is what's important about leaders is rewarding those signals early so the rest of this stuff can happen.
Brian Milner (33:42) Yeah, I agree.
Lance Dacy (33:43) The last part to that on these is continuous improvement. You know, learning organization, it doesn't fail because people don't care. Typically. I don't know. You may think something different, but I don't think this stuff fails because people don't care. Most people care. They want to do a great job. And for the most part, want to be professional. If you don't have that, then none of this matters. But I think it fails because leaders unintentionally punish the truth, which kind of slows down these signals. so I feel like if you fix the tone,
then build in the loops, the improvement stops being these initiatives and it starts being how you operate. I think that's the key to success on this is building this into the operating system instead of having it as a separate post-mortem and all these other things. And so I think leaders can lead first with their psychological safety, their tone and quit punishing truth.
Brian Milner (34:35) I agree. It's like we said, it's got to be part of the DNA. If you're a leader listening to this and feel kind of overwhelmed, you know, there's all these things, where do I start? Like we've talked about, it's like any big thing, you start with one thing and you move on from there. So I think that's one thing that if you're looking at these five habits, pick one.
Lance Dacy (34:53) Change your first sentence with bad news hits. That's the first thing you can do this next week or this week, I guess, whenever this airs is just think about the first thing that's gonna come out of your mouth. Keep the same standards, but lead with curiosity instead of interrogation maybe.
Brian Milner (35:09) Yeah, yeah, be curious, not judgmental, right? This has been great. Lance, I really appreciate you coming on and sharing this with us and helping us through these five habits of high learning teams.
Lance Dacy (35:19) Thank you, Brian, for having me and hope this helps some of you out there and we would love to hear some feedback on it. We can go into this topic all year long, I feel like.
Brian Milner (35:28) Well, once again, big thanks to a friend of the show, Lance Dacey, for coming on and helping us walk through those five habits of high learning teams. And I agree, it's one of those really important things I think that needs to be in the DNA of a team is just that mindset of we're continuously learning, we're continuously improving, that there's importance placed on that.
If you like this topic and want to help us out, tell a friend, tell someone you know about it. This might be helpful for them as well. So point them our direction. We really appreciate it when you do that. If you like this topic or there are other topics that you want to have us talk about or there's other guests you want us to have on, please let us know. Send us an email at podcast and mountain goats, software.com.
We really covet your feedback. We wanna hear from you about how we can make this a better show. So send us an email. We'd love to hear from you about how we can improve and get better. And of course, like and subscribe, all those social things to make sure that we're in your inbox and you don't miss an episode here from us at the Agile Mentors Podcast. And that'll wrap us up. Thanks for joining us again. I hope your week is going well and we'll talk to you next time on another episode of the Agile Mentors Podcast.