How to Enable a High Performing Deal Team

I'm Kisam Patel and you're listening to M and A Science where we talk with deal professionals and learn valuable lessons from their experience. This podcast focuses on stories, strategies and what actually happened during M and A deals. Welcome to M and A Science. I'm here with Harvard instructor, author and speaker Richard Kasparowski. Richard is an expert on building high performing teams using Agile and core protocols. Today we're going to discuss what characteristics create high performing teams and how M and A practitioners can implement these traits to close deals faster and set their deal team up for long term success. Well, Richard, if you want to maybe just kick off with a little background on yourself.

So I'm Richard Kasparowski. I'm an author, teacher, coach, consultant. I focus on high performance teams. I've written a couple of books about high performance teams. For the work I do with my clients, I use these tools. I use a tool set called the Core Protocols. I use a tool set called Agile Software Development or Agile Product Development and a tool set called Open Space Technology. I created and teach a course on Agile Software development at Harvard and you can connect with me and learn more at my website, kasparavsky.com hey, thanks Richard.

So I know we've had an initial conversation when I reached out to you, really looking to explore ways that Agile can be implemented and introduced and M and A. And I want to first pick up on some of the interesting points that you've brought up around team research that correlates to highest performance.

There's like five or six decades of academic research published in peer reviewed journals on teams and team performance. It's been spearheaded by psychology departments and business schools. And the question is basically this, some teams perform better than others. Why? Right. So people have been trying to figure out why for about six decades now. What they've found? Well, they've identified as many as 250 different characteristics of teams that depending on the researcher and the methodology and what they were looking at, there's over 200 different attributes that correlate to higher performing teams. And so the question becomes, well, which one of those? Because we can't try to improve 250 different things on any particular team or in any organization. It's just too much stuff. So people have honed it down to two primary things. The two primary things are psychological safety and team emotional intelligence. Psych safety. This research has come to the forefront since the mid-1990s. Actually, the team emotional intelligence stuff has come to the forefront since the mid-1990s as well. So all the research Supports the idea that psychological safety and group emotional intelligence correlate to better performance. Teams that measure higher, and these are things that you can objectively measure. Teams that measure higher on psychological safety and teams that measure higher on team emotional intelligence, they measure objectively higher in their performance. So that's a two minute intro to it.

Well, I'd love to get some specific examples just to better understand.

So for psych safety, psychological safety, the idea is that you feel safe when you're with your team or you feel safe when you're at work. It's like you can take risks without fear of being embarrassed or any fear that you might get fired, any fear that it would hurt your career in any way. You can try out new roles, you can be yourself, you can admit you don't know something, you can ask for help. These are characteristics of psychological safety. And then team EI extends from the individual EI stuff that Dan Goldman popularized in his book emotional intelligence back around 1995. Team Emotional Intelligence is the sense that we know how we're feeling as a team and we can articulate it and we can behave appropriately. So, like, if I'm angry or if we're angry about something, we don't go over to the next team's workspace and start kicking down their computer screens, right? We go talk to them about if this is governing your behavior appropriately, no matter what your emotional state is. And we can also infer the emotional state of other teams and even the whole organization. And we can influence the behavior of other teams. And we have enough knowledge of how the organization works that we can influence teams and people within the organization to do the right things, both for our team and for the good of the company as a whole. And psychological safety is a subset of this thing called team emotional intelligence. So you feel safe when your team is experiencing this sort of emotional intelligence. Teams that measure high on group emotional intelligence, they also measure high on things like social capital, which is. Okay, this is the M and A podcast, so we know what capital means. Social capital is like investing in relationships with other people or other groups in a company in a way that you get a payback later on. And teams that have good investments in social capital, well, it turns out they have high executive support. And then it's sort of obvious when the executives support your team or your business unit, well, they get impediments out of your way. They unblock things for you, and they give you the resources you need to get the job done. And so obviously those teams are higher performing. Those teams are successful. This is sort of a cascading effect from psychological safety to larger scale team emotional intelligence. It includes psych safety, it includes social capital, includes measurements of executive support. All of that stuff goes together to teams that measure high on those characteristics. Those teams perform better than any other teams.

