Podcast: Play in new window | Download
If you want a high performance team you want shared vision (Gamasutra) and psychological safety (Google). Bringing your whole self to work is crucial. People have a 1-10 ratio (fastest to slowest). Teams have a 1-2000 ratio (fastest to slowest). This interview will change the way you think about the workplace and teams.
- Host: Ron Smith
- Contact: richard
@kasperowski.com - LinkedIn – https://www.linkedin.com/in/kasperowski/
- Music: www.hooksounds.com
Use the comment section below to comment on the interview.
Want to get more helpful project management insights like this directly in your inbox? Subscribe to the Managing Projects newsletter (see subscribe in right side menu).
Ron is a Project Manager with Chalder Consulting Inc. www.chalder.ca
Linkedin: linkedin.com/in/rondsmith
Check out the contributors page.
Transcription of Interview
Intro: Welcome to managing projects the podcast for project managers in search of trends and insights. Join us as our guests dig deep into the thought provoking topics that matter most to project management professionals. You can find all the episodes at managing projects.ca. And now here’s your host Ron Smith.
Ron: Welcome to this episode of managing projects. Today I will be chatting with Richard Kasperowski. Richard is a speaker, trainer, coach and author focused on high performance teams. Richard is the author of The Core Protocols: A Guide to Greatness. He leads clients in building great teams that get great results using the core protocols, agile and Open Space Technology. Richard created and teaches the course Agile Software Development at Harvard University. So welcome to the show Richard.
Richard: Hi Ron – thanks.
Ron: So listen I saw one of your talks online. I know that you cite a few different sources for part of your talk. And one of them was very interesting a source named Jeff Sutherland did a study on productivity. And I wondered if you kick us off with what that study was about.
Richard: Sure. Yes I think you’re watching a video of keynote I did at the agile games conference a few years ago.
Ron: Yeah that’s right.
Richard: So this is the this is the Jeff Southerland who’s the co-inventor of scrum. So Jeff Sutherland and Ken Schwaber co-inventors of scrum and Jeff a couple of years ago he wrote a book called Scrum: the Art of Doing Twice the Work in Half the Time. So his thesis is that if you’re using scrum, it is possible to have teams that are four times more productive – twice the work and half the time. It’s sort of aimed at executives and leaders more than at practitioners so doesn’t doesn’t get into details of how scrum works. It describes reasons that you might want to try it or were why you might want to focus on teams and on team productivity and team efficiency. One of the things he cites is a study of computer science students at Yale. He didn’t actually I don’t know if he went to Yale. No he did not go to Yale. He went to the Air Force Academy I think. So he cites Joel Sapolsky. Joel’s article he wrote on a blog from 2005. Joel was a student in computer science students at Yale and he kept in touch with a teacher of a particular class that everybody in CS at Yale takes. As part of this class, the students that they’ve got a bunch of programming problems I think each problem ticks that they get like two weeks to get it done. And and students report how many hours they spend to get the get each assignment done. If you look at the fastest students in that class there Yale students right. So they’re all like pretty high pretty pretty high end performance no matter what they’re like in the in the upper half.
Ron: These are the high achievers.
Richard: Well yeah you know it’s Yale. This is the high achievers out of the population of everyone who’s college age right. So they’re like they’re like ninetieth percentile individuals at least. These aren’t these aren’t people who who struggle to learn hypothetically. In this course, in over years and years of doing it, so that they’ve been doing the same assignments over and over for for like more than a decade. So that the teacher has a lot of data. And from the data set what they know is the fastest students get these assignments done in one to two hours and the slowest students take about ten times as long. Right. So that’s interesting there’s a big difference even even when we’re looking at people who are ninetieth percentile or better for it for individual performance. There’s as much as well there’s a five to 10 times productivity difference between people in the class.
Ron: I’ve noticed this as well myself, depending on who’s doing a piece of work on a project team, you know you have your superstars that can crank it out really really quick and you have the folks that just take a lot longer.
Richard: Yeah. And what’s cool about this if you’re measuring this in this kind of stuff at work it’s it’s actually really hard to do single variable experiments where the only thing that’s different is the person doing it. When we’re doing it at work there’s all kinds of variables like the other people on your team or whether you’ve solved a problem like this before or when two people are if you could possibly get two people their two teams to work on the same problem so that the only variable is the teams. There’s there’s always other variables. So what’s what’s interesting here is that it’s the same assignments over and over every student to solving the same problems it’s the same teacher. There are very few variables aside from who are the students doing it. So then Joel refines the data even more. And what he does is he says well that that’s that’s a wide disparity. Maybe some of the students actually aren’t very good students and maybe they switch majors or something or they drop the course. So he changes it to look at the top quartile of the students in the class that basically the ones that get A’s and B’s the students that are really successful in the class. He drops the other 75 percent of people from the work. So this is like now we’re looking at only the good students in this course only the best students in this course and even then… And they’re the ones that that have they’ve gotten good grades they’ve passed all or almost all of the tests that they’ve submitted solutions to all the homework problems they’ve gotten really good grades on them. So even in this even in this subset of that population there’s still a wide disparity in how fast people get get the stuff done and the disparity is still like 5 to 1. So the most productive individuals even at the top tier are five times faster doing the same work than the slowest individuals. So that’s interesting that’s just a variation in individual performance.
Ron: It seems pretty easy to determine a resources productivity. But then did they get into starting a study team productivity as well.
Richard: Yeah. And by research I mean a person.
Ron: Right. Exactly.
Richard: And yet differences between individuals because that you know it’s a it’s a it’s a computer science class. They’re grading people individually in a couple of chapters later in his book. Jeff Sutherlands shares a story of a similar study at IBM and the difference in this study is that it’s about teams and this is you know this is a little harder to do. There’s a lot more variables. Although all the projects are different there’s different people on different teams but there’s a large enough sample size that it seems like a pretty good pretty good study. There’s 3800 software teams software projects in this study. So it’s a really big sample size and they’re all done by teams and in this study the best teams get their stuff done well we’ll said the slowest him’s take 2000 times as long to get their work out as the fastest teams. This is a huge performance difference between teams that the fastest teams and the slowest teams and it’s two orders of magnitude bigger than the difference between individuals. Right. Right so for individuals at Yale it was ten to one. And here it’s 2000 to 1. That’s huge.
Ron: Did they guess as to why. There would be that much of an amplification of that difference in the in the book.
Richard: Jeff doesn’t share why. I haven’t found the original publication of this like I’ve been able to find the original the original publication but the Yale data. But the point that Jeff is making is if you want if you want really fast software projects that you want really high quality software projects focus on the teams not on the individuals. The difference between team performance is two orders of magnitude greater than the difference between individual performance. So even if you had all the best individuals on a team they still might underperform by two orders of magnitude. That’s really interesting and of course he’s he’s talking about scrum and is about teams working together. So he’s he’s making a case for the executives and leaders who are reading his book that that scrum or something like it some way to get a team to work really well together is where you ought to be heading as a leader or a member of the team working on working together building something
Ron: That’s funny. You’re making me think of another time in my career when we were building a team and there was someone in the company who was seen as a quite a leader you have a guru you might say. And what was discussed was do you and other gurus with them or will they just fight. And so anyway building that team. The thought was that you know if you had one you know a stronger leader built around with some other people who were just going to come behind them and learn as opposed to argue. Now that’s really really interesting.
Richard: Yeah yeah this really piqued my interest right and I’ve been I’ve been interested in teams and helping teams be their most awesome for a long long time couple of decades since I was since I was a young software developer.
Ron: So in your talk you also cite Gayman sutra saying that right. I ask that question every time I say. I tell people that as it game-a-sutra is that Gama-sutra. It’s one of those maybe it’s game as interim maybe it’s Gamasutra. So it’s a it’s a website. It’s a periodical about videogame industry. And so I’ve taught a class somewhere and the team later asked me if I’d seen the study come out like a couple of weeks before I went to teach this class for them and it was it was really cool this study that they did. So in the in the academic literature when people are looking at team performance workplace performance that they try to measure things very objectively and they’re looking for different characteristics. Different behaviors that might correlate to success to have performance in the Gamasutra study which they called the game outcomes project. And you can find it on the Gamasutra website. They they took 200 different metrics to 200 different dimensions of Team behavior. And they wanted to know which of those correlated to success in video game projects. They found they did this around 2014. They found they found a population of 120 different projects to look at. They came up with a set of objectively metrics for how successful each video game was as well as subjective metrics. Did this list of 200 different things that might correlate to success according to the academic literature. Because I didn’t want to have to invent new things to measure and they wanted to see if the literature was replicable. They were actually doing good science replicating somebody else’s research. So what they found in the in this project the game project was that the one thing that correlated more highly to videogame success than anything else was shared vision. So that’s really interesting for for objective success. They looked at things like like financial return on investment. So some companies spent a bunch of money developing this project. How much money did they make back. So that’s profit or loss. They looked at just this really simple metric – was the project delayed, was the product canceled. Right. If it if it actually got to the end and they they could publish their game. That was that was a positive outcome. They looked at critical success. What did the critics think about it in reviews that in the press and they looked at whether it met the company’s internal goals whatever those might have been. Right. And they put that together into a scorecard of whether one of these 120 projects was successful or not. And what they found was the thing that they correlate most with shared vision. They also found these four other things that they actually ranked all these 200 different things in order of correlation but that the top five were shared vision, managing risks, everybody buys in on decisions they avoid death march kind of time crunching. And it’s safe to take risks on these sorts of teams that are successful and shared vision tops the list for the Gamasutra study.
Ron: So do you know Richard how they measured that. Was it was an interview style with each resource to figure out whether they would agree they hold a common shared vision.
Richard: Yeah. So they they they replicated the methodology that’s typically used in the academic research and the methodology is typically a self report survey from each member of a team. And what you want is a 100 percent response rate from all of the members of a team to be able to measure these things in a team like you know that they would ask everybody on likert scale from strongly disagree to strongly agree. I believe the people on my team share the same vision or I believe or I feel safe when I’m with the people on my team. These sorts of things. This is the kind of survey that they give to measure these sorts of things. It’s a very it’s a very typical way to measure these kinds of things.
Ron: You’re bringing up some of these topics that I know are also part of our of your conversation as we go through this interview. So safety at work as a logical safety you have. You speak about some research that was done as well that came out of the Microsoft project teams.
Richard: Yeah and this has been replicated over and over this kind of research. Stuff about safety correlating to high performance teams originated in healthcare. It’s been replicated in many different industries on thousands of teams that that teams that measure high and safety also measure high end performance Google replicated this research a couple of years ago. They shared their story the New York Times. I think exactly two years ago in February 2016 similar kind of thing as Gamasutra. Everyone at Google works on a team. Some teams are better than others. Kind of like the IBM study some teams are better than others and they know they’ve got objective performance metrics for teams. With what they want to know at Google. As a business is these teams that are better what are they doing that’s different. And could we get all of the teams to do whatever those most successful teams are doing so they replicated the research they called it Project Aristotle. They spent a couple of years. They got something like 200 teams to volunteer to participate in the research. They measured all the teams and all these different performance characteristics from the literature and in the Google work the one that correlated most highly to success or to high performance on teams was psychological safety. So they got it they got a similar result that was in the top 5 of the Gamasutra study along with they talked about shared vision stuff like that. These were also of the top five in Google’s work. So they replicated the research just like Gamasutra did for Google for the teams at Google the answer was psychological safety. So that’s that’s really interesting. If you want if you want a high performance team: this is kind of what gameasutra is saying and you want a high performance team you want shared vision and then in Google’s work they’re saying if you want a high performance team you want psychological safety. You want people to feel safe when they’re with each other like it’s safe to take risks it’s safe to be yourself it’s safe to admit you don’t know something that you made a mistake. So you can get the answer so you can improve together as a team faster basically so you can learn faster.
Ron: You also talk about a book by Frederick Lalaux. Is that how you pronounce his last name. Think so reinventing organizations. Yes.
Richard: So Frederick is this Belgian guy with this French sounding name. He talks about things like well you know sort of like fiction of work life balance. Like people on awesome teams are people in high performing organizations. Do they leave part of themselves at home when they come to work. Do they leave their work at work and go home. Not really the kind of bring their whole selves to work and they bring their whole selves back home. And by doing so these these sorts of organizations seem to outperform others. So he has a bunch of case studies in his book Reinventing organizations. Different companies different size organizations and a lot of different industries. And he’s looking at organizations that have a structure and management system that I call humanistic or holistic. His work is based on integral theory and in Lulaux work. He lays out a scale for how organizations fit for how people organize themselves historically. All the way back from the first groups of humans to today. The most interesting parts of it to me are the more recent organization styles because they’re more relevant to us today in the sort of creative work that many of us do. And I call I called the two styles mechanistic or achievement oriented versus humanistic or are holistic. So he might call these he actually color codes them these might be orange organizations that that’s more mechanistic industrial edge sort of management structure versus green or teal this is more humanistic holistic self-management self organization these sorts of things. And what he finds in his case studies is that the the organizations that are that are structured in a way that the people have more more autonomy they care about each other like they’re humans that they talk about each other like they’re people even versus resources. Resources is kind of like an industrial edge way of talking about people calling them people is a humanistic caustic way of talking about people. Just just calling them people keeping them human. When you call them resource it’s kind of dehumanizing like they’re just replaceable. So you know this is like I was just I was just looking at an old blog that I wrote. And I called it The Diamond Age. It was sort of based on Neal Stephenson’s novel from a few years ago the Diamond Age. What do you do differently if you’re running an organization and limited resources, scarcity of resources, was not your problem. Industrial style management mechanistic style management is kind of based on the assumption that that there is scarcity and that we have to be really efficient to make sure we don’t waste anything. What if there was an abundance instead? And there kind of is abundance. People humans for the work we’re doing today were full of potential were full of full of creativity were full of ideas and. And it’s up to us as leaders and people guiding organizations and leadership thinking within organizations to offer these ideas that there is abundance. And there are different and better ways of getting that abundance and getting the full creation of that abundance from a group of people right. So the industrial era way of working doesn’t really make sense. If you’re talking about abundance and creativity and like daily invention which is what we do as software developers and technologists and you know and creative thinkers.
Ron: I have been an audible member for a long time. I’m taking a short break from the interview to let you know how you can support podcast. Today’s episode is brought to you by Audible when we spoke with my case a few weeks ago. He had several book recommendations. One of them was by Liz Wiseman. Her book is titled Multipliers in this book she talks about the contrast between a multiplier and diminisher. The full title of the book is how the great leaders make everyone smarter. You can download this week’s recommendation or pick another audio book for free and support this podcast. All the same time. How cool is that. You can do this by visiting managing projects dossier for Flash audible. Now get back to this interview.
Ron: So many companies today would have this sense of this industrial mystic type approach to how they’ve even approached software development in this waterfall type model that everyone used to buy into now and now there’s so much of a shift towards agile. The philosophy that they describe is that we are just going to take these smaller pieces of work and we’re going to iterate through them and we’re going to we’re going to dig deeper in the in the moment of the work. But there’s so much more involved in that. So I think it supports what you’re talking about where if you look at the Agile Manifesto it talks about compassion having compassion for your… and I won’t use the word resources… and I did use the word resources earlier in this interview. Compassion for your people. And there’s also another attendant that says we believe that the people that are working on these projects are doing the best they can. Having having no taking into account the circumstances that they’re in. That’s the philosophy that you run these projects under. It’s interesting so I’m also a co-host on another podcast called Ardent Development. And we just released a chat that we had with April Wensel. She started an organization called compassionate coder. And this is what she’s talking about is realizing this empathy in I.T. and to your point exactly to say we’re not shoveling coal. We have a task that we’re we are going to do exactly the same replicated task like it’s a machine over and over again because the creativity and the the ability to compete in the market at times means you’re building these you’re creating something new. Right. I can relate to what you’re saying wholeheartedly. Where it does seem like the industry is waking up to it out of an old style of management that is very much industrial. You know we crank out code for a living. We use the exact same thing every day. What’s interesting is when you create something that really is for the first time I’ve had the opportunity to be involved with some projects that we really were doing something for the first time. And it is a very different management mindset that you get yourself into it’s very much in the creative space. You can’t knock on the doors of everyone else that’s done before you just say well how did you do it. You know what. You know what difficulties did you run into.
Richard: Yeah. And and that’s one of the things that’s different about our creative work versus said shoveling coal or whatever. Every time we do it it’s a little bit different even if it’s something we’ve done before. It’s you know it’s integrating that same kind of solution maybe with with different code. So even if it’s something we’ve done before we’re always doing it in a new way. It’s not just stick the shovel in and get the same amount of coal out and stick it in the fire. It’s always a little different.
Ron: Talk to me a little bit about core protocols.
Richard: Yeah OK. So I think you mentioned this book to me it had been on my reading list for a while actually just cracked it open this morning thinking fast and slow. So you know instead of thinking about industrialism and how to get the most efficiency. Well how would you get it. Maybe you think about industrialism how would you get the most efficiency out of creative people. And I think the answer is to tap into the fast brain of people so this is like closer to the brain stem versus the prefrontal cortex. So you know prefrontal cortex this is the logic part of the brain. This is the the part where we ruminate over things it takes us a while to get the right answer. This is the human part of the brain the mammal part of the brain. It’s actually the slower part of the brain. The more brainstem limbic system. Sometimes we call it the reptile brain. This is closer to the top of the spine it includes things like the amygdala. People associate this part of the brain with with with fight or flight with emotion and things like that. This is the fast thinking part of the brain. So what if you could get people to tap into that part of the brain and tap into that part of the brain as a team not just as an individual because remember that the difference between team performance in individual performances is like 2000 X versus 10 x. So if you really want awesomeness you want team awesomeness. What if we could get a team to tap into that fast part of the brain that really creative without without thinking about it and taking a long time? I think this is what the core protocols is about at some level. So the the story the core protocols is the story of this team that you mentioned at Microsoft and Jim McCarthy and Michelle McCarthy. They Jim and Michelle joined the team it was the compilers group it was something like 150 people. It was a mediocre team at the time they joined and somehow it became a really successful team like maybe the most successful team at Microsoft in its time maybe the most successful software team in the industry at the time. So they built it eventually with me and as they transform from mediocre to excellence. The thing that they built was visual c++. It was like for its era the mid 1990s it was a technical wonder it did things that no other product could do. It kind of lowered the bar for people to be able to build applications and write code. It made it much easier than it had been. It was so good it could put other companies out of business like Borland’s was a competitor. Borland went out of business because that because Visual C++ was just so good Borland came back to life a little later. Like at least the name came back to life. Somebody somebody bought the name and started marketing it or that name again but it wasn’t the same company they actually they actually went out of business. Jim and Michelle had this experience of Team awesomeness and they kind of wondered whether they could do it again that they felt like they got lucky which is how I usually feel when I look back at my my best teams in my life. I feel like I got lucky so they left Microsoft. They started up a team research lab and they tried to figure out what were the ingredients for really great teams like that. What they did was they would invite a team in to their lab and they do a five day long experiment. On day one they would give the team an assignment and they would just watch for five days. On day five, everybody there could tell whether the team was successful or not. How good of a product they had built together. They did this five or ten times. They started to notice some patterns and they documented these patterns using that pattern language idea was popular in the late 1990s. So they documented the behaviors of successful team as patterns and they called these patterns protocols because a protocol is a way that humans communicate with each other very structured way for two humans to communicate with each other. Think diplomatic protocols – the way the way diplomats talk to each other between countries. They’re very precise to make sure that there’s no myth that there’s very little opportunity for misunderstanding each other and that’s kind of what a protocol is. As as software developers we think of that as the way the way my code communicates with somebody else’s code we use some sort of protocol. And it comes from comes from the way humans communicate with each other to make sure everything is clear. So then the next phase of their experiment was to say if you know those teams in their lab that were successful were they just lucky or could this be replicable. Could they teach these behavior patterns to tombs and replicate that success. And so for the next five or 10 teams in the lab they did a little intervention. Intervention is the psychology experiment word that means we would do something a little different. And their intervention was teach the core protocols. Teach these teach these protocols to the teams on the first day of the lab and see what happens and what they noticed was every time they taught these behavior patterns of successful teams, to new teams, those new teams were also successful. So that they knew where they were on to something here. They weren’t doing this as a academically rigorous research because they didn’t care about academic credentials or you know that they just wanted to know if they could find the ingredients of team success and do it on purpose. And they did. And they replicated this hundreds of times and other people have replicated it so it’s not just if Jim and Michelle intervene. Then you get successful teams. Other people have have taught these patterns to teams and they.
Richard: Give me a few of these protocols that they would introduce him to some of these teams.
Richard: Yeah. And and as I described some of these you’ll see that they closely correspond to the ideas of humanism or are holistic organizational structures. One of the starter ideas is freedom or autonomy or opting in. Right. So “check out” is that one of these patterns. Every pattern has a name and then and then some. Some context in which it’s applicable and a way to a way to do it yourself. So check out is the name of one of the patterns check out you use it whenever you can’t stay engaged with your teammates and that might mean you have something more important to do. That might mean you just don’t feel right at the moment with your teammates for some reason. It might mean that just you just need to go clear your head and checking out works like this. You just say I’m checking out and you leave the room.
Ron: So I’m picturing say say a standup. As an example you’re a project manager you’re running a standup in agile and you get all your team together and you’re all standing in the room and as quickly as you can you say what you did yesterday and we’re going to do two more. And somebody in the corner says I want to check out. It’s funny I was having lunch with a friend of mine and I was telling him about this idea. And I wanted to debate with him how he would feel about it as a manager because in some companies what pops into the manager’s head is well that’s part of your job. You know Sadly or Billy whoever wants to check it right now you’re actually getting paid to participate you’re in the room right now. So some people will respond to this negatively and say it right. Exactly so. So so talk a little bit more… can you challenge the person after are you not supposed to challenge them?
Richard: There’s no challenge because that would that would eliminate the psychological safety for being able to do it. Right. So here’s why it works. Oh and that that’s that idea of what we’re paying you to be at this meeting. So you have to stay here. You have to participate. That’s mechanistic industrial era kind of thinking. We’ve got we’ve got resources in the room and we want them to perform the best. And you know it’s resources again instead of people. That mechanistic industrial age kind of management. The the evidence. You know this is evidence based by watching high performing teams. The evidence is that on high performing teams people opt in to be together. People are on that team voluntarily because they want to be because they believe in the vision of that team because they have a shared vision with people on their team not because somebody commanded them to be on that team. Now of course he can command people to be on the team. But in the evidence from watching high performing teams they weren’t commanded to be together on the highest performing teams they’re together because they want to be. And this is this is kind of like the way at least half the teams at Google for example are formed they’re formed organically because people want to work together on a team. That teams engineer at Google gets an idea and their 20 percent time and they’re really keen on the idea they get some other engineer to join them on it and that person 20 percent time they think they’ve got something good they share it with. And of course they’re doing it together because they want to share it with. They find a project manager or somebody like that to join them on the team. Then nobody is commanding that project manager or join them on the team to do it because they like the idea and they like these other people and they think they’ve got something that they can do together. And then they just recruit other people to join the team.
Ron: It brings up a very pleasant feeling of what if everyone on your team as they were driving into work were choosing. You know for instance you’re walking you’re walking to your next meeting happens to be a stand up and your peers says I have to go to this stand up now – ugh. Or I’m choosing you know I’m I’m going to stand up and then you know the attitude behind it speaks volumes. I wonder what the percentile is of the people and this was what the debate was over lunch with my with my friend that we debated this. I said to them I actually think if the employees are choosing to be there that very seldom would that check-out happen because your thought process is like I’m choosing to do all this stuff. This is where I actually want to be right now.
Richard: Yeah so people often ask me like what. Well what happens when you when everybody decides to check out or ever decides to pass on what’s going on with the team. Well that’s probably behavior of people on a team who are forced to be together who don’t really have a shared vision. They’re not really into the product they’re building they should probably all find a team they want to work with it instead of being. If you want if you want a high performance team then we want people who want to be there voluntarily not people who are forced to be there. And if you want a lower performance to him then you can command people to be on that. And we know from the resource what the result will be.
Ron: If you took this approach though, you would find out so much earlier. You know you haven’t gone through all the painstaking work that the team didn’t want to be a part of. And then realize we’re out of luck. In that scenario where they said what everybody in the room are. So yeah it gives you an opportunity to say oh I’m not understanding… Something’s terribly wrong and we have a chance to talk about that.
Richard: Right and agile we have this expression we we at least say, I don’t know if we all believe it, but we just say it’s good to fail fast or we like to fail fast. Right. So what if we could fail really fast with even the people who were on the team building the product. What if we could know by the end of the day whether this is the right group of people why do we have to wait six months and waste all that time and waste all that money. Let’s just find out today if this is the record that people.
Ron: I came across another protocol in the research. You probably pointed it out in your talk or I found it somewhere. Was this sense of if you’re holding a meeting you’re actually agreeing that you will be present if you’re if you’re working with people. So for instance you would be sitting in a room where a meeting is happening in your laptop is going and you’re typing something or you’re checking something on your phone. But this is almost a team promise that you say I’m going act this way so I will be in the room I’ll be present and I’ll give you my best because I’m here.
Richard: And if you can’t actually leave. Yeah it’s a commitment to be engaged when present and if you can’t be engaged that’s when you leave. That what checkout is all about checking out of the room when you cannot be engaged when you’re present with your team or you’re in the room.
Ron: You are saying I am fully engaged.
Richard: You got it. Your physical presence is a signal to everybody else on your team that you are totally there not just your body but your mind and your spirit your emotional self. Every part of you is there fully.
Ron: So how do you gauge that? I heard some examples of – you would actually have these words. I feel sad. I feel mad. You know whatever. And this is a this is a pattern that you would go through with the different folks that have just joined your meeting is that right.
Richard: Yeah. So, this is back to Jim and Michelle’s work watching the high performance teams and their lab than reteaching these patterns to additional teams. They noticed that on high performing teams the successful teams in their lab. The people on those teams would share their emotional state with each other no matter what it was and they wouldn’t get judged for it and nobody would try to fix it. They were they were welcome for who they were and how they were no matter what. So this is a characteristic of you know the evidence is watching high performing teams the characteristic is on high performing teams. People share their emotional state and they don’t get punished for it or ostracized for it. It’s just part of who they are and we welcome who they are. So the behavior pattern as a as a protocol is you just say how you’re feeling. You say I feel mad and maybe you explain it. I feel glad and maybe you explain it so the people on your team can understand you a little bit better in your current emotional state. And then when you’re done everybody says welcome. OK – it’s kind of corny that everybody says welcome after you say I’m feeling sad about blah blah blah. But what happens when that when we do that with each other is it’s sort of it’s a really nice acknowledgement from everybody on the team that they heard you and that it’s OK that you’re part of the team no matter what your emotional state is. So yeah this check in protocol is sometimes I call it the emotional Check-In. It’s a nice way to… It’s a very effective way to reengage with your teammates anytime.
Ron: Do you find that there is a percentage of the population that says oh this is wonderful I can see how this is humanistic. I love it. And there’s this other percentage that says “Blaw” well why do we to do this stuff. I wish we didn’t like what. So what’s your percentage of those groups. What’s what’s been some of the reaction.
Richard: Yeah I’d say if we divided the world into these more mechanistic organizations in these more humanistic organizations I think in the Lalaux’s book he says something like 80 percent of today’s organizations are more like mechanistic and maybe maybe 10 to 20 percent or more like humanistic. And if you try to share something like this with the people who are in the mechanistic side of things which which is most people it just doesn’t make sense to them and will say that’s OK. If this doesn’t make sense. You know nobody’s going to force you to do it. If you’re sort of at the cusp between mechanistic and humanistic maybe you’re open to this and that’s exactly who this who this works. The core protocols is for people who are sort of at that cusp and who want to want to operate in a way that’s more humanistic individually or with their team or with their whole organization.
Ron: Well I for one would welcome the move away from the mechanistic organizations into a humanistic.
Richard: And there are there are a lot of people like you, right. It’s a big planet. We’ve got seven and a half billion people. Twenty percent of the big number is a big number so there’s a lot of people who are open to this kind of way of working together.
Ron: Well Richard I think I could talk to you all day about this stuff. This is this is a very deep topic. If people wanted to learn more about your work or attend one of your sessions where would they find you online?
Richard: Visit my website kasperowski.com. I’ve got a newsletter you can sign up for. Lots of people are interested in high performance teams who are interested in this humanistic holistic way of working. Those are the kinds of people who subscribe to the newsletter. So if that’s you, know what to do.
Ron: Awesome thank you for this. I’ve enjoyed this very much. Maybe I’ll get a chance to see you in person at one of these conferences.
Richard: I sure hope so. Thanks so much Richard. My pleasure. Thanks a lot.
Outro: Thanks for joining us for this episode of the managing projects podcast find show notes and more at ManagingProjects.ca and follow us on Twitter at Manage_proj. If you enjoy the show helped us out by recommending it to a friend or leaving a review on iTunes. Talk to you next time.
