 Welcome to Agile Roots 2010, sponsored by Version 1, Rally Software, Vario, AmirSys, Agile Alliance, and Xmission Internet. Managing Agile, transforming the three dysfunctions of management by Diana Larson. I'm really interested in and explored it all, yes. And so I'm hoping that over the next, or this afternoon and tomorrow, you'll come up and give me your ideas about what's here while I do this talk. And, you know, I appreciate if you would sort of hold questions until they occur to you and then ask them. I'm not promising that I will have answers for all of them. So this is in the nature of sort of a mutual exploration today. So I hope you'll join me in that. And if anybody came here opening for the definitive, this might be your time to escape to another session. So the definitive isn't going to happen here. The interest of transparency. So I have been working with an around Agile for almost ten years now. It occurred to me that we were talking about the ten-year anniversary of the big and solid cities that come up. Talking about the ten-year anniversary of the signing of the manifesto is going to be next year, next in January. And that reminded me that actually my first real in-depth introduction to Agile happened in that same month. It didn't happen here. It happened in San Francisco. But I had been talking with a number of my colleagues, Martin Fowler, poor Cunningham, Ron, Joshua Karyewski. We were all part of a group that would meet together periodically. And so I had been hearing about these ideas for a while. And my background at that point was in work process redesign. So I would go into an organization and work with the people who were doing the work to figure out how they felt their process should be constructed and go together. And inevitably, when we were usually with the team, when we were doing that work, if the work we had in question was knowledge work, if it wasn't sending on work or if it was knowledge work where people really had to bring their hearts and minds to bear as well as their hands and muscles, inevitably they picked a team-based structure, and inevitably they picked a cross-functional team-based structure, and inevitably they began tearing down barriers, and inevitably there was friction with management. Every second time. So my in-depth introduction to Agile was I attended a week-long extreme programming boot camp that Joshua Karyewski and Eric Edwards were putting on. And said, let's go. And when they invited me, I said, you know, I'm not going to be able to do any coding. And they said, that's okay. We have roles for you, right? So in the long simulation that happened as a part of that boot camp, I was the customer. And so I got to see how some of those things played out and what that role was like as well. And also walking out of that, I thought, hmm, I wonder how they're going to handle the interface of management. Because it seemed to me as I went through that, that this was a really elegant way of designing work. And because of my experience working with other teams, I could sort of see that, you know, if you gave team-free reign to design their own work and they were doing that, this particular kind of work, this is probably pretty close to what they would create to come up with. And so that, you know, that is sort of how I got here and why I'm talking about the things I'm talking about. And, you know, when I'm thinking about 10 years ago and now, maybe here in Salt Lake, where next year we'll be able to utilize the Agilcom. If you haven't figured that out yet, talk the film. So we're here to talk about managing Agil, the three dysfunctions of management. And of course I sort of stole the three dysfunctions. Thank you for the five dysfunctions of the team field. I mean, I figure if a team gets dysfunctions, management should have dysfunctions as well. There must be some there somewhere. But I do not intend this talk as an opportunity for bashing managers. As you'll learn as we go through this, you know, I really do want to take a systemic view. And any of us that are working in a system have our behaviors influenced by the structure and construct of that system. And so it's just as true for managers as it is for team members. But I do see some recurring patterns. And I do see some patterns that really do cause some problems. And so that's what we're going to be talking about. I found this great Peter Drucker quote. I think it's, he wrote this maybe 15 or 20 years ago, but I think it's still true. You know, we are in such a time of marketplace churn and organizational churn and information overload kind of churn and so on that we really have huge opportunities. I mean, these are the times that give rise to enormous opportunities to make things different, to make things better. It's much harder when everything's skating along in the status quo and everyone is comfortable to make any shifts. It's when things get in turmoil, when things are turned upside down that we're able to make the kind of shifts that we need to make. To look at the assumptions that we've been working under to rethink. And so that's what I'm hoping we can do as a result of this. So till now, there has been an assumption about what it is that managers do in organization. And it really is this list of things that I'm not going to read to you. You can read for yourself. But so there's a big body of work that managers have been responsible for. You know, managing the budget and directing the work and making sure that things are coordinated. As if people doing the work couldn't do some of those things for themselves. In some instances that may be true. But there's been a belief that in certain kinds of systems this may be the best way for management to get done. If you've been a highly bureaucratic system, this might be the best way for managers to work. However, if you're in an agile environment, this is all up for grabs. Because it's not just the manager who would do these jobs. Which calls into question, you know, so what will managers do? So I'm going to try to answer that question as well. So there's no point in dwelling in the past and saying, you know, how do we get here? Why do we get here? I'm a bigger fan of retrospectives than there is. But at some point you just say, well, this is just the way things are. We're going to accept reality. We're going to move forward. And, you know, Jerry said, as Jerry also does, he said it, you know, as well as anybody can say it about that. So let's talk about these dysfunctions. And I'm going to think of them as traps. You know, it's not that we're bad people or that we're, you know, pain from dysfunctional families. I mean, you know, I don't know what your family is like. I'm going to make that a summary. But there are certain traps that the way we construct an organization, the way we put our org charts together, the way we have our reporting relationships, the assumptions that we may have created some traps that we could fall into that cause dysfunction to happen in the organization. And the first trap is magical thinking. But in a lot of organizations I go into, someone will tell me about a decision that's been made. And I'll say, oh, well, that's interesting. So how, you know, how did you come to that conclusion? Well, we just think that's the way things should be. Well, we're confident we can make that happen. I actually have a manager once who set up a revenue target for the department that I was working in that seemed a little odd to me. And so I went in and I said, hey, how did you decide you were going to make half a million dollars this year? When in every past year we had made well under $300,000. He said, I just know we can do it. And besides, it's what my managers want to hear. So thinking I was being helpful, I went back to my desk and I figured out how many people were in the department and what kinds of projects we were working on and how much revenue, average revenue of each of those projects would bring in and what, you know, so on and so forth. And there was one really big project that we had that was actually getting ready to go away. It was a government funded thing. It was just leaving. And so I didn't know what was going to replace that. But okay, I'll make the assumption and I'll give another one of those if you want. And I got the numbers and I said this just doesn't count. So I went back in and I said, damn, of course. Here's our track record and here's what I see happening in the future. And I said, oh, I never worry about budgets. And I was gone in about five months from that place. It was too hard to work there. It was too difficult to work in a place where there was no justification for decisions that were being made. I couldn't understand what was going on. I'm not proud of not seeing that pattern when we're over here. Maybe some of you have noticed in your organizations times when, yes. Okay, so I'm not alone. I'm not the only one who sees this. There's a woman that I sometimes follow. She does a thing called the work. And she's a very pragmatic person. She really focuses on questions like, do you really know that to be true? Do you pack it if that wasn't true? Things like that. And this is one of her sayings. You can fight reality and you'll lose. But only 100% of the time. Right? And yeah, in our organizations we continue on making decisions based on which we're thinking. So I dug into this a little bit. And there's a really good book out right now called Hard Facts, Dangerous Actress, and something. I'll show it to you later. It's by Jeffrey Pfeiffer and Bob Sutton. And their whole point is that there needs to be a shift to what they call evidence-based management. That is one of the things that helps us move out of which we're thinking. And thinking with this list of too many management decisions are made based on what somebody hopes will happen or fears will happen. What other people are doing and having some success with. Which is a lot of what I think we're seeing in Android now. We see someone else is having, it seems to be having success with that door. We wrote a article, we heard a story about someone else having success with that door. So we just apply some of that stuff. We start having meetings without really digging into why did that work for them? And what does that mean about whether or not that will work for us? And what would have to be the same or different for that to work for us? Look Jeff, stop this morning because it really digs into that question. How do we know? How do we know that will work for us? In some instances, maybe business decisions based on what's happened in the past, even though we can clearly see the future is going to be different. And this idea of what we think should work. Well they should understand what this required specification says because I did my best at writing it clearly. So they should understand. And the fact that they don't somehow doesn't have as much credence as the fact that they should. So they have chapters on this in the book and it's fascinating stuff actually. So I think one of the ways that Agile well done, thoughtfully applied, constructed in context addresses this is that Agile actually, if you're willing to look at it, supplies a lot of evidence, right? We keep data because of the works that are right in the middle that we can come look at it. You know, we probably have some kind of roadmap charts or roadmap charts. We probably have looked at our risks. We may have asked for our team to be chartered when we got started so that we can have a clear idea of what it is we're all trying to accomplish here together, what outcome we're looking for. And how that's going to satisfy any sort of business case for the organization. It's a lot of evidence if someone is willing to look at it. It also highlights the things that are in the way. I mean, that's one of the issues, of course, sort of everything comes with it's upside and downside, is that, you know, if there's something not working in your organization, if you're really doing the old college try at adopting Agile, all those things that are working in your organization are going to show up pretty clearly. And you have to be willing to look at them. But then, once you look at them, you can figure out what to do about it. Until you look at them, you can't figure out what to do about it. Agile, one of our values kind of is transparency. You get to see what this we're doing. Any time, come on by, come take a tour. Then the little innovation says, we'll show you. We're just all hanging out in this big room together. Everybody can see. So in this idea of continuous improvement that we're never really there yet, that we're always looking for ways to get better, whether we're doing that, you know, with a compound kind of way, or whether we're doing that iteratively and really focusing on continuous improvement actions coming out of retrospectives, doesn't really matter the specific practice. The idea is that we really are devoted to making sure that things continuously improve, but in order to do that, we have to collect data. Otherwise, how will we know if there's been any improvement? And because of the cross-functional issue, because we want to collaborate, there are more perspectives brought to bear. And any time we have more perspectives, we have a better idea of what it is we're working on. And of course, we have retrospectives. So we can look back, we can see what can be learned, what wisdom can be gained, and we can make decisions based on what we've really learned, as opposed to what we think should happen. So there's a lot in Agile to really help just, you know, get rid of that big pothole that could be manageable thinking, wishful thinking. Oh, here's the book. Evidence-Based Management Skills. They have a lot in there about this particular issue, this wishful thinking, and really making sure that we're making our business decisions based on really good data. There's another stream out there called Discipline Optimism. So sometimes when I say we have to make all our decisions based on data, someone will say to me, yes, but isn't it the job of the manager to hold the vision and, you know, shouldn't I be telling people, you know, giving them aspirational goals and stretch this and that? And, you know, yeah, you should be holding the vision of kind of what the product needs to be or what outcome we need for our organization. Yes, hold that. But when we're planning this release, stick to what we know. So maybe long-term, yeah, vision, short-term, let's work for data. Let's work for data. Discipline Optimism is an interesting thing that I ran across that has to do with your aspiration but not ignoring kind of unwelcome facts. And so a lot of this has to do with managing the paradoxes that come up. And that, I think, is one of the jobs of the manager because there are a lot of paradoxes ignore people. Another way of working from data is to develop what I call a tracker's view. I have a number of friends and family members who do a lot of holders tracking it. One time I was asking them about that and it turned out what they do when they go out in the woods sounds a lot like what I think works for managers to do. It's worked for me anyway. And so new ways of gathering evidence, new ways of gathering this data is, you know, look differently. Look at things differently. Take a new perspective. If you've had your management had one, just for the day, say, well, if I were walking into this project and I were a talent, how would I perceive this differently? If I walk into this project and I am building skyscrapers, how would I see this differently? And try that on, try on those hats. Maybe try on some of the hats of personas and people that you're trying to serve. But it helps you to think about things in ways you're not used to. One of the things the trackers talk about is the dead zones. And the dead zones are places where we don't normally look. Or places where we just aren't aware. Like right now, right up here, this is a dead zone to me. I can't see my hand, I don't actually know what it's doing, other than the sensation that I have. Right? That's dead zone. For me to know what that is, I have to look up. Right? I have to look behind me, I have to look around. And all of us, every day in our daily lives, have dead zones. Places where we've just, we've gotten out of the habit of looking. And managers really can't afford that. So we need to help identify the dead zones and begin to look there as well. Make sure that we're seeking information, seeking our data from lots of different sources and not always relying on the same channels. Learning to notice the things that we want to have happen. And make sure that we are recognizing that and interacting with that appropriately. Right? If we, if we want people to be pairing, use that example. Now let's make sure we notice when it works. Or create situations where it will naturally occur. And this last one is one of my favorites. When you, the way the trackers describe it to me is that when you go out into the woods. Right? Imagine yourself sort of walking down a path into the woods. And you hear a bird call. That's your area of disturbance. It's not something else that's happening. They're talking about you. And so, so that means, you know, the Heisenberg, right? The observer is the observed, right? Every place we're walking is changed by the fact that we're there out to the limit of our area of disturbance. So we're not really seeing what would, what's real there. What would normally be happening. Because this, this other thing is happening. So, so the idea is reduce your area of disturbance so that you can see what's real. And all, and reduce your impact on the environment so that you can get real data out of it. Well, you know, expanding your own awareness hopefully beyond that. So I think that's an interesting little bit. So the second track. The second track is the illusion of control. It's interesting that wishful thinking, magical thinking and the illusion of control are actually like documented psychological states that could find them on the web. And the illusion of control is this idea that if, if I hold on tight enough, you know, I can, I can make things happen the way I want them to happen. It's kind of like, you know, gripping a handful of sand and even tighter, right? You open it up and it's gone. So there is this, this idea that if we, if we, the real way to get control is not to micromanage the details, but to set the context. And then watch what happens there and make adjustments as needed. So another one of those paradoxes. The more you exert control, the less you actually have. So I, again, I'm preparing for this in my, in my studies. I found this interesting, Jules Polsky has done a whole plot post about the illusion of control. And he came up to these three drawbacks to command and control ways of management. People don't like it. So you're not getting their best work because they're spending a certain amount of time trying to think about the fact that you're commanding and controlling them. And that is not a productive time. So people don't like it. I left your management by walking around the slide, right? You can't sit with everybody all the time. So you end up hit and run management, right? Which is just disruptive. Which also is, you know, so you become the person who is reducing the productivity. And people who are closest to the work, and this comes up over and over again. Joel is the first one to say it. Daly has said it. A lot of other folks have said it. The person who's closest to the work is in the best position to really make decisions about the work. You know more than you can ever possibly know. So how does Agile help you avoid that trap? So Agile emphasizes craftsmanship and self-organizing teams. So it starts from a premise that we're coming to work. We want to do our best work at work. If we're given the right setting to do that in, you're probably going to get more from us than you would some other way. Again, promoting communication, promoting visibility, promoting a good work environment. It's a way of setting that context to get real control. Feedback and continuous learning also helps to give that sense of, if you really want to know what we're doing, come on down to the demo. Watch our demo and tell us what you think. That's how you steer. You don't steer by standing over our shoulder or disrupting our sprints. And the other thing is that Agile really does celebrate what's real, that too, by the key, in the sense of we know and accept that there is uncertainty and unpredictability in the world. That's what life is. That's why we've not responding to change over following the plan in the manifesto. We take that as a given. And so we know how to work with it. We have a lot of techniques and practices and things that we have developed that help us work with that. So you may not get the kind of hold and type control, but you have a kind of control that comes with letting go and paying attention. One of the tools for that, I recently attended a workshop with David Snowden on the Kenefin trade one. So beginning to think in terms of systems. Because if you can move up to the systems level, there are some predictable patterns that we can count on. And really thinking about what is the nature of the work that's going on where you work. Can we rely on best practices? Do we have really simple work where we can just see what's going on, categorize it, and then have that already programmed response. Just pull the best practice off the shelf. Because this is work we've been doing forever. It's always the same no matter how many times you lick and stamp envelopes. That process stays pretty much the same. And if you've got a big pile of envelopes to lick and stamp, one person could probably do the whole thing. It would just take a lot longer. So we might bring a group of people together to do that. But there's no real synergy there. It's still just licking and stamping and it's kind of a known process. We may have figured out that it's better if we crease the plate before we start stuffing it. But we figured that out pretty quick. So simple. Simple work. Convocated work. It's not quite so straightforward. There's a lot more building parts. The things aren't always exactly the same. There's some diagnostic issues that have to happen here. So we look at what happens and we have to do some analysis before we choose our response. But the thing is, it's well within our capability. It's stuff we know about. It's just lots of pieces of parts to put together and collect. So in that instance, we want to find... It may not be one best practice. But we're expert enough to know what the range of good practices are to choose the appropriate one. But we think we're best at this situation. So either of those sound like software development work. So then we get to complex work. And this is where we really... Things are changing all the time. There is that uncertainty. There is that unpredictability. Because new stuff comes on the scene. And sometimes as a result of what we have done, we get new stuff that impacts us. Which is I think why the many of the features that we write need to throw away. Because we learn new things as we go along. New stuff emerges for us. And so here we have to figure that out. And then the connected framework. David says what we do then is we probe. We poke it a little bit. We see what happens. Then we choose our response. So in March is out of our experience. Out of our experience of poking. So you see what happens. If you try this, then what? Does that change things? Does it stay the same? And then finally there is an area of chaotic work. Which is there is a flood coming. And we got to figure out how to deal with it. We haven't dealt with the flood before. So we may just have to take some action and see what happens. And then choose our next action based on what happened then. So then we've got really rapid emergence. And everything is new. Any time to think about what kind of work is in front of us. How much of it is simple? How much of it is complicated? How much is complexity? Are we in chaos? And what does that mean in terms of how we manage the work? It really gives you more control than the holding on type or the micromanaging. I read a recent study that said that over time the one thing that has been the best predictor of organizational success. Success in the marketplace. Success as defined by the people who work there on many dimensions. You know, isn't marketing or innovation or isn't a lot of things that you might think it was. It's not about technology. It's not about having the latest technology. It's about having the strongest culture. Which I thought was fascinating. And so instead of the illusion of control. Part of the way the managers can get real control and do that dysfunctional crap. Is to really help to create a vital generative culture. Wherever you are. You get more real control over what kind of culture you're in. Than in any other way. So we do that by focusing on value and flow and people. And make sure that we're keeping up this sense of continuous learning and continuous improvement. And of course both of those are supported by all kinds of agile practices. So, another place managers should focus. This is according to Mary and Tom. Managers should focus on enabling intelligent self-organizing mission-focused behavior at the lowest levels in the organization. That's about what kind of culture we have. Because our culture is the main one. Crop number three. I'm voting my 50 minute deadline. The fantasy of individual blame. You know, I go into organizations and I find people spending a lot of energy on figuring out who's to blame for something that just happened. Rather than just fixing it. Like it's more important that we can pin it on somebody. That we actually can make progress and move forward. That to me is hugely dysfunctional. And I think it's important that we move away from that. And one way of moving away from that is also thinking systemically. The psychologists have a formula. B is the function of P in E. Behavior is a function of a person in an environment. Behavior is not just about the person. Behavior is about the person in the context, in the environment. Responding to the stimulus that is there. So, it follows that performance, which is one kind of behavior. Productivity, which is one kind of behavior, is a function of the person in the environment. So it's not so simple as just blaming someone for something that happened. We can't fall into that trap. Because that ignores the whole piece of it that has to do with the environment. There's one of my favorite, there have been quotes along with one of my favorite pictures. The performance of anyone is never largely by the system. And the system is the responsibility of everyone. And this is one of my other favorite to me. I don't know if you ever get a chance to see a video of him. He was the most awesome sort of cantankerous curmudgeon ever saw. I've been fortunate enough and I hope enough that I actually got to be in a workshop with him one time. It was awesome. So, what is this blame? So as someone else said earlier, blaming really just leads to a lot of CYA behavior which tends to lead to waste. If I'm trying to make sure that I've commented every bit of my quotes and nobody can hold me accountable for anything that goes wrong there if I make sure I document everything, right? That's all, that's waste. And it comes from a culture where blame is widespread. Because when there's a lot of light going around, everybody gets very busy trying to deflect it. I don't want to bounce it all off one side of it. So, how does Agile help with this? It really helps that Agile is built on a foundation of values and principles. When you're working from values, when you're working from first principles, blame gets a lot tougher. It's a lot tougher to assign that way. It also has this idea of collective ownership. So, if we all own the outcome, if we all own that what we're building, this whole question of, well, I got mine done, I don't know what happened with you, goes away if we're really collectively emphasizing delivering value in different ways. Also, the idea that Agile has this emergent property around it. You know, in my role as chair of the Agile Rights Board, I get to hear a lot of talk about how, you know, you've just ruined my Agile's. You know, you're not doing it right. And the thing is, you know, as I hold them, but I don't think Agile is big. I think it's done. I think we've got a good start on it and we're headed in a good direction and I think it's still evolving. I think we're still learning. I hope we're still learning things. So, I don't see how we can break it, really. We can try new stuff and if it doesn't work, not do that anymore. We can do lots of experiments. And so, in some ways, what I see is people who are doing strung by or, you know, whatever their experience is. So how's that working? There's always the opportunity for another experiment. And if we stay in experiments, there's also, it's a lot harder to blame. Right? It was just something we tried. I don't want to go try something else. We're just from this awareness of complex, adaptive human systems. Right? I mean, there's a lot of complex, adaptive technical systems out there, but there's also this complex, adaptive human system that we're really concerned with. And that's our teams and our organizations and our interactions with our customers and so on. So I went out and collected a bunch of added values. This is obviously the exhaustive list, but this is a bunch of them. And if you look at those and recognize stuff that's going on where you were, you're probably in the right camp. Recently, a lot of people don't know, but a couple of years ago, the Agile Alliance faced a kind of attorney point. Everybody knew about Agiles knew the word at that point. Did we still have a reason to exist? And it's just getting the word out was all we were about. We could have declared done and moved on. But we decided that we weren't really done. That it wasn't really just about how people learned about Agile. That there was a reason we wanted to help people learn about Agile. It was bigger than just methods and practices. And it was that everybody who was at that time serving on the Agile Board and a lot of other people that we talked to really had much more of an interest in a higher purpose, which was helping to make the software industry more productive, humane, and sustainable. And so that's what we worked on. When someone comes to us with a program or an idea or how they want to do something in the conference, we say, will that get us toward helping the software industry more productive, humane, and sustainable? So values driven, purpose driven, really helps to keep us out of play as well. I'm familiar with the crime directive. If I say not the Star Trek one, how many answers? Crime directive. It was written by Arm Kurz in his book Project Retrospectives. And he proposed it as a working agreement for Retrospectives, the big end of Project Retrospectives, which is what he was looking at doing at that time. I'm struck by how much this applies much more universally and how it really is about how we work together and what a systemic view this is. Performance is a function of the person and the environment. If a person does not have the right information, if a person hasn't had the opportunity to get the right skill, the training so that they have the skills they need, if a person isn't in one of my resources, if they're in a context that, you know, where they're being multitasked and both assigned to six different projects in both six different ways, how could they possibly be successful and how could we tell them your best isn't, you know, your best isn't good enough? Sometimes it is. Sometimes the person is absolutely doing their best and there aren't any of these other impediments in the way of their best isn't good enough. And we know what to do with it. We give them the opportunity to approve them if they don't and we decide they are probably a good fit for us. But it doesn't mean they weren't doing their best. Given their context, given what they do, there's a lot of interesting wisdom in this thing. So, job management instead of knowing who to blame really is about focusing on the work environment and the value-producing system. You work at that level, interestingly, the dogging people around, micro-managing other people's work. There's a huge challenge here focusing systemically. And Gloria Aviation has said a couple of books out. She has something called the Human Systems Dynamics Institute. She really studies human systems and how those work. And she's given us a tool called the C&E model where we can look at what's going on in our organization in three ways. One is what containers are there, right? Container is anything that has a boundary. Anything that's a boundary compact is a container. So, a team is a container. A multi-team project could be a container. We can have multiple belongings. We can be in many containers at once as individuals. But it's useful to know what containers there are. And what are what Aelia calls the differences that make a difference between the containers? How are they different? Why is that remarkable? Why should we notice that? Again, gathering data. And in what exchanges happen between the containers? Where's information passing? What kind of other handoffs are going? Where are their transactions and so on? So there are some tools out there for managers to use to begin thinking at that systemic level. So for me, the real issue here around these three traps, these three dysfunctions, magical thinking, the illusion of control and the fantasy of individual blame, is shifting our focus to what is emerging and how do we create the most resilient and sustainable organizations? How do we create a context within which people can express their resilience and have noticed what's emerging in them and outside of them? So, in conclusion, I invite you to think about what one thing will you take away from these ideas? Where are you falling into a trap? Are you able to spring a trap for someone else by introducing a practice or an idea of an actual that might help them? What thing, one thing might make a difference? Just think of it to yourselves. And speaking of tweets, if you want to get in touch with me, there are a number of ways to do stuff, and they're all up there, and I really do enjoy talking to people about what's going on in your organization, how are your teams doing, how's that work for you, what experiments have you tried? What worked? Why do you think it worked? What didn't work? What did you try after that? So please, you'll think to get in touch with me. And I think we have a couple minutes for questions. We have questions. CEOs in the room, will you identify? Okay, two, three. Pardon? Will your presentation be available after? Yeah, I think... Yeah, we're going to get the slides up somewhere. Is there a recording as well? Yes. I think so. I didn't actually check that one out. The green shirts alone. Check with a green shirt. I'm going to be here all the rest of today and all day tomorrow, so if you have feedback on this talk, I would love to hear it. Also, just as another invitation, sometimes this evening, somewhere that hasn't quite been figured out yet, we're going to try. Because of my interest in picking ourselves, we're going to try out a learning system called Where Are Your Keys? Some of you may have heard that there are a few people in the room who played this game with me and with other folks, and it's just a fine game to play that really helps us understand a lot about learning. So find us and we'll be playing. So thank you.