Today we’re throwing it back again, this time to our 100th episode where Esther Derby joined us. Esther is an esteemed guide and consultant, specializing in teamwork optimization. She is on a mission to change work environments so that teams and individuals can flourish. In this episode, we discuss responsibility for results versus responsibility for improvement, in terms of management and team style. Esther gives us an overview of the nine-quadrant role statement and how this could be applied in various work contexts. It is fundamental to define and clarify roles not only because it removes uncertainty but also to address differences in expectation. This is not to say that one role is better than another, but rather that they are equally different. Esther also walks us through what makes great teams, how to effectively implement change, and much more. Programming is a team sport and these lessons are useful for any work situation you may find yourself in. Be sure to tune in today!
Key Points From This Episode:
Transcript for Episode Remix: 9 Roles for Creating Results or Growing a Team with Esther Derby
[INTRODUCTION]
[0:00:00.8] MN: Hey, you all. Mike here.
[0:00:02.7] DA: And Dave as well.
[0:00:03.6] MN: Oh, yeah. We’re here. If you’re listening to this, this is a remix of one of our previous episodes that we want to highlight from the past year. Today, we're talking about the episode 100.
[0:00:16.9] DA: It was a big year.
[0:00:17.5] MN: It was a big year. 100, I remember doing the intro for that particular episode in the bathroom of my house, just hiding from my child.
[0:00:26.6] DA: Hiding from my child who can potentially cry as I wanted to celebrate with all of you, the fact that we actually were able to hit episode 100. Thank you for listening. The episode is nine roles for creating results, or growing a team with Esther Derby.
[0:00:41.9] MN: Yeah. Esther's really great. She's a very good explainer of concepts. I really liked the discussion that we had around these different hats that we put on every day as co-workers. Particularly if you're a consultant, these are different roles that you might see, but I think they apply to everybody and to software engineering.
[0:01:08.1] DA: Yeah. I mean, Esther is definitely a friend of the show. Every time she jumps on the podcast, it's always a great learning experience. We hope that if you are unable to listen to this episode that you appreciate some of the gems that she drops during this episode.
[0:01:24.9] DA: Yeah. She just came out with a new book last summer, called 7 Rules for Positive, Productive Change.
[0:01:29.9] MN: Nice.
[0:01:31.0] DA: Definitely check that out too.
[0:01:32.3] MN: Yeah. We’ll probably put the link in the show notes, if necessary. We hope you enjoy the show.
[EPISODE]
[0:01:37.4] DA: Hey, folks. Thanks for tuning into the 100th episode of The Rabbit Hole. We never would have made it this far without the support of our colleagues, guests, listeners and of course, our fearless leader and host, Michael Nunez. Before we get started with the episode, we have a special update straight from the Bronx on babies, software, and otherwise in the long road to 100. Here we go.
[0:01:58.1] MN: Hey, there. Michael Nunez from The Rabbit Hole. Just a few updates as I've been out for some time. As you may know, I've been on paternity leave. Me and my wife have been spending our time raising baby Giovanni and has been quite an experience I've never felt before.
Oftentimes, you hear software engineers mentioned in a particular part of the application that they've built their “baby.” It's a feature, or an entire part of the site. I totally understand what that phrase comes from, but it's not the same. With your “baby” as you're building this feature, you probably have a test environment that you're running your tests and ensuring that your “baby” is doing whatever it is that you want it to do.
It's a nice area that you can try and figure out how it would behave and no one out in the public would ever see those changes as you're building them. Me on the other hand had a completely different experience with Baby Giovanni. There are a ton of books that contradict each other. Baby Giovanni is essentially production. I have to figure out ways to ensure and appease Baby Giovanni. If that includes bouncing, singing, walking around to get him to be happy, then I'm ready to do that. Everything feels all under the gun and you have to make sure you can do it as fast as possible.
One thing that he really likes is that when I carry him and do squats, he seems to enjoy himself. My legs are going to be hella swoll when I come back to The Rabbit Hole. Maybe I'll send a picture and put it on Twitter for you guys. We have a voice-mail number. Feel free to hit us up on the normal channels, which right now is Radio Free Rabbit at twitter.com. Our voice-mail number is 914-999-2165. We'd love to hear your thoughts and questions over voicemail as we figure out other channels to receive your feedback. Again, the number is 914-999-2165.
Last but not least, a really big thank you. Thanks to both Dave Anderson and William Jeffries in building The Rabbit Hole to what it is right now. I can't imagine that it would be where it is without them. They've been great at contributing and even right now, holding it down. Great, great stuff. I never would have thought that we would make it as far as we have right now without them.
All the editors throughout the way, you probably listened to the first episode and our sound was very different to what it sounds like now. That's thanks to the people responsible for making me sound smart and making the podcast sound amazing.
Last but not least, to all of our listeners. A really big thank you to all of you who subscribe. If you would have asked me two years ago, I would not have thought that I would be part of a podcast that would have 100 episodes. We did it, 100 episodes. Holy crap. I would not have been able to do that without Dave, William, our regular guest, shout out to Emmanuel and many others, and our honorable guests who have appeared on the show.
With that being said, let's dive right in to episode 100 of The Rabbit Hole.
[0:05:18.5] DA: Hello and welcome to The Rabbit Hole, the definitive developer’s podcasts in fantabulous Chelsea, Manhattan. I'm your host, Dave Anderson. With me today, I have –
[0:05:27.1] SM: Stephen Meriwether.
[0:05:28.5] WJ: And William Jeffries.
[0:05:29.6] DA: Today, we will be discussing responsibility for results versus responsibility for improvement, in terms of your management and team style and what forms and shapes that takes. With us today, we have the esteemed Esther Derby. How are you doing, Esther?
[0:05:47.9] ED: I’m great. I made it home through the snow, so all is well.
[0:05:54.3] DA: Yeah. Unlike in New York, where we just get snow for a brief duration and then ice and gross stuff after that. I guess it seems that in Minnesota, they have real snow.
[0:06:06.2] WJ: Yeah. It's like a 7-11 slushy mixed with dirt.
[0:06:12.1] DA: That's not the romantic snow. Why don't you introduce yourself for folks who might not be familiar?
[0:06:17.8] ED: Sure. Well, I started my career as a programmer, so I had that in my background. I haven't written code for a while, but that's how I started. I did some testing, because we always used to test our own code. I was a team lead and a dev manager and internal consultant. What was clear to me from all of those different roles was that our work environment has a huge impact on our ability to be successful. That's where I focus a lot of my attention right now is how can we create work environments where good work is the default and people find satisfaction in their work, where it's not a soul-sucking experience?
[0:07:00.7] DA: I love that concept, where you're designing the system to encourage the behavior. Often, it's the opposite where people want heroics, or what have you, that save the day. Actually, if you just step back and look at the larger forces at play, you can understand how to live a better life.
Esther, the way that I first found out about you was through a Google Doc that was just floating around in the Stride Google Drive, which I have no idea where it is now. It may no longer exist, or in some dusty corner. It was a list of Agile videos and consulting videos that you must understand if you – when you're starting at Stride. One of them was your talk about the six rules for change.
[0:07:50.7] ED: That's good to hear.
[0:07:51.9] WJ: There are six rules for change!
[0:07:53.2] ED: Actually, there's seven now, which is –
[0:07:54.8] WJ: Oh, my goodness.
[0:07:56.6] DA: Which is great.
[0:07:57.3] ED: I wouldn’t be a good role model for change if I refuse to add something new one and thought about it.
[0:08:05.5] DA: Can we go over what these seven rules are?
[0:08:07.0] WJ: Yeah, let’s hear it.
[0:08:08.0] ED: Start from congruence, because it's the only place from which empathy is possible. Honor the past, present and the people, because paradoxically, honoring the past helps people let go of it. Assess what is, because change doesn't start with a vision, it starts with where you are. Activate networks. Don't rely on the hierarchy. Real work happens through webs of connections. Guide rather than standardized. Figure out what has to be consistent across the organization and where local evolution is possible. And experiment, because big changes freak people out and small changes are a vehicle for learning and contain the mess. Use yourself, because you are the most important tool for change you have.
[0:08:55.5] WJ: It's pretty good stuff. Yeah, I appreciate it how the rules for change themselves are also malleable and also this feels like a sequel, a Hollywood sequel. It's a big blockbuster. The seventh rule.
[0:09:08.4] SM: That does sound ominous, doesn’t it?
[0:09:12.7] WJ: How does this tie in to results versus improvement, these six rules, seven rules?
[0:09:18.4] ED: Well, I think you can make a lot of ties in that if you want to improve something, you have to assess what is and figure out what you can – what experiments you can do to move things in a more fruitful direction. That means you have to honor what's happening now, so that people don't feel you're just trashing their efforts, right? Their past efforts. I think there's a lot of tie-ins.
[0:09:43.8] DA: Yeah. I think a manager, a really great manager of a team will probably know how to work easily, whether either unconsciously or consciously. Yeah, I thought that. Recently, we're talking about the different roles that one might take, that have fallen to different areas in terms of your responsibility for improvement for another person, versus your responsibility for the results that they're doing. I thought that was a pretty powerful tool, where in the bottom right quadrant where you're responsible for results only and the growth of no one else, then you're just a hands-on expert and you're just getting things done and you don't care about anybody else.
Maybe in the middle you're a teacher and you're showing people and working through those things. Not for a right-hand corner where you're response for results and growth. You’re a partner. You're really in it with them together.
[0:10:41.6] WJ: What's the final quadrant?
[0:10:43.1] ED: Well, there's nine of them. One axis looks at responsibility for improvement and the other looks at responsibility for results. It comes from some work by Champion, Kiel, and McLendon. I studied with Jean McLendon, so that's how I became aware of it. It's a way of thinking about in a given situation, if I'm a coach, if I'm a team lead, if I'm a consultant, how can I be an assistant in this situation? It's also has something to do with what the psychological contract is. If I've been hired as a hands-on expert to write code and then suddenly, I'm trying to teach people how to do something, or teach the managers how to do something, it's going to be extremely disruptive, right? It will it will often be taken as trying to one-up somebody.
It's useful in a lot of different dimensions, but thinking about what is my responsibility here? Is it for just getting stuff done, or am I supposed to actually leave this team in better shape than when I got here more capable?
[0:11:51.6] SM: Esther, does this mean that a quadrant isn't better than another quadrant?
[0:11:55.9] ED: That's correct. It's all about what's the best fit for the function and what's the relationship you have established. I remember a billion years ago when I was taking ballroom dance lessons, there was there was somebody who was really quite a good dancer and she tried to give some pointers to someone and that other person just got really angry, because he had not agreed that she could be his teacher. It's not that one is right or wrong, but it is what is the fit for the situation and what is the fit for the relationship?
[0:12:31.1] WJ: Yeah, that makes sense. It’s nice having tool they provide some additional vocabulary, that we can use to communicate about these things, so we can address problems like that, where there's a difference of expectation.
[0:12:40.8] ED: I've seen that play out in the situations that you guys are often in, where you are hired to come in to a company and work on writing code. Sometimes the expectation is that you will actually impart better practices, or knowledge of certain languages or techniques. If the people there on the team haven't been told that, they may not have accepted you as teachers.
[0:13:08.2] DA: That's not to say that you can't, even if you have been hired in position as a teacher, doesn't mean that you cannot play that role at a company, or as a person. It's something that you have to earn and come to an organic way.
[0:13:25.0] SM: Yeah. As a team lead, I imagine interacting with various people in various groups, you have to do differently. How do you suss out where someone thinks they are and if they think they are somewhere, whether or not, how do you help them get to where they think they need to be? If someone thinks, or a technical expert, you probably want to interact with them differently than you would a partner. But how do you figure out what the expectation is? Do you just ask the question ahead of time?
[0:13:52.8] ED: Well, you could say, “How do you see yourself on this project?” That might that might get you some answers, or at least an opening to have more conversation. If they say, “Oh, I see myself as the lead engineer and the expert on blah, blah, blah. Tell us your something.”
[0:14:10.5] SM: Yeah, definitely.
[0:14:11.0] WJ: This is making me wonder about what all of my co-workers think that their role is on the team. I never thought to ask them that. That's a great question.
[0:14:18.2] DA: Right. Yes, interesting to have a label for it, or you were saying before, ability to ask permission. I know pair programming is a great thing to talk about all of these different aspects of the quadrant, more towards the results side. Ideally if you're in a great pair, like your partners, you're both helping each other grow, you're both responsible for results you're writing code. Sometimes you might want to take a step back and be like, “Let me show you something. Let me model this for you,” which is the step below that. You could say, “Okay, let me do this right now and then you can replicate it.”
[0:14:55.7] WJ: What I have defaulted to these days is to model what I think are best practices and assume that the other person understands and follows along and let them slow me down and say, “Stop. I don't understand this. Can you please explain? Or actually, I'd like to do this in a different way.” Rather than trying to assume that there's something that I don't know, or something that they don't know that I should teach them.
[0:15:22.7] ED: Yeah. Well, I think that's always a good starting place. Do you have the explicit discussion about if I'm going too fast, slow me down, or –
[0:15:30.8] WJ: Sometimes I'll say, “If you have any questions about what I'm doing, definitely ask me,” or something to that effect. I usually do it in passing it quickly.
[0:15:40.6] DA: Yeah. Yes, an interesting idea about signals, like laying everything out on the table and having that available for someone to point to and be like, “Oh, this is what's happening right now. You're going too fast. Or I don't understand that.” That there's an expectation that that's okay. Cool. We've talked a bit about individual interactions and working towards growth one-on-one. What if you're in a situation where you're responsible for a whole team, or a group of people?
[0:16:19.6] SM: Yeah. I'm really curious about this subject. How much as a person that's new to our team, or a team leader should they focus on leveling up the entire team, so that the team is more efficient and produces more, as opposed to leveling up individuals and making the individual a better programmer, or engineer?
[0:16:41.8] WJ: I guess the dichotomy there is how much do you focus on actually delivering and then how much do you focus on getting the team moving faster?
[0:16:51.1] SM: Well, I think as a leader or as a manager, there's certain things you can do within your team to make the entire team deliver faster.
[0:16:59.6] WJ: Yeah, absolutely.
[0:17:00.5] SM: Then there's certain things you can do to help individuals level up. I'm curious how you identify which person needs leveling up and how you identify, how do you identify when it's necessary to just unblock the team?
[0:17:17.3] ED: Well, it's an interesting question. I think the traditional assumption is that if you have – if you pay attention to individual skills, you'll end up with a great team. I think that is not the case. I think if you focus on having a great team, then you're going to have great individuals, because they'll learn from each other, right? They will challenge each other and they'll grow together, right? I think it's great teams result in great individuals, rather than the opposite.
[0:17:50.9] WJ: Just focus on improving the team and then the individual improvement will follow on its own?
[0:17:56.0] ED: Yeah. Well, sometimes you need to put some special effort into it. I mean, I've done retrospectives with teams where they talk about, where do we have a lot of strength and where are we only mediocre in a particular skill? What can we do to improve as a group? Which individuals might invest in this and then and then share it with the team? Individuals learn stuff and individuals have capabilities. Their capabilities are amplified when they're in a team that engages in continuous mutual help and learning, and where they're amplifying each person's strengths.
A really interesting diagram a while ago, Llewellyn Falco drew it. Anyway, it was like, he was diagramming what happens in mob programming. If you have a line here, each individual has strengths and weaknesses and mobbing allows you to take advantage of everybody's strengths and it mitigates the weaknesses, because you're all working together all the time. I think that's true, even for teams that aren't mobbing but are working really well together. You're able to take advantage of everybody's strengths and minimize the impact of areas where they're not as well-versed in a technique, or a language, or practice, or whatever it is.
[0:19:28.5] WJ: Yeah. I've been going through that recently. Actually, I’ve been mobbing on adding automated end-to-end testing for an application. Recently, I've seen exactly this dynamic. We had a mob session and there was one person who was an expert in the codebase and really understood where the skeletons were hidden and all the edge cases. There was somebody who really understood the infrastructure. There was somebody who really understood the testing tooling. Then there was a QA engineer who had been doing all of the manual testing. It was really interesting watching the group work together. It didn't really matter who was at the keyboard, because you could fill in for each other's weaknesses.
[0:20:14.4] DA: Yeah. Enzyme testing sounds like there's a lot of monsters there. You have to have a full understanding in order to have an effective test.
[0:20:24.7] WJ: Yeah, and it was like, we would have these questions. What actually do we really need to test? The QA guy was like, “Well, here's what we actually do test.” That's a good starting point. Here are the areas where we've actually found bugs before.
[0:20:40.2] SM: Is the solution to just mob program all the time?
[0:20:45.5] ED: No, I think that's a really – it's a really great story. Mobbing is one way to do that. There are teams that manage to do it without mobbing all the time, because they are engaging in that discussion as they do their work. It shows up the fallacy of we all have to have – if we just have five superstars, we'll have a great team, right? Because it really requires the specialization of each person, as well as their ability to learn near neighbor domains and absorb from other people.
[0:21:19.8] SM: As a manager or a team lead, how have you found effective ways to foster that communication within the team if they're not doing something like mob programming?
[0:21:29.4] ED: I think pairing helps. I think if you can do egoless reviews, that helps, which is something we use.
[0:21:37.4] DA: What's an egoless review?
[0:21:38.9] ED: It's a Weinberg style technical review, where you're actually looking – you're looking through each other's code something and examining the code, not the person, right? There are just particular protocols you follow that makes it not a horror show.
[0:21:58.1] DA: As many PRs often devolve into.
[0:21:59.6] ED: I know. I know, I know, I know. That can help. I mean, I've at various times done sorts of chalk talk about it, or will just pick an interesting piece of code and we'll talk about, “Well, how was this implemented? What are other ways it could be implemented?” It's just a way of having those discussions in a particular setting that's focused on learning, not as fluid as mobbing would be, but it has some of the same benefits.
[0:22:29.7] DA: It sounds like a lot of that comes back to feeling safe. Doing a code review in a way that doesn't feel like an attack, or considering alternatives even if we may not go with them just for the sake of bettering ourselves and considering what might be, even if we don't actually go through that.
[0:22:53.0] WJ: I read an article in the Harvard Business Review recently, they talked about this. It sounds very similar to what you were talking about with the Weinberg style reviews. The idea came from Pixar. The way that they were able to transform Disney's culture and get them back to making hit animated films, and what they did was they added one rule to the meetings when they did these reviews of scripts. I was surprised at the rule. I mean, so they began by saying obviously, “This is an egoless place and we're going to provide criticism and it's going to be hard. Just we all have to trust each other and be safe.”
That's an easy thing to say. Oftentimes you say it and it doesn't really feel that way. What they added to that was they said and we're being very explicit about everyone in this room being an equal and everyone in this room making suggestions. The final decision is always going to continue to lie with the person who is actually doing the implementation, the people who are actually writing the script, or in our case, the people who are actually writing the code. We tried that on my current team and it really did change the vibe.
[0:24:14.3] ED: That's super interesting, because that's one of the general guidelines for a Weinberg style review is that ultimately, the person who wrote the code makes the decision.
[0:24:24.4] WJ: It was hard. It was awkward and difficult, just like in the Pixar meetings. They say that it always is. I remember we got to a point where everybody disagreed and it seemed like we were getting more and more suggestions and we’re not getting any closer to consensus, but we pushed through it. Eventually, we started to hone in on things that actually felt better. I don't think that we got to a perfect solution, but I do think that everybody left that meeting feeling we had left it significantly better than we found it.
[0:24:54.5] DA: Good stuff. Yeah. I mean, those exchanges to people can become very invested in their ideas and their expertise being an extension of themselves. By choosing one expertise over another, one design up for another, it can feel like a personal attack and an eroding of your value.
[0:25:17.0] WJ: What do you mean you don't like my method name? Does that mean you don’t like me?
[0:25:24.1] DA: You finally figured it out. Yes, it was the method names.
Yeah, it's intense. Yeah. There's an interesting comparison between – there's the legend of the programmer and where the programmer goes into a room by himself and locks him in aside there and writes until 3 a.m. and whatever. It's very legendary solo thing. Programming is not like that anymore. It's a it's a team sport and you have to be good with people in order to really make a great thing, because it’s too complicated for one person to lock themselves in the room.
[0:26:05.1] ED: I think with a few exceptions, it's always been that way. Because I was writing code in the 70s and the best code always was – you'd work on something, you get some input, you'd work on it, you get some input. It wasn't the lone person sitting in a room. I mean, Alan Turing could probably do that, but the rest of us, it is definitely a matter of communication and collaboration.
[0:26:31.9] DA: Yeah, yeah. Sometimes I felt like requirements, documents and other things, like can I just put up barriers. I’m like, it’s okay. Well, we don't have to talk. For those at home, Esther it looked like she was about to vomit. Just barf.
[0:26:51.2] ED: Yeah. They're a way to put distance between people. The sad thing is that the people who might write that document have a huge amount of knowledge, but most of that knowledge is not actually contained in the document and is lost when they hand it off to someone else to write the code. It was a quest for efficiency that didn't actually help.
[0:27:11.9] DA: It was fun while it lasted, we'll say.
[0:27:15.5] ED: No. I worked that way and it was at one point and it wasn’t – wasn’t that much fun.
[0:27:23.9] DA: Yeah. Thankfully, we're talking about collaboration and gathering together. Yeah, so I really feel we went through a lot of these roles here today on this podcast. Thank you for being a teacher, Esther, and teaching us about these roles, William and Stephen partners, as always. Esther, do you have anything you like to plug, or any way that people can reach out to you?
[0:27:49.3] ED: Well, I think we also modeled continuous mutual help. I'll send a picture of that grid, so people can look at in the show notes.
[0:28:02.0] DA: Oh, yeah. I think that'll be super helpful.
[0:28:04.5] ED: I'll do that. The other thing I should mention is I have a book coming out this summer, which is super exciting.
[0:28:10.8] DA: What?
[0:28:12.4] SM: That’s over exciting.
[0:28:13.9] ED: Yeah, 7 Rules for Positive, Productive Change: Micro Shifts and Macro Results.
[0:28:19.0] WJ: By the time that book comes out, it’s going to be eight, I feel like. No, we’re already to the galleys. When is it dropping?
[0:28:28.2] ED: I don't remember the actual pub date off the top of my head. July. I'm looking at the copy editing now, so traditional publishing is a waterfall process. Anyway, but coming out this summer.
[0:28:42.0] DA: That's fantastic. That's going to be a blockbuster, I'm sure.
[0:28:44.0] ED: If people want to get hold of me, it's pretty easy. I'm esther@estherderby.com, or @EstherDerby on Twitter.
[0:28:50.8] DA: That's easy to remember. All right. Well, it was a pleasure.
[0:28:55.2] ED: Yeah, it was really lovely. Thanks for inviting me.
[0:28:57.7] SM: Thank you, Esther.
[END OF EPISODE]
[0:28:58.6] DA: Follow us now on Twitter @radiofreerabbit, so we can keep the conversation going. Like what you hear? Give us a five-star review and help developers just like you find their way into The Rabbit Hole. Never miss an episode, subscribe now however you listen to your favorite podcast. On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Michael Nunez who’s out being a dad, and me, your host, Dave Anderson, thanks for listening to The Rabbit Hole.
[END]
Links and Resources:
7 Rules for Positive, Productive Change on Amazon