That makes a lot of sense. I'm a pretty big advocate of displaying vulnerability to the team. Just encourage some of that comfortability with identifying where our weaknesses are and sharing how we can improve with each other in a positive way. Where would be a good starting point for a team that wants to identify these areas as opportunities to improve? How do you see it coming for a team totally new to this in the real world?

What I often hear from people and my clients engage me on this. In particular, people will say, or team leaders, company leaders will say, we've heard about this psychological safety stuff. We've seen Amy Edmondson's TED talk. We read the New York Times article about Google and psychological safety and how they replicated the research. We want to know exactly how to do it. So there's this other related body of research, this is non academic research. It's totally in the field. It's contemporaneous. It began in the mid-1990s. This is the body of knowledge called the body of practice, called the core protocols. So the core protocols are a set of behaviors. So imagine that you could watch high performing teams and just like observe and write down the behaviors that you're noticing and you watch another team and you start to notice similar behaviors. You watch another high performing team and you notice similar behaviors. So this is what two people, Jim and Michelle McCarthy did back in the mid-1990s. They watched high performing teams, they noticed their behaviors and they noticed that there were common behaviors between high performing teams. They wrote these down sort of as recipes. They had an idea that if we could figure out the behaviors that high performing teams engage in and transmit those behaviors to other teams in a way that those other teams could learn those behaviors, could those teams be high performing as well? So that's what they did. They wrote down the behaviors as recipes, they called them protocols, and then they tried it out. They did this intervention, they took random teams and intervened by teaching them core protocols. It turned out that every time they did it, those teams were successful and they tried it in various companies. Other people have done it and reproduced it. They never published this academically. They're not academics, they're practitioners. They didn't care about being published. All they cared about was helping teams be effective. Fast forward more than two decades now to 2019. I've been collaborating with one of the researchers, Steve Wolf, he's one of the researchers with team emotional intelligence. We've been finding that the behaviors of the core protocols very, very closely match the measured emergent states in team emotional intelligence and psychological safety. We've done enough research that we could call it. It's probably a valid case study. We wouldn't call it publishable science yet we've got a really good case study and we're continuing to do this research with different companies, different organizations and their teams. If we teach teams core protocols, do the behaviors emerge? Do they actually engage in these behaviors? Do they measure higher on psych safety? Do they measure higher on emotional intelligence? Do they measure higher on performance? So far, the answer is yes. It turns out that McCarthy's discovered a set of behaviors that you can use to induce higher ei, higher psych safety and performance in teams. And so those behaviors are called the core protocols in the tool set that I use when I'm working with teams.

That's interesting. So that's actually possible to teach teams.

New behaviors, but for organ teams that want this, yeah, we have a reproducible way to train them in these behaviors. And really what it is, it's to help them build new habits, because that's really how you learn things. You build a habit and you do it. So if we turn these behavior patterns, these recipes into habits, well, then the teams start to do them with regularity and then we start to see the measurable changes and the measurable better results.

When it comes to foundational skills, what are the foundational skills teams must possess in order to work together more efficiently, productively?

So foundational skills for this stuff, Foundational skills for. Well, we can draw this from the practices of the core protocols, these recipes. One foundational skill is everything is opt in and it's okay to opt out. If you watch high performing teams, you'll notice that these are groups of people who are together because they want to be. They're working with the people they want to work with, they're working on the projects they want to work on, and they're working on them in the way in which they want to do it. A good example of this is that something like half of the projects at Google start organically. Somebody has a good idea, some engineer has a good idea, and they just start working on it and they share it with a friend and that friend joins. Well, now it's a project. We got two people working on it and they show it to a project manager, maybe a product manager at Google. And the product manager likes it and opts in, joins that group and starts looking for other people to join the group and starts spreading word about this project or this potential new product to other people inside the organization. These people are opting in, they're working on this project because they want to, and they're doing it in the way they want to. And they're choosing to work with a group of people that they want to work with together. Right. So everything is opt in and it's okay to opt out. When you make it explicitly okay to opt out and people practice it and get positive feedback that opting out actually is okay, well then they start to feel safer about saying no to things and managing their own time and working more effectively for themselves, for their team and for the whole organization. So that opt in, you might call it freedom or liberty, you might call it ability to opt in or ability to opt out. That is the foundational skill. When you watch high performing teams, they're together because they want to be, they're working a thing because they want to. And if they have something more important to do, they opt out and they go do that more important thing. So that is the foundational habit.

