The Professional Agile Leader part 2 - Dual Operating Model, Self-Management and More

In this episode of the Scrum.org Community podcast, Kurt Bittner, PST Ron Eringa and PST Laurens Bonnema come together again to join host Dave West for a discussion on some of the topics in the new book, The Professional Agile Leader: The Leader's Journey Toward Growing Mature Agile Teams and Organizations, including the Dual Operating Model, Culture, self-management, bottom up intelligence and more!

 

Transcript

 

Dave West: 0:20

Hello and welcome to the scrum.or community podcast. I'm your host Dave West CEO here@scrum.org. This is a podcast from the Home of Scrum. In this podcast, we actually feature professional scrum trainers. And today we have two professional scrum trainers and other scrum practitioners are sharing their stories and their experiences and hopefully you can learn from it now. We're very excited today because we actually have this is sort of a version to the second release that the subsequent additional episode with three amazing authors and also trainers and I was gonna say thought leaders but I definitely like that anymore. Certainly thought in Volkers in our in our industry. So we're very fortunate to have today with us, Kurt Bittner, Laurens Bonnema and Ron Eringa. Now you may know, ladies, gentlemen, people, the listeners that they were the recent authors have a new book, professional agile leader that's flying off the shelves or the virtual shelves as we speak. And we recently did a podcast on on the book, which some of you may have listened to this is the second conversation around leadership because there's been so much interest. So thanks for joining us gentleman today. Welcome. Thank you, Dave. is great to have you here from the Netherlands and from Colorado. And I'm obviously speaking you from the home of Scrum in, in Boston, Massachusetts. So, So gentlemen, great book. Lots of really positive things I've been seeing in the in the Twittersphere. And on LinkedIn, etc. So the book launch party, but that is a topic that has been, you know, spoken about. Kurt, you wrote an article about it recently. The dual operating model, it seems to be creating some, I think confusion, but there's definitely lots of questions around it. So maybe, before we get into the sort of nuances, I'd love to have it described. Kurt, you wrote an article recently, can you sort of like describe what the jewel operating model is for our listeners?

Kurt Bittner: 2:52

Yeah. So basically, whenever an organization, a traditional organization, that's organized hierarchy, hierarchically, you know, managers, having departments, managing teams, etc, you know, you can think of that sort of pyramid picture. Whenever they start us trying to adopt an agile approach, they typically carve off an Agile team off to the side, they give them a product that they can work on independently. And they have sort of cross team connections to various managers in the traditional organization, who can help that team in theory with things that they need. So you know, they might have a relationship between the agile team and, and the head of software development and the agile team and the head of IT operations and HR. And, and, you know, this all works, you know, pretty well to get started, and there is really no other way to get started. And so that traditional organization, you know, but it's organized in in non agile ways. And so there's there's a fundamental tension. And this is what we talked about both in the book, and in an article I wrote that sort of highlighted some of the issues in the book, that at some point, as you said, they there's a tension between the agile organization and the traditional organization. And I think what you're talking about, the question you're asking is about, in a sense, what is that tension? And, you know, can it exist forever, you know, at some point, as does the traditional organization need to change? So there's lots of interesting questions in that, but but that when we talked about dual operating model, it's basically that some part of the organization is working in an agile way and other parts of the organization are working in traditional way.

Dave West: 4:46

And yeah, exactly that tension, and thanks for it for describing it. That tension. Ron described, could you describe a little bit about the tension of having these two organizations machines operating. At the same time, it must be a little bit confusing for what parts of the company like HR, even ops and support, help desks, you know? Yeah. Tell me a little bit about that tension.

Ron Eringa: 5:14

