An interview with Richard Kasperowski on High-Performance Teams
Stephen Harrison: Let me introduce Richard Kasperowski. Richard and I worked together a while back and have been friends ever since. Along the way, Richard has become a recognized expert in an interesting and relevant field.
SH: Richard, welcome. Thanks for taking time to chat.
Richard Kasperowski: Thank you—I’m happy to be here!
SH: What’s your elevator pitch?
RK: I’m an author, teacher, coach, and consultant. I focus on teams, helping people build and maintain teams in a state of high performance. Some of the tools I use include the Core Protocols, Agile software development, and Open Space. And I teach a couple of courses: one at Harvard University called Agile Software Development and one at Boston University called Spark!. Spark! is an innovation program for teams of students creating awesome new products together.
SH: You’re one of the best presenters I’ve seen at workshops. What’s your secret?
RK: What a funny question because the first time I spoke at a conference I really sucked! This was about 25 years ago. I decided to speak at a conference because I thought it was something that, I don’t know, cool people did, smart people did, successful people did. And I got into this conference and I showed up wearing a suit and a tie because I thought that’s what you did when you went to a conference. So I stood there in my suit basically reading the slides in a monotone voice. I sounded like a robot—I was so scared of being in front of the audience! The feedback I got at the end was that you had good material, but you looked liked you were really nervous: You might want to try changing the tone of your voice once in a while. :-)So, Stephen, I know you use a lot of the practices that I call Agile, like continuous integration, continuous delivery, and so on. Maybe my “secret” is this old idea from Extreme Programming: If it’s hard, then you do it all the time so it becomes easier. So I just do it a lot now—I do a lot of public speaking and teaching. At first, it was hard. But I still liked it, so I did it more. Practice, practice, practice. Now I don’t feel so scared talking in front of an audience, and at least a little bit of my personality comes through.
SH: Staying with workshops for a moment. I notice you get people to engage in your exercises and overcome their initial reluctance. Tell us how to do that too.
RK: I think this is all about people feeling safe. And by safe I mean the opposite of a fight-or-fight response. So how do people feel safe? Here’s a really common facilitator technique to help people to feel safe: it’s called solo-pairs-quads-all. You do an activity, and you ask people to do it solo. That’s totally safe: you can do the activity in your head, on a piece of paper. Totally safe, nobody sees what you wrote, nobody hears what your idea was. The next level up is to pair together on an activity that’s the same or similar. And it’s easy and safe because people basically have their answer written down and just read their answers to each other. But they’re together in these small groups, and they end making a new friend—they feel safe in their group of two. And the next level up … it’s pairs of pairs, and people feeling safe in groups of four. And then you expand the activity to the entire group.
This scaffolding helps people feel safe. Whatever you’re doing, find some scaffolding, some framework in which people can feel safe with each other. Find a way to avoid that fight-or-flight response. When people are experiencing fight or flight, there’s all this cortisol and adrenaline in their bodies. They can’t think, they can’t be creative, they can’t participate, they can’t learn. They can’t even hear what you’re saying. They’re just worried about themselves, trying to defend themselves. What we get from this safety scaffolding is serotonin, dopamine, oxytocin. These are the chemicals in your body that make you feel good, help you connect with each other, put you in a state of flow and high creativity. That’s what we want for the people we work with and care about.
SH: In your travels around the world helping people build high-performance teams, what have been some of the consistent and challenging themes?
RK: Continuing on this idea of safety, you can’t just tell people to “do more safety with each other at work.” People have some idea of what that means, but nobody has an in-born idea of how to “do safety.” So psychological safety is this idea that relates to high-performing teams. We feel safe when we’re together. We’re in a state where we’re not experiencing that fight-or-flight response. What are the practices to feel safe together? The first practice is everything is opt-in. And it’s totally OK to opt out. So invitation. And the second step is share how you’re feeling with each other. Yeah … that’s crazy stuff!
That first idea—it’s OK for anyone to opt out at any time—as soon as I share it with managers, they’re like, “Wait a minute, if I don’t command people to come to a meeting, or I don’t tell them what to do, they won’t do anything. That won’t work.” And the second idea, to share how you’re feeling with each other, folks will say, “No! I just want to write code. We don’t do feelings here.”
But if you look at the science and the research of the behaviors of high-performing teams, they do these things. They opt in to their team, their project, their way of working together. They do the things because they want to do the things. They solve problems the way they want to solve them. And they share how they’re feeling with each other. When they’re happy they say so, when they’re mad they say so, when they’re sad they say so. They connect with each other better. They become friends.
And you and me, Stephen. We worked together on a team once, and I talk about that team as one of the best teams in my life. And I say we got lucky. We didn’t really know what we were doing. If we look back at that, we became friends. Could a random team do that again on purpose? How do people become friends? For starters, you decide you want to. Nobody makes you do it. It’s opt-in, and you share with each other—things about yourself, including how you’re feeling.
SH: Are there some occupations, industries that push back the most on these ideas? How do you work around peoples’ skepticism in a tough crowd?
RK: I think the profession we’re in, the techie business resists the most. And I joke about when I work with finance companies. Stephen, you’re working at a techie finance company…
SH: [awkward silence]
RK: … I mean like Wall Street stock trading companies. They don’t believe in sharing feelings.
Many of us who do this kind of work, this techie kind of work or this finance kind of work, we’re really good at numbers, and we’re really good at logic. And this is part of why we think we don’t need emotion at work. Because we’ve been so successful at work with just numbers and logic. Like me: why did I get into working with computers? Because I sucked at people. But I totally understood numbers and logic. That was easy.
I share with folks the science and research on teams and team performance. The literature and the evidence is that teams who have high group emotional intelligence outperform other teams. I make this case as a “hook.” If you believe in evidence-based thinking, if you’re a numbers and logic person, then you more or less believe well-done research. Now, if you believe in evidence-based research, and you want your team to be high performing … well, gosh, you have to have high emotional intelligence in the team because that’s the logical case.
SH: Who are your greatest influences and why?
RK: Jim McCarthy with his work on the Core Protocols and with an assignment that he uses in his signature course.
I have been teaching technical skills classes recently, so influences like Llewellyn Falco, Tim Ottinger, and Arlo Belshee come to mind. They are three leaders in writing amazingly good code.
I learned Mob Programming from Llewellyn, which is like Pair Programming, but with more people.
I learned an idea called “pin-down tests” from Tim. Imagine you want to refactor some legacy code. You want to make sure you don’t break anything. But it’s legacy code, so it doesn’t have any tests that tell you what the code does. First, you write tests that tell you how the code works, so when you refactor it, you know you didn’t break anything. “Pin-down testing” is a metaphor from high school biology class. You don’t just take the frog in one hand and the scalpel in the other hand and cut it open—you would hurt yourself with the scalpel. Instead, you take the frog and pin it down to the table. You make it safe to examine its insides. In the case of software, pin-down tests make it safe for you to open up the code and put it back together without hurting yourself.
Arlo has this idea of “provable refactorings.” Because of the rules of your programming language and runtime, you can prove that your refactoring is bug-for-bug compatible with the original code.
So these are some really important ideas for clean code and technical agility. You can’t arbitrarily change code—even if you think it will fix a bug—when you refactor. What you think is a bug might be someone else’s feature. If you change the code’s behavior, their code will break, and your business will lose money.
Arlo is also the one who first popularized “Promiscuous Pair Programming,” where pairings change every morning and afternoon. So you’re always writing code with other people on your team. They were working on this in the early 2000s where, as a rule of thumb, they’d pair the most knowledgeable person with the least knowledgeable person on the team to amplify the learning and the creativity. The most knowledgeable person teaches the less knowledgeable person, and the less knowledgeable person will have the freshest ideas. This makes the solutions great and brings the team up to speed quickly.
SH: We’re not all familiar with some of the terms you frequently use: Core Protocols, Open Space, and so on. What are they?
RK: Core Protocols is this: if you watch high-performing teams working together, creating products, you would notice they have a set of behaviors in common. If you factor out those success behaviors that they have in common, write them down, and share them with other people, you can intentionally reproduce success on your team. One of those behaviors of high-performance teams—and this is weird for techie people like us—is sharing your feelings with each other. There is solid science to support that sharing makes better teams.
Open Space is a great way to hold a meeting for 5 to 2,000 people to creatively solve a really important problem we needed to have solved yesterday.
SH: How do you know when you’re really making a difference?
RK: There are objective metrics: We have a valid and reliable diagnostic for high-performing team behaviors. We have measures of technical team performance.
But even better than metrics, you can tell you’ve made a difference when people show up to work with their team and want to be there, are happy and energized, and they’re creative with each other.
SH: Thank you so much agreeing to do this. Richard, this has been wonderful.
RK: My pleasure, Stephen! Always great to spend some time with you.
— Stephen Harrison, Venmo SRE
A version of this interview appeared on the Venmo Technology Blog.
