Episode 18: Idea Development through Error Correction
- Links to this episode: Spotify / Apple Podcasts
Unofficial, reviewed transcript. It may still contain mistakes; check the podcast when wording matters.
Speakers are labeled by first name where identified. Unidentified-speaker labels may refer to different people. Bracketed question marks indicate uncertain wording.
Transcript
[00:00:10] Bruce: Welcome to the Theory of Anything podcast. We're here again. I've got Cameo and Bart with me. Hi guys, how's it going?
[00:00:18] Bart: Hi, Bruce.
[00:00:19] Unidentified speaker: Hello, Bruce, doing great.
[00:00:21] Bruce: All right. So we've been talking about trying to, well, mostly Radical Candor, but application of critical rationalism or Popper's theories to business. So Bart is, this is what he does for a living. He is a consultant that goes around helping people understand how to apply these sorts of theories to actual management practice. So today, in today's episode, we're going to have Bart talk about his own theories, which are somewhat different than Radical Candor’s, and how he goes about trying to apply critical rationalism, and some other ideas too. It's not just critical rationalism, but various ideas to how do you get to the best ideas in management, and how do you apply that into a business setting. So Bart, why don't you take it away?
[00:01:13] Bart: Okay, cool. Thank you, Bruce. Please interrupt me for questions or challenges. I'd be happy to have some interaction on this, of course. But before I start or by starting, I would like to introduce a central concept that we use often throughout our philosophy approach and methodology, and that is what we call an organization's problem-solving capacity. That is a definition for a capacity of an organization to solve problems in a particular way. It's a particular way in three senses. It's the combination of what I call the width of the portfolio of problems that an organization addresses. So you can have organizations that are capable of only addressing very narrow portfolio of problems and you can have organizations that can address, tackle and try to solve a very broad portfolio of problems. That's the first dimension of this problem-solving capacity.
[00:02:17] Bart: I call it the width of the portfolio of problems being addressed. The second one is the quality of the solutions that the organization comes up with. Then the third dimension of this problem-solving capacity is the degree of cooperation with which those solutions are developed. So problem-solving-
[00:02:40] Bruce: Can I ask a question about that? So on those three points, are you saying like the width of the portfolio? So that makes sense. How many projects can you do simultaneously? That's clearly a matter of capacity. But then it looks like you're saying maybe that there's a trade-off with quality. So you could do more projects with lower quality, or you could do fewer projects with higher quality. Is that like what the first two points are getting at?
[00:03:04] Bart: Yes. Yes. There can be a trade-off between both, and you cannot optimize all three of them at the same time with the same resources indefinitely. That's certainly so.
[00:03:17] Unidentified speaker: Okay.
[00:03:17] Bruce: So this is kind of what people call the project management triangle. But applied to problem-solving capacity. So you've got the bandwidth, you've got the quality, and then the degree of cooperation would be like the resources. So it's like a slightly different take on the project management triangle. Are you familiar with the project management triangle? Do you know what I'm talking about or?
[00:03:41] Bart: No, not particularly.
[00:03:44] Bruce: Cameo, you probably know what I'm talking about, right?
[00:03:47] Cameo: I do, but honestly, the further you get away from my core PMI body of knowledge around project management, that is a little less of a concept that is regularly talked about.
[00:04:04] Bruce: So you know what? I'm not even sure I like the concept that much, but let me just explain it quickly so you can understand. It's the idea that for project management, you've got duration, you've got cost, and you've got quality, which different people define quality in different ways. And so when you're doing a project, you could add people to the project and it's going to cost more. Or you could reduce people from the project and it will take longer. Or you could cut corners, have a buggier release, or have fewer features. Those are both forms of quality and that will reduce cost and duration. So you end up with a trade-off between the three sides of the project management triangle, but you can't get all three. You usually end up optimizing for two out of three.
[00:04:54] Bart: Yeah. So that's similar. That's similar maybe in the project management area. It's a little bit more focused on formal projects. For me, any problem can be a project and it doesn't need to be a formally resourced project with a dedicated team, dedicated steering committee. I extend the definition of problems to anything that can be improved, anything that needs to be understood in order to improve. It doesn't have to be a formal project with a formal resourcing and organization and steering committee and all those formal things. But apart from that little difference, I guess it's very similar in the sense that you're looking at the width, the quality, degree of cooperation. The third one, I don't know really whether that is similar because for me, cooperation is also the extent to which the solution is being developed by the whole team, and not by the dedicated resources or the dedicated functional responsibilities and with everybody else on the team just listening in or sitting in.
[00:06:04] Bart: So cooperation is also a very central aspect in the methodology, and you can have a very broad portfolio of problems. They may be relatively high in quality, but they can have a very low degree of cooperation, and that is a signal that future bound, there may be problems with the problem-solving capacity in the organization. If, for example, the whole project is always executed and done by only the project manager, but with very few contributions, very few ideas of other people on the team, then you may still deliver a project with a reasonable quality. But if the degree of cooperation is not sufficiently high, then you probably are not going to reiterate that a lot, in the future.
[00:07:00] Bruce: That makes sense.
[00:07:02] Bart: So, cooperation and the behavior of cooperation, that's why it's our third point, and it's equally as important as quality of solution and width of portfolio.
[00:07:12] Cameo: How do you build that amount up, that cooperation within the organization around the solutions? Maybe I'm jumping ahead in your slides, but that's really interesting to me. I'd love to know how you start to get an organization on that path.
[00:07:31] Bart: Yeah. And that's indeed a very relevant question. It's key. For us, cooperation is basically the enrichment of an idea of an individual by the team. And so, this is a content definition, if you want, of cooperation. Let me first explain other definitions of cooperation, and they all go into more personal aspects and more behavioral aspects, but they don't look at the solution and how a solution is being developed. So, classically, we talk about cooperation in the sense of, you know, having trust in each other, all aligning around a certain solution, believing that the solution will work, being nice and friendly and good for each other, all those kinds of personal aspects. Pactify cooperation has a link with the knowledge or the ideas or the solutions that are being developed. So, it's a process where anyone can have an idea to start, an idea that solves the problem at hand or that solves the problem that the team is being asked to solve.
[00:08:48] Bart: And then cooperation is basically the action or the process where the others on the team enhance, enrich the idea of the individual who came up with the first idea. In the Popperian epistemology terminology, we would call it error correction. And it's essentially that. So, we allow anybody on a team to have a single idea that is a start to solving a problem. Then that person becomes the idea owner. And the idea owner actively or proactively goes out in the team to seek for error correction on his or her idea. Improvements, additions to the idea in order to make the idea better, make sure that the idea solves the problem in a more optimum way. And that process is cooperation. So cooperation is actively building a solution that is better than if you were only just dividing the work and cutting up the entire solution. Everybody does its part.
[00:09:53] Bart: And at the end, we're throwing everything together. And that is our final solution. But more often than not, we often realize that if we throw everything together, that there are inconsistencies or that people have done things twice or things that just don't match with each other, and in Pactify, it's the other way around. Anyone can start with an idea on the team. So it doesn't depend on your function title, whether you can have an idea about a specific problem or not. But once there is an idea from anyone on the team, that idea should be actively error corrected for, enhanced, enriched by the other people on the team. And also in a transparent way. So we make the initial idea transparent. We make transparent how people contribute to improving the idea. So we also make transparent the evolution of the idea up until its final implementation and realization.
[00:10:51] Bart: And to get to that point, cooperation is really the strengthening, the process of strengthening a single idea of a single individual by contributions of the rest of the people on the team. And so the knowledge is growing. The solution is changing. And that is crucial in Pactify. Whereas in other more different definitions of cooperation, we often regard the solution as fixed. That's what we have to live with. And then we try to get along with each other and build confidence and try to develop trust. But the fundamental difference with Pactify is that we believe that trust and confidence in each other and team spirit is built by shaping the solution, by improving a solution, by error-correcting a solution in a process that is taking place in a team around the problem.
[00:11:50] Cameo: You talked about increasing transparency. How do you go about doing that?
[00:11:55] Bart: Yeah, so we very concretely, we have a software to do that, a very specific software where obviously the problem that is being given to a team is made transparent. Everybody is on the single platform, on the software. Any idea owner who can stand up in the team and say, I have an idea, I want to work out this idea, makes his or her idea also transparent. And then there is again a transparency on the evolution of that idea. So people will add to the idea, people will suggest other components of the idea. Basically the idea is always the collection of what is going to cause the implementation or cause the problem to be solved. And so you're making plans, approaches, while executing you're going through stages of progress. And all those things are made transparent, including who basically improved the idea or who added to the idea. And so it is in essence, it's like any project management software, but there is an additional piece of transparency on who had the idea in the first place and what the evolution of the idea was and by whom, basically.
[00:13:22] Cameo: So how do you deal with conflict? If you have this problem to be addressed and you have two people who have very different ideas of how it should be addressed, how does that manifest?
[00:13:37] Bart: So the concept of the idea owner that I introduced is basically also a choice to go for correcting one idea and improving it and ending up with probably and hopefully a better one. So what we typically don't do is let two ideas fight, because when you let two confronting, conflicting ideas fight with each other, probably the camp of the idea that's going to win is going to have somebody who has the power to decide. And I'm not that kind of a believer in letting two ideas fight. We introduce the concept of an idea owner to deliberately select one idea whenever somebody stands up. It's the first idea, the first stab, the first guess. But then the error correction or the improvement of the idea can be very interactive, can be very critical, can be very intense. And the initial idea always ends up in another place through this criticism and through this interaction.
[00:14:42] Bart: But what we kind of do a little bit structurally to avoid chaos is that we select one idea to work out, one idea owner takes his or her idea and actively seeks out criticism in order to improve the idea. But we don't set up two camps with two conflicting ideas and let them fight for whomever wins that fight. Because we believe that if that fight is fought and won, it's probably not the best idea that has won. It's probably the idea with somebody who has authority, or it could be that the other camp just gave up because they're bored and tired of fighting. And that's where we intervene also as consultants, but consultants not in the classical sense, but we have a mandate to organize the process in that way, and so we can protect an idea owner in his or her quest for criticism and avoid that a conflicting idea enters the debate. You can enter your conflicts through the form of criticizing the idea that is being criticized, but not just enter another one and have a head-on fight of ideas.
[00:16:04] Bart: Those often don't lead to the best ideas in the end.
[00:16:10] Bruce: What if there's like difference of opinion on how to improve a single idea?
[00:16:15] Bart: Yeah, there we, if that's the case, we have a couple of options, but you always have an escalation level. You can always go ask the hierarchy above to select [between] two ideas. If the team really says, you know, we have two theories, we can't decide which one of the two is the right one, then we can escalate and we can ask somebody higher up in the organization to decide. It's not the preferred option because I try to avoid escalation as long as possible. But that is one way of resolving it. Another one is to always give a little bit priority to the idea owner. I mean, in some way, he should get a little bit of a little more rights in the end, if there's really a conflict, you know, to pursue the original idea or his or her preference. We don't want to push that because that would be justificationism of the knowledge of the idea owner. But what you see more often than not is that once this process is up and running and the idea owner really takes care of his or her ideas and the other people on the team really focus on this one theory, this one idea and how to improve it, that because this focuses on the improvement of one theory, you typically end up with a better theory.
[00:17:53] Bart: And most of the problems of conflicts always arise when you have two or three or more theories that people just take a stance behind, defend themselves behind those different theories and typically end up in a kind of stalemate position or a depolarization [wording uncertain in this context]. And the fact that anybody on the team can be an idea owner also helps to avoid these kinds of conflicts. And when there is a minimum of cooperation already, the team will often refrain from conflict because we can have other ideas through other idea owners that can evolve as well. There's never a shortage of ideas to be evolved. And it's more often than not that you get into conflicts when you assume that knowledge is like zero sum, that you can't grow knowledge and grow yourself out of conflict. Most conflicts arise because we assume that we cannot solve it because we can't create better ideas or we can't error correct anymore.
[00:19:05] Bruce: So you actually asked me a question about this on my blog, I haven't had a chance to go comment on it, about the difference between having conflicting ideas that are in competition versus trying to improve a single idea. And I can really see why in a management perspective, it would make sense to try to avoid the extra conflict and instead try to bake a single idea and see how good we can get this idea and use error correction to continually improve the idea. It is interesting to note, though, that this does strike me as different than Popper's epistemology as applied to science, where you are usually maybe even talking about... I don't even want to say usually, because I feel like science is not what people usually say it is. But we often concentrate on the concept of conflicting ideas in science, where we have competing theories, how do we come up with a critical test between these two theories, so that we can refute one in favor of the other.
[00:20:15] Bruce: Do you see this as a difference just because of context, or how would you maybe think about that differently from the way we apply Popper's epistemology to science versus the way we are suggesting to apply it to business?
[00:20:31] Bart: Yeah, okay, but now I understand your question a little bit better, but the point is that it's not different at all. The idea owner is basically the one responsible for seeking criticism and organizing criticism. So the idea in itself evolves. If somebody on the team has an improvement or has found an error and through a test, through doing something, through putting the other or the competing ideas into reality and seeing what the result or the progress is from it, the team decides for one or the other outcome. And they can do it either by debate and discussion or it can be effectively pursuing one idea and then evaluating whether or not it has led to the process or the progress that was intended. And so the idea under an idea owner is very much evolving, is very much being error corrected by alternative theories that survive criticism better because we've tested them, because we've tried them, or because we have just really better arguments for it.
[00:21:40] Bart: So it's not the case that the idea owner gets away with his or her initial idea at all costs. That would be justificationism.
[00:21:48] Bruce: Yeah, no, I can see that.
[00:21:50] Bart: No, no, no, it's really, and that's a skill. That's a skill that is not often practiced, but that is key for cooperation, is that even if you have an idea, you have to actively go seek out to improve it and actively seek out criticism, seek out for alternative theories, and then decide between which one of the two is the better one to pursue going forward. So yeah, maybe I haven't been that clear, but it's definitely not the case that an idea owner gets away with his idea. We want to improve and strengthen the skill of an idea owner by helping him to actively go out, because we believe that if his or her idea is enriched and error corrected, then not only the idea will be better in the end and the execution and the implementation and all of those things, but it also builds cooperation, because you get the sense that together you have improved the idea.
[00:22:51] Bart: The idea owner is still there with the basic idea, with the start of it, the ignition, but collectively and together, you have managed to improve the idea through the process. And so that's again linked to our definition of cooperation, is that cooperation happens in and through the evolution of ideas by, you know, improving them together and error correcting them together.
[00:23:18] Bruce: So yeah, I can see what you're saying. So if I can use an example from philosophy and science, you go way back in time and there's this theory of atoms that is an ancient, ancient theory. And the original theory of atoms is nothing like the theory of atoms today. The original theory of atoms was this idea of these indivisible little parts, that's the word atom, atomic, and that you can't divide them. And then the ones that prickle on your tongue, those are the ones that are sharp. They're little sharp atoms. I mean, the original theory was something that came out of ancient philosophy and you can tell. But there's actually a thread of improvements on that initial, what we would kind of laugh at theory, until finally you end up with modern atoms, modern science, modern chemistry, which is good science. And it was really just a matter of centuries of improvements of an original idea until finally the original idea is in some ways lost.
[00:24:23] Bruce: It's almost hard to recognize where we're at today compared to where we started, even though that was the impetus for the entire line of thought that took place that got us to modern science.
[00:24:37] Bart: Yeah, and that's really good because that's a sign of knowledge growth, which is also the intention or the aim in Pactify. Knowledge is not a zero-sum game. If we consider it zero-sum, then we're going to fight much more and we're going to be much more in conflict than if we consider that any idea can improve and should be improved and preferably should be improved together, in cooperation.
[00:25:04] Bruce: Do you know, man, I shouldn't even go on this tangent, but I keep wondering if this could be applied to politics in some way. I mean, you really don't see the idea of, let's take an idea on how to solve a problem and let's have everybody work together to try to improve it. Now, I do think that's what actually ends up happening over time, but everything's treated like a political football, right? I mean, everything's treated like we got to defeat this idea or we got to make this is the one right idea. And there doesn't seem to be at least a lot of emotional attempt to take an idea from one side and improve it to where more and more people like it maybe even because it's solving problems in a way that doesn't create new problems for other people.
[00:25:54] Cameo: I think it ends up happening by conflict, which is almost like the anti of what Bart's talking about here, where you get ideas being refined, but only because they're being treated like football.
[00:26:13] Bart: You would hope that the party who is in power internally goes about business this way and improves their suggested policies in this way. But it's another thing to say that the party in power versus the opposition or the other party will ever get to this. Ideally, it would be great. But I guess for now, this idea evolution together with cooperation, hopefully it happens in the parties that have the power or among different parties that share the power and therefore improve the policies or the planned policies or the evaluation of the effect of policies and all those things. So hopefully it happens within all the entities that have the power. But I guess it's another thing to require it from the broader constellation of all political parties that basically have to come to good policies also somewhat together. That's maybe one step too far.
[00:27:26] Bruce: Well, I think this does go on. Like when something comes to Congress, they have to take each law and they have to adapt it based on what the other party thinks also to get the necessary votes. But kind of the famous case is like pork, right? Where to get it passed, we get a law enforcement law passed, we add something about building bridges that's going to satisfy some senators, constituents or something. In which case, it seems like we're definitely not talking about improvements of ideas. Maybe ideas are improved in Congress way more than we hear. Like if things are really going well, we probably don't hear about it. It's probably only the cases where it went off the rails that it makes it into the news media and that we hear about it. There's probably a lot more. I mean, the system works fairly well. Clearly, there is a Popperian epistemology improvement of ideas that is going on with politics.
[00:28:21] Bruce: But it's hard to see it as a layman, right?
[00:28:28] Bart: Sometimes you need a facilitator. That's our role in business. But the role doesn't exist in politics. But the facilitation of this is important. Because, as I said before, it's very hard to improve an idea without avoiding chaos and conflict with multiple other ideas at any level. If it's already clear at a higher level, then the conflict will come at a lower level of problem solving. But at any of those levels, it requires a little bit of, let's say, structure to avoid that anybody comes with any conflicting theory at any time and doesn't respect this kind of principle of error correction, focus on improving one idea, really focusing on the question, why are we going to do it this way and not that way? So competing or asking the question why this theory of progress is better than the other one and really adopt that kind of thinking and be rational about it as opposed to taking any opportunity to counter any dynamic with any particular conflicting idea.
[00:29:48] Bart: And that is something where in the beginning you have to intervene a lot. You have to, as a facilitator, you don't bring ideas, you don't bring the solution, but you help the team to adopt this kind of reasoning. And sometimes you have to protect the idea owner from being attacked with too many too personal comments or conflicting theories that are not brought under the form of a criticism to the theory or the idea that we were discussing. And facilitation is key in that because this doesn't self-organize this way of thinking. Eventually, they get better and better in it. And they get the concept that whenever there's a new problem, they go into this kind of, yeah, we call it rumination. This is the phase where we're brainstorming and ideas are exchanged up until the moment that one idea and one idea owner stands up. And then we go into this idea improvement cycle.
[00:30:49] Bart: So there's a couple of things that look like a process and that need to be learned. And to learn and respect that, there is a facilitator in the beginning, that his role can gradually fade out. But in the beginning, to avoid chaos, to avoid polarization too quickly, to avoid non-argumentation or bad criticism, you need somebody in between to get this way of thinking up and running. Without intervening on the content side. So I used to be a classical consultant, giving all the answers. Now I'm a facilitator asking all the questions. But through those questions, you can start up this process and people get the hang of it. They know when they're an idea owner what to do, and they know when they are on the team, how to give constructive criticism, propose alternatives and respect in that way the error correction process.
[00:31:53] Cameo: I'd love to know a little bit more how you introduce this to a new team and how you do that facilitation process, because this is so much different than what a management consultant might normally do.
[00:32:07] Bart: Yeah, one of the key aspects is what we call staying in the question. That means basically asking the right questions for the... So in order to trigger the problem solving on the other side, on the side of the people on the team, and indeed my classical role for 15 years was giving the answers. Any problem that came or any new problem situation, we immediately jumped into our pens and started writing slides with answers, answers, really rationally and well structured. But now I'm doing the reverse of that. So I'm asking only questions in a team, and in the beginning I explained a little bit some basic concepts of what is an idea owner and what should an idea owner do, and what is good criticism. A little bit the things we discussed in the other episode on how to make an idea better without getting personal or getting off topic, or really annoying somebody who is having an idea, purposefully annoying him.
[00:33:25] Bart: And you can achieve that learning or that gradual adoption of those principles by asking questions. You don't have to reiterate theory or give models, certainly not give answers, but really ask questions. Ask questions not only for the idea owner to sharpen his or her idea, but also to try to seek for good criticism in the team. And all of those things come when you ask questions, not when you give answers, because when you give your own answers, you get opposition, you get either they didn't understand it or they give you hard time or they are against what you're saying. But asking a question really opens up idea generation, knowledge creation at the side of the person you're asking the question to. And that's really the key.
[00:34:22] Bruce: When we talk about the degree of cooperation, which is kind of what led to this aside that we're discussing, one of the things that Bart keeps emphasizing is ownership, right? That by working on an idea together and improving a single idea, that we get people buying into this idea and it becomes their idea and they own it. So, Cameo, I don't know if you remember this, but you and I had had a conversation about the fact that in my experience, a really good project manager can ruin your project. And it's a tough situation because a competent project manager that really knows their PMP, they will almost invariably cause other people to stop thinking and to stop owning the project.
[00:35:09] Cameo: Yes, I remember that conversation.
[00:35:11] Bruce: And it's because they do a really good job with it. But then that's exactly what you don't want, is you don't want the team not owning the project and everyone goes to the project manager. The team says, I'm going to be late on this. And they know the project manager is going to come up with some way to deal with that problem, instead of them dealing with the problem. So I can see a lot of this here where I think traditional project management is exactly the same problem that Bart is describing, where they come in with answers and people love it. People love traditional project managers. Management loves traditional project managers. Maybe don't have as good a reputation for team members necessarily, or maybe for the customer. But the person who's the one that's over the project manager, they love the fact that there's some competent person who's making sure that certain things happen and driving the team.
[00:36:10] Bruce: They really like that. And yet it's actually an unhealthy thing in lots and lots of different cases. It may be a step up compared to complete chaos, but it's a step down compared to the ideals of a self-managed team where the team owns their own problems and their own solutions.
[00:36:29] Bart: I prefer not to have that role on the team even. Why would you have to have the role if you have good people with good knowledge of various domains that are all related to the problem? Why would you want to designate one of those as being the project manager? I prefer that anyone on that team can become an idea owner on any part of the problem that needs to be solved. And the more idea owners, the better, because the idea ownership then is being distributed. And everybody helps everybody else on their ideas and on the evolution and the improvement of the ideas. But I do not necessarily need someone of that team to be the designated formal project manager as a role, because then he will suck all of the attention and all of the final communication and the reporting and the justification of where things stand, whereas all of those things should be distributed much more.
[00:37:35] Cameo: I love that. I like that comparison too, Bruce, because that's long been something you and I have kind of had this idea around. Well, you and I have just had this conversation, I think, even more than once. And how do you ultimately [unclear] project management, even in the world where Agile is esteemed, there is still generally from the executive level the desire to have somebody like a traditional project manager who is, quote-unquote, responsible for the outcomes. And it's an interesting question of how do you, short of having Bart come over and run training with all of us, how do you transition into that new mindset of not having a really good person who is responsible for the team's outcomes?
[00:38:30] Bruce: Yeah, this has been great asides and I think these are things that Cameo and I both wanted to ask Bart for a while.
[00:38:39] Bart: Yeah, so at the end, I'm writing that this concept of problem-solving capacity is a bit of an abstract concept. You cannot really measure it. You cannot have any quantitative measure for it. At least I wouldn’t know how to do it if you look at the collectivity of an organization because there are so many people, so many problems. And to try to measure the problem-solving capacity would be not a very smart thing to aspire to. But the concept is important for something else. It leads you into our approach and into all of those aspects of idea evolution and idea ownership. And I conjecture or we conjecture that there is finally no better concept to try to get right for the CEO than this problem-solving capacity. I think that is what he or she should lie awake about. Because if you get that right, if you can address a maximum of problems, if you have high-quality solutions, and on top of that, they are developed with cooperation, I don't think you have to aspire anything else.
[00:39:53] Bart: And so my conjecture is that for sustainable performance, as well as engagement of people, let's say the two most fundamental, holy grail type of outcomes that an organization needs to achieve, that it's the problem-solving capacity that should be increased. And so that's why I think it's important and it leads us into our concrete approach for problem-solving. So I conjecture that if you solve problems and you solve them in cooperation with autonomy of people in the team, regardless of their functional responsibility, then all that taken together is both going or is going to simultaneously drive performance as well as engagement. And if there's anything that a CEO should lie awake about at night, then it's those two things. It is performance in the end, productivity, whatever you want to measure it by, and engagement of people. And I conjecture that these two things simultaneously increase when the problem-solving capacity as defined above is increasing.
[00:41:10] Bruce: By the way, I really like that, the classical idea of who should do what. That really is how we typically think of managing organizations.
[00:41:19] Unidentified speaker: That's an interesting point.
[00:41:22] Bart: Yeah. The who should do what is in our approach much less important than how are problems solved and how are people contributing to those solutions, as opposed to are we sure that the right person has said the right thing or has contributed the right thing according to his or her formal authority or responsibility. But it's true, as Cameo said, it is a change. In the beginning, it's not a beauty contest. And that's also why you need facilitation. And especially when the culture has been very different up to the moment you want to start to change the culture. And also in the beginning, you better do this not throughout the whole organization on any problem with everybody altogether immediately. So you have to pick four interesting problems and select relevant teams to try to do this and to jumpstart this. And then later on you can extend to other problems with other teams and you can grow this.
[00:42:32] Bart: We call this our approach being sizable and scalable. And so this is an evolutionary approach. You can start with four people on one problem tomorrow and in three or six months you can do this with ten teams. And you better do it this way because you're going to learn in the beginning a lot of how this works and how this can be steered and whether you're going too fast or too slow or whether people really find it still very terrifying to be able to give ideas. In some company cultures, you spend three months convincing teams that it's okay to have an idea even if that piece of idea doesn't fall under your formal responsibility. And so that may take three months even to get to the first idea with the first idea owner. But then you can pick up speed and you can evolve things gradually. But in the beginning, it's like any change and especially cultural change.
[00:43:40] Bart: It's a bit weird. It's a bit strange. And you cannot force things. You cannot try to do it in a revolutionary sense. I don't believe in that. I believe in an evolutionary sense. And so that's why we typically start small. We start with a couple of teams or maybe even only one team, but we get the team going and eventually they don't let go of this way of working. And it's being replicated in other teams and on other problems. But for sure, the beginning is, like any major change, interesting.
[00:44:21] Bruce: That's awesome. That makes sense.
[00:44:23] Bart: Knowledge ideally starts from a good problem to solve. So we try to avoid getting knowledge to solve problems in companies from authorities or from reapplying existing knowledge or from observations that we generalize into knowledge and that we deem applicable for any future problem. Knowledge needs to grow. It's not a zero sum game, as I said. So for any problem you're encountering next week on Monday, there is no knowledge in any kind of drawer that we just have to open and just throw at the problem and assume that it will be solved. And why would we do it is even the more relevant question. If people can generate ideas and if people can solve problems, why would we revert to old knowledge, existing knowledge, the kind of attitude, yeah, we know that problem, we've solved that six months ago, here is the manual, please execute. Those kinds of things I'm a little bit wary of and we try to avoid it.
[00:45:33] Bart: We always try to start from a good problem, something that doesn't work, something that can be improved. It can be something on the customer side, it can be something on the production side, on the supply side, on any combination of those things. And you just gather the right people together with the knowledge and you give them the mandate to solve a problem. And you describe the problem, you can even describe your expectations, so it doesn't need to be entirely open or entirely free what the solution will be. But the point is that you give a problem with a minimum of degrees of freedom for the solution, so that people can use their autonomy to come up with good solutions. And the worst thing is that you already give the answer, because that's an argument of knowledge coming from authority. And that's the assumption that the problem is already solved before you start tackling it.
[00:46:36] Bart: And that's something that I'm not keen on doing, and that's not at all in our approach and methodology. So we mandate problems and we refrain from giving too many answers and then simply saying, please execute the answer. That's something that we don't encourage or incorporate, at least in our methodology. You wanted to say?
[00:47:03] Bruce: Yeah, I was going to say, I do think there is such a thing as an off-the-shelf solution, but I suspect that you would have a hard time perceiving those as problems to begin with. So the solution to how do you efficiently type stuff is you get Microsoft Word, right? It's an off-the-shelf piece of software. But probably most people don't even perceive that as a business problem anymore, precisely because there is an off-the-shelf solution, so you don't perceive it as a problem. You just go buy Microsoft Word. I think that in general, when the problems that you're working on as an organization, they must almost by definition be unique problems that the world has never seen before, that that organization must solve for itself, and that there won't be a pre-built solution for it. Even if there is a supposed pre-built solution, it will have to be adapted in some way, which is the same as problem solving.
[00:48:04] Bart: Exactly. Exactly. Exactly. That's key. Because again, an idea owner, he can perfectly in the first version of his idea, he can say, let's take this known methodology, for example, lean or agile or yeah, software, a particular software that can be part of his or her first idea, but it will always be with a specific adaption to the context of the new problem. And so this adaption is already knowledge creation. It's already something extra. And my conjecture also is that I think that every problem in an organization is somewhat new and always needs somewhat of an adaption. And it's fine to reapply as part of your idea some existing knowledge, because there is a procedure for something or a process or a tool or a system that helps you in particular parts of solving the problem. And you can reapply it, you can recycle it. But the adaptation to the specific problem is always a piece that is some extra knowledge that the idea owner will have to create and will probably also always make the difference in the end.
[00:49:26] Unidentified speaker: Yeah.
[00:49:27] Bruce: Cameo, I'm sure you've done numerous quote, off-the-shelf projects before. Can you recall any of them being anything but a giant customized project?
[00:49:37] Cameo: Yeah, I think as much as we like the concept of consistency of problems and being able to utilize all of the experience from the past problem to be able to solve the new problem, they are unique. But I think your other slide, Bart, also talked about the width of knowledge. And I think while you can't solve a new problem with the old knowledge, like you talk about here, it does kind of stimulate the ability to have more starting points to kind of jump off from.
[00:50:21] Bruce: We're never really trying to reinvent the wheel from scratch. We're always starting with our existing knowledge in the background. And that is something Karl Popper always talked about. And that was one of the reasons why he was so strongly in favor of evolutionary politics, where we improve things a little at a time, rather than trying to go for a utopia, was precisely because there is so much knowledge in the existing background knowledge. Sometimes we don't even realize what it is, right? It's stuff that has survived because it works, and we may not even have an explanation as to why it works. Our institutions and our traditions and things like that. So you're always starting with existing knowledge. There's always a giant injection of existing knowledge into all problems that you solve. But I think the point that Bart's really getting at here is there's really no such thing as a pure off-the-shelf solution.
[00:51:22] Bruce: If there was a pure off-the-shelf solution, you would probably not even perceive it as a problem to begin with. So if you're talking about problems for your organization, it is almost by definition something unique to you that will have to be adapted.
[00:51:38] Bart: And then the interesting question is, because I fully agree, but then the interesting question is adapting existing knowledge, or if you prefer our language, error-correcting existing knowledge to be suited to the problem, that's obviously then the point. And there can be different qualities of error correction, because some teams, they can go on error-correcting endlessly and not realize anything and only consume time and not have any sense of progress. So error correction is crucial and vital, and it's also an attribute of cooperation, as we discussed. But the quality of error correction also needs to improve. You basically want an organization that cannot only error-correct, but can error-correct qualitatively and within a certain amount of resources, because also you don't have endless amounts of time and endless amounts of resources to ever adapt and ever improve an idea.
[00:52:38] Bart: So there is a balance between the amount of error correction that a team can deliver in a certain amount of time versus a minimum level of adaption or adaptation of that initial knowledge that needs to be incorporated. And so good teams are teams that are very good in error-correcting initial ideas within a given time frame and a given resource spent.
[00:53:10] Bruce: So in software, we actually have a term called analysis paralysis, which is the idea that you can be error-correcting your ideas basically forever, right, and never get anything actually done. One of the things that came out of the agile software movement that's now getting adapted into outside of software into agile management and things like that, is the idea of getting some, the idea of a sprint, the idea of getting something out, getting something into production, getting it into the real world where you start to gain value from it rather than continually trying to improve it forever, where you get no value for it. And it's entirely possible that once it meets the real world, you'll find out you've been working on the wrong problem the whole time.
[00:54:01] Bart: Yeah. And sprints are a nice example of better error correction. But the point that is sometimes missing in sprints is that it's not because you're doing stuff with shorter iterations that you're doing optimum error correction. You also need to develop always an explanation for why you're changing the sprint and why you're withholding particular features in the sprint and why you didn't withhold other ones or you're changing them. So it's good in the sense that it's frequent feedback and short iterations. But you also need an explanation for why you go from the one sprint to the other one and then from the other to the next one. And when that explanation improves, then you are on to one of the better levels of error correction. But it's never a guarantee.
[00:54:56] Bruce: They actually have something called sprint themes, which is the idea that you shouldn't just be splitting up your work into two-week periods or something. That's not that useful. But instead, you actually have something you're trying to deliver or accomplish with that sprint based on some idea. I don't think I've ever heard it called an explanation like you just said, but that would make sense. Agile didn't come out of Popperian epistemology. It just happens to match up with it nicely. So they have their own vocabulary for things. But that's really what it is. There's an explanation for what is it we're doing. Why is it we're doing this sprint? What's that explanation? That's really what a sprint theme is.
[00:55:40] Cameo: Although I don't know how commonly sprint themes are used. And even in a lot of really common agile kind of groups, it's not something that you hear talked about a whole lot. It would be a good trick interview question. And for somebody who claimed to be super agile, to ask them to define what themes are and how they drive outcomes.
[00:56:09] Bruce: Yeah, you're right. You know what? When we talk about agile, of course it's always somewhat idealized. It's rare you get, I mean, the vast majority of implementations of agile are kind of 50% agile and 50% traditional software management. We've even got statistics that 70% of agile implementations are hybrids. I got that from one of my books that I had to study for one of my certifications for. But I think that you're right, that the idea of a sprint theme is something that gets introduced and then it kind of falls by the wayside and people don't end up using it. And I think what I'm hearing Bart say is, you're giving up the explanation when you do that. You're giving up the chance to have a good explanation for why you are doing these changes and getting people organized around that explanation. And I can see that.
[00:57:06] Bart: Yes. Ideally, after sprint or at the beginning of a new one, you should always ask the question, why are we putting this feature in the sprint and not this one? And the answer to that question, why this and not the other, that's your growing explanation. And that one needs to improve, sprint after sprint. And that is where the high quality error correction ultimately emerges from. But not necessarily only because you're doing, you know, things in short iterations.
[00:57:36] Cameo: And speaking specifically of sprints, one place I can see within Agile that's in conflict with a lot of what you're talking about here, is this concept of the product owner being the owner of what goes in and what goes out. Because generally, you know, in Agile, even if you're doing error correction on how the team's working together in the form of good retrospectives and trying to continually learn from the team's performance how to make the team's performance better, the team almost never has any actual say into the features that should be put in or pulled out. Other than from a technical perspective, a developer might be able to say, Oh, we need to do X, Y, Z to support this. And since it's not feature specific, the product owner may not be able to say, Yes, we're putting that in or pulling it out. But there is this very strong concept of having this one person who's responsible for why and what features get put into future sprints or pulled out of sprints.
[00:58:50] Bart: Yeah. And I haven't tried it before, but I would definitely dare to do it, to do Pactify in an agile project. And the only way I would change it is that I would allow anybody to become the idea owner of the next sprint or being the product owner of the next sprint. And why would I dare that? That is because the formal product owner is still on the team and still has a chance to criticize a certain proposition for a next sprint by an idea owner who can come from anyone on the team. So I'm relatively confident that it could work and gradually grow this idea of rotating the product ownership and having each time someone as an idea owner for the next sprint and to compose the next sprint and to have a good explanation for why the next sprint is composed out of those features and not other ones. And have that idea basically rotate or have that product ownership be distributed among the team.
[00:59:56] Bart: The product owner is still on the team, so he doesn't in theory lose all of his powers or all of his rights. He can criticize any idea for a sprint. And if the team really cooperates, then the effect of his criticism will be as powerful as if it was in his classical role or even more powerful.
[01:00:18] Cameo: Yeah, that's interesting. And we've seen a lot of power and collaboration come from having the Scrum Master role be treated that way, where each sprint a different person is responsible for being the Scrum Master. Really, that's fascinating. I don't want to get us too sideways here, but that's an interesting idea.
[01:00:42] Bart: Yeah, and the one thing I would want to say is the other difference with Pactify is we would ask who has a good idea for the next sprint. So we wouldn't force somebody to become involuntarily the product owner or the Scrum Master, but we would ask the question who has a good idea for the next sprint composition and why. And then the first one, with a good, well-documented idea and explanation for how that next sprint should look like, can perfectly become the idea owner or the temporary product owner for the next sprint, including some rounds of criticism from everybody on the team, but then finally closed off and agreed upon as the next sprint.
[01:01:27] Cameo: Very, very interesting.
[01:01:29] Bruce: All right, we're coming up, we're past an hour, I think. So we probably need to wrap it up for this session and we can continue this next time.
[01:01:39] Unidentified speaker: All right.
[01:01:40] Bruce: Well, thank you guys. And thank you, everyone.
[01:01:44] Cameo: Fascinating.
[01:01:45] Unidentified speaker: Thank you.
[01:01:50] Bruce: The Theory of Anything podcast could use your help. We have a small but loyal audience and we'd like to get the word out about the podcast to others so others can enjoy it as well. To the best of our knowledge, we're the only podcast that covers all four strands of David Deutsch's philosophy as well as other interesting subjects. If you're enjoying this podcast, please give us a 5-Star rating on Apple podcasts. This can usually be done right inside your podcast player. Or you can Google The Theory of Anything podcast Apple or something like that. Some players have their own rating system and giving us a 5-Star rating on any rating system would be helpful. If you enjoy a particular episode, please consider tweeting about us or linking to us on Facebook or other social media to help get the word out. If you are interested in financially supporting the podcast, we have two ways to do that.
[01:02:35] Bruce: The first is via our podcast host site, Anchor. Just go to anchor.fm slash four dash strands, F-O-U-R dash S-T-R-A-N-D-S. There's a support button available that allows you to do reoccurring donations. If you want to make a one-time donation, go to our blog, which is fourstrands.org. There is a donation button there that uses PayPal. Thank you.