That's interesting. I feel like in M and A people tend to get pulled into these deals, but there's probably aspects that could be introduced from a larger corporate organization perspective as well.

Yeah, well, maybe not M and A, but if you're looking at like a private equity takeover situation, the investors are looking at what they perceive to be an undervalued business and they're buying it for what they perceive to be a good price and they think they have techniques to increase the value of it. So take the techniques of high performance teams, take these core protocols, and you will almost definitely raise the capabilities of the acquired organization. You know, assuming that they want that for themselves, that they want to improve because they have to opt in themselves. And there are other tools and behavior patterns in that core protocol set or even in Agile. One of the patterns is, well, asking for help is a pattern on successful teams. Forcing help on people is an anti pattern. And I've experienced this personally every time I've forced help on somebody or assumed somebody needed help. I had this boss once, he was from somewhere in Great Britain and he had an accent that was different from most of ours here in Boston. Okay. And we have our own accent here in Boston that sometimes people don't understand. That's true, but his accent was A little different. And his vocabulary, his word choices were a little different. He was trying to explain something to the team one day and my perception was that people weren't getting it. And so I jumped in. This was sort of like forcing help. I jumped in and I tried to explain what he was saying on his behalf and a little bit of telling him why they weren't understanding. And he looked at me like I was his new archenemy. I was forcing help and it wasn't working. He didn't want the help. He wanted to explain it himself, his way, his words. That was the wrong thing for me to do. That's the anti pattern, the success pattern is that when people want help, they ask for it, right? And they ask for it as much as they want. On lesser performing teams, you might notice this behavior. Somebody gets stuck on something, they don't know how to do something, they've got a problem that they haven't seen before and they try to figure it out themselves or they're afraid to ask somebody else to help them on it and they get stuck. Takes an hour, two hours, half a day, a day, three days later, they're still stuck, they haven't asked anybody for help. That's characteristic behavior of a lower performing team when people are getting stuck, right? On higher performing teams, people might try to solve the problem themselves for a little bit, but notice really quickly when they need help and go ask for the help, they get unstuck in half an hour. And then on top of that, there's another behavior pattern for giving and receiving feedback. Forcing feedback, we'll call it an anti pattern. And it's a really common anti pattern that people engage in. The boss gives feedback to an employee. The boss gives feedback to a whole team. The VP gives feedback to a large group of people. Forcing feedback on people usually doesn't work. Asking for help and saying, I want feedback, that always works because people are open to it, they're receptive, they want to hear your ideas. One person can get this kind of feedback from five or 10 other people. And it's a way to collect everybody's genius together into a, like a, sort of like a super genius. You get everybody's ideas, everybody's open to sharing, everybody's open to hearing ideas with each other and from each other. It's sort of like if you imagined, okay, most, most people working, most people listening to this podcast will say have above average intelligence. I don't know what the number would be, but let's say 120 IQ points, right? Regardless of whether you think IQ is a measurement of intelligence, we'll just use that. If you had 10 people together, you'd hope that you would have 10 times 120 IQ points of team intelligence. Right. So would that be 110020 or 1200 team intelligence points? Yeah, see, I need some help with my intelligence points. Now. If you've got anybody on the team holding the team back, well, the team's total intelligence will probably be less than that. Right. And that would be a value creation opportunity. If you're thinking about it in M and A terms. We've got a team that has the potential of over a thousand IQ points together, but they're actually exhibiting only 800. That's a value creation opportunity. And you can use some of these high performance teams, habits and tools to release that value. Oh, and it's even better than that. It's not just that it scales linearly with each individual on the team. So if you have a 20 person team, it's going to be 2,400 IQ points. It's more like it's almost exponential. You get 10 people together and they're really working effectively. It's not like you get 10 times the average intelligence. It's more like you get to the 10th power of total intelligence on the team. They really become super genius as a group of people together. Like you've figured out a way to connect their brains together seamlessly. So it's more like one giant super brain than a collection of individuals. This is the sensation of being on a super high performing team and everybody's experienced something like this at some point in their life. The question is, how do you reproduce it in a way that it can happen every time with every team? And that's what these habits or these behaviors or these protocols, these core protocols are all about. How can you reproduce that state every time?

