This is a transcript of episode 261 of the Troubleshooting Agile podcast with Jeffrey Fredrick and Douglas Squirrel.
An article by Atul Gawande on coaching for surgeons inspires Squirrel and Jeffrey to reflect on why you and your team might need a coach—for techniques and skills that they are already good at.
Show links:
Listen to the episode on SoundCloud or Apple Podcasts.
Introduction
Listen to this section at 00:11
Squirrel: Welcome back to Troubleshooting Agile. Hi there, Jeffrey.
Jeffrey: Hi, Squirrel.
Squirrel: So we’ve both been reading this article and we really found it interesting even though it’s a few years old, because it gives a lot of insight into frequent feedback, coaching, and improvement in your team of any type, including a technology team. It’s from the world of surgery. So how do surgeons improve, or more importantly, not improve?
Jeffrey: This is a great topic and I think it’s a good one for the New Year, thinking about what we might do differently. It was an article that you sent me, so thank you for doing that. It was from Atul Gawande, which people might recognize that name from The Checklist Manifesto, which I’m sure we’ve talked about before on this podcast.
Squirrel: Loads of times, but we’re not going to mention the word “checklist” again.
Jeffrey: Yeah. It was a very interesting article because it started with this surgeon and his observation that he’s pretty good. One of the things about surgery is they track the outcomes of what you’ve done and complication rates and things like that, so he noticed that he had stopped getting better.
Squirrel: But he was pretty good. He was at 80% or 90%. He felt he was doing a good job, but it had stayed there. He hadn’t made any changes.
Jeffrey: Absolutely. He contrasted this with the early years of his career, early on he was getting better year over year, and then that kind of plateaued. He had thought “Well, is this professional peak? Is this the limit?” But he had the insight that perhaps it would be possible to improve. So he looked to see how people improve in other places and what struck him is that other people who care seriously about improvement have coaches. In the article he goes and looks at singers and professional athletes and it’s striking to him as a surgeon that there’s no feedback after medical school. The only people who watch you perform an operation are the people who are assisting you with it. You never have a colleague or mentor or anyone come in to watch what you’ve done after you have become a full-fledged surgeon. Maybe that’s part of the problem? So he did a really interesting thing, which is he went and asked someone who he respected to come and observe him operate and then give him feedback. He talked about what a large difference this made and the discrepancy between how valuable it was to him and how uncommon this practice was. And that had me thinking about the software industry too where in a lot of ways for most software professionals, they’re not going to get a lot of feedback. They’re not going to get a lot of coaching because we haven’t really structured ourselves for that in most ways.
Improving vs Averting Calamity
Listen to this section at 03:55
Squirrel: “Oh it’s fine Jeffrey, we have code reviews. That’s all right. People will look at the code and tell you whether it’s any good.”
Jeffrey: But does that happen? It’s usually sort of like a “good enough” effect. I imagine there are places that have code reviews where people do get good feedback. But it’s not necessarily normal. It’s not something that is a standard practice.
Squirrel: The big difference is the code review I’ve seen while coaching is looking for bugs and obvious problems and glaring errors. What it’s not looking for is poor variable naming or confusing structures or an edge case that someone hasn’t considered. You might stumble across that, especially if you use large commit sizes. If you’re changing many, many lines of code at once, you will definitely not be able to find those sorts of things unless you devote a huge amount of time to code review.
Jeffrey: That’s right. Normally the level here is adequacy or sufficiency. It’s not “How can I reach my personal best? How can I continue improving?” When I first read this, I thought, “Oh this would be great to talk about.” But I also kind of thought I’d feel a little bit like a hypocrite because I’ve never hired a coach. And then you reminded me that I definitely had had coaching.
Squirrel: You just hadn’t hired us.
Jeffrey: That’s right. In 2012 when you and I first started looking into this communication stuff, we had a coach in Benjamin Mitchell who knew this stuff very well. The way that we improved was we would have group practice sessions where we’d come in and get feedback. And the thing that struck me once you pointed that out was not only did I get very explicit coaching on communication, but that communication was an area that I had considered my one of my strongest attributes in my professional career. I had been a public speaker, I had talked to lots of conferences, I did speech and debate in high school. For people who know what the National Forensics League is, I had a double ruby in that. So I had done lots of speaking. Not only that, but I had talked about communication for people in software at conferences for quite a long time. I believed I was very effective and I believe the advice I gave was very effective. And yet, I discovered this whole area of improvement that I had no idea about. That had tremendous follow-on effects such as our book. So it had a big impact on my career when I got coaching on an area that I considered myself already good at, and that was a real surprise for me and it made me feel much more connected to the article and the surgeon there.
Feedback Isn’t Fungible
Listen to this section at 07:13
Squirrel: Listeners might be in a position where your tech team or you yourself might do things like code reviews and retrospectives and feedback mechanisms from customers and so on. You might think to yourself, “Wow, we’re getting a lot of feedback. Why do we need any more?” But the difference is, if we take the Gawande example, that’s like the hospital doing inquiries into bad outcomes when the patient dies, or the surgeon doing a teaching round. So they might get some feedback as a result of teaching or considering his or her work in that way. But what you don’t have is regular continuous attention to very small but very significant improvements, which a professional can make at the top of his or her game. If you imagine what a professional footballer is getting better at, I know nothing about football, but I think you have to kick the ball and you probably have to kick the ball slightly differently. A millimeter difference during a certain type of play can make massive, massive differences to the outcome in the game. But if you just watch a few films, if you observe how many goals you’ve scored, that won’t give you the kind of feedback that you would get if you had a highly skilled coach who’s looking for those differences. That’s what we’re probably missing. That’s what our listeners are probably missing in their teams for their processes and in their coding for their individual contributors. Who is looking at that area of expertise and providing tiny, tiny improvements which add up very quickly to a significant boost?
Jeffrey: Right, exactly. This is something that we’ve talked about before in the past episode, the principles of the Agile manifesto and in paricular one of them is Principle 12, which is basically talking about retrospectives as a place for improvement. We talked about the power of incremental improvement. We also cited an excellent article that came to mind called The Mundanity of Excellence, and it’s an ethnographic study of swimmers in America in the seventies. It had some findings that are very consistent with the inspiration from Atul Gawande here. In particular, it talked about how swimmers could see dramatic changes in their performance, dramatic improvements when they changed coaches, because the stratification within swimming was based on technique and different coaches knew different techniques. When you learned a new technique, it kind of took you up a level. So in swimming they were rating people from C up to AAA, I think. And as you stratified from these different levels of competition, between the different levels they weren’t doing the same thing but faster, they were doing different things. They were qualitatively different. And so the question here is how do people learn some of those qualitative differences? Hopefully we’ve made the case that this is something worth doing. I think maybe next time we should get into ideas about how people might do this. How could people actually bring this insight about qualitative differences into their workplace? What do you think about that?
Squirrel: That sounds like a super idea. Let’s do that for sure. Thanks, Jeffrey.
Jeffrey: Thanks, Squirrel.