In this podcast episode, we welcome Richard Kasperowski. Richard is an author, teacher, speaker, and coach focused on team building and high-performance teams.
Richard is the author of two books, High-Performance Teams: The Foundations and The Core Protocols: A Guide to Greatness, as well as the forthcoming book High-Performance Teams: Core Protocols for Psychological Safety and Emotional Intelligence.
We talked to Richard about what core protocols are, how important it is to talk about one’s feelings, and how to help your team achieve new heights. Listen to the full episode or read the transcript.
Things we covered:
- How Richard started his career
- What are core protocols?
- Why psychological safety in teams is important
- Why it’s important to share how you feel, even as a developer
- How big should the team be?
- What is mob programming
- Things to do and not to do as a team leader
You can also get Semaphore Uncut on Apple Podcasts, Spotify, Google Podcasts, Stitcher, and more.
Like this episode? Be sure to leave a ⭐️⭐️⭐️⭐️⭐️ review on the podcast player of your choice and share it with your friends.
Introduction
Darko Fabijan (00:02):
Hello, and welcome to Semaphore Uncut, a podcast for developers about building great products. Today, I’m excited to welcome Richard Kasperowski. Richard, thank you so much for joining us.
Richard Kasperowski (00:11):
Hey, it’s a pleasure. Thanks for having me.
Darko Fabijan (00:13):
Great. Can you just go ahead and introduce yourself?
Richard Kasperowski (00:16):
Sure. I’m an author, a teacher, a keynote speaker, a coach, a consultant. I focus on team building and high performance teams. I’ve written a couple of books about teams and have a great team and I teach a couple of university courses, actual software development at Harvard and an entrepreneurship course at Boston University.
Darko Fabijan (00:38):
Great. One of the things that you are known about among many things that you do are core protocols or, in terms that people would better understand it on this channel level is high performance teams.
Do we all want to work in high performance teams or have high performance teams? Of course. Yeah, I think that is not trivial. I think that each one of our listeners can identify with that part.
So yeah, if you maybe can give us an intro of how you ended up working on that team as one of the main things in your career.
How Richard starter his career in agile
Richard Kasperowski (01:16):
I was a young software developer. I actually started pretty young my work career. I was 19 years old and I was a software tester, I was a software developer. I got really, really good at my individual skills.
I got to the point where I felt like I could do anything and because of my skills and abilities, I kept getting promoted. I kept getting these bigger jobs, bigger job titles, team lead, technical team lead, manager of teams. I got more interested from there into how we could be great together, not just me, but all of us because I was actually responsible for all of us being great together.
And that got me into things that today, people call agile. That got me into the agile technical practices drawn from extreme programming into the agile business practices, you might call them that, or social practices drawn from scrum.
And it got me into even more interesting things. It got me into thinking about the psychology of teams, organizational development, the emotional intelligence, learning more about myself, Myers-Briggs profiles and other kinds of personnel and personality profiling. And ultimately, somehow by chance, I get introduced to the work of the core protocols through Jim and Michelle McCarthy and realized, through a massive personal transformation, that these are a great set of tools for helping teams be their best.
What are core protocols?
Darko Fabijan (02:43):
And for us who know little or nothing about the core protocols, what would be the essence maybe to start with and then we can dive deeper?
Richard Kasperowski (02:51):
Sure, sure. Just this idea of a great team, the high performance team and the jargon that people use in the research. Think back to the best team you’ve ever had in your life. Maybe you’ve been on more than one.
Imagine that you could watch a couple of high performing teams or five or 10 high performing teams and notice their behaviors and notice the behaviors that they have in common with each other. There’s probably commonalities between the best teams. There’s certain things they do that are similar to each other.
There’s probably commonalities between the best teams. There’s certain things they do that are similar to each other.
-Richard Kasperowski, Author, Coach, Keynote speaker
Our audience here is at least slightly technical. Imagine we could factor out the common behaviors and write them down as something that maybe other teams could learn or everybody in your team could reinforce if they were to do it, amplify and get more of it.
That’s what the core protocols are. They’re drawn from watching high performing teams, noticing their similarities, writing down these behaviors that they have in common with each other so that other people can learn them. So other teams can learn them and replicate those behaviors, putting names on those behaviors so we can talk about them more easily and building habits.
This is how we work together. And by building those habits together, we end up performing well.
Darko Fabijan (03:58):
Yeah. Clear. Sounds straightforward. However, yeah, we know in practice, as you mentioned, teams are usually composed of lots of different people, which is great, which is the value of the team and also very different ages and experience levels, often. Maybe what are some of the things that you are most frequently seeing and trying to help teams to implement and live, really, core protocols.
How psychological safety in teams is important
Richard Kasperowski (04:26):
Some of the foundational habits or foundational behaviors to adopt, well, all of this goes back to the research. According to the research on teams and high performing teams, some of the most important things are psychological safety and group emotional intelligence.
Safety is this idea that when we’re together, we can take risks. It’s okay to try new things. It’s okay to throw an idea out there, even though you might not know that it’s an idea that the team will like, just toss it out there and see what happens. And you don’t get judged. You don’t get held back in your career. You don’t get threatened or fired in any way for not succeeding the first time at something. It’s okay to take risks. It doesn’t hold you back.
Richard Kasperowski (05:07):
And then, team emotional intelligence is this idea that we understand what we are doing together. We understand how we feel together and we can behave appropriately no matter how we’re feeling toward our goals, that we can modulate our behaviors individually and together as a group and we understand how things work outside of our team.
We’re probably operating in a larger organization or even in a small startup, there’s at least one boss or some stakeholders or customers outside of our team. We understand how things work outside of our team and we can influence others through our actions and what we say so that we can all accomplish our goals together.
Richard Kasperowski (05:46):
This is the research on teams and team performance and the research falls a little bit short in that it doesn’t tell you how to do that stuff. Core protocols offer a way, it’s a how-to to get this psychological safety and team emotional intelligence. Some foundations of these how-to, these actual behaviors are, first, everything is opt-in. We have freedom. We have autonomy. We do things because we choose to, not because anybody’s coercing us or forcing us to do things.
And you can opt out of anything anytime. So if you don’t want to do something with your team right now, we have a habit, a behavior, we just say, “I pass,” or, “I’m checking out.” And your teammates know what these phrases mean. “I pass,” is really just, “I’m still with you, but I’m opting out of this activity right now.” And it’s totally safe to do that. Nobody judges you or hassles you or tries to make you do it anyway.
Very concretely, this could be, it’s your turn at the daily scrum, but you’re not ready yet so you pass. Or it’s your turn to be the driver if you’re pair programming or mob programming, but you just not ready right now or you don’t want to do it right now, so you pass and it’s totally okay.
Why it’s important to share how you feel
Richard Kasperowski (06:59):
This freedom foundation, this foundation of autonomy starts building safety together. We can opt out of things and it’s totally okay. You don’t get punished for it. And then, the second easy thing to do is share how you’re feeling. Now, this sounds wild to a lot of us engineering people. I grew up as a software developer.
Share how you feel? What? Just tell me what to do. Tell me what the work is. I’d rather write code. I’d rather think of algorithms. I’d rather figure out how to store a ton of data and optimize my code or whatever. Share feelings? No, I don’t want to do that, but it turns out, according to this science and research, okay, teams have to have technical competence, but all teams have technical competence, we’ll just be an average team.
If we want to be the best team, we add on to that with sharing how we feel with each other. We build up this team emotional intelligence.
Richard Kasperowski (07:52):
It adds on to our sensation of safety. It helps us perform better. The research is there and the easy habit is just say how you’re feeling to each other. “I feel sad about blah, blah, blah. I feel glad about blah, blah, blah.” In the background, there, this is an audio podcast so people can’t see what I see. You’ve got these nice drawings over on the side and I’m really happy about them.
Oh, maybe people can hear the sounds in the background. I actually love hearing the sounds of people’s kids in the background. It brings life into the work we’re doing. Wow, I just shared how I’m feeling about a couple of things. If we were working together, maybe you would do the same and we would start to connect more. It’s these teams in which people connect with each other, they’re cohesive. These are the teams that are better than all the rest.
Darko Fabijan (09:21):
This element of sharing the feelings, as you said, it can be scary for lot of people. You introduced here, the concept, us tech people.
Richard Kasperowski (09:32):
Yeah.
Darko Fabijan (09:34):
Guys and girls in the industry, it is a bit different crowd, not in a bad way.
Richard Kasperowski (09:41):
I self-selected into this group. When I was growing up, I felt safer by myself with a computer than I did with the other kids or the other young adults. It is a real growth step for me to be able to share how I’m feeling with people and it turns out we’re all better when we do that.
How big should the team be?
Darko Fabijan (09:59):
Yeah. What I wanted to ask is, these elements of teams and team sizes and how teams are composed and so on, there is that element of holding any meeting and that right number of people who are in the meeting. And if you add literally one or two more people, everything breaks apart in a way. People start speaking less, just asking questions less.
So, yeah, I just connected that with my experience. And it definitely maps directly to there is less element of safety is then decreased with more people. And also, the element of sharing how you feel.
One of the big mistakes of my career, as the majority of people who a great career or no career at all is that they do progress from a developer to a tech lead or a manager and forward, that you put a group of 10 people and literally, everything becomes awkward. And then, if there is a smaller group, it works. And there are many advices in these areas of team of five is maybe ideal, or a couple.
Can you maybe share some of your experiences? Did you experience those situations where we gather maybe 10 people in the room and things collapse?
Richard Kasperowski (11:15):
Yeah. And one of the terms use for this is voice. Do you have voice? Is your voice being heard in the group? What we want, and again, back to the research teams that have more equal voice, and you can measure this by talk time. Teams that have more equal talk time amongst the members outperform other teams. I feel this.
When I’m more with a larger group, I’m a quieter person. So the larger the group, the less likely you are to hear my voice. And they’re loud people, the larger the group, the more likely you are to hear the loud people’s voices. I don’t mean loud as in the amplitude of their voice. I mean loud like they’re just hogging the talking time. They need their voice to be heard versus, I’m more of an introspective. I’m happy to just talk to myself even in the presence of others. Just listen to my voice in my head without even using my mouth.
Richard Kasperowski (12:08):
Yeah. This is an interesting podcast for the two of us, because we’re both inner conversers, inner thinkers. How do we get more voice? That’s a question.
In any group, one way, we mentioned this emotion check in idea, what if you start a meeting or start a work session with people sharing how they feel? I take a turn, you take a turn. The next person takes a turn. The next person takes a turn. Wow.
Right off the bat, everybody’s voice has been heard. We’re doing it, right there. It’s just how we start the meeting. We start the meeting by hearing everybody’s voice. We’ve all warmed up. We all know what’s going on with each other. We’re all connected more. The meeting will go better.
Richard Kasperowski (12:46):
And there isn’t a lot of research about team size. You mentioned the number five, that’s the number that most people quote. This research goes back to the early 1970s, about optimal team size for groups of people doing creative problem solving work. They really only measured two dimensions there. It was something like the quality of the outcome, self-reported quality of the outcome amongst team members in the group and self-reported satisfaction with having done of work together.
Five people is the optimal team size. We can all hear other’s voice and add on some intentional habits.
-Richard Kasperowski, Author, Keynote Speaker
And these two dimensions happen to intersect at the number 4.6, 4.6 people is the optimal team size. But of course, we can’t have 0.6 of a person so we round it up to five and say five is the optimal team size. Maybe small-ish groups work best for making sure we all feel comfortable with each other, we can all hear each other’s voice and add on some intentional habits. At least introduce yourselves, say your names, maybe share how you’re feeling. I’d say, yes, definitely share how you’re feeling and really connect right off the bat.
How to adopt new habits
Darko Fabijan (13:48):
Yeah. Great. Great. And in this category of introducing these habits, I mean just those two small things, small, can make a huge difference, obviously, and I think that the majority of listeners would accept that statement. But in terms of introducing this, do you think that there should be a driver within the team, within the organization, or it’s individual things we are going to adopt this protocol?
Richard Kasperowski (14:15):
Good question. So how could we adopt these sorts of habits intentionally? If we don’t try anything intentional, we’re likely to have an average team. The vast majority of teams are average, but we all want to have a team that’s better than average. So how do we do that? Well, we have to try to have a team that’s better than average.
I’m doing a lot of piano to a playing and singing lately. I could just sit down at the piano and try a new song every day or not practice much and I would be an average pianist, but I’m doing things intentionally to be a better than average pianist. I’m doing a little bit of exercises every day, I’m learning songs that push me out of my comfort zone. I’m playing songs where I actually sound bad because I don’t know that technique yet, but I feel safe too.
I’m playing mostly by myself or my wife upstairs hears me. And it’s totally okay to try out these new things and intentionally build my skill.
Richard Kasperowski (15:08):
The same thing with a team. You’re going to have to try things that feel uncomfortable. You’re going to have to push your skills. If you want to be better than average, you’re going to have to intentionally do something different to be better than average.
A lot of teams do a retrospective. This is a really good habit, either daily improvements, continuous improvements or periodic improvements, this is a great habit for teams to have. But what if you don’t know what to do?
Richard Kasperowski (15:36):
We’ve identified some challenge or some growth point in ourselves as a team, but we don’t actually know what to do to solve it, to fix it or to get better at that growth area. It may help to have somebody who knows these skills, has read about them or heard about them or you just want to try them out together. You’ve discovered these core protocols or something similar and you want to try them out. Try them out just do it by the book. It’s thecoreprotocols.org. It’s free. You can just try these things out.
How people share skills and ideas
Richard Kasperowski (16:04):
Sometimes it helps if somebody is already skilled at it. It could help to go through a class together. We run short classes on this. Or if somebody’s skilled at it, you can just start doing it. And people call this mirror neurons. If you start doing something, the other people in the group will imitate you. You’re nodding your head at me right now, so I’m nodding my head too. Or you’re smiling, so I’m smiling. It’s mirror neurons.
We imitate each other. It’s a human characteristic. If I start sharing how I feel, there’s a really good chance you will too. If I start using a particular way for us to make decisions together, there’s a really good chance you’re going to copy me. This is how humans work. This is how we learn from each other. This is how we share skills and ideas. So we could learn these things together or if you already know them, you can just start doing them and people will imitate you.
What is mob or ensemble programming?
Darko Fabijan (17:38):
There are potentially some practices that could be complementary, potentially, to introducing this. I don’t know why, but mob programming keeps popping up in my head because it is one of those activities where you can feel unsafe and awkward, potentially, and you need to ramp up.
And what happens is that maybe someone is just, how you said, a louder voice, and then, can dominate the group or something like that. Can you maybe share your views or experiences around mob programming and how it helps?
Richard Kasperowski (18:16):
Yeah, mobbing or ensemble programming, people have different names for it these days, it is a great tool for getting more voice, for getting more creativity, for getting better solutions together, for connecting more, for even having fun together while we do the work, which is critically important. The practice in pairing or mobbing, one of the foundational practices is to periodically change who’s the driver.
We use this car driving metaphor. The driver in a car is the person at the steering wheel. You’ve got a navigator sitting next to you from the days before we had a, I’m holding up my phone in my hand, the days before the navigator looked like this little thing in my hand with maps and it talks to you and tells you what to do, the navigator was a person sitting next to you with a paper map unfolded in their lap, telling you what to do and where to go and giving you advice.
Richard Kasperowski (19:11):
But as driver, you’re actually executing the advice and you make the final decisions that whether you turn right at that street or at the next street. As a driver, you decide. The driver’s voice is heard the most within the code. The navigator’s voice, actual physical voice, might be heard the most in the group, but the driver’s decisions are final.
To get more equal voice in the team, we have this practice of changing who is the driver frequently, the person typing at the keyboard, controlling the mouse, typing the code. The more frequently we change drivers and the more drivers we have, the more equal voice.
And I guess, in this case, talk time means code writing time because we’re talking through code with each other while we’re building software and digital products. So changing drivers frequently is really important.
Richard Kasperowski (20:07):
Building habits with each other when we’re mob programming, we have many navigators, so building habits together to make sure that everybody’s voice is heard within the subgroup of navigators is really important. And pausing and reflecting on how to make things better, retrospecting our continuous improvement.
One of the interesting things about mobbing is, we get better results when we share our intention with each other.
-Richard Kasperowski, Author, Keynote Speaker
One of the interesting things about mobbing is, we get better results when we share our intention with each other, it’s not just you start writing code and the navigator starts telling me what code to write, but you say what you intend to happen before you start writing the code or what you intend to happen, what you hope the outcome will be before you start navigating.
I live in Boston. It’s not just, somebody starts navigating me to back out of my little tiny street to turn left to Maple Avenue, turn right at Church Street. It’s the intention. We’re going to drive to New York city.
Richard Kasperowski (21:05):
Knowing that intention, I can make lots of little micro adjustments without even hearing what the navigator might say as their detailed instructions. We just know what the goal is. Sharing the goal with each other is really important.
How to have an above average team?
Richard Kasperowski (21:17):
A lot of the practices that people discover that work well for them mobbing together or ensemble programming together, they’re similar to or could be enhanced by some of the core protocols practices. What is your intention? What do you hope to get? This is one of the protocol’s passing. Everything is because you want to do it.
You don’t have to take a turn as driver if you don’t feel comfortable right now. Asking for help, this is another one of the core protocols. It turns out that the best teams, we ask each other for help and we typically end up helping each other. We don’t get stuck. This is something that we see in mob programming teams. We say we don’t know how to do something and somebody helps us. They navigate us through it.
Or we learn it together if it’s something that we’ve never done before. A lot of the things that happen with mobbing teams happen with any good high performing team, assuming people want to be really good, assuming you want to have a great team experience, assuming you want to build a really great product together.
It’s easy to have an average team. But to have an above average team, we have to intentionally try to be better than average.
-Richard Kasperowski, Author, Keynote Speaker
It’s easy to have an average team. But to have an above average team, we have to intentionally try to be better than average.
Darko Fabijan (22:21):
Yeah, absolutely. As you were talking about, this one thing pops up, experiences that I have, let’s say ensemble, I would take them back to when we were having some kind of outage or an incident is maybe a great example of how you can check how the team works in the pulse.
It’s not super high stress environment, but there is an element of pressure and timeliness in making decisions and also communicating and making mistakes has a higher impact.
Darko Fabijan (22:56):
However, ensuring that still, things work together fine. It’s not that I have a point. It’s more that it reminds me of that environment because there is usually a person who is a driver, explaining to us what happened than what we might do next and so on.
A question, as you’ve were describing your career and the progression that you eventually became a team lead and then entered some positions that include management and so on, over and over, I’m amazed how young our industry is and 50% of our developers writing code today have less than five years of experience or something like that.
For those people who feel confident with their skill and are attracted or pushed by organization to take leadership roles, what would be some of your advices? What are some of the most important things not to mess up?
Things to do and not to do as a team leader
Richard Kasperowski (23:56):
Things to do, things not to do as you become a team leader. Figure out how to create this sense of safety together. That it’s okay to make mistakes. It’s okay to learn things. I’m not saying it’s okay to intentionally take down production. It’s not okay to intentionally cause your organization to lose money or move away from whatever your goal is. But sometimes, it happens.
So avoid accusation and blame and move toward asking questions. This was actually a really big growth point for me as a manager of other tech people. I got there because I actually did know the answers. I knew how to do things.
How do you write this code? How do you deploy that to production? Should we do it this way or that way? I got to leadership because I knew how to do these things. I knew the answers to these questions.
Richard Kasperowski (24:58):
I became a better leader when I let my people answer these questions themselves. Somebody might come to me and to ask a question, “How do I do this? How should I do this? I could do it this way or that way.”
And my answer would be more like, “What do you think? Let’s walk through it together. How could we decide? What would the positive outcomes be? What might the negative outcomes be? What are the consequences if we do it this way or that way?”
A big growth point for me and for our team was, let’s figure it out together.
-Richard Kasperowski, Author, Keynote Speaker
Or, two people come to me because they disagree about which path to take writing some code or building some components and they just can’t get aligned. They want me to decide, do it this way or do it that way.
A big growth point for me and for our team was, let’s figure it out together. I’m not going to decide. What would happen if we did it this way? What would happen if we do it that way? What are the best elements of both approaches? How can we combine the best of both approaches and make it a third way that’s even better?
Why it’s important to make decisions together
Richard Kasperowski (25:59):
A side effect of the boss makes the decisions is, the people aren’t bought in on the solution and if they don’t like it, they can complain about the boss. And it’s like they don’t have personal responsibility. They don’t have a stake in it. They don’t have to give it their all. It’s the boss’s idea. “I don’t believe in this idea, but the boss told me to do it.”
But if we make the decisions together, it’s our decision and we’re in on it. Or if you make the decision by yourself, it’s your decision and you’re going to do everything you can to make it work. This is one of the ways that individuals and teams do better together. We are in together on our intention, on our goals and on the steps that it’s going to take to help us realize our goals.
We make the decisions together and we’re aligned with each other. So as a leader, as a new leader, take steps to make sure everybody’s voice is heard, that people are making decisions amongst themselves and you will have better results together as a team.
Darko Fabijan (26:55):
Yeah. I couldn’t agree more. It’s always pure gold. I wish that earlier in my career, I heard more of these things because most of the people discovered these things, it’s just that, how many mistakes you make, how many casualties you leave behind.
Richard Kasperowski (27:14):
For sure. I made plenty of mistakes.
Darko Fabijan (27:17):
Yeah, of course. That’s the best way to learn. Other quotes.
And for pepolpe who want to learn more, you mentioned the book, you mentioned a website about this, also research.
You’re also involved as an instructor on a number of courses. Can you give us a list? If we want to learn more, what are couple of resources to hunt for?
Richard Kasperowski (27:38):
Absolutely. For starters, just visit my website. It’s kasperowski.com. You’ll find a couple of my books there. You’ll find my blog there.
You’ll find my podcast there where I’m talking to people about the best team of their life and interviewing people. We’ve got 50 or 60 guests, 50 or 60 different opinions and life stories, experience reports about the best team of somebody’s life and what they did to make that happen. These are some great stories.
In addition to kasperowski.com, we’ve got thecoreprotocols.org, where you can find a really concise description of these behaviors. And on my website, you’ll find the books with more verbose descriptions of these behaviors and why they work.
Darko Fabijan (28:22):
Great. Thank you so much. Good luck and yeah, thanks.
Richard Kasperowski (28:26):
All right. Thank you so much. This has been fun.
