The following is a rough transcript which has not been revised by The Jim Rutt Show or by Daniel Mezick. Please check with us before using any quotations from this transcript. Thank you.
Jim: Howdy, this is Jim Rutt and this is The Jim Rutt Show. Listeners have asked us to provide pointers, some of the resources we talked about on the show. We now have links to books and articles referenced in recent podcasts that are available on our website. We also offer full transcripts, go to jimruttshow.com. That’s jimruttshow.com. Today’s guest is Daniel Mezick.
Daniel: Hey, Jim, thanks for having me on the show.
Jim: Yeah. It’s great to have you on the show. A lot of really interesting things to talk about from your work. Daniel has been coaching executives and teams since 2006. He is a Scrum@Scale trainer, an expert on business agility, and then the author of three books on organizational change. We’ll talk about the books as we go along. As usual, links to those books will be available at the episode page at jimruttshow.com. Won’t you tell just a little bit how you got interested in this area and what you did before.
Daniel: In 1993, I formed a IT services firm, consulting firm and I had operations in three states for about 10 years, Rhode Island, Massachusetts and in Connecticut. Then with the dot bomb crash and the Year 2K thing, all that materially changed and I found myself kind of pretty much on the beach around 2003, not wanting to go back to the previous thing, which was no longer the happy hunting ground that it once was, and not knowing what was going to happen next. For about three years, I didn’t know what I was doing. Then around 2005, 2006, I started hearing this noise about agility and Scrum, and XP and started researching that. In 2005, 2006, I went to a class about Scrum and that pretty much put me on the path I’m on today. Since then I’ve been involved in coaching and training in that area.
Jim: I first got exposed to the Agile field in 2001 when I got asked to become chairman of a high end chip design software company in Ottawa. It was an amazing little company. Four recent college grads who had about two years of experience at Northern telecom, had some very clever ideas and were on their way but they needed some organizational help, a little bit of help on fundraising. But one of the things they did happen which they believed in, in a religious fashion was the use of Scrum.
Jim: I said, “Okay. I’m just going to watch here. Maybe I can give wise man advice when I see, ‘What a ridiculous thing this might be.'” A person who generally scoffed at “management systems.” Truth of the matter, the old guy this time just sat there and didn’t say anything, just learned and actually worked great. We did a second company with some of the same cast of characters after we sold the first very successfully and they did it again. They used a slight variation on Scrum, which they essentially had learned from the first time around. What’s the other one? Kanban or something. It was kind of like a hybrid between those two.
Jim: Again, watched them do it. I didn’t have a word to say, they clearly knew what they were doing. I’ve been basically participating as involved with the use of since 2001. Then in 2013, a little teeny micro startup that I oversaw for about six months, we also use the variant on it so I was very impressed. For the scope of a team of 10 or less engineers, I was convinced.
Daniel: That’s what it’s for.
Jim: I know but your ideas, the concept and philosophy can be used at greater scale. Is that fair to say?
Daniel: If you have certain conditions in place, yeah, you can scale it.
Jim: All right. Let’s jump in here and talk about the first book I read in prep for this podcast. As my listeners know, I typically spend about 10 hours getting prepped for each podcast. The first book is called Open Space Agility Handbook, of which Dan is one of the co-authors. But kind of reading between the lines, I’d say it smelled like you were the main author. Is that fair enough?
Daniel: That’s fair. I pretty much composed the list of authors. They were invited in to help with the book. They substantially helped and I put them all on the cover.
Jim: That’s a good thing. That’s a good thing. Essentially, the basic framing is around, I would describe it as Agile Open Space Technology. Could you unpack that just a little bit?
Daniel: Our natural way of working is to do what we’re happy doing and do what we’re passionate about doing. Do stuff we have energy around. So Open Space Technology is you could think of it as a meeting format or an event design that allows that kind of self-organized behavior to just show up and surface itself very, very quickly. The normal rules of engagement are suspended. Everyone’s responsible for themselves in an open space meeting, for their learning, for what they contribute, for where they go and what they do. So if you have a great time in open space, you can blame yourself for that.
Daniel: And if you have a terrible time, you can also blame yourself. The natural, self-organized world reveals itself in open space when people are in it. If you’ve ever seen a picture of it sometimes it’s up to 700, 800 people sitting in a circle in the beginning and end of the meeting. It’s quite an epic visual. Then throughout the day, folks are left to organize their thinking attention and learning in a way that’s meaningful to them throughout the day with the others. We use that for organization level transformation.
Jim: How do you staple that to the concept of Agile? They seem to be, again, in my mind and in my experience, limited that it is, I think of agile as a technology appropriate for a team of not more than 10. Maybe on a really good day, 12 engineers. How does the concept of agile for a small team get stapled to this open space concept, which sounds like it could be up to hundreds of people?
Daniel: I have a hypothesis about the agile stuff. First, a decent definition of agile is the ability to rapidly identify and respond to change and to take advantage of opportunities that are presented by that change. The whole idea of this revolves around self-managed teams. Self-managed, meaning they’re managing decisions that pertain to the whole group. So the self-management idea is core to agility. I have a hypothesis about this, which is, most, if not all, of the improvement that you’re getting from agility comes from this self-management behavior.
Daniel: So, executive leaders create the conditions where this can happen, they get out of the way and allow people to do their thing. When folks start making decisions they engage and the engagement is associated with just about every good thing. Then you see this great productivity improvement, improvement in quality, predictability, reliability, and so on and so on. Open space technology, the meeting format, without a lecture, it demonstrates what the self-managed, self-organized way of working actually looks like.
Daniel: Harrison Owen composed open space in the mid ’80s. His work predated the Agile Manifesto by some 16 years. Open space technology, the meeting format formulated by Harrison Owen or what he would say discovered by him, is actually 100% aligned with agile ways of working. In fact, it totally embodies that. When you go into an organization, you bring open space to an organization. The executives, the workers, the managers, directors, everybody, they have a big wow experience. What they’re really experiencing is the power of self-management. Without a lecture, we’re demonstrating how good it can actually be, how efficient it can be. We bring that in, in Agile way of working, we use that as a sort of frame for discussing how this thing really works.
Jim: So is it fair to say that the cost … I’m again trying to get the concept clear here. Is that we have Agile as a set of philosophies and tools aimed at doing work at the team scale. Then when you take those philosophies, at least, if not all the techniques, and marry them to the open space meeting format, you are then able to bring at least some or all of the Agile philosophy into larger scale entities. Is that reasonable?
Daniel: Yeah, yeah. Let me tell you a story. Most organizations, what they do is they do an Agile type pilot. So they might bring in Scrum and work with three or four teams and get them moving. Those are teams that want to actually work in that way. When organizations do pilots with Scrum, Jim, they typically will look for willing teams to reduce the risk of failure. Willing teams committed authority figures, the Scrum framework, that’s a winning combination. So most of these pilots will go pretty good. What happens is they get some really nice improvements in things they’re measuring, and then they immediately want to scale it to a whole enterprise. There is some problems with that. The primary problem is the leaders get organizational amnesia, they forget that the teams that were in those successful pilots were willing teams.
Daniel: So we go from sort of an opt in approach to a mandated rolled out approach. You know, a lot of times, that just doesn’t work. The reason why is because good agile runs on engage people and engage people are people that are choosing. In deciding, choosing turns out to be very engaging. So there’s this whole relationship between choosing something and being engaged. This is exactly the concept in open space. In open space, the meeting is optional to attend. No one can make you. You don’t have to go to the meeting. That is a requirement of open space.
Daniel: So what we’re doing with open space in organizations, Jim, is we’re trying to gently introduce the idea of agile organizational change across the whole organization and we’re gauging that organization’s willingness to proceed. You put all the people that are involved that are affected in a large all hands open space meeting that’s invitational, you’re going to find out right away about the organizational readiness and willingness to move forward.
Daniel: A lot of these organizations, they “roll out” Scrum, Agile across the whole organization, they might as well just put the money in a big pile and fluff it up and sprinkle a little gas on it and flick a match on that million dollars. That would hurt a lot less people. There’s also this kind of infliction of organizational change today. Open space rolls that back and says, “Let’s find out what people are willing to do then let’s invite them into it.” That’s how we do it with open space agility.
Jim: That’s very smart. Because again, the times I’ve seen Agile work is when the people who are doing it are committed. It’s actually from my days as a corporate technologist. You may or may not know this, back in the day, I was responsible, directly and indirectly, for 5,000 technologists that today is Thomson Reuters. That was the day somewhat of the waterfall method though, at least in my tech groups which ended up to about 1,000 people. We didn’t use anything quite so rigid as that but on the other hand, we didn’t use anything quite as disciplined as Scrum. I would say that trying to have forced Scrum@Scale across 5,000 people strikes me as a daunting task at the minimum.
Daniel: Jim, this is happening routinely around the world today. As we’re speaking, there are probably three, four, or 5,000 implementations of exactly what you just described. The reason is basically that executives, they want an ABC story of how the change is going to go. Meanwhile, Scrum is an empirical approach to process control. In software being a high complexity type of an endeavor, Scrum is perfect for that. The reality is that we’re going to do a little, we’re going to learn a little, we’re going to inspect that, and we’re going to go again. That just doesn’t land with a lot of authority figures who they want to hear an ABC plan with an ABC budget. So they want a waterfall approach to the implementation of an empirical approach. That gets sold all over the world every single day.
Jim: Sounds like a shit show ready to happen.
Daniel: It’s in progress, Jim. It’s totally in progress.
Jim: Even better, I might be able to make a Saturday Night Live. Some of it’s not be quite … So now I think I’m getting a better sense of the whole open space agility concept here. So I’m going to try to restate it again. I tend to do this until I understand something very clearly, which is your argument is that your open space meeting technology and things we’ll talk about later, like your 100 days, et cetera, are a way to get an organization to appropriately adopt Agile techniques at appropriate scale.
Daniel: That’s right.
Jim: One would not expect to run a 3,000 person division from top to bottom using Scrum, that’s just wouldn’t work. But that the teams within that 3,000 person division for whom Scrum or one of the other Agile techniques was appropriate, would seduce themselves into doing so when it was appropriate, something like that.
Daniel: Well, yeah, organizations have different functions in different divisions and departments. When we talk about product, all our products can run on Scrum@Scale. Certain conditions have to be in place but it’s certainly doable and you can create a delivery machine and point it at anything using Scrum for product. The organization itself also has different functional areas like HR people Ops, legal and compliance and so forth. They’re not going to adopt perfectly to a Scrum approach. But the reality is on the product side, Scrum is a very good way to organize your engineering teams at scale. So I’m working right now with an organization that has 900 engineers globally. And we’re in the early steps of implementing Scrum@Scale.
Daniel: The first thing that I’m doing with this leadership team with my colleagues is we’re taking them through a series of one-hour meetings. It’s a 13, 14 person leadership team. I’m confronting them with the reality of the Scrum Guide. The Scrum Guide says things that are rather abrupt and harsh. The primary thing that Scrum does is it has a set of rules around decision rights around the three roles. So for example, for the product owner, it says, “For the product owner to be successful, everyone in the organization must respect his or her decisions.”
Daniel: We’re walking through those kinds of statements in the Scrum guide and I’m asking the leadership team, you know, “What do you think the level of agreement of the organization overall right now is with the state? You’re doing Scrum, how well are you doing it? And rate it on one to 10, where 10 is great and one is really bad. Then rate yourself, what’s your level of willingness to support the statement as a leader to create the conditions where this statement can be true? Around the world, organizations overall do not go through this exercise. They just roll out Scrum to unwilling teams. They don’t ask the teams what they think or anything, they just roll it out. A lot of times, the CEO wants it or the CTO wants it, but you’re an executive for decades so you know that just because you want something, doesn’t mean that your team wants it. Your leadership team. Right?
Jim: I have to tell you this story. When I first became a CEO of a publicly traded company, I brought on one of my favorite strategy consultants and he was cynical to the bone. We just tell you the way it was. The first day, the first five minutes I was sitting on the imperial throne, he said, “Jim, all these buttons and levers conceptually that are on your desk? 90% of them aren’t attached to anything. You can pull the levers and you can press the buttons, but not a goddamn thing will happen.”
Daniel: Exactly.
Jim: You know what? He was right. Of course, that was a company where I didn’t build it. If I build it, goddamn it, all those buttons would work. But this is one where I came in and it was essentially a turnaround. He was absolutely right, most of the ship was broken. The job was to unfuck it basically over a period of time.
Daniel: Exactly. Exactly. You know, if you’re going to do good agile, you have to create the conditions or the space for people to do that kind of great work. That space is created by authority figures, they create the conditions they define the game. I work with the leadership teams around creating those conditions and I want a very, very strong, unambiguous yes to the things that the Scrum Guide lays out around decision rights. They understand the way decisions are made is going to change. Sometimes I kind of Dr. Phil them. Like they’ll give me objections to the Scrum decision rights. They’ll say, “I don’t like that rule about the product owner,” or whatever.
Daniel: I’ll say, “Well, hey, let me ask you a question. You make decisions today about product a certain way, don’t you?” They’re like, “Well, yeah,” I’m like, “Well, how’s that working for you?” Then we have that conversation. They’re admitting that the way they make decisions around product isn’t working. It’s slowing things down and increases decision latency. We’re going to we’re going to use Scrum to reduce that decision latency. That’s going to require discipline. I really love the way you mentioned that about Scrum. You mentioned Scrum requires discipline and I just so enjoyed that you said that earlier because that’s what it takes.
Jim: I just realized we jumped in to the deep end of the pool. Could you take a couple of minutes and describe how Scrum works? Let’s just use Scrum because I think that’s pretty close to a core standard flavor of Agile. Just give the roles and the sort of the basic how an eight man team might use it.
Daniel: Sure. So Scrum is a pre-fabricated plan for executing on work in three roles. There’s a product owner, there’s a team, and there is a Scrum master. The product owner owns the product vision and maintains a list of things that need to be done and prioritizes that list. The team serves the product owner’s vision by looking at that prioritized list in a highly structured planning meeting. The team and only the team has the right to decide exactly how much of the top most prioritized work they can fit into their time box sprint, which is one week to four weeks long.
Daniel: Product owner present it to the team, the team examines it as it stands, they pull as much of the work as they possibly can into the sprint, they have a conversation about the release plan and contingencies, things might happen during the sprint. Then they go off and they do the sprint. The rule is that none of that work can change. It’s frozen. The team knows exactly what the scope of their work is and they know how much time they have. They come out of that meeting knowing those two things. Then each day, they’re required to depict their progress and some kind of visual artifact that anyone in the organization can look at. So it’s put somewhere on public display or somewhere on a shared drive or something, Jim, where anybody at any time can see the work remaining.
Jim: In a small company like the ones where I’ve used it, we actually use yellow sticky pads on a wall.
Daniel: There you go. So anyone at any time knows exactly where the team stands. Then each day the team has their own private, daily Scrum, a stand up meeting, which is a kind of status meeting. Interestingly, in the status meeting the authority that they report to is themselves. Each team member basically reports on what’s going on with their work today and yesterday and what obstacles they’re facing. Out of that meeting comes a list of impediments, things that are holding the team back. There’s a facilitator role called the Scrum Master whose job is to basically help the team be great. As impediments are surfaced during the daily Scrum, and through conversation throughout the work, the Scrum Master takes care of removing those impediments, and the Scrum Master is duly authorized to do so.
Daniel: So if necessary, the Scrum Master is authorized to go to the highest executives in the company and straighten things out so this team can get their work done. Then when the sprint ends, there’s a demonstration of the work. Stakeholders are invited to that demonstration. The product owner is there, it’s their meeting. The team is there, they demonstrate the functionality and the goal in Scrum, the Scrum done extremely well provides for the possibility of shipping something at the end of the sprint. A potentially shippable increment or product is produced by the team which implies a lot. Because there has to be a lot of testing, it has to be production ready, all of these kinds of things have to be in place.
Daniel: So most organizations are there but we move in the direction of improvement every single sprint. Then you know, at the end of a sprint, we have a retrospective meeting. We will look back on what we just experienced and get some learning from that and form some new experiments that we want to try in the next sprint to improve a little more. Then we repeat the cycle. That’s how Scrum works. The team size is never less than three people and more than nine.
Jim: Or 10, in that range. Very interesting. I think you did a good job laying that out. A few comments I wanted to make, I think I’ll start at the bottom and work my way up. You talk about that in theory, you need to be able to ship something at the end of each sprint. You know, I tune that down a little bit. I say you have to have a deliverable that actually runs at the end of each … A deliverable, meaning an internal deliverable that actually runs, which then implies that you have to have a discipline of incremental builds all the time. None of us build it and then or then write, write, write then test and then hope it all passes a test. Wrong.
Jim: You have to compile every night at the worst. In this day and age, you might as well do it continuously, which means that you have to invest. This is something that if you don’t do this, you probably shouldn’t do Scrum in a big corporate environment, which is you need to invest in something called DevOps, which is a new career. And if you’re a person looking for a job that will pay well for quite a long while, DevOps is one. Which is what is the operational infrastructure necessary to be able to do continuous builds and continuous deployments without having to be touched by human hands. There’s all these really neat tools these days that do just that. Then the final part, I would put my flavor on it, you’re going to have deliverables at the end of each sprint, using incremental builds in DevOps.
Jim: It makes a lot of sense to do what’s called test oriented development, which is you literally write the tests first for every little tiny bit of code down at the functional level so that when you push the code to the server and the DevOps magic occurred and it’s all built, all those tests are run. And if they don’t pass, you get a yellow flag back to you by email or Slack or something, within a minute or two of the time you checked your code in. You might check in at two o’clock in the afternoon, at 2:05, you get a message on Slack says, “Your code fail the following three tests.” That means that you got to work on it so that certainly by the end of the sprint, probably better, that by the end of the day, you fix those problems.
Daniel: I love that. I’m glad you’re bringing up DevOps. Like when a COB programmer goes to work for Facebook or Amazon, the first thing that they do with them is they have them push some code to production the very first day. You can think of DevOps as a kind of radicalized Agile. What happens is all of the repetitive tasks that no developers want to do anyway, is being relegated to robots, programs and computers. What’s happening there is the authority to make decisions is being democratized, Jim.
Daniel: Previously, in these big firms like insurance companies, brokerage firms, banks, government agencies, they have their quality assurance department, which is an entire thing with a head and a budget and hire fire authority and all this stuff. In the New World DevOps, radicalized Agile, the COB programmer now is authorized to push things to production. There are no gatekeepers. If it passes through those tests, like you say, there is a 99.99999% chance that all the code is good. So what’s happening is a total revolution.
Jim: Well, I wouldn’t go that far. Truthfully code coverage is never that good. 99.99. It’s probably 98 or 99. So you can still have fuck ups, which is why if you’re going to push stuff to production, you have to have a way to revert real fast. That’s again part of DevOps.
Daniel: Right. Right, right. So Amazon and Facebook, they push stuff the production 400, 500 times a day.
Jim: They probably pull it back two or three times.
Daniel: Right. Right, right. What this is doing, Jim, is it’s upsetting everybody. Everyone’s upset. Why? Because people who made decisions yesterday do not make them today. The QA people used to make decisions yesterday, now the COB developers make those decisions. That’s upsetting to people. This is whole revolution and decision rights that’s going on that’s being driven by this Agility stuff. And DevOps is a radicalized form of that. I’m so glad you brought it up because it’s so shows what’s happening, the revolution in decision rights in software development. It’s just amazing.
Jim: If I was doing a readiness assessment for something like your Open Space Agility, one of the things I’d absolutely make sure if I said the word DevOps and a senior executive looked at me cross eyed, I’d say, “Maybe I better come back next year.” Because DevOps would seem to be central to make this kind of stuff work, particularly at scale.
Daniel: Oh, yeah. But you understand now, I mean, any organization can spend 100, maybe 150, 200,000 bucks and set this up. But the resistance is in the entrenched bureaucracy of QA and some of these other departments that don’t want to evolve. They like things the way they are and …
Jim: Don’t want to lose their head count right now. They have their jobs. They don’t want to lose their jobs. God damn it, didn’t want to break the iron rice bowl.
Daniel: Exactly. That’s what’s happening.
Jim: Fuck them.
Daniel: The horse is a [inaudible 00:28:10] on, right?
Jim: [inaudible 00:28:11] in their horses. Then you barbecue the horse. All right, that’s absolutely good. Just critical stuff. But I’m going to pop up to my favorite hobby horse. People that work with me know that if I actually had to do a real job sometimes, sure as shit, I hope I never have to do, it would be as a product manager. Even though I don’t think I ever had that title, that’s what I always was. The biggest value, I believe, I added into corporate America in the 1990s was introducing Rutt style product management also under the startups.
Jim: The key part was the product manager had to be a really senior job and frankly should report to the CEO. As you can imagine, that caused all kinds of shit storms in the same way DevOps does. But when I then learned about Agile in 2001 and they made this focus on the product owner, I said, “I love this. This is like a miniature version of Rutt Product Management.” And you highlighted the part that is absolutely necessary but usually doesn’t happen, in which is the product owner has to be strong enough to have credibility up and down the chain. And if you turn the product owner into some 22-year-old person fresh out of college with a clipboard, that they got a bunch of function points from the marketing department, you know it’s going to be a shit show. The product owner has to be able to put themself in the place of the customer.
Daniel: Absolutely. And they have to really, really know the business and they have to have more than a clue about the technology and they have to have the respect of everyone in the organization. This is a rare person. Someone who relishes authority and has the goods.
Jim: Now, are you seeing that out in your practice in the world that people are willing to or confine whether they’re willing or not, but that really good product owners are appearing when needed?
Daniel: You know, my whole approach to this around the rules is that in an organization, the best thing to possibly do is describe the role, identify people who might be able to fit the role, get them all in one room and invite them to come in and occupy the role instead of assigning it. This will create the best possible product managers you can get. You whittle it down to the people in your organization that you think meet the criteria. You get them in one room, explain the gravity of the situation, and allow them to opt in. This is the fastest way to get a good product owner that I know of.
Jim: I like that. That’s great. Because it’s key. Without it, ain’t going to work.
Daniel: It ain’t going to work.
Jim: In fact, one of the very first PowerPoint I ever did on Rutt Style Product Management, it showed the product manager as the Greek god Janus with the face in [inaudible 00:31:05]. I said it has to look to the technology, what’s possible and to the market, what’s needed. In fact, I then eventually … It took me about a year, I cooked product management, this is not quite the same as being a product owner but very close, down to one sentence. Do you want to hear the Rutty in one sentence on product management?
Daniel: Sure.
Jim: It is the optimal trade off between the doable and the desirable.
Daniel: Yeah, and that raises the whole issue of value. Right?
Jim: Exactly. Someone has to know what is desirable. That’s what being the [inaudible 00:31:39] for the customer is all about.
Daniel: Yeah. Value has many dimensions. That’s something that is hotly discussed during product development, and that’s how you prioritize things.
Jim: But at the end of the day, you got to have one person make the call is my view.
Daniel: Jeff Sutherland refers to it as the single wringable neck. [crosstalk 00:31:59] ask about that. I hope you’ll interview him on your show. Jeff Sutherland is the co-creator of Scrum. He’s a West Point grad. After that, he graduated top in the Top Gun Fighter Pilot Program. He flew 103 recon missions over North Vietnam and F4 for over the tree tops. The mortality rate was 50% of people who had that job. He’s in the Air Force for 11 years doing that stuff and other things. Then after that, he went on and got a PhD in statistics from Stanford. He did cancer research as a professor at the University of Colorado. He really got into complex adaptive systems when he started studying biology.
Jim: Hells bells, say no more. Do you know this guy? Hook us up?
Daniel: I’ll definitely hook you up, yeah.
Jim: A guy who flies phantoms above tree tops, I have some personal history on that. It’s in the complexity? Hell, yes. And invented Scrum? God damn right. Well, I have him on The Jim Rutt Show.
Daniel: I’m telling you, he’s got something to say. He made this rule about the product owner having command authority over the prioritization of the backlog. It’s always one person, not a committee. This is how you just reduce complexity really, really fast. The developers can go to one person to get an answer, there’s no ambiguity about it. There’s a lot of decisiveness. The decision latency is really, really low. You know, the quality of what’s being produced is very high if you have a good competent product order.
Daniel: Jeff composed Scrum in the early 1990s. He started in 1993. I actually was teaching at that time. I was teaching Microsoft platforms and tools. I was working with a company called IDX in Boston that later got purchased by GE Healthcare. I was hearing these noises from some of the developers in my classes about this guy Sutherland, the new CTO and he’s got this thing Scrum and he have this daily stand up meeting, he have to answer these questions and all this kind of stuff. What was actually happening was the genesis of Scrum right under my nose, but I was too busy to really even notice in those days, 1993.
Daniel: Jeff created a system where when the work is at the edge of chaos, you can bring it down from the edge of chaos to complex, and from complex to complicated and wrap your hands around it and increase the predictability and reliability of software development. As you know, software development, predictions in the beginning are just wild ass guesses, Jim. There’s two standard deviations, a variance in the range of what could possibly happen. So through experience, we narrow that cone of uncertainty through getting direct experience.
Daniel: There’s a couple lessons of Agile, they’re very interesting. The first one is just going and doing something is superior to talking about it. That’s number one. Get direct experience, inspect the experience. Then the second lesson that’s really interesting is the quality of the software turns out to be a function of the quality of the interactions and communications by in between the team members. Scrum encourages very, very high quality interactions through the daily Scrum, the sprint planning, Sprint review. There’s a real efficiency of communication there that’s really beautiful and it can create something really great.
Jim: Absolutely. We’ve discovered in the ’80s something that I would say conceptually a precursor. Which again, back in the early ’70s and early ’80s, people would have the various sub parts of the teams working on their modules and they wouldn’t bring them together until ridiculously late in the process.
Daniel: That’s always a bad idea.
Jim: At least in my companies, one of my innovations was the earliest possible end to end system. We could have fairly minimal functionality but the goddamn thing had to work from one end to the other. Most of the businesses I was involved in was building online information system that worked at least the continental scale, sometimes a worldwide scale. There was an awful lot of shit involved to make it and actually work. But I’d get end to end to work by three or four weeks into a yearlong project. And people said, “That’s impossible.” I go, “No, it’s not. We just put bullshit wherever we need to.” We will have information flowing from end to end and back again in three or four weeks, and then we will work from there. That’s, again, conceptually similar, not as fully robustly grown out as the Scrum approach and it’s incremental builds and the damn thing actually works every day.
Daniel: Yeah, yeah. It’s so great to be talking to a software guy about a software development process. This whole thing with that Agile, Scrum, organizational scaling of Scrum and so forth, points to the fact that it’s the quality of the interactions, the communication that determines the quality of the product. Actually, the more disciplined we are in communicating, the better the quality of the product. That’s the lesson of Scrum.
Jim: Scrum happens to be, and has been tuned to be, a pretty good approach. You do make the point in your book. I think this is important to throw out here. That even though my experience has all been Scrum, one case was a homemade variant of Scrum. But there are several other disciplines of Agile out there and your books are quite clear that you should not prescribe one or the other that is … I read them that teams should choose which one of the Agile approaches that they want to use.
Daniel: Yeah. Your listeners, they want to really do some research on this. They can go and Google the Agile imposition or the Agile imposition revisited, where you’ll read essays about how processes, so-called Agile processes are being imposed on teams. Meanwhile, self-management is where all of the goodness comes from and you’re killing it with the prescription. You’re prescribing something to the team and not self-managing anything at all because you’re not deciding anything. This whole concept of deciding, Jim, is absolutely key to team productivity. Leadership needs to look at this as game design. Certain decisions are set aside for formerly authorized leaders and teams don’t make those decisions.
Daniel: But a certain number of decisions that do not fall below a certain threshold, in terms of frequency or number are given to the team. Why? Because the decisions generates engagement, it gets in the head of the developers and they get in the game and now they’re really creating something. If the decisions they’re making falls below a certain frequency or number or volume, they will check out. They will literally start to just say, “You know, I don’t care. Whatever Bob says.” And that’s what it’s going to be.
Jim: I hate that. When people just become hands, forget it. The company has died. We have to have heads and hands all the time.
Daniel: There’s also this concept of learned helplessness. Have you ever heard of this one?
Jim: I don’t know how much you’ve read my writings about Game B but that is we call a core example of Game A malware is learned helplessness. Why don’t you explain for the audience what it means?
Daniel: Well, what it basically means is at some point, if you’re experiencing pain and you try to get away from it and you can’t get away from it, at some point, you give up. Even though the exit door is right under your nose, you won’t even look for it anymore and you just resign yourself to the pain. Because other people’s situation is good but mine really sucks. When that happens, the productivity drops dramatically in exponential fashion. What’s happening is if you learn it over the teams, if you take all the decisions away, you make all the decisions for them, they will give up on engaging and then they will also give up on everything and they’ll just become zombies. This is what goes on in a lot of organizations all over the world. Scrum is actually a way out of that because it’s saying in through its rule set, “Some of the decisions belong to the team. Here’s the definition of those decisions and these rules are not to be trifled with if you want to produce good software.”
Jim: One of them, let’s get back to the topic, is that the team should be allowed to choose which Agile discipline they want to follow. Is that correct?
Daniel: Absolutely. Because not every project or not every program, not every product is an Agile product. Some are sunsetting projects that are well-understood and do not require empiricism for process efficiency. It’s a lot of projects or ABC, products or ABC. But new product development, a lot of variants in it, a lot of unpredictability, a lot of uncertainty. You use empirical process control for that, you use something like Scrum. That’s your way out of it.
Jim: My point, I guess, I’m getting some more narrow point is that the executives should allow the teams to choose which of the Agile disciplines they might want to use.
Daniel: That’s right. In Open Space Agility, what we say is the constraint that we put in, we have a 90-day experimental window where we try some new process. The constraint is the 12 Agile principles in the manifesto. What we say to the teams is, “Use any process you like but don’t violate these principles. If you violate these principles, we’re going to take you out, you’re going to get a talking to. But go ahead, use whatever you like within these constraints.”
Daniel: That turns out to be rather confining but also rather liberating at the same time, because they are choosing within a fairly choosable range. It’s a narrow range but there’s still some choice there. They can use Kanban, they can use Scrum, they can use other empirical approaches. The act of choosing is very engaging. That’s the team itself becomes happier, that happiness gets associated with up tempo, up tone, and boom, outcome is high quality product.
Jim: Just, again, for our audience, who many of them are not professional software developers, but they may be executives who have those functions under them, what are some of the names of some of the other approaches other than Scrum? Just so people heard the words.
Daniel: The two primary tools that are used today, Jim, are the Kanban Method, which is pioneered by a fellow named David Anderson, and Scrum. Then within that there’s other practices that are used. For example, under the heading of XP or extreme programming, there’s pair programming, continuous integration, ideas like this that you incorporate and make part of your sort of roll your own method. If you go to extreme programming, you’ll see many things in there like refactoring and this kind of thing. Refactoring is a programming practice where you restructure the code, it doesn’t change the functionality but it increases the overall robustness of the code, reduces the brittleness, makes it softer, makes it more malleable, this kind of thing.
Jim: Let’s now pop up a level. We’ve talked a lot about Agile itself. Now let’s talk about your bigger picture, Open Space Technology married to Agile. Why don’t you take people through what open space is and get into some detail and talk about your principles and the roles and that kind of thing. Take five or 10 minutes.
Daniel: All right. Open Space Technology, what is it? It basically creates a conditions where people can be themselves, where they can make decisions and act on what they want to learn and how they want to contribute. Let’s talk about the starting conditions for an open space meeting in an organization. It’s basically three or four starting conditions, maybe five. Here they are. Number one, we have a matter of mind numbing complexity where no one person has the answer or claims to. That’s number one. Number two is there’s a diversity of opinion about it, pro and con and people really care about it. There’s heat around the issue, pro and con about how to solve this thing. Every one has an opinion about it.
Daniel: The third condition is this high potential for conflict as we process this thing. The fourth one is a decision time of yesterday. We’ve already waited too long and we need to do something now. Those conditions are ideal for enterprise wide organizational change. This makes the open space meeting highly conducive to an efficient change experience. Open space meeting is invitational in nature, no one can make you go to it.
Daniel: A formerly authorized higher up authorizes the time and the space, develops a theme, which is wide enough to contain everyone’s issues but narrow enough to focus the group typically that’s developed with a cross section of influencers and people in an organization. Then the organization’s given a couple weeks to process, you know, an invitation that this leader sends out. Then when the day comes, the people who are strongly attracted to the issue who feel passion and responsibility around the issue, they show up at the meeting.
Jim: Let me jump in. Let me jump in here just for a second. One thing I try to do in all my podcast is get down to tangible examples. So as you’re going through this, I love to throw out an example that we both agree would be appropriate for use of this process. And as I was listening to you, it struck me that one that fit all three of your criteria in the right context would be the classic problem for a successful but still early stage company is what should our next product be?
Daniel: Yes, that is a great theme statement. And so interesting, that you put a question mark at the end of it because themes typically have a question mark at the end because question marks tend to open the conversation where a period tends to close the conversation. Right, Jim?
Jim: Frankly, one of the things that some startups I’ve been involved with is, “Should we even have an X product or should we continue to just invest in our current product?” It’s a big tension. There’s lots of controversy and it’s a big stake because it could be half of our free cash flow next year. Do we put it into improving our current product or rebuild the next product? When you’re listening to Daniel talk about the process, think in mind that this is for a company that has one product doing 4 million a year, they’ve just reached breakeven, positive cash flow, and should we have an X product and if so, what will it be? That will be our high stakes topic. So continue.
Daniel: Beautiful, yeah. The formerly authorized leader who’s going to function as a sponsor and the host, who’s going to be the inviter, sends out an invitation, refers to the theme, refers to the opportunities and the threats that the group is facing. Invites everyone to show up, kind of sets the boundaries for the thing, namely that, you know, “We’re looking for some solutions. It’s going to be a Book of proceedings that’s generated and we intend to act on those proceedings after we come out of this meeting.” The meaning’s just the beginning, we’re going to use the proceedings as a basis for action moving forward.
Daniel: They send it out as widely as they possibly can, as many people that might be affected by the issue are invited to the meeting. Then whether they go or not, they all receive the proceedings. It’s sent to them. It’s like a PDF on a shared network drive or something like that after the event happens. Now, inside the invitation, they might provide a link that kind of describes what open space is. An open space is a gathering. It’s an invitational gathering around a theme. There’s five principles to open space and there’s one law.
Daniel: Here’s the five principles. First one is, “Wherever it happens is the right place.” Wherever you’re doing open space, it’s the perfect place. It’s good enough, it’s going to happen exactly one time there in this way, and we’re doing it right here.” The second one is, “Whenever it starts is the right time.” The idea here is that the normal rules of punctuality are suspended in open space. The meeting will start when it starts. That’s pretty much when the people show up, when they all sit down. If it’s supposed to start at 9:00, people get there early maybe it starts “early.” If people show up a little later, maybe it’s “late”. There is no early or late in open space, it’s just whenever it starts.
Daniel: The next principle is, “Whoever comes are the right people.” When you have one of these meanings, the people who show up, we know for sure why they showed up and that’s because they were attracted to the invitation. The people who didn’t show up, there’s 87,000 reasons for a no, but there’s only one reason for yes and that’s that they found the invitation attractive. Whoever shows up are the right people, people who found an invitation attractive. Then the next principle is, “Whatever happens is the only thing that could have happened.” There’s no preset agenda in an open space meeting. There’s all kinds of things that can happen and occur. There’s a slogan in open space, “Be prepared to be surprised.” One definition of being surprised is that you learn something. There’s a lot of learning that goes on in open space.
Daniel: The last principle is, “When it’s over, it’s over.” Some small sessions throughout the day might end a little early, they might go out in the hall and continue the whole day. We don’t know how long a session is going to go or who’s going to show up, what’s going to be said, what’s going to emerge there. These principles are recited by the facilitator. During the event, everyone assembles in a big circle, the sponsor who invited everyone reminds everyone about the opportunities, the threats, the theme, why we’re here, and then introduces the facilitator. Then the facilitator will explain these principles.
Daniel: Now, I facilitated dozens of these meetings. What I find happens is by the time I get around to the third principle, a lot of people start smiling at me. It’s because they realize that this whole five principles and one law thing, I’m going to tell you the why in a minute, it’s just it’s a sort of metaphor for the fact that you’re free. As I recite the principles, I get the feeling, “Okay, I’m free to do what I want. Nobody can make me do what I want here. Nobody can, not do what I want but nobody can make me do anything that I’m unwilling to do at this meeting. We’re all basically equal in authority here.”
Daniel: So when they get that, they start smiling at me. This is the vibe of open space. One of the conditions is high potential for conflict. There’s one law in open space. Here is the law, “The law of two feet.” If you are not getting the kind of learning that you are seeking or getting the opportunity to make the kind of contribution that you want to be making, your two feet can take you somewhere else where you can get those things. Leave the session you’re at and go to another one.
Daniel: There’s a couple of sort of sub roles in this open space thing. There’s a sponsor, there’s a facilitator, and then there’s a participants. But the participants can function as what we might call bumblebees. They just moved from session to session. They don’t spend too much time in any one session, they kind of pollinate the conversation across all the different small group sessions that have taken place. Then there’s this concept of this behavior like a butterfly. People hang out, they don’t go to any sessions, they don’t call any sessions. They’re usually found by the food and beverages having conversations with people and they’re just in the space. So the bumblebees and the butterflies.
Jim: Let’s get down to tangible. Again, as I recall how this thing works, there’s an opening meeting where everybody shows up, right?
Daniel: Yeah, big circle.
Jim: So that’s like 500. Let’s say the company has 100 people, they all show up. A master of ceremonies, as I recall, starts the thing off. So let’s start, you know, just run the example through.
Daniel: The sponsor stands up, welcomes everyone, reminds everyone about the opportunities and threats in the theme, hopes everyone has a great day and remind them that we’re here to get those proceedings because we’re going to act on them afterwards. Then that highly authorized authority figure who invited everyone sits down, or will introduce the facilitator and sits down and then the facilitator stands up and takes people through the rest of the process of getting underway. You could think of it like this, there’s a convergence of everyone at the beginning of the meeting, Jim, and then there’s a divergence throughout the day where we move into small groups. For example, at one o’clock, there might be seven different small meetings going on in the big room, one in each corner and spread out around the entire hall.
Daniel: Usually, these meetings are held in a very large ballroom in a hotel or something like that. So if you’re in a small session, you can look around and see six, seven, eight other sessions going on. You can see your friends, colleagues, and peers at those sessions. You can also count the attendance at those sessions and you can listen to the noise level of what’s going on then that level of passion. If something grabs you, you can just get up and leave and go see what’s going on over there. That’s what goes on throughout the day.
Daniel: At any given time, at one o’clock, at two o’clock, at three o’clock, there’s seven or eight different things that you can graze on topics and when the meeting opens, people announced those sessions and they put them on a grid on the wall. There’s a big blank wall at the beginning of the beginning, and at the end of the beginning that wall is filled up with sessions and each session is going to occur at a certain time in a certain place throughout the day and people can go up to that wall and plan their day. At any given time, at one o’clock, two o’clock or three o’clock, there’s seven things to pick from, eight things to pick from. Then at the end, we reconverge and we have a closing circle. That’s where people will offer their reflections on their experience today, we have a formal closing, and then we reconvene and everyone’s dismissed.
Jim: Sounds pretty straightforward. Now you keep the available sessions up on a physical board. I’m starting to think in my head, it would be kind of cool to have an app so that new sessions could come and go and you could look at your app. Especially if you’re going to have your right to vote with your feet because, “Goddamn, this session sucks. Let’s see what’s happening right now.” Have you tried anything like that?
Daniel: I have a great story about that for you. If you want, I could tell you about it.
Jim: Sure.
Daniel: It was actually a Capital One. It was the largest open space I ever did. They were expecting 400 people at the event. In two different cities we did it. In the first city, I brought some people in who had more experience than me with open space because I felt that I needed that help. One of the women who I invited, she came up to me and she was very gentle about it, everything but she said, “Listen, Daniel, tomorrow …” We’re setting up to the night before and she said, “Listen, Daniel, tomorrow there’s going to be like over 400 people here and the marketplace wall …” This big grid is called the marketplace. It’s where the sessions go, where the people post the sessions.
Daniel: “You know, that marketplace is so big and people don’t have much experience with this at all. We might want to position ourselves to receive them and kind of teach them how to post to the wall.” I said, “Well, thank you for that. It’s a good suggestion. Let me think about it tonight. I’ll give you my answer tomorrow about what we’re doing.” The next day, I woke up and got ready. I realized, “No. This is all about self-management and self-organization, I’m not going to manage anything. I’m not going to authorize the management of anything here. We’re going to see what happens.”
Daniel: We went to the space and I told Linda, the one who made the suggestion, you know, my decision. She’s like, “Well, okay.” Then we opened up the opening and we went through the one law, the five principles, and be prepared to be surprised and everything else about open space. We told them what to do and how to do it and then invited them to come to the center of the circle and write their session down, grab the microphone and announce it to the group.
Daniel: This one guy just made a beeline for the center of the circle and immediately announced this session. Put it on the wall and then he hung out over there. Then other people did the same thing. They headed to the wall and he guided them and coached them on how to do the marketplace. What that dude had going on was he had an app on his phone that he wanted everyone to use, which would socialize the marketplace and made it easy for people to keep it in their phone and he wanted to make sure everyone had a shot at using his application.
Jim: That’s kind of cool. Is there now a commonly used app for that purpose?
Daniel: There are some open space apps that automate and facilitate the marketplace and also the use of online open space. I’ve done open spaces online with global audiences up to 200 people using Zoom video.
Jim: I remember we did one for Rally Point Alpha. It was kind of about two thirds of shit show but that wasn’t your fault. I don’t know if you remember that.
Daniel: I remember [inaudible 00:58:54] showing up after having a certain procedure.
Jim: I let him in. Anyway, that’s ancient history. You’ve done a good job of describing what an open space meeting is. Now let’s pop up to your next level of obstruction, at least, as I took it out of your book, which is let’s say a company has convinced itself it wants to deploy Agile where appropriate, let teams choose to use Agile or not, to choose what’s flavor of an Agile or not, et cetera. And you’ve embedded this as a first round of what you called 100 days of experimentation. Could you talk about the framework of 100 days of experimentation and how open space and Agile essentially self-organize over 100 days within an organization?
Daniel: When you bring procedural change, ways of working change, organizational change, that creates anxiety. People get worried. When people are worried and afraid, they can’t learn very good. Agile is all about learning, adapting and changing and pivoting. What we’re doing there is we’re bracketing the learning experience so it has a beginning, a middle, and an end. That begins and ends in space meeting. In the middle, we’re going to do experimentation, we’re going to do iteration, we’re going to do adaptation, and we’re going to do inspection. So those are core Agile ideas. We’re going to inspect, we’re going to adapt, we’re going to work in iterations and we’re going to experiment in an iterative fashion.
Daniel: So what we’re really doing here is we’re taking those team level ideas, Jim, and we’re making them first class objects at the level of enterprise. We’re executing on a 100-day iteration of change, where there’s an inspection at the end. We’re going to have a referendum on what worked, what didn’t work, and what we want to change at the enterprise level. This has a profound effect on people that are resistant because they’re not being asked to do this for the rest of their lives, they’re being asked to do this for 100 days. What we do is we create what I call a chapter learning and that is bookended by these two open space events.
Daniel: At the first open space, and this is key, the leader, the sponsor, the host, says to the folks, “Not just we’re here for the proceedings, but if you like this meeting, in 100 days, we’re doing this again. So suspend your disbelief and act as if and pretend that what we’re about to embark on in the next 90 days might actually work. If it doesn’t, we’re all going to get in here, everyone’s going to get a here in 100 days, we’re going to inspect this thing. Stuff that didn’t work, we’re going to drop like a bad habit. But we’re moving in the direction of improvement one way or the other.” That’s the message.
Jim: That’s interesting. I think it’s I would say psychologically-wise, one of the things I’ve taken away from my business career is that most people really don’t like ambiguity.
Daniel: Right.
Jim: There’s only a few of us maniacs who actually thrive on it. But they’re willing to tolerate it in tolerable doses. What you’re doing here is saying, “We’re dosing this ambiguity for you.”
Daniel: That’s exactly it. That’s exactly right. That’s a very astute observation. What happens when you bring this stuff to an organization is people get real nervous because here’s what’s really going on, Jim, we are refactoring the authority distribution schema when we bring this Agile stuff on. People who made decisions about product yesterday don’t make them today, other people do. That makes a lot of people nervous about their kid’s college education, about their own mortgage, about their car payment, and all this kind of stuff. Their retirement, the whole nine yards. It’s very triggering because it triggering this fight-flight and survival instincts. Then when people are triggered like that, they’re not behaving rationally. So what we’re doing here is we’re reducing the anxiety that is brought on by this ambiguity that you’re talking about, Jim.
Jim: Again, you compartmentalize that and further, I’d like the concept where, again, there is no dictating to the teams that they must choose Agile but they’re going to learn about it. Here’s some ways that it may be good for them. If they want to, they get to choose, which is kind of cool. Then now pop it up one more level, as I understand your process, you then have a repeating of these 100 days. After the first 100 days, if things went well enough, people want to do.
Daniel: Regarding the 100 days, what we know from experience now is that 45 to 90 days is the sweet spot. 90 days is like one material quarter on the calendar. 45 days is half of that. Lately, there’s been a rush of this trend towards OKRs because of the John Doar book, and that map’s neatly to 90-day iterations. 45 to 90 days is pretty much the standard that we’re using now. But in terms of what you’re saying, we’re going to use iteration just like with Scrum. The metaphor is, in Scrum, you have sprint planning, you have the sprint, you have the sprint review. In open space agility, you have the first open space meeting, you have 90 days of experiment with a new way of working and then you have the second open space meeting. That frame allows people to make meaning of the situation.
Daniel: Like your startup example, where should we build a new product or not? Should we continue to go with the first product, should we build the next product, where are we going to get the money from? All these kind of stuff. Coming out of that first meeting, there’s a book of proceedings, it’s got a bunch of ideas in it. The organization is going to act on some of those ideas in a 45 to 90-day period. The idea is they will look back and look forward in the next open space.
Jim: For instance, maybe it came out of the first meeting here, you know, “Here’s some research we need to do. All right, here’s a little prototype we need to try to build. We can’t build the prototype, we probably shouldn’t try to build the product.”
Daniel: That’s right.
Jim: It could be it could be some action item. Is there any formal mechanism and open space to cook down the book to action items or is it not intended for that?
Daniel: Open space meetings are intended to generate dialogue and ideas, the proceedings that come out of an open space meaning that our output of an open space become input into action planning. They’re not quite there but typically the next day. This is what typically I’ve done and works really, really well. You have the meeting the next day, the chairs are all in a circle, you’re still in the same room. People come in and they inspect the proceedings, they spend 30, 40 minutes browsing the proceedings because you can’t go to every single session. But every single session is documented in the proceedings.
Daniel: You lead through the proceedings, you thumb through it, you pick off the ideas, the themes and the major ideas that are in there, you pick out the seven or eight top ones, those are presented to the leadership group. The leadership group picks four or five things that they want the whole enterprise to focus on. Then you look for champions who are going to pull that together in the next 90 days. They work directly with executive leadership and they’re authorized to champion that issue. What we usually do there in that session is we put one issue per flip chart on around the room. So if there’s five issues, there’s five flip charts, each one with a different issue.
Daniel: Then executive leader stands up and explains that, “We’re looking for people to champion these things in the next 90 days but before you jump out of your seat, let’s explain the gravity of what this means.” Then they lay out the constraints. Like, “One of the constraints might be if you volunteer, you can’t unvolunteer. You’re in for 90 days. You also commit to meeting with us once a week or every two weeks,” and some other constraints. Typically, what you’ll do is take the bottom 10% of some of this workload and distribute it to other people so they have 10% of their time to work on decision.
Daniel: That generates a tremendous amount of engagement. When that’s over and the leader says, “Okay. Those of you that want to champion these issues, go stand next to the one that’s really hot for you.” Then usually about five, 6% of the people get up and they stand up and they stand up next to those issues. Then we have kind of a science fair kind of approach after that, where everyone else gets up and grazes around. Then you’ve got the 45 to 90 days kicked off. You got champions and you’ve got those issues and it’s a separate … What I’m saying is it’s a separate event and a separate function. There’s dialogue, there’s deciding and action.
Jim: Okay. Then now talked about the next meeting. What does that look like?
Daniel: You mean after the experimental period has passed?
Jim: Yes.
Daniel: What that looks like is … Here’s what happens there. We talk about people gaming the meeting. That’s actually a form of self-management and self-organization. When people learn about this open space meeting format and they learn that it’s really open, what they’ll tend to do is conspire with their friends to move the second meeting in the direction that they want it to go. The second meeting is like a retrospective and a prospective. It’s a retrospective on the past 90 days, what worked, what didn’t work, what do we want to change. And it’s also a perspective on what’s the next chapter look like and what are the next set of experiments that we want to do.
Daniel: What happens is the real passionate and responsible people, they will tend to talk to each other and start to strategize and plan how they’re going to play the second meeting. That’s when it gets really interesting. I was in one company where the Scrum Masters conspired around getting a product roadmap out of the second meeting and the product guy was not the least bit interested in that. Within about a month and a half, that guy was gone, he quit. Because after the second meeting, what was in the proceedings was, “We want a roadmap that looks at least 90 days. 180 days would be better.”
Daniel: They went to him and he’s like, “No, I don’t think we’re going to be doing any of that.” Then they went to his boss who was the general manager and we got that meeting. Those Scrum Masters facilitated a half a day or almost full day meeting, product roadmapping session where they got that roadmap and kind of deauthorized this product guy. It wasn’t too long after that, he quit. Then progress at that company really escalated because he was blocking. These are the kinds of things that happen in these meetings.
Jim: Very cool. Well, I think that’s where we’ll transition way from your first book to one of your other books. I picked two of them to read. The second one is called Inviting Leadership. Again, there’ll be a link to it on our episode page, jimruttshow.com. Why don’t you talk a little bit about this idea of inviting leadership? I actually found it quite intriguing. It might be nice just to introduce it.
Daniel: Sure. The idea here, Jim, is that you’re in an era of full employment, in an era of mobility, and an era of change. Your best workers are at-will employees, they’re really volunteers. If you’re not mixing in some invitations with those delegations, you might be losing some of your best people because they have a strong drive for autonomy. The idea here is, especially in times of rapid change, you need feedback. Delegations do not generate even one-10th of the feedback than an invitation generates.
Daniel: For example, you invited me on to the show. What happened next? I got to choose the timing of my response, the medium of my response, the content of my response and so many other things around my responding to your send of that invitation. That’s all rich feedback for you to act on about just how good or not good this interview might go. With delegations, you don’t get any of that feedback. In good Agile and good Scrum, good empirical process runs on feedback. Without feedback, you have nothing. The idea here is yeah, I continue to delegate but mix some invitations in with your delegations. Here’s why, because every invitation has inside of it an invitation to decide yes or no.
Daniel: It turns out that decisions generate mindshare and deciding is highly engaging. When you invited me, here’s what goes through our mind, “What happens if I say no? What happens if I say yes? What will I miss if I say no? What will I experience if I say yes?” All those things are in my head. So when you invite me, you get in my head. This is a very, very strong way to lead today, especially when you want to be able to respond to change. Responding to change is about feedback. Invitations generate that feedback, they engage your best workers, the ones with options, the ones who will loiter at the exits with their resume if they smell that smell.
Jim: Could you give a nice tangible example of where a manager might want to choose to use an invitation rather than a delegation?
Daniel: Let’s take an example where … Let’s take that product owner example. You know, you asked me earlier, you know, “How do you select a good product owner?” My approach would be define the role, identify people who could fit in the role, and then if there’s three or four opportunities to play the product owner role, invite 12 people and let them know, you know, the first four who respond to this, they have the job and see what happens. Now you’re going to get super enthusiastic all the way in 100% in product owners, instead of foot dragging, pissy, half-hearted product owners.
Jim: We should increase the chances of it. I don’t think any of these things are panaceas but I can see that that would be interesting. Your concept here dig into it is that putting a decision into the head of the person who may or may not do the work is actually an important way to generate information. In this case, you can figure out who is interested in this role and who’s not rather than saying, “Sue, you look like the right person to be the product owner.” She may not want to be the product owner, but she might feel compelled to say yes.
Daniel: Yeah, and I can give you another tangible example of something that I did in the ’90s. In the ’90s, I had a technical services firm and it grew to about 55 people and I had operations in three states. I created a benefit, which was a book stipends. People could spend 500 bucks a year on books. Here was the rule, the rule was the book has to pertain to your job “in some way.” Then it was user to lose it and then it reset every year in January. Those were the rules and the constraints. Everyone was invited to just take advantage of it. Well, don’t you know how much feedback I got out of that, Jim? A lot of people who are working like in .Net, they were buying Java books. I had no idea they’re interested in Java stuff so I got to talk with them and I found out that they were real passionate about Java.
Daniel: I was able to move some things around and really keep people engaged and motivated. I got a lot of data from what books they bought, when they bought them, whether they used up all the stipend, what they were reading, what they’re interested in. That’s another example of generating feedback off of an invitation.
Jim: That’s a good one. What else can we talk about here? You talked about the core principles of inviting leadership. Could you go into those?
Daniel: Yeah. There’s four things in common with any good game and any good invitation. Jane McGonigal wrote a book called Reality is Broken about, I don’t know, 10 years ago. On page 22 of that book, she defines the properties of a good game in this forum. I really love her definition. She says a good game has a very clear goal. Second thing it has is very clear rules or constraints. Third thing it has is a way to clearly track your progress to know what level you’re at and to get feedback. The fourth property, and the most important one, is opt in participation.
Daniel: It turns out that these four properties also apply to any good invitation. Any good invitation has these four properties clearly defined. In the book, what I described is that there’s some real rigor and discipline that has to be applied to your invitations. In fact, you can’t just casually invite someone, you have to really think about it and structure it properly. Unlike delegations, which you can just throw at people. It sounds clinical but it’s actually very simple. Like, you know, “I can invite you to dinner now and I could satisfy all four of these properties.” You want me to take a shot at that?
Jim: Yeah, actually why don’t you use the example of inviting some people who might be candidates to be product owners? Because that’s a little bit more business.
Daniel: Here’s how it would go. Let’s say that I was reciting an email that I composed and I was reading it now. I’m going to put it out to all the candidates that we believe would be good product owners, maybe it’s 20 people.
Jim: All right. That’s perfect.
Daniel: Our preamble, discuss the need, the opportunity and the challenges we’re facing while removing the Scrum. Then would say you’ve been selected as a candidate to occupy this role. It won’t be assigned to you, you’ll have to choose it. Here’s the goal, our intent is to create a predictable and reliable delivery function in this company. So we have a delivery machine and the product owners play a critical role. They’re actually the hero of the … They’re the star of the show. They are the deciders and they have a lot of authority. They also have a lot of pressure because they have to face the pressures of the technology teams, the business teams and they have to resolve, basically laid out as an enticing high profile role.
Daniel: The goal is to improve our predictability, reliability and quality of our products and you’ll play a critical role in the vision of our products. What are the rules? You’ll need to show up if you’re interested in this at a meeting, that’s two weeks from today. On Thursday, we’ll provide further information about what this role is and the gravity of it. You must do the following things before you arrive there. You know, thing one, thing two, thing three, and one of those might be read the Scrum Guide.
Daniel: We’ll track our progress through time and test through the meeting and also by who signs up. We need four product owners. Not three, not five but four. We hope that you’ll consider being one of them. The first four who volunteer to be a vetting, it’ll be like one more sort of check before its final but if you sign up there’s a high likelihood you’re going to this job. Here’s how you’ll be measured, here’s how you track your progress, here’s how you lower you’re [inaudible 01:19:02]. You’re invited.
Jim: Now, as we get into the book a little further, you start off by talking about authority. Give me your view of authority. I have my own views. I’d love to hear, have you articulate from the book since the book’s a little old, then we can talk a little bit about authority and how one should think about it.
Daniel: Yeah. Authority is a triggering term. When we go into an organization when we’re being introduced around after you meet the person or when you meet the person that the introducer will always say, “You know, Mary runs product,” or “Mary imports the so and so in quality, you know.” So you know where they are and what their authority level is. In the book, we define authority as the right to do a specific kind of work. Some of the most important work you could possibly do is making decisions that affect the group as a whole. If you’re authorized to do that, we call you a leader. If you participate in decisions that affect the group.
Daniel: But the definition of authority in the book is the right to do a specific kind of work. Then we go on to define power as the exercise of authority. Authority is a really deep topic. I’m pulling this from the group relations community. There’s a worldwide community that studies and implements the work of a fellow named Alfred Bion, B-I-O-N. They run these conferences that are empirical where we study authority in the here and now and they create a temporary institution in these conferences where we explore and play with authority in a safe kind of a space away from work.
Daniel: I’ve attended several of these. The people that I’ve met there have been pretty amazing. Like people who run West Point, captains of industry, university professors. All kinds of really high achieving, high impact people who are struggling with the exercise of authority and their jobs. I’m bringing that experience and that learning into the book. You could think of authority as the essential information that describes the group. If I want to know the group, all I need to know is who has decision rights. That’s going to form the structure. In the book, what we say is, “If you want to change culture, all you need to do is change who’s authorized to make a decision.” That will change culture right away.
Jim: Let me hop in here. This was something we believed in a lot at the Thompson Corporation. I remember once at least we have these annual top management meetings like 150 people, something like that. I remember, as part of my keynote address, I said, “Here’s one of the more unfair advantages against our competition.” The Thompson corporation, which is like I bought an $8 billion company, 50,000 employees, we have 500 people who are authorized to waste $50,000. I looked over at the CFO and watched him cringe but then also smile because he knew it was true. Our number one competitor, McGraw Hill, we know there are three people who are allowed to waste $50,000.
Jim: I assert that this is one of our great competitive advantage. Our mantra at Thompson was we delegate authority down to the level we’re comfortable with and then one level below that. I should say, this was Thompson in its heyday in the ’90s. They brought in the usual corporate clowns and the next generation of management and it ain’t that no more. But man, did we do some amazing things with that design of pushing authority down and of course, if you push the authority down, you have to put accountability down. In Thompson, it was well known, if you missed your numbers two years in a row and your head will definitely get lopped off. Oh, well, right? You had all the authority. And if you fuck it up, it’s on you.
Daniel: Exactly. You had danger and you had opportunity, all in one spot, right.
Jim: We had 25 year old guys who were four years out of college, who were running a $5 million business unit and they had amazing authority and accountability.
Daniel: Right. Authority to do what? It’s authority to decide.
Jim: In this case, authority to hire and fire, design their budget. Once they have their budget within the very broad flexibility to spend their budget how they want.
Daniel: Authority to decide when its authority to the edge, here’s what happens, your company becomes more responsive to the ever changing range of opportunities that are present each day as things change. If you centralize control, centralize decision making authority then you get to be less responsive to them. That’s the bottom line.
Jim: I will say that this goes into evolutionary theory that in a business space or any kind of competitive space, there are fitness landscapes that are either changing rapidly or slowly. If they’re changing very slowly, say you’re a nail factory, right, [inaudible 01:24:10] factory, it’s like Adam Smith’s canonical example. Probably you don’t need to decentralize too much because you really need to optimize what they call an evolution exploit. You need to exploit the space, make better pins for less money. On the other hand, if you’re in the publishing business in 1992, which is when I showed up at Thompson, at least a few of us knew damn well that I see a revolutionary sea change was about to happen.
Jim: In 1992, Thompson got 90% of its revenue from paper. Maybe throw in some CD ROM. What we knew by 10 years, it would be the other way around. This was going to be a very rapid changing environment. He or she who was most adaptive on this fast evolving co-evolutionary landscape is going to be the winners. We basically went from number four to number one in 10 years by being wasteful. It’s interesting. Our profit margin was always a little lower than McGraw Hill a couple points. But our ability to transition from the old world order to the new world order was vastly more rapid and that was the do or die thing at that time.
Daniel: Isn’t that interesting that you’re mentioning that this idea of distributing authority to the edge and that there’s some what we might call necessary waste involved there. There’s a fellow named John H. Hall. You probably know him because he was a trustee and a external professor at Santa Fe. Do you know him?
Jim: A great friend of mine and one of my most important mentors in my scientific third career.
Daniel: Well, isn’t that interesting? I’ve just come across the most remarkable book by this man. I’ve never seen a book like it. The title is Signals and Boundaries: Building Blocks for Complex Adaptive Systems, Jim.
Jim: I have not read that one but I’m going to.
Daniel: This is a super interesting book because those signals at the edge, when you empower decision making, the individuals at the edge with decision making authority, they’re at the edge where the signal is and they can actually respond because they have the ability to decide. This man, John Hall, and he writes extensively in his book, he uses a micro biological cellular theory to describe what goes on in social systems. That’s exactly what we wrote about in the inviting leadership book as well. It’s extremely interesting about this boundary management stuff in particular concerning decision rights, the boundaries on authorized decision rights.
Jim: That’s your next point in the book. So let’s talk about that.
Daniel: Yeah. It turns out that most of the impediments to good throughput in most organizations is because they haven’t refactored what I call the authority distribution schema or the distribution of decision rights, Jim. The world changes, we have a reorg but the reorg comes too late. You know, this is latency. With Scrum, what we’re doing is where you’re creating a lot of responsiveness around this guy, creating the conditions where the authorized decision rights are in the right place. That impediments to good product, high quality product, reliable, predictable product delivery are removed.
Daniel: The biggest impediment to delivery is the way we’re making decisions. That’s what’s actually going on around the world. We make decisions a certain way, the world changes, we keep making decisions that way. Now there’s an impediment to throughput. This whole idea of authorized decision rights and continuously refactoring that so that the impediments to good product and all the things we say we want, the goals we’re trying to see, those impediments are minimized or even completely removed because my hypothesis and the thing that I coach executives on is that the way decisions are being made in the organization is actually the place where all the problems are.
Jim: Absolutely. In fact, I go a little further which I’ll say what is an organization but a signal processing system whose output is decisions.
Daniel: Exactly. Isn’t that so true? The book inviting leadership basically offers the assertion in the hypothesis that if you distribute decision rights, which is what you’re actually doing with invitation, that you become a more responsive organization in the time of high magnitude change technology. I was listening to the Apple financial results for the quarter, there’s 1.3 billion Apple devices out there now. This is totally transforming society. I was saying to my wife, Roberta, that it’s not changing the fabric of society, the technology is the fabric.
Daniel: So what’s happening here is the pace of change is speeding up. It’s hitting businesses first. They’re stuck in the mud in the way that they’re making decisions and they can’t get out of their own way. These companies are going to get acquired, they’re going to be run over by a fast and moving nimble competitors, smaller one startups with nothing to lose. This is what we’re up against. In inviting leadership, what we’re doing is we’re actually taking an empirical approach to leadership. That’s what the book’s all about.
Jim: Let me have one light final tuning and then we’re going to have to wrap up here. We’re about at our time. Which is I would extend the authority with a little cloud around it of signaling. I’m going to give you a real life example. One of my collection of businesses I was in charge of when I was at Thompson, I was a group CEO, whatever the hell that is. One of my businesses was one that would periodically have serious problems on short timeframe.
Jim: We had pushed a lot of authority down to the head of that business unit, as would be usual. But because of the nature of the business, there could be things that were beyond a reasonable amount of scope to push down to a 27-year-old guy. So I told him, “Chris, should there ever be a high …” I was a busy son of a bitch in those days. I mean, my time was scheduled at 15-minute blocks and it was just nuts. But anyway, I told him Chris, “If there’s a decision that is above your large but not infinite delegation of authority and you need me to make it right now, come and stand on my desk even if I’m in the middle of a meeting.”
Jim: He was a very athletic guy. A former wrestler, I think. Anyway, one time, he actually did that. Sure as shit, it was a mission critical fucking decision that had to be made in the next three hours or there would be large consequences. He appropriately used signaling to extend his own authority.
Daniel: Now, isn’t that interesting that you defined the protocol?
Jim: Exactly. Literally, it’s a protocol.
Daniel: It’s a protocol. That’s what you actually did and that’s a structured interaction. That’s a very, very high functioning kind of behavior. That signals, symbols, and signage. There’s a whole science around this called semiotics, Jim.
Jim: Peirce, right? Famous Peircean Theories of Semiotics.
Daniel: Exactly. A subset of this is bio semiotics. That is the signaling in signage and in symbolic aspects of biological systems. In the inviting leadership book, we introduce a further subset of semiotics, which we call leadership semiotics. That’s actually the story that you just told, was the story about leadership semiotics. Leaders can think of themselves as signaling devices in the social system. When we go down the highway driving, we use signage and symbols and signals to keep ourselves safe. We use the signs along the road to find our way and then we signal to the other vehicles that are moving what our intentions are. So we signal our intent through directional signaling. This is what leaders are doing. People are listening very carefully to what they say and what they do. Leadership semiotics is actually a very big deal.
Jim: Cool. I didn’t know that I was no semiotic motherfucker.
Daniel: Beautiful.
Jim: I love Peirce. Charles Peirce, probably America’s greatest philosopher, but he don’t write like a philosopher, you can actually read this stuff. There’s a wonderful collection of his writings on semiotics called Peirce on Signs. You can get it on Amazon for 20 bucks, something like that. Well, we’re about at our clock here. Daniel, this has been wonderful. I think this has been just the kind of conversation I was hoping to have. There’s still seven more topic points we didn’t get to but that’s all right. Keep the audience wanting more. That’s the whole idea.
Daniel: Okay, Jim, thanks a lot for having me on the show. I’m very honored to be on the show and to be included in such a list of people. I mean, the list of interviewees you have is just amazing. You know, listened to several of the episodes and they’ve been edifying and rich and nourishing. They have a high nutritional content.
Jim: This episode I hope will do the same. I’m going to turn it off …
Production services and audio editing by Jared Janes Consulting. Music by Tom Mahler at modernspacemusic.com.