Inspire, develop, and guide a winning organization.
Create visible workflows to achieve well-architected software.
Understand and use meaningful data to measure success.
Integrate and automate quality, security, and compliance into daily work.
Understand the unique values and behaviors of a successful organization.
LLMs and Generative AI in the enterprise.
An on-demand learning experience from the people who brought you The Phoenix Project, Team Topologies, Accelerate, and more.
Learn how making work visible, value stream management, and flow metrics can affect change in your organization.
Clarify team interactions for fast flow using simple sense-making approaches and tools.
Multiple award-winning CTO, researcher, and bestselling author Gene Kim hosts enterprise technology and business leaders.
In the first part of this two-part episode of The Idealcast, Gene Kim speaks with Dr. Ron Westrum, Emeritus Professor of Sociology at Eastern Michigan University.
In the first episode of Season 2 of The Idealcast, Gene Kim speaks with Admiral John Richardson, who served as Chief of Naval Operations for four years.
New half-day virtual events with live watch parties worldwide!
DevOps best practices, case studies, organizational change, ways of working, and the latest thinking affecting business and technology leadership.
Is slowify a real word?
Could right fit help talent discover more meaning and satisfaction at work and help companies find lost productivity?
The values and philosophies that frame the processes, procedures, and practices of DevOps.
This post presents the four key metrics to measure software delivery performance.
August 26, 2020
This is a transcript of episode 126 of the Troubleshooting Agile podcast with Jeffrey Fredrick and Douglas Squirrel.
Coming to the final chapter of Agile Conversations, we look at how leaders can not only provide accountability for others, but be accountable themselves, including stories from the early days of agile and from today’s clients.
So this is our last in the series of podcasts about the book. We’re up to the final chapter of the book. As always in the series, we’re not going to recap everything we talked about in the book. Instead, we’ll talk about what was the story behind it, kind of going alongside it.
In the book, we do talk about what we mean by accountability and important principles. But for me, this was a really interesting chapter. I got started in the world of Agile a very long time ago, the late 90s. I ended up on up on the Wards’ Wiki. The first Agile book that I got was probably the first Agile book that people would still recognize, which was Kent Beck’s Extreme Programming Explained. Also called The Whitebook.
And back in the early days of Agile, XP—Extreme programming—was really the dominant methodology. I’m talking about like 2000 to 2003, 2004, something like that. When people talked about Agile, that’s probably what they meant.
The first book was really a manifesto, and it really had a huge impact. And it’s funny because there’s the Agile Manifesto, of course. But the idea of the values and principles that were in XP Explained really resonated with me and with a lot of other practitioners at the time, lot of developers. In particular, a lot of the cultural elements, which were different from a lot of other books I’d read.
I’d read other books about how to be better at programming and how to do better project management, many of which I still think are fabulous books, Rapid Development by Steve McConnell is one. Don’t Flip the Bozo Bit, the book by Jim McCarthy is another one…that’s not actually its title, that’s the subtitle, I always remember that subtitle.
But this idea then, the cultural value that I remember the most from the book was courage. And so I was thrilled when in this sort of age of my career, kind of the early 2000s, I was working at a company called Agitar Software where we made testing tools, and Kent Beck ended up working with us. And in about 2006, he did a talk that was sponsored by Agitar titled Ease at Work, and this was a very influential talk for me.
This whole idea of what it means to be accountable for me changed when I watched that talk. And so the framing of our chapter here on accountability was really, in a sense, shaped in 2006 when I heard Kent Beck give this talk. What really struck me was Kent Beck talking about being accountable, and the idea of making yourself accountable, choosing to be accountable, and how different this was from the way most people talk about accountability.
Most people, I mean, I’m sure you hear this all the time when when you’re consulting, when people use the word accountability, what do you usually hear people say? They say, “Who can I hold accountable? This was terrible. We had an outage. We didn’t make money. This project didn’t work. Who is accountable?”
And it goes along with things like “Whose feet can we hold to the fire to make sure it gets done?” And “Whose neck can we wring if it goes wrong?” There’s a punitive aspect for accountability. Traditionally, historically.
And there’s two things that I never hear. One is “Who can I hold accountable for this success? This was wonderful! Who’s accountable? Who’s the person who’s accountable for this great thing that made us lots of money, that made our customers happy.”
Then the other I don’t hear is “Who’s accountable at the top.” The project didn’t go well, or maybe it did go well, either way. “Who’s accountable in the leadership?”
Where the leadership’s accountability is often the accountability of the outsourced vendor, the accountability of the Agile team, which is a valid point of view. We’re interested in accountability of all parties, but not necessarily the accountability of, say, the board or the accountability of the CEO. That’s something you don’t hear as much about.
There’s kind of an assumption that accountability is something that’s from the top aiming down. And that’s what really was, for me, revolutionary about this approach with Kent talking. He talked about that “accountable” really was a kind of straightforward word. If you were accountable, what that did mean was you were obligated to render an account.
That’s very different. In a sense no one can make you accountable. Just by your situation you can say “I’m obligated to render an account. I’m part of this project. I should be telling people what I’m doing and why I’m doing it.” And this sounds so simple. It sounds so obvious, but it really struck me, and it had this similar kind of force to when I look back to myself as a child. I remember trying to avoid getting into trouble for things. And in child development, young children don’t really have a sense of ethics and morals. And we teach children to lie when we imply that there’s going to be punishment for what went wrong. When we look to hold them accountable, you know. “Okay. Well, who was it who made the mess here?”
“It was nobody! There was that Nobody person who came in and Nobody made the mess. Yep.”
“Well, maybe a bird came in and did it.”
There’s a great book called Nurture Shock that talks about how we train children to lie from this. It reminds me a lot of accountability, which is this idea of punishment. And as children, we don’t have ethics and morals. We’ll make up a story because we think that will make things better, you know, will make people happy.
At some point, I remember I had a momentary revelation as I was getting older, which was, “You know what? I don’t need to lie.” Like, if something goes wrong at home, if I’m cooking and I break a dish, I should just clean it up. And when I’m asked what happened, I can say, “Oh, I’m sorry, I was doing this and I broke a dish. I’ve cleaned it up.”
And this may sound really silly, but as a child, when I had that sort of “aha” moment, it really changed my relationship with my parents and how I thought about things. And suddenly accountability at home wasn’t problematic. Get into the workforce, though, and that sort of fear and tension is brought in, the implication that “We’ve really got to make sure things don’t go wrong here or someone’s gonna hold us accountable.”
Or at least that people don’t find out how wrong it is. To find out. That’s the key thing. That’s where you get to the lying.
We talked it in a past podcast about greenshifting, which is the same idea. We’re gonna make things seem a little bit better than they really are. “Yeah, it’s not perfect. But, you know, we’re largely on track,” and that becomes shifted as it goes up the chain of command until the people at the top are hearing “Everything’s great. We’re definitely going to hit that deadline.” This idea to sort of placate people. And so I really am thankful to Kent Beck for this idea that accountability is not something to be afraid of, but rather something to be embraced. And not something to be imposed by someone in control, but in fact, something that is shared between people who have a more commanding position and those who are executing. Both need to have accountability, and it’s a moral obligation. It’s not something imposed from the top.
If I as an individual, if I accept, if I take, if I demand my own accountability, then I suddenly feel like I’m much less vulnerable. I’m much less afraid. I don’t need to worry about someone trying to make me accountable. I’m already accountable. And that’s to the fullest extent that I can be, and there’s nothing more that someone can demand from me.
That has been tremendously helpful for me throughout my career, well, since 2006. And it’s something I try to help other people adopt as well. When they do, they find it very helpful.
But the first message around accountability is not just something that’s top down. People at the top need to be accountable as well. That’s the other major idea in this chapter that I think is very different. In the story about your relationship with your parents when you had that “aha” moment—that you could explain about the dish—they must have modeled for you some notion of effective accountability, because if you had only heard fear and loathing and catastrophe on the event of breaking a dish, that would not have created the psychological safety for you to be able to do that.
There was accountability. I’m sure they were accountable to you in some way for things that went wrong, and that is a very important thing to model to kids. Similarly, when I’m coaching people in leadership positions, I often find that their default position is that initial definition of accountability. “Well, how do I hold them accountable? How do I make them render an account to me of what they are doing so I can correct it.” And the first lesson that I often work on with someone is “You are contributing to this situation, and you are not modeling the type of accountability that you would like to see. So why would you expect that you would have that level of accountability from them?”
I had the most beautiful example recently, which I will appropriately anonymize, but I’ve just begun coaching someone who is in a leadership position. And, you know, you never get controlled experiments in coaching and consulting generally, you never get to try one team that uses test driven development, one team that didn’t, and they do the same project, and then you see who’s better. I’d love to do that, but you only get to do that in academia. But this is almost a controlled experiment!
So he has two teams beneath him that are working on two different activities, and he said, “Boy, Squirrel, they couldn’t be more different. They’re like night and day. There’s one team, they’re outperforming their goals. They’re going to complete everything for sure, plus extra. When I talk to them about what it was I wanted them to change and what I wanted them to do, they got it immediately. They had a useful, productive conflict with me about which bits to do and where to start and so on. And we came up with a great plan and they’re executing. They’re super. And then there’s this other group.” And of course, he was positioning it as their fault. I would position it differently. I’d say the common theme here is it’s the same manager, the same guy. So there’s something that’s different in how he’s treating them. And there’s something different in his behavior.
But the other team had made many false starts, had not understood what he wanted them to do, kept doing something which was quite different from what they wanted. And of course, we talked about the techniques that are here in this chapter, things like briefing and back briefing, a way of making sure that you communicate clearly what freedoms and constraints and goals you have to the team, and then the team coming back and saying, “Here’s how we’re realizing that well before they get started.”
So you miss out a lot of the false starts and miscommunication. So we talked a lot about that. But the key insight that I hope he got was that he needed to have accountability just as much as the teams did. And the thing that he hadn’t done well with either team was he had not given them a clear direction about what their constraints were and what things they were not to do.
Now, the first team happened to figure it out because they kind of got lucky. And they also had an approach that allowed them to push back, discover the constraints, and find it out that way.
The other team worked in a perfectly reasonable way that just happened to be different and didn’t work well with this manager because they just said, “Oh, well, he told us to do this. Well, he didn’t tell us not to do it this way. So, great! We’ll do the thing he told us. We’ll do it in this way that makes sense to us.” And it, of course, wasn’t OK with him, and that was a failing of his. That wasn’t a failing of the team.
He had this great insight partway through the conversations, great “aha” moments. It’s fun to watch when they happen. He said, “Yeah, you know, when I’ve worked with teams before, I’ve always hired all the people. This is one of the first times I’ve inherited a team.” And I said, “Yeah, you probably unconsciously filtered for the sort of people who would work well without very many constraints, and who would go and discover the constraints rather than just go off and do it their own way. You didn’t get that here. You inherited this team. And you’re going to inherit a whole lot more teams.”
His further career will involve a lot more of this type of activity. He’s not going to be hiring his own teams forever. And therefore, he would benefit and he would be a better manager if he were able to take any team and help them to be effective, not relying on certain characteristics, like the ability to discover constraints.
So I think that was a great moment where he realized and helped me to see the details of his responsibility in this situation, to be more accountable. In this case, he can go back to the team and say, “You know what? I haven’t been very good at telling you what the constraints are. And I kind of assumed you’d figure them out, and that probably wasn’t so good.” Just like you going to your parents and saying, you know, I was cooking dinner, and I’m not great at handling plates, and it was too hot, and I dropped it. He can do the same thing, and I think that will really build trust with his team. So I’m looking forward to the results there. And if he is able to explain constraints more clearly as a result of doing that and perhaps build a better relationship with them.
This story really illustrates the situation well. We’re describing constraints and we have talked about constraints in accountability before. We talked about briefing and back briefing. And I think to me, the way these things tie together goes back to the default view of management, which is that, well, if things are going wrong in this team’s project, well, it must be a problem with the team. There must be something wrong with those people. And I need to go and manage them. I need to go hold them accountable and make that there’s consequences for doing things wrong.
That totally misses people’s motivation, which is that people want the projects to succeed. They care about them being successful. And if there’s problems, that a team isn’t delivering, well, then there’s probably something you can do. But it’s not necessarily trying to make them want the project to succeed. It’s probably figuring out more about what could you have done differently.
That’s an idea that I’m happy to be closing on at the end of the series about the book. This idea of “What could I be doing differently?” It’s, in a sense, the overall message of the book. If I want the culture to be different than I should look at my conversations and see how they can be different. If I want accountability, then I should be looking to say, what could I be doing? That’s true no matter what role you’re in.
If you’re the manager, then you should be saying, am I doing a good briefing? If I’m the person who’s implementing and doing the work, then I should say, am I being accountable? Am I doing a good back briefing? Am I radiating intent? Am I making it clear what I’m intending to do? And so to me, it’s, in a sense, no surprise that our overall idea that we can each take action to improve the situation is true for the whole book, and it’s true when it comes to accountability.
Coauthor of Agile Conversations
No comments found
Your email address will not be published.
First Name Last Name
Δ
We're thrilled to announce the release of The Phoenix Project: A Graphic Novel (Volume…
The following post is an excerpt from the book Unbundling the Enterprise: APIs, Optionality, and…
A few years ago, Gene Kim approached me with an intriguing question: What would…
Ever since digital tools and experiences became aspects of everyday work life, there’s been…