Yeah, that's that's an interesting one, I think the tension can be seen. But it can also be felt way you could actually see it as an as in the structures in the way that the organization is organized, like, you know, where's the decisions being made. big example of a traditional organization, of course, is that the smartest people, they typically reside in the management teams in the upper layers of the organization. And basically, there, they take all the decisions, while the the notion is there that you know, the teams at the bottom in the organization they just execute, right, that's, that's kind of the typical paradigm of a traditional organization. When we start installing agility in organizations, the reason for that in the first place is, you know, we want to go faster, we want to have better quality is there's tons of reasons why organizations want to do that. And we want to actually speed up the decision making by letting the people that do the work, make more decisions. And that's when it's the tension starts building up in the structure, but also in the culture, right? Many organizations are built based on decisions being made in teams that are in the bottom of the organization. And that creates tension in the structure. And but cultural wise, this is one of the things that you, for example, also see in many of those agile surveys out there, you can see that the Agile culture starts to clash with that traditional culture. Because, well, in order to enable teams to make more decisions faster, we just need to start letting go of their traditional responsibilities. Just to give an example, I recently had a conversation with HR in an organization, where we would like to enable the teams to do 360 degree feedback to help each other grow, grow faster than they were doing in the traditional organization, where HR was actually and management was controlling the well the the yearly conversations on how to grow. And so it's no longer controlled by management, it's shifting towards the teams, there are tons of these kinds of mechanisms in an organization that's shifting towards the teams actually, which builds up tension in your organization. So you can see that tension grow. And will there is a breaking point in that jewel operating model. And I think what we talked about in the book is that just you know, you can keep this dual operating model for quite some time, you just have to because that's where it starts. But at some point in time, you will reach that breaking point where people started really getting annoyed, the ones that really get agility start bumping into these traditional boundaries that they they want to break through. And I think that's the tension that we're talking about.

Dave West: 8:00

It's funny that John Kotter, in his book accelerate, though, he's not talking about agility, he's more talking about innovation, etc, and change. He describes the fact that after a, when people leave, suddenly, the Jonas disappears. You know, I had already talks about Cisco and some other examples. The dual operating model, or the multi operating model is dependent on certain key individuals, managing those tensions and ensuring that both parts of the organization get get what they need. And when that leaves, is that something you've seen, you've you've seen Lawrence, around people?

Laurens Bonnema: 8:41

Yeah, that's definitely something I've seen in real life and working with clients. And that's also why I'm actually a bit of a fan of the notion of the dual operating model, because it's a really good way to explain also what tensions people can expect, and how much it depends on the people at key positions on both sides of the organization, just like you just mentioned. That's always true, by the way, it really matters. That's also one of the key points in the book, right? Leadership actually does matter. Therefore, it was necessary to write a book about it. Also in an agile context, what I find, though, is that the notion of the dual operating model sometimes becomes a little bit of dogma in and of itself, right? So you have to have one. And that, of course, it's not true. You don't have to have one. It's just as a it's more like a fact of life and talk about facts of life. I've also never really seen the other end, maybe in smaller startups, but I know precious few companies that really have no sense of duality at all. And to me personally, that makes sense, right? Because there's always parts of the organization that actually don't do really complex work and And I'm not saying the people there that they're not smart, it's just the work that they do, does not require them to work in an agile fashion. And when that's not required, actually, it makes sense to not do that. So, in my opinion, that is where the dual operating model actually does have a future. But arguably, as things become more complex over time, generally, I'm thinking, most organizations will have a big honkin, agile section, and a rather small, non agile or classic, or maybe just differently optimized section and a little bit more plan driven. I don't think that that is bad, I think it's bad to want one or the other. But I do see how it could be problematic to essentially say you have to you have to do both. And maybe,

Ron Eringa: 10:57

Lawrence, if I may, because you kind of touched something important there, I have been working with a few small startup kind of companies. And they are actually struggling with like, they need more structure. But they don't want to be this hierarchical organization. And what I typically see in these type of companies, there, you can actually skip the whole dual operating model, because they're used to having, you know, agile cells, as we call that in our book. So if you have that, that's maybe a good starting point to really start from scratch, and don't look at the dual operating model. But most of the corporates like Lauren's just describe a day just inevitably have to go through that period of we have both systems in place.

Dave West: 11:39

So as a year, prior to scrum.org, I was Chief Product Officer at a startup. And as we grew it, though, we started very agile, very agile, and, in fact, cross functional teams that never really had all the skills to do anything. You know, it was one of those sort of situations as we grew, and we got financed, it became harder and harder not to bring hierarchy and structure in primarily because of one word risk or perceived risk. It was really interesting, that empowered teams was great on paper, until you start having using somebody else's money. And that other person was like, Really, you need somebody that they trust at that at a certain level. So risk is, you know, we we built these hierarchical organizations to manage risk, effectively, and to become very efficient, which is an element of risk. How does How do you manage to deal with that risk element in in this dual operating sort of model II kind of way? Kurt, you've got some perspective on this.

Kurt Bittner: 13:00