That's an interesting perspective. I know myself. I'm guilty of force feedback. So, Richard, you teach Agile at Harvard?

Yeah. This was an idea I've had. I grew up as a software developer. I rose as a software team leader doing all kinds of things and doing different startups and in larger companies. Along the way I discovered this stuff called Agile Software Development. First as a practitioner, then as a team leader. And what I noticed was every time we did Agile by the book or Scrum by the book, we got good results. In fact, we got great results. My first experience of doing it all by the book was at a startup that was building in the mid-2000s. We were building mobile phone apps before iPhones existed. So it was really hard work. We were ahead of the curve. It was challenging technology and it was challenging business, business space, because people weren't used to running mobile apps on their phones and a lot of the phones didn't even offer the capability. But this is where I first used Scrum and we pretty much did Scrum by the book. We got our customers in with us, we built bespoke mobile apps and we got our customers in with us and showed them the work incrementally as we went. And we deployed these new apps in the backend servers to production every two weeks. And people got to try them out and tell us what was working, what wasn't working, and actually, you know, we were inviting the feedback and we got really predictable. We got really good at forecasting so that when our CEO and our salespeople would go out making new deals, they could accurately price what the product was going to take to build for this new bespoke mobile app product, and that they could price the deals appropriately based on how predictable we were as a technology group. This was a true success. We were really good at agile, we were really good at Scrum. What was frustrating as I started doing this more and more with different teams and different organizations was that we have to teach it to everybody every time we do it. Like, like these are foreign ideas people are used to. We'll call it the old fashioned ways of project management, where you do, you spend a whole lot of time doing a big design, you spend a whole lot of time creating the product, then you spend a whole lot of time doing quality control and finding all the problems and the projects are always late and people are always disappointed, right, that that's what people traditionally are used to doing as they build a new product. But what if instead you did all of those really rapidly, like every week or every two weeks, you did a little bit of design, a little bit of building the product, a little bit of quality control, a little bit of delivery, get a little bit of customer feedback and know every week or two whether you're on track and then make adjustments. And it turns out that when you do that, and this is kind of like agile, by the book, everybody's happier. The people on the teams are happier, people building the product are happier, the stakeholders in the company are happier because the customer is happier and their retail customers are happier, the people that their end users are happier. And I noticed that we had to teach this to people over and over and over and over. And this is like this has become an Industry teaching Agile to people. The big consulting companies, Deloitte, Accenture, bcg, they're teaching Agile to people as ways to unlock more value. Now, I think that's stupid. Why don't people come out of school knowing this stuff already, Right? So this was my dream. Make it so that people coming out of computer science and other programs from universities just know this stuff and it's just how they work. And I was fortunate enough to be invited to teach this course at Harvard. About half of the students that I have, they're team members, team leaders, they're directors and VPs who want to know these skills and bring them into their organizations so that they can unlock the latent value that's hidden within their organizations by building products the old fashioned way instead of the more nimble, more agile way.

What would you say are the biggest takeaways that you want your students to take away from your course?

Well, if you look at Agile and back in 2001, a group of people got together and they sort of laid out a manifesto for better ways to build software. They called it the Manifesto for Agile Software Development. The first thing that they have on their manifesto is that we value individuals and interactions more than we value processes and tools like, okay, processes are good and of course we need some tools, but we value people and people interacting well with each other more than anything else. And it turns out that when people interact with each other, it turns out that we get better products and our customers are happier and the build team is happier. The second thing is we value a working software product. We value a working product more than documentation about what that product might look like someday in the future. Right? The proof that you're on track, that you're delivering what your customers want, is you have a piece of the product that works, they can get their hands on it, they can try it out, they could install it on their phone, they could install it in their back end. They can actually see if it integrates with the rest of their back end or if it's a retail mobile app that they experience joy when they're using it, that's doing something that they want and need and they're getting some value from it. These are some of the foundations, these.

