Transcription
Maybe I can explain to the audience what double loop learning is rather than single loop learning. Single loop learning is when you, let's say, let's say you want to speed up your process of getting ready in the morning. And so you, you get up out of bed and you go and brush your teeth and then you go down the stairs and you prepare yourself breakfast and you eat breakfast and then you go upstairs and you get dressed and you're, you're going back downstairs to make your lunch, etc. And single loop learning would be, uh, focusing on the single parts of that and being like, "Okay, I want to speed up the process." So I'm going to use a different type of toothbrush which is faster when I'm brushing my teeth so that I can save a little bit of time. So the whole process is not looked at, but single parts of the process.
Double loop learning is taking a look at the entire process and thinking, "Maybe there's something not so fast in, or maybe, maybe I'm wasting time, or I'm not doing it in the most effective way. Let's change the process." So instead of going up and down the stairs, how about we do everything that we need up the stairs first? And then when we're finished getting dressed and everything, then we go down the stairs. Maybe we have our toothbrush next to the sink downstairs so that when we eat our breakfast, we can brush our teeth immediately and then go out the door. And then you actually make big improvements. So that's is the difference between single loop learning and double loop learning for teams. So I'll go back to the question. How do you think about supporting double loop learning where teams don't just improve actions, specific actions and what they're doing in the teams, but also question underlying assumptions of, let's say, the entire process?
>> Yeah, again, good question. Two things. First part, this is zoom in, zoom out. Are you hyper-optimizing a tiny bit of the process that doesn't really, like, not much savings? Zoom out to see the whole picture.
>> Yes, exactly. So, and this is very important because teams, as founders, they shift so many things in their head, like what we're building, who, what's the value stream, who are we connected to, and so on. So, they need the ability to zoom in and out, literally. That's why we give them, uh, tools like catalog so they could actually visualize different parts of their processes or the product that they're building and discuss that. Then there is the question of who has the ability to review those things because if, uh, your processes and metrics are hidden in the office of the CTO, then only the CTO can review them and contribute to what's actually happening. If you openly share data with your teams, your team members are super smart. You're giving them the ability to engage their minds and question like, "Why are we still doing that? This is no longer, like, we, we like this is no longer a priority. We should stop doing that and stop wasting our time." Because a lot of metrics have limited use. For example, if you're optimizing for deployment time or cycle time, something like this. Once you reach a certain point or get an answer, you may stop doing that. Stop, stop wasting your time and focus on, uh, other priorities.
>> Like the 80% instead of trying to get 100% because that last 20% takes a lot of time.
>> Yes. Yes.