Yeah. So there are, there's maybe one thing, a couple of things to think about when you think about that risk, how to manage that risk effectively. And one is that self management of a team is not it's not a binary thing. It's not, you're not either self managing or not self managing, it's really on a full spectrum. And so a team that's relatively immature, that has doesn't have all the skills that needs that maybe is new to the domain has a lot of new people to the organization, they're going to take some time to develop and learn how to work together and to make better decisions. So a leader working with them might gradually, you know, work with them to try to increase their ability to self manage, but but in a in a way that, you know, you might go back to that phrase from the Cold War trust to verify, you know, trust the team in a certain bounded, you know, you know, we talked sometimes about guardrails. So, you know, within certain boundary conditions, you trust them, but you also verify that they're doing, they're making decisions in a good way. And that you're examining the evidence and sort of following them along the journey. But as they prove themselves, they earned the right in the sense to make broader and broader decisions and to self manage more effectively. So, so that's one thing is that, you know, it's it's a sort of, you know, trusted verify on the part of the manager. The second thing is that there's this concept that we often talk about in Scrum, that is, is very important here, and that's called bottom up intelligence. And so, you know, the assumption that somehow management has more knowledge and more expertise and more visibility into the problem. A woman that they're better able to, to measure risk and make appropriate decisions is sometimes a fallacy. Because they're further away from the problem. They're further away from, from many of the things that the team has, is encountering on a daily basis. So, you know, it's so so yes, the venture capitalists and other people who give you money are sort of addicted to this traditional organization of, you know, the big Herald Leader who makes all the right decisions. But the reality is that the team might actually be able to make better decisions and better able to manage risks, if they're given the right tools and help to develop. So in our book, the things we talk about is our How is how did the manager how's the leader, help the team to develop those decision making skills, so that they are actually better at making decisions than the manager would be? And that's, again, that happens on a spectrum. It's not a you know, one day you're making decisions, you're not making decisions, and then the next day that you are, it's maybe it starts off with you make small decisions that have sort of a low risk, at first, and then gradually you increase that. And all the time you're measuring and having a dialogue with the team to see if that's the right, you know, if the team is at the right level. So I think that's, that's one of the things that it takes a long time to help to really help that team develop to the point where they can make effective decisions, but at some point, they can make better decisions than the manager.

Dave West: 16:39

So there's this false notion of actually, I'm leading the audience by saying false there is this notion that you trust the system. I've already admitted my, my, rather than the people. And, you know, we build these incredible systems. Kurt, you and I, back in the day, were on calls, about arguing about, you know, $100 expense, and spending significantly more money arguing about the expense than we actually done. But the system was built in a way that that protected the company, from you and I spending ridiculous amounts of money on magazine subscriptions, or whatever. And is it true that a budget, the Agile leadership, is about agility is about trusting people, rather than systems? Or do we still need to have the systems in place? What's the relationship between those two? Who wants to talk about Yeah,

Laurens Bonnema: 17:41

I think you're spot on there. And also, that's, that's the touchy subject. Because it's both really, and I think in Agile environments, people start to recognize that it's people who are responsible for creating that system. So the system is of crucial importance, the system of agreements that we make together, and then it all depends on the people. And what we've done in, in in terms of risk management is create a system where we assume that people are evil, and they're stupid, and they would buy magazine subscriptions, if you just give them the right to do so. Or at least if you give them the corporate credit card, when all hell will break loose. And that's actually not true, you can just give them some rules, one of the rules could even be don't buy anything stupid, that arguably has nothing to do with the business that we're running here. And it could be even more specific, but no hard control. And then when somebody actually does end up buying lots of irrelevant magazine subscriptions, you just fire them that could be part of the system. And then 90% of the people because it's really that big of a number would just do well, right. So they wouldn't make the mistake that you've created a straight jacket tie type system for to to limit or maybe even trying to eliminate that risk. And I think that is the change, there is a different sense of risk. Because the the flip side risk, of course, is opportunity. And with all that risk management that we do, we also stifle a lot of opportunity for innovation. And that is usually as Kurt mentioned, that comes from the people who actually do the work who know what they're doing. If you hired the right people, again, that's a leadership thing. But if you hire the right people, and you give them the right environment, and together you create the system within which to operate effectively. That in and of itself is a better de risking strategy than having a elaborate framework that essentially puts a straitjacket on people.

Dave West: 19:46

I recently read the Tesla employee handbook. I don't know if you read it, it was thinking about that. Yeah. It was a very having visited them and being a keen fan of They're the tech and what they're doing in the world. But what was struck me, and Joe justice talks about this in a talk around this was the fact that no, you can buy anything you want. But you will get fired if it's stupid. And I was like, wow. So for instance, if you're in the production system, and you need, you know, this a different oil for your machine, or whatever, I don't know, you literally can buy it, you can go to central purchasing, if they can't get it quick enough for you, and you think you can drive around to the local Walmart and get it quicker, then do it, you know, but if it's stupid, and sets fire to the machine, you will be in trouble. And you will be fired. You know that. So and I think that is an interesting culture change, because frankly, nobody ever got fired in the old system.