Are really interesting points. So our company mission is to make M and A more collaborative. And one of our goals is bringing Agile to the aspect of being utilized in M and A transactions. We've identified a lot of similar challenges. Some of the things that you've described where there's just a variance in predictability in terms of when you do a project and new information comes, things change and et cetera. I liked your perspective about the collaboration with teams because we see the same issue where people are working in their silos and maybe they're responsible for an aspect diligence or integrating a component of a company. But then there's this more of a realistic sense. If there is this team approach. Instead of working in silos, going down a checklist, looking for doomsday tomorrow type of risk in a transaction, a team can actually connect the dots and identify the underlying risks.

It could be as simple as talking to each other once a day. This is one of the behaviors in scrum. You talk to each other once a day. That sounds kind of funny. Of course we're going to talk to. No, really actually talk to each other about the project at least once a day. The anti pattern is we only talk to each other when things are failing, right? So it's always tense and stressful. Somebody's always blaming somebody for not having done something or not having done something properly. That's bad. Relationships, you know, think of the best relationship in your. In your life. I don't know if you're married or you have a significant other. Imagine that you only talked to your significant other when something was going wrong, right? This is like all negative feedback all the time. That's not the basis of a successful relationship where you're achieving your goals together. Same thing in work teams. If you only talk to each other when things are going wrong, it's all negative feedback all the time. And it's not the basis of a good relationship or good results. So you just talk to each other regularly. At least once a day, maybe twice a day, maybe all the time. Maybe you have a shared work area. You know, meetings kind of suck, but what if the way you worked was the meeting? Everybody's had this experience where something goes wrong. You get together in a conference room, you change the name of the conference room temporarily to war room and you work together on the problem until it's solved. And it might take an hour, it might take a couple of days. Those are always the best work experiences. We're super aligned on solving the problem together. We're all in on it. We're communicating quickly and effectively. There's really fast feedback. When I have an idea, I share it and I get feedback right away. If that's a really good way to work, why don't we do it all the time and work together really well all the time? That's kind of like good Scrum or good MOB programming. And you could do this with anything, like just that war room idea. Just work together like that all the time.

I like the way you're describing it and really breaking it down to techniques because I think that's one of the challenges when we're introducing agile in the industry. It's relatively new to it. It's tough to introduce a large framework like Scrum with some technical jargon in there and we really want to simplify things. And I like the way you're describing your current approach is just can you take one little piece and introduce it and see how it works? And I want to talk a little bit more about that in terms of how do you actually get the transformation to happen with a team and what does that look like? Are you building a roadmap? How is it taking? Because I think that's going to be our big forefront challenge in bringing this to a new industry.

So one of the patterns is to maybe start with one team that really wants to try this and really wants to do it, or maybe they've done it previously in some other organization and they know what to do. Try it with one team, get one team doing it really well and then have them as a success example. Other teams, other business units might be attracted to that success example and they'll want it, they will be opting in for it. So people will notice that it's working and they'll want some of that. They'll ask for it. They will ask for that training class, they will ask for that extra coaching to help them along with their Agile for their team or their team of teams or their business unit. Another one of the success patterns for Agile introduction in a company is to do it using Agile. So you'll have an Agile change team, an Agile executive team, call it what you want, and a group of people who are passionate about Agile, who understand Agile, who are aligned with the company goals and aligned with the goal of unlocking this latent value and people who have influence in the company to, that's your Agile change group. This will be composed of people who are domain experts in agile. Be composed of people who have business influence within the organization. So you know, maybe managers, directors, executives, VP level people. That group of people, they will play Scrum or Agile, you know, whatever Agile framework they want to use. They will build a roadmap, we'll call it a backlog, an ordered to do list of things you want to be true in the future with measurable results for each thing and little by Little, maybe week by week, they'll make a tiny project plan for changes they hope to affect that week. They'll talk to each other every day during that week about their progress toward their goals. They'll talk to each other at the end of the week and share their progress with each other. Sort of demonstrate what they've done to each other and to anybody else in the organization who's interested. And they'll do a retrospective. Retrospectives are probably the most valuable thing. If you ever worked on a project that lasted many months, maybe even more than a year, and at the end of it they did a thing called a post mortem, we just give each.

Other high fives and move on.

