Co-Intelligence: Why Learning Together Beats Knowing Together
The Meridian Point Podcast
Guest: Diana Larsen
---
KUMAR: Hi, everyone. Kumar Dattatreyan here with The Meridian Point. Thank you for joining us. Today we are joined by Diana Larsen. She's one of the most influential voices in the Agile world, and she'll be the first to tell you that Agile didn't invent itself. With over thirty years working at the intersection of team improvement, learning, and leadership, Diana is a Roaming Leadership Agility Advisor. I like the roaming part. I'd like to do a little bit more roaming myself. She's also the co-author of six pivotal books, including Agile Retrospectives: A Practical Guide for Catalyzing Team Learning and Improvement. That was actually one of the first books I read on my agility journey, back around 2008 or 2009. A wonderful book. I still refer to it all the time. She also co-authored Liftoff: Start and Sustain Successful Agile Teams, and her most recent book, co-authored with Tricia Broderick, Lead Without Blame: Building Resilient Learning Teams. You can see a theme running through her work. It's about the team. She co-originated the Agile Fluency Model with James Shore and serves as a keynote speaker, consultant, and mentor to leaders navigating complex, rapidly changing environments. She's based in Portland, Oregon. Please help me welcome Diana Larsen to the show. Thank you so much for coming on, Diana.
DIANA: Thank you for inviting me, Kumar. I'm looking forward to this.
KUMAR: Me too. So, Diana, in our prep call you made an observation that I find both funny and profound: the software world sometimes acts like it invented agile thinking from scratch. But you came to Agile from organizational design, change management, and high-tech manufacturing. What did you already know, before you ever heard the word "agile," that you later recognized in the manifesto?
DIANA: Well, I was actually pre-manifesto. My entry into what became the Agile world was through Extreme Programming. I was very attracted to its values, and very attracted to the shift toward team-based work, because I had been helping organizations make that shift for about ten years at that point. I was coming from an organizational development world called socio-technical systems design, which was very much about moving toward team-based work and how people who collaborate get things done better. So when I met the folks who ultimately became Agile Manifesto signers, most of whom I met through the Extreme Programming community, it made so much sense to me. I thought, this is a really good team-based design for this kind of work, for software work.
I had already developed ideas around what became retrospectives, and ideas around what became Liftoff, because we had been doing those things with teams for some time. I had always really enjoyed working in the software world and had a lot of colleagues there. The fact that I could take what I already knew from my background and bring it into that community was genuinely exciting to me. My dad was a systems analyst. I was a kid who got to play with flowchart templates and had taken a couple of programming courses on a mainframe. So it felt like a really good match for both my professional background and my interests.
KUMAR: That's amazing. It's funny, in our conversation I shared my own origin story. I started in restaurants, and there are a lot of things I learned running a restaurant that are really very agile and nimble in nature. You work with teams: the front-of-house team, the kitchen team, the prep team. I think it was that experience I brought with me when I eventually moved into IT and software development. Starting to work alone was really hard for me because I was used to working with people, so one of the first things I did was try to change that. I didn't know anything about Agile, but other people did, and they said, "Hey Kumar, we ought to try this Agile thing." That was in the early 2000s. So you brought an OD lens into Agile after ten years of practice, and for me it was really just about systems and running a restaurant. Interesting parallels.
You introduced a distinction in our prep talk that I found really profound: the shift from knowledge work to learning work. Can you break that down for our audience?
DIANA: When the term "knowledge work" was coined, Peter Drucker and others defined it as mind work: the knowledge you have accumulated and how you manipulate it as part of your work. Attorneys, accountants, certain kinds of analysts. The field of accounting, for example, has its foundational credits and debits that have been around for centuries. Knowledge work is about having a deep understanding of your field and working with what you know, as opposed to what your hands or muscles can do physically.
Learning work is different. A number of people are starting to use this term, and my definition may not match everyone else's exactly, but the idea is this: we can no longer rely solely on the knowledge we have accumulated and our ability to apply it in different ways. What we have to do now is notice when the world around us is changing, when a new technology arrives, when any number of things are shifting, and be able to learn what that means for us. Connect it to what we know, but not just rely on what we know.
Barry O'Reilly wrote a book called Unlearn about this: how quickly can we let go of past knowledge when it no longer applies? What does apply now? So it's not that we jettison knowledge work. We have to add an intense need to continually learn what's going on in our professional world and be able to apply it quickly.
KUMAR: You can't take four more years for another degree before adapting.
DIANA: And it would be obsolete by the time you got it anyway. Disruption is changing things that quickly. It's a problem for people who have been used to saying, "I'm the expert in my field," because you can't stay the expert if you're not devoted to continually learning how your field is changing.
KUMAR: How do you see that manifest on learning teams versus knowledge worker teams?
DIANA: A good example that Tricia and I wrote about in Lead Without Blame is COVID. When COVID hit, a number of high-performing teams, teams with really effective routines and work processes that helped them ship high-quality work, suddenly couldn't be co-located. They needed to learn very quickly how to work remotely. Many of those teams fell apart. They were no longer high-performing. They struggled.
And yet some teams simply said, "Things have changed. We're going to learn how to work remotely. What tools are available? How do we bring those into our world? And is there something new we can build for the marketplace?" Zoom was around before COVID, but it was not the powerhouse it became. Zoom was very quick to add features specifically needed for the new reality, unlike some competitors who got stuck in "this is how we've always worked." The ones who noticed what this new world needed got busy building it. The ones who stayed stuck had a problem.
KUMAR: In many ways, the pandemic forced us to become more learning-oriented. That catalyst forced us to figure out how to deliver value in a very different environment. In terms of the shift from knowledge work to learning work, I think "speed to learning" is also a differentiator, right? How fast can you learn and incorporate new knowledge into the work you do? Would you agree?
DIANA: Absolutely. And there are so many dimensions to it. That's what retrospectives were always about: learning how your team works together, learning how your system is performing, understanding what the customer really needs, what the organization needs from you. Some people just step up to that, and the ones who can't have a real problem.
KUMAR: You mentioned in our prep call that AI isn't waiting for us. What happens to companies that don't make the shift from knowledge work to learning work?
DIANA: I think some of them are making very bad choices right now. Instead of saying, "We have a great workforce with a lot of institutional knowledge. How can we implement AI in a way that helps them all learn more together?" organizations are saying, "We'll get rid of those people and let AI do their work." That's a big mistake.
If we're building something we expect humans to use, we still need humans in the mix. They're the ones who understand human reactions, who make judgment calls. What we need is to use AI in a way that makes sense when mixed with human cognition and human capability. How can it be an assistant rather than an expected leader? Because the agents that exist today are very capable but very narrow. They're focused on knowledge work areas. When it comes to learning together, that's something still being explored, but it isn't widely available yet.
KUMAR: So AI today could function as a knowledge store that helps humans learn faster?
DIANA: Yes, that's one way it can be used. The model could be: AI and human in the loop, using AI to bolster what people already know, but more importantly, to help them learn faster and adapt to whatever they need to adapt to, whether they're a lawyer, an accountant, or a software developer.
Some of the things I've written about in the past, like Liftoff and agile chartering, make me wonder: what will it look like when we have a couple of humans and a team of supporting agents all collaborating together? That's the interesting direction things are heading. Not just very smart agents capable of gathering knowledge from certain areas, but how do we put them together with a team of humans to get the effective learning we actually need?
KUMAR: I hadn't thought about running a team charter with a few humans and a number of agents. It almost makes the charter even more important, to define what the agents do and how they support human thinking and learning.
DIANA: Definitely one direction. I know some folks experimenting with something called ClickChain AI, which is exploring team-based combinations of humans and agents. My expectation is that something like chartering a team, doing a liftoff, making sure all participants understand the purpose of why the team was brought together, the mission, what the customers need, what expectations exist for how they'll work together: that's going to make a huge difference. Each functioning part of the team, whether AI or human, needs to know what their role is. That will determine how quickly they're able to do the work.
KUMAR: That's fascinating. The company I'm currently supporting is still in its infancy figuring out governance models for AI. I use it a lot in my own work, but it is interesting where this is headed. I saw an article saying that general AI superintelligence may be arriving within the next year.
DIANA: Then we'll have to figure out our place in the world. But we've always needed to do that. My grandmother was born in 1906 and during her lifetime went from horse and buggy to automobiles to radios and television. She went through enormous technological change. We have always had to make adjustments. Each one is challenging because it's something new to learn.
KUMAR: That's a good perspective. I actually just wrote an article comparing the exponential change of the automobile to the solar and battery revolution, and the parallels are striking. We've been through this before.
DIANA: The pace is different, though. How many centuries did we depend on horses and wagons? We had a very long time to get used to that technology and bring it to high levels of development. With automobiles and airplanes, it's been about a dozen decades. The pace of change has accelerated, and humans are not very good at detecting exponential change. We handle change on more reasonable timescales much better. So we don't do a great job of recognizing that we're living in an exponential era and that we need to accelerate our pace of learning just to keep up. That's a big challenge for leaders, because they have to manage their own learning and also create environments for the people around them.
KUMAR: I want to shift to Lead Without Blame. You and Tricia make a powerful case that blame is the enemy of learning and therefore the enemy of resilience. What does that mean in practice?
DIANA: Think about it physiologically. When we are learning, our eyes are wide open. We're looking around, gathering data, sharing it with each other. That's the posture of learning. When we're being blamed, or even when we're blaming someone else, the posture closes. It's inward. There's sadness, shame, guilt. It's very hard to add enthusiasm and creative thinking into that mix.
Blame has a direct impact on psychological safety. If blame is being tossed around, people armor up and withdraw. They stop engaging. I've been accused of being touchy-feely over the years, but this is actually very practical. If people come into a meeting already trying to point fingers or deflect blame headed their direction, what kind of creative thinking are you getting from them?
Compare that to someone who can say, "I just made a big mistake and I'm really sorry. But in making this mistake, I learned something new about our system. I didn't know it would react this way. Now we know that. Now we can build on that." That's a learning stance. It's not hiding. It's not pretending the mistake didn't happen. It's acknowledging what happened, cleaning up the mess, and staying focused on what comes next. That makes a real difference. And it connects to other things like dependability. When someone gets blamed, they become less dependable because their energy is focused on managing the fallout rather than doing the work.
When you compare autonomy-supportive leadership, which is learning-oriented leadership, with controlling, punitive leadership, there's just no comparison in terms of where creativity and innovation come from. Do you want blind obedience or a healthy organization that actually produces results?
KUMAR: You've been coaching for a long time, and I have too. These problems have persisted. Why do you think the old models survive, and what can be done?
DIANA: That's a question for the ages. On one level, how we're parented makes a big difference in how people grow up feeling about themselves and their capacity to learn. The work Carol Dweck has done on growth mindset is very relevant here. I once went into an organization to give a talk and was told beforehand that no one would ask questions afterward, because they had all been hired for being the best and brightest, and asking a question would expose areas of ignorance. That made me very sad.
A lot of it comes down to tradition and habit. We learn how to lead from the people who led us, and not all of those experiences foster our capabilities in the ways they could. There's no simple answer. That's probably part of why people like you and me stay employed, trying to help improve the conditions for people doing the work, whether they're leading, doing, or somewhere in the middle.
DIANA: That's also why Tricia and I wrote Lead Without Blame. Neither of us is that kind of leader. We wanted to give people some guidance from what we'd learned out in the territory: here are some ideas for handling these situations, here's how to create work environments that foster learning, innovation, and collaborative work.
KUMAR: Your work on team resilience applies broadly, right? Not just to delivery teams, but to leadership teams, any group of people working toward something together?
DIANA: Yes, absolutely. Any team trying to become more than the sum of its parts.
KUMAR: That's consistent with the Disruptor Method as well. Whether it's a leadership team or a product team, it's about how you become more than your individual parts.
All right. One final question before the lightning round, and then please share anything I haven't asked about. This is about the Agile Fluency Model, which you co-created specifically to push back against the idea that there's one right way to do Agile. What does the model invite leaders to ask or do instead?
DIANA: People often ask us whether they can become an Agile Fluency organization, and my answer is no. The model is a model of team behavior. It's a way of looking at teams, understanding their behavior, and knowing what to expect from them. That has enormous management and organizational implications.
What the Agile Fluency Model asks is that you spend some time thinking about what you actually need from your teams. First, does the work even require a team? Some individual contributor work is fine handled that way. But when you're starting to look at more complicated or complex work, you probably want a team of people's minds on it.
The model has zones. If you're moving into team-based work and you just need people to quickly build internal marketing software that changes regularly, you probably need what we call the Focusing Zone: teams learning to work well together, understand customer value, those fundamentals. For that kind of product, technical debt is less of a concern because the products aren't long-lasting anyway.
On the other hand, if you're selling software as your primary product and need continuous updates, versioning, and new features, you'll probably need to be in a different zone. You'll need cross-functionality, continuous deployment, and engineering practices that go deeper. You can read more and download a free white paper at agilefluency.org.
The core idea is this: really understand what you want from your teams, get very clear about that as an organization, and then give your teams the support they need to deliver it. Don't assume every team is interchangeable with every other team.
KUMAR: I love that it starts with a question rather than handing you a framework and saying, "Go do this." All right, what haven't I asked you that you'd like to share?
DIANA: What's coming next for me is a program I'm putting together for leaders in fast-paced environments who are beginning to drown, or can see that feeling coming. Leaders who want to avoid burnout. Because leaders are the ones who create work environments for teams, and if I care about how teams work well together, I need leaders to have what they need to create those environments.
The program is called Thrive in Turbulent Times. It will be for middle managers and senior leaders who have the responsibility to create environments for themselves and their teams, and who need to not only survive in the current environment but actually find moments of thriving in it. It will be small groups, a mix of in-person immersions and virtual sessions.
If people are interested, they should go to my website, dianalarsen.com. There's a Subscribe tab at the top of the page. You can sign up for my newsletter, workshop announcements, or both. As we finalize the program, that will be the first place we announce it.
KUMAR: Wonderful. I'll include the link in the show notes. All right, a couple of lightning round questions and then we'll close.
What are you reading right now?
DIANA: I recently got another copy of StrengthsFinder. I did my first one back in 2013 and felt like things might have changed, so I'm refreshing myself on that. I've also been reading a lot about how to promote programs online. One of my big learning challenges in recent years has been the shift in how we market services. I'm trying to learn as much as I can about how to tell people what I have to offer. I'm also aware that I won't be working forever, even though I love my work. I want to use this time to share things I've learned across my career that are still relevant or that I've adjusted for current times.
KUMAR: That's wonderful. I'd love to learn from you. So are you using AI to help with marketing?
DIANA: We have used it a bit, yes. Simple things like understanding the relative advantages of small groups versus large groups for individual learning, so we can make wise choices. But I'm also using a combination approach. A couple of months ago I asked people on my newsletter if they'd like to give feedback on the new program. A number volunteered, so I did individual human interviews to get feedback on our ideas. Then I also tapped into AI. And then I looked at where the two aligned and where they didn't, and compared that with what my own team's instincts told us. Pulling on a number of resources.
KUMAR: I love that. It's almost a direct test of your model. AI as the knowledge store, and the human doing the learning from that.
All right, one last question. Is there something you believed about teams that you've completely changed your mind on?
DIANA: Yes. Co-location. There was a time when I would have gone to the mat for the position that teams have to be co-located. But I didn't fully understand how technology could support distributed work. I still think there is a place for co-location. If you want your team to work really well together, plan for some in-person time. How you do that is up to what the team can manage. But in-person time does add something. It's just no longer the be-all and end-all. It is perfectly possible, particularly with practices like mob programming and ensemble programming, to have a very strong, distributed team. But you have to give them the right tools and conditions.
KUMAR: And all the things that lead to high-performing teams still apply, probably more so when the team isn't co-located.
DIANA: Exactly.
KUMAR: All right. Thank you so much, Diana. It's been a real pleasure. I feel like we could talk for another hour easily, but we'll have to have you back and pick up where we left off.
DIANA: I would love that.
KUMAR: Awesome. Thank you so much. Thanks for watching, everyone. See you next time.