Kurt Bittner: 20:56

Interesting things about that old system, is that part of the reason why it has all those silly rules is because they decoupled in a sense, the profitability, or the revenue side, from the cost side. So if a team has, if a team has responsibility for the overall, in the sense outcomes of the product, and the overall profitability of the product, if they think that buyings, you know, magazine, so the team can learn more about how to do something better, if that's going to actually help the ability of the team to perform, you know, then that should show up in the outcomes that the product produces. And so I think you know, what, some of those, those in the sense of pathologies of the traditional organization, are created, because they don't have empowered teams. And because nobody really has responsibility for anything until it rolls up to the CEO, you know, because costs are in one organization and revenues are in another. And so you know, then they end up having to have a complex system to try to get people to do the right thing. But you can't do that, because people don't see the connection between spending money on something and achieving some benefit. So I think it's, it's, you know, the problem that you point out is one of the problems of the traditional organization, and the fact that it doesn't really manage reality very well.

Dave West: 22:20

And part of the solution, and you talked about this in the book is, is measurement is those outcomes, you know, whether it's effective OKRs or EBM, or something that really pulls together the value that that you're delivering, which obviously has to consider both risk and opportunity and all of those things. And it means everybody has some level of ownership and leadership. Having, you know, studied your work seems to be about communicating that and an effective way, and providing guidance and coaching in an effective way around those those constraints, those opportunities, those potential risks. And, and that's, that seems to be what I what I've seen, and what I've read from from you, does that is that is that really the, the sort of like the, the nugget to all of this?

Ron Eringa: 23:22

Well, if you would ask me, what would be key in this, I think it would be will setting the right examples, because you know, what you're just mentioned that as well, like, if you have that traditional organization, that is set up for preventing mistakes to happen, and all the structures are organized to prevent mistakes from happening, people just, you know, I call that the cinema mode, they will sit back, you know, watch until the curtain opens, and they just, you know, complies with the rules, but don't go beyond them anymore. But if you create an environment in the organization with extreme transparency with all these KPIs and measurements, and you know, and they really relate to the goals of the company, as well, you're going to start to engage people to actually feel ownership of what they're doing. But it needs extreme transparency. So if you focus on instead of keeping people complying, but creating a culture where people start, you know, feeling ownership and taking ownership. It's not in the end the you know, the role of a leader to prevent people from making mistakes, but to create an environment where mistakes can be made. And people can learn from it. You don't have to fire them right away, right? If they order a description that is costing them a lot of money. But I hope that next time when they do that you've learned from that and we we've talked about this, so that everybody knows that that was a mistake. I think that's you know, it's maybe it might be an expensive mistake, but those kinds of mistakes can, you know, be a very good learning for others. So, as long as you build in mechanisms where people learn from those mistakes, I think that's pretty much okay. But I think that's the switch and leadership style. So you have to be comfortable in lending Mistakes happen, so that people can learn from them without punishing them. And I think that's kind of a, you know, a strange way to manage organizations, if you've never done that before.

Kurt Bittner: 25:15

That's funny anecdote, one of my former colleagues work for a large research organization and doing some pretty sophisticated design work. And anyway, this guy was a young guy. And anyway, he made a mistake in some software that he was writing, and then ended up costing the company millions of dollars. And he got called into his manager's office, and, and he was fully expecting that he was going to get fired that day for that mistake. And, and they talked about the mistake, and you know, what, what could be done better to catch those sorts of things in the future? And then at the end of the meeting, this friend of mine colleague, said, You know, I thought you were gonna fire me and the manager said, Oh, no, I wouldn't fire you. I just spent a million dollars to have you learned that lesson. You know, we need to share that with other people. So anyway, that it was it was a good illustration, even your MD many years ago that, you know, there were some people who have always been working in this servant leader way and, and that making mistakes is the way that you learn and how you react to that really, I think, for me, is the hallmark of leadership.

Laurens Bonnema: 26:30