It's either you give each other high fives and move on, or you complain about all the things that didn't go well and you move on and nothing changes. You start the next project and nothing changes. You do all the same things that you did last time, whether they were good or bad. Postmortems are ineffective. Right? And they happen. Postmortem really means after it's dead. Postmortems happen after the project is dead. So they have no impact on this project and they really have no impact on the next project because it's a different configuration of people, a different team. They're not getting fast enough feedback to actually learn effectively and make a the changes. So one of the typical Agile practices is to do these. We call them postmortems, but do feedback sessions with the team. They call them retrospectives. In Scrum, do a retrospective every one or two weeks, look at what's happening, look at ways to help the team be more effective, look for ways to unlock the team's latent value and the organization's latent value. And do that every week or every two weeks and actually do it. Once you have one idea, if you have one idea every week for how to make the team or their company better, well, by the end of the year, you've had 52 ideas. And it's not just like you have 52 ideas and you fixed 52 things. It's like the first idea from the first week, it's sort of like compounding interest. That first idea, the interest on having made that improvement will compound throughout the rest of the year. The second week's idea, well, the interest on that second week's improvement will compound. You'll get greater and greater benefits throughout the year. By the end of the year, you've had 52 ideas to make things better, and you've had all the compounding interest from the 52 weeks, the team and the organization are going to be so much better doing that versus doing a post mortem at the end of the 12th month.

I see that in our industry because a lot of our clients are working on several transactions throughout the year where just in their practice sense, it would make a lot of sense to do that on even a per deal basis.

Yeah. So at least talk to each other once a day and maybe once a week talk to each other in a slightly different way. Looking for at least one thing we could do to make the team and the particular project work better.

Are there any specific techniques that you've seen that make transformation happen or easier?

Specific techniques for making transformations happen are making them easier. One of the techniques is this idea of the Agile Change team or the executive Agile team. It has different names. Jurgen Hesselberg wrote a really good book. It's really the book about enterprise scale Agile Change. I think it's called Enterprise Agility or Unlocking Enterprise Agility. He just published it a few months ago. It's in the Mike Cohn Signature Series from Addison Wesley. It is the book about organizational enterprise scale, agile change. It's got a lot of different ideas and patterns in it. One of the patterns is you have an executive Agile change team, people who are in on it, people who know enough about Agile, people who have influence to actually affect the changes in the organization. Another idea from Jorgen's book is an idea of waves of change where the first wave would be. You need help from somebody from outside the organization to teach you what agile is and teach you how to do it effectively. And that gets you started both at small scale, at team scale and at larger scale, teams of teams and maybe whole business units. First wave is you get help from somebody from outside. Second wave is you form your own internal agile groups of people who are sort of like those outsiders. You grow your own Agile trainers, you grow your own agile coaches, and maybe the outsiders are mentoring them and maybe you create your own internal agile community of practice. And so they're like industry groups in practically every city around the world. Agile New England Agile New York City, Agile, you know, Agile Bay Area, Agile Seattle. Do one of those inside your company. I did this when I was working for Nokia for a while at the office based here in Boston and at the office in Finland. In the office in Boston, I started up Agile Nokia Boston. It was our internal Agile group. We shared ideas from people who knew things and had success stories from their teams, sometimes brought in external speakers to Share things from the outside. Spin up your own agile community of practice. Start your own agile industry group within your company and spread the knowledge that way. And the third thing is, well then you don't need outside help anymore. This is the third wave and you're just on a self sustaining path. You're doing continuous improvement as a company, you're doing retrospectives on how to make things better and you're enacting the ideas.

That makes a lot of sense. Is there certain things that you've seen with teams in terms of characteristics that make them more amenable to an agile change?

The most important thing that makes teams amenable to agile change is they're interested in it. This goes back to the opt in idea. It's something they're interested in, at least enough to try it out for their team. You can try using the word experiment. We're going to do an experiment. That company that I mentioned where we were doing bespoke mobile apps. I introduced Scrum little by little with that group. It was my first Scrum experience and I just did it little by little. I was a little bit afraid. I didn't want to tell anybody that there was this thing called Scrum and we were doing it. So we did it little by little. Our first experiment was we're going to talk to each other once a day and I know everybody's busy. We're just going to do this for at most 15 minutes every morning. We're just going to get together over here and talk to each other and if it doesn't work out, we'll stop doing it. Right. This was an experiment and the experiment had a sort of a measurable goal. It was sort of subjective. If it doesn't work out. Oh, and if you get in trouble from anybody, make sure you tell them it was my fault. So I made it safe for them to get in trouble for not doing work for 15 minutes. You know, air quotes around that not doing work. And then I introduced another thing. The next two weeks after that we tried two week long sprints or I was trying two week long sprints as I, as I did this. What if we put some project progress trackers on the wall where we're meeting once a day and we'll have, you know, we'll have something that we can point to and talk about and sort of gauge the progress of the project as we're talking about and we'll try it out and if it doesn't work, we'll stop doing it. And you know, if anybody gets in trouble for putting stuff on the wall, Just tell them it was my idea, so I'm the one who gets in trouble. Two weeks later, we tried another idea. What if we, I don't know, how about, how about at the beginning of every two week period we make a. We make a little project plan for what we think we'll get done by the end of the two weeks. This is just like the idea of a sprint planning day. We'll make a tiny project plan. What do we think we'll get done together? And then we all get aligned on what we're going to do for the next two weeks. And you know, if anybody gets in trouble for spending half a day with me, just tell them it was my fault and everything will be all right. And if it doesn't work, we'll stop doing it. I just did this over and over with every different ingredient of Scrum by the Book and so that by the end of a couple of months we were doing Scrum by the Book and everybody was happy with it. There's one idea, you could try it little by little. They used to call it. I tricked people into doing Scrum, you know, by the end of a couple of months it was like, oh, by the way, we're doing this thing called Scrum and it works really well, doesn't it? Isn't that cool? And people were happier and not just the people on the teams, but the stakeholders, the executives in the company and our external customers. So that's an idea. And just having people opt in to the ideas, whether it's a big we're doing a Scrum now kind of idea, or a little idea like let's try talking to each other at least once a day. Or one of the more modern agile ideas, like let's experiment with that war room experience. Let's do that for a normal piece of work instead of an emergency piece of work. Let's do that experiment and see how it goes. Right? And you don't even have to tell anybody. It's called mob programming. Just try it out.

I like the incremental approach.

It's small changes so they're safe and people can try them out and collect their own data points. This is a really important idea. Let people try it out and collect their own data points and reflect for themselves on whether it work and decide what they want to do next. What's the next change that we want to make for our team or for our business unit so that, that we can be even better. That idea of doing retrospectives that's one of the most powerful ideas that there is.

One challenge in M and A is the structure of teams. Sometimes you have teams that are continuously working on multiple transactions and then you have teams that are constructed temporary. They may be working together for a few months or several months. How do you see a rollout of Agile in those different circumstances?

Let's take those as two cases. One case is a. We'll call it a stable team working on many different things. That kind of team. There's a lot of agile techniques that can help with that. One of the techniques, well, we've talked about a lot of these. Talking to each other at least once a day, maybe making a little weekly plan, getting together at the beginning of the week and talking about what you hope to accomplish together each of the individual M and A projects and talking to each other at the end of the week. How did it go and what could we do differently so that things go even better and we enjoy this more and we're more successful next week. Just foundational scrum ideas there and making the work visible. Like maybe doing this on a big screen in a shared space, maybe doing this with, with paper and marker tools, post its on a wall just to make the work visible so we know what's going on. We can see the progress day by day and week by week. So for a stable team working on multiple projects, this is really just a special case of an agile team working on multiple features in a software project or multiple work items and talking to each other frequently valuing individuals and interactions, valuing progress toward the goal versus talk about progress toward the goal actually doing. Then the other case would be either dynamic teams, people working on multiple teams simultaneously or short lived teams. They're together for a period of time, then they disband and people form a new team to work on another project. I think this is where the core protocols, those team building habits are really, really valuable. If you've built in the habits for people to form teams quickly and effectively, then they can re team frequently, quickly and effectively. Some of those habits are that opt in idea and opt out when there's something important to do and people trust you that you're opting out for a good reason. You know, I just have to go work on that other more important thing or it could even be my wife called me and I really have to talk to her right now because it's something about school for our kid or whatever it is. Another foundational idea there for quickly reforming new teams. Quick team building is share how you're feeling with each other. Share your emotional state and maybe even do that as part of the we talk to each other at least once a day. We share how we're feeling with each other at least once a day. I'm happy today about blah blah blah. I'm sad today about blah blah blah. I'm mad about blah blah blah. I'm afraid about something. Ooh, nobody's ever been afraid at work before. This is interesting. We better pay attention. And this is a really easy way to build group emotional intelligence. We actually understand how we're all feeling together and a really easy way to build safety. In many corporate environments people don't share feelings because it feels this sort of vulnerability about how I really feel. It's not safe to do that. If you actually get into that habit, then it feels safe to do it with each other. And going back to the science and research, we know that teams that measure high end safety and high on emotional intelligence, they perform better. So build that into your that every day we talk to each other meeting every day we talk to each other about the project and we share how we're feeling. We share emotional state with each other. And there's other foundational team building habits that you could use for that condition. When teams are short lived or when people are working on multiple teams, if everybody in the organization has that skill set, then working together in different team configurations is easy. We know how to do that. It's just a different group of people that we're sharing that we're opting into and we're sharing our emotional state with and we know we can ask for help from each other and we know we can. You know, we have good techniques for feedback and decision making and conflict resolution. All these team habits are easy. There's a company here in Boston, Davis Square, they did a project with the Harvard University Libraries and I was involved. I taught them a little bit of Agile and I taught them a little bit of these team building core protocols habits. They've been blogging about how successful they spread these ideas through their company, the team building habits. And they've been blogging about how successful that project went and how successful their team is. They spread it throughout their whole little consulting company and it's helped them engage with each other better and be more successful together for their clients. Their clients are super happy having had incorporated these core protocols team building habits for dynamic retaining into their company.