And that's where the the dual operating model, we, where we started, actually comes back into this, because it's like a pathway from an organizational structure where you essentially think you're doing risk management, but in actuality, you're doing like opportunity prevention. And then you move across the bridge to the other side, so to speak, and provide some examples, but also some real support for that kind of behavior with examples like the one that Kurt gave. And, and that will make people actually believe that you mean that, right, because it's a big cultural shift from one end to the other. And people need to see leaders actually accept that now, risk management is no longer opportunity prevented, we actually want you to capitalize an opportunity, while also managing risk. So risk management takes its proper place, again, in the business, if you do it, right. And as it does, the need for a dual operating model will usually evaporate, and you'll have become a really big startup, if you were big, or a way better startup, just like Ron mentioned, like the startups that are able to jump that curve, that don't even use hierarchy as a form to structure themselves, they will probably have a huge head start. And that's exactly what you see Tesla and SpaceX. And while essentially the musk company's doing, and they do that based on like, solid understanding of the science behind all this, right, so they don't make those decisions just just because they think it's better. There's a lot of research that has been published into why that's better. And I really like that. In modern leadership, we're actually able to use all that knowledge to create just better organizations. Now, personally, what I do see is that in the end, almost all organizations, if they're big, they have some form of hierarchy left. That's not necessarily a dual operating model. But there is always a form of hierarchy there to make sure that people know what's what, just like with scrum.org Probably the most agile organization on Earth, still everybody knows to talk to Dave, right.

Dave West: 28:43

And I instantly get people that are much smarter than me like people like you three to, to feel those questions. My job is just build an environment for the amazing people in our community and@scrum.org To be successful, make sure things are transparent and communicated and, and sometimes deal with some of the tension that that transparency creates.

Ron Eringa: 29:09

It's actually, if I may interrupt you there, Dave, because Lawrence also mentioned the hierarchy part. And I think in the dual operating model, that's something to zoom into a little bit, because that's grounded or there's not a lot of hierarchy, right. There's you Dave, and then well, then there's us right below that's pretty much it. Yeah. If you look at the dual operating model that I see with many large corporate rights, if you will, will caught are actually as it's interesting video called Accelerate. If you look that up on YouTube, for the listeners, you know, that's a great video to look at. The only thing in that video that I have strong doubts on is that those things I think they draw five layers of management on the left hand side and on the right hand side, there's this mechanism that looks like an agile cell, or as we call it. If in your organization while you're doing an Agile transformation, those five layers are not changing. It's not getting smaller. That's an indication that you're getting stuck in this operating model. I think if you're moving towards low, fewer layers on the left hand side, while the other people and that's also what's something we explain our book, you can invite people to, you know, move from that other pole part of the organization to the newer part into the Agile cells. But if you're, the rest of your organization isn't changing, if that isn't, you know, decreasing and if the other side isn't growing, that's a signal that there's, you know, that there's a lock up in the system. So I think

Laurens Bonnema: 30:32

I couldn't agree more, the end goal is for one for management to become one of those cells, right. So in doing so management actually becomes a team. And that, I think, is an important notion that that's also a team.

Ron Eringa: 30:46

And many people think that there's no hierarchy in an agile organization. But I do think that is needed, there needs to be hierarchy, it's just probably less of a power hierarchy, but more of a hierarchy of concerns, while the management or maybe you know, the leadership, whatever you want to call it, concerns more about the organization, keeping the teams together, keeping the value streams together, that kind of stuff. And it's less than about the power hierarchy. So, you know, that's where the lack of responsibility shift towards an agile sell and the new part of the organization, but you still need to hire Do you think I think

Dave West: 31:20

this is we could talk about this for days, in fact, you know, I think that's what you do often for many days. So I don't mean to cut us off here. Because, you know, I think there's an opportunity to talk a lot around hierarchies, and that might be a future. podcast, I'm, I've made a note here, because I think there's a really interesting conversation about, you know, the, actually, the McKinsey model is seven layers, not just five, which is interesting, that, you know, the, this was the old one, seven, you know, in the 70s and 80s, the model that they develop them. And it's just really interesting to see how you move from a hierarchical organization to make a lot flatter, and power, promotion, incentives, all of those things become incredibly important levers that you have to think about, and constraints that you have to worry about. So I'd love to talk about that at another time. But I'm afraid today, we've hit our time box. So I just want to thank you all for spending the time Kurt. Lawrence, Ron, thank you for spending the time of our listeners. I learned some stuff made some new T shirt sayings, you know, trust the people, not the system, I think that's going to be my new new T shirt. I think that's a really good one. I also really, really enjoyed the, the this how you sort of manage some of these tensions and really, really focused on really providing some more insights on that jewel operating model obviously, got better wrote a really interesting info cue article. If you're listening, please have a time to read that. And there's also many things on scrum.org about this. So I want to thank my listeners. Thank you for tuning in today. Thank you to my guests, and have a fantastic day. Bye everybody.