It's great to hear they apply in a variety of different team configurations. Last question Richard. When looking at the before and after of implementing Agile or even some of the core protocols you mentioned, what do you see as the big differences and maybe even some of the improvements that are achieved right away versus later?

When I was first launching my sort of running a boutique teaching and speaking and coaching and consulting company, when I was first launching this company, one of my clients was interested in measuring the results and I thought this was great. I definitely want to measure the results. I love numbers. You know, I'm sort of a little bit of a math and science geek and you can tell because I'm talking about science and research and doing experiments. And this VP of the R&D grant group measured in six months that the group had a 12% measurable performance increase. And he was super happy about it. Along with they went from sort of like 50% forecasting success on projects to more like 80% forecasting success. So he was really, really happy. They could make promises to their stakeholders inside and outside the company and most of the time they would deliver on those promises. And they were 12% faster, more productive than they used to be. They had good data to back this, this up. And I used to tell this story over and over and over. You know, it was like, wow, this was awesome. They were 12% more productive, right? So if they had, I don't know, do some quick arithmetic. If they had 100 people working there and they were paying 100 salaries, it was like they were getting 112 people worth of output now. Or you know, actually if this was latent unreleased value, it'd be like they were paying 100 salaries but they were getting 88 people's worth of output for that 100 salaries. They unlocked some value that had been held back. That's a good story. And then I had another client a little more recently. We added agile, we did agile technical practices and we did these core protocols, team building skills together. And this is where we were measuring psych safety and emotional intelligence as well. As part of the project, they measured a 250% performance improvement, right? I used to think 12%. Yeah, that's really good. This group measured a 250% performance improvement. That is a ton of value that they unlocked by incorporating agile practices, both the project management stuff and the technical practices. And by incorporating these team building skills from core protocols into their company. They were just hugely successful by adopting all these ideas.

Wow, it's incredible. They actually have some math to back up their performance enhancements from putting all this effort to make these changes and it's just not feel good stuff.

It's not just feel good stuff. They had data, they had metrics to back it up, and that was in the first six months.

Well, I appreciate the time, Richard. I know we come to ours. We'll look forward to continuing this conversation and maybe we can see how some of those performances enhancements would apply in the M and A world.

Yeah. And ask me for help anytime.

Thanks so much Richard. I appreciate your time.

Thanks for having me.

Thank you for taking the time to explore the world of M and A with our podcast. Please subscribe for more content and conversations with industry leaders. If you like our podcast, please support us by leaving a five star review and sharing sharing it. I enjoy hearing feedback and connecting with our listeners. You can reach me by my email. It's Kisan K I s o n ealroom.net M&A Science is sponsored by Dealroom, a project management solution for mergers and acquisitions. Additional educational content is available on Deal Room's blog@dealroom.net thank you again for listening to M and A Science. See you next time.