Today on the show we will be discussing responsibility for results versus responsibility for improvement in terms of your management and team style and what kind of forms and shapes that takes.
Joining us for the discussion, we have the esteemed Esther Derby. Esther started her career as a programmer, and quickly realized that her real work involved changing the way people worked, and supporting them though that process. In 1997, she founded Esther Derby Associates, Inc., and today she works with a broad array of clients from Fortune 500 companies to start ups. Inside this episode, we discuss and outline Esther’s seven rules for adopting change, why it is more important to level up the whole team rather than choosing individuals, and what it looks like to have the proper knowledge communication within a team. For an insightful conversation, join us today!
Key Points From This Episode:
[0:00:00.8] DA: Hey folks, thanks for tuning in to 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. Been a long road to 100. Here we go.
[INTRO]
[0:00:21.3] 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.
Often times you hear software engineers mention in a particular part of the application that they’ve built their “baby” and it’s like a feature or like an entire part of the site and I totally understand what where 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. You’re running your test 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, I’ve had a completely different experience with baby Giovanni. There are a ton of books that contradict each other. Baby Giovanni is essentially production and I have to figure out ways to ensure and appease baby Giovanni. 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 could 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. So my legs are going to be hella swole 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 @radiofreerabbit at twitter.com but our voice mail number is 914-999-2165. We’d love to hear your thoughts and questions over voice mail 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 Jeffreys 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 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 listen to the first episode and our sound was very different to what it sounds like now, and 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 outs to Emanuel and many others and honorable guests who have appeared on this show.
With that being said, let’s dive right in to Episode 100 of The Rabbit Hole.
[EPISODE]
[0:03:41.6] DA: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast in fantabulous Chelsea, Manhattan. I’m your host, Dave Anderson. With me today I have —
[0:03:50.3] SM: Steven Merryweather
[0:03:52.1] WJ: And William Jeffries.
[0:03:52.9] DA: Today, we will be discussing responsibility for results versus responsibility for improvement in terms of your management and team style and what kind of forms and shapes that takes. With us today, we have the esteemed Esther Derby.
How are you doing Esther?
[0:04:11.2] ED: I’m great. I made it home through the snow, so all is well.
[0:04:17.2] 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:04:29.3] WJ: Yeah, it’s like 7/11 slushy mixed with dirt.
[0:04:35.0] DA: That’s not the romantic kind of snow. Why don’t you introduce yourself for folks who might not be familiar?
[0:04:41.2] 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 and, you know, I did some testing because we always used to test our own code and I was a team lead and a dev manager and internal consultant and 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.
So that’s where I focus a lot on my intention 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:05:24.6] DA: I love that concept where you know, you're designing the system to encourage the behavior. Often like it's kind of like the opposite where people want heroics or what have you that save the day. But actually, if you just step back and look at the larger forces at play, you can kind of 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 is in some dusty corner but it was like, a list of agile videos and consulting videos that you must understand if you – when you’re starting at Stride and one of them was your talk about the Six Rules for Change.
[0:06:13.5] ED: That’s good to hear.
[0:06:14.7] WJ: There are six rules or change?
[0:06:16.8] ED: Actually, there’s seven now, which is I wouldn’t be a good role model for change if I refuse to add something new when I thought about it.
[0:06:28.5] SM: Can we go over what these seven rules are?
[0:06:30.6] WJ: Yeah, let’s hear it.
[0:06:31.2] 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 it 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 standardize; 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:07:18.8] DA: That’s pretty good stuff. Yeah, I appreciate how the rules for change themselves are also malleable and also, this feels like a sequel, like a Hollywood sequel. It’s a bit blockbuster: The Seventh Rule.
[0:07:31.3] ED: That does sound kind of ominous, doesn’t it?
[0:07:35.9] WJ: How does this tie in to results versus improvement? These six rules, seven rules?
[0:07:41.6] ED: 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, you know, honor what’s happening now so that people don’t feel like you’re just trashing their efforts, right? Their past efforts. So, I think there’s a lot of tie in’s.
[0:08:06.9] DA: Yeah, I think a manager, really great manager of a team will probably know how to work easily whether either unconsciously or consciously. I thought that – so recently we were talking about kind of the different roles that one might take that have fall into 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 like, you know, 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, you don’t care if anybody else. Maybe in the middle you’re a teacher and you’re showing people and kind of working through those things. You know, in the upper right hand corner where you’re like responsible for like results and growth. You're a partner, you’re like really in it with them together.
[0:09:05.0] WJ: What’s the final quadrant?
[0:09:07.0] ED: Well, there’s nine of t hem so one axis looks at responsibility for improvement and the other looks at responsibility for results. It comes from some work by Champion, Kiel, and McClendon and 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 of assistant in this situation and it’s also has something to do with what the psychological contract is.
If I’ve been hired as a hands on expert, you know, 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. It will often be taken as trying to one up somebody. So, it’s useful in a lot of different dimensions but thinking about, you know, “What is my responsibility here? Is it for just you know, getting stuff done or am I supposed to actually leave this team in better shape than what I got here, more capable?”
[0:10:14.8] SM: Esther, does this mean that a quadrant isn’t better than another quadrant?
[0:10:19.2] 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 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:10:54.5] WJ: Yeah, that makes sense. It’s nice having tool that provides 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 expectations.
[0:11:04.1] ED: I’ve seen that play out in a sort of situation that you guys are often in where you were hindered to come in to a company and work on writing code and sometimes the expectation is that you will actually impart better practices or knowledge of certain languages or techniques but if the people there in the team haven’t been told that, they may not have accepted you as teachers.
[0:11:31.8] 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 can apply that role at a company or like as a person. But it’s something that you kind of have to earn and like, you know, come to in an organic way.
[0:11:48.2] SM: Yeah, so as a team lead, I imagine interacting with various people in various groups, but you have to do differently. How do you suss out where someone thinks they are and if they think they are somewhere where they’re not, how do you help them get to where they think they need to be?
So, if someone thinks are 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:12:16.2] ED: Well, you could say, “How do you see yourself on this project?” That might get you some answers or some at least an opening to have more conversation. If they say, “Oh, I see myself as the lead engineer and expert on blah-blah-blah,” tells you something.
[0:12:33.3] SM: Yeah, definitely.
[0:12:34.8] WJ: This is making me wonder about what all of my coworkers think that their role is on the team. I never thought to ask them. That’s a great question.
[0:12:41.8] DA: Right, it’s interesting to have like a label for it or like you were saying before, an ability to like ask permission. I know like, 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 you’re 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 and you can say, “Okay, let me do this right now and you can replicate it.”
[0:13:19.1] WJ: What I have sort of 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 is something that I don’t know, or something that they don’t’ know that I should teach them.
[0:13:46.5] ED: Yeah, I think that’s always a good starting place. Do you have to explicit discussion about, “If I’m going too fast slow me down”? Or?
[0:13:54.3] WJ: Sometimes I’ll say, “If you have any questions about what I’m doing, definitely ask me,” or something to that effect. But I usually do it in passing and quickly.
[0:14:02.3] DA: Yeah, that is an interesting idea about signals like laying everything on the table and having that available for someone to point to and be like, “Oh, this is what is happening right now. You’re going too fast.” Or, “I don’t understand that.” Just so that there is an expectation that that’s okay. Cool.
So, we have talked a bit about like individual interactions and working towards growth one-on-one. What if you are in a situation where you’re responsible for the whole team or a group of people?
[0:14:42.7] SM: Yeah, so I am 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:15:04.5] WJ: So 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:15:13.7] SM: Well, I think as leader or as manager, there are certain things you can do within your team to make the entire team deliver faster.
[0:15:22.5] WJ: Yeah, absolutely.
[0:15:23.7] SM: And then there’s certain things you can do to help individuals level up and I am curious, how you identify which person needs leveling up and how do you identify when it’s necessary to just unblock the team?
[0:15:40.1] ED: Well, it is an interesting question and I think the traditional assumption is that if you pay attention to individual skills you’ll end up with a great team, and 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 and they will challenge each other and they’ll grow together. So I think it’s great teams result in great individuals rather than the opposite.
[0:16:14.0] WJ: So just focus on improving the team and then the individual improvement will follow on its own?
[0:16:19.2] ED: Yeah, well sometimes you need to put some special effort into it. I mean, I have done retrospectives with teams or they talk about you know, “Where do we have a lot of strength and where are we — we’re only mediocre in a particular skill. What can we do to improve as a group and, you know, which individuals might invest in this?” and then share it with the team. So it’s not strict. You know, 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 are 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 and 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 kind of mitigates the weaknesses because you are all working together all the time and I think that’s true even for teams that are mobbing that are working really well together. You’re able to take advantage of everybody’s strengths and minimize the impact of areas where they are not as well versed in a technique or a language or practice or whatever it is.
[0:17:50.7] WJ: Yeah, I have been going through that recently actually. I have been mobbing on adding automated end to end testing for an application and recently I have seen the exactly this dynamic. We have a mob session and there was one person who was an expert in the code base 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 and then there was a QA engineer who had been doing all of the manual testing and 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:18:36.6] DA: Yeah end to end testing sounded likes there’s a lot of monsters there like you have to have a full understanding in order to have effective tests.
[0:18:46.7] WJ: Yeah and it was like, we would have these questions like, “What actually do we really need to test?” And the QA guy was like, “Well, here is what we actually do test.” So that is a good starting point and, “Here are the areas where we have actually find bugs before.”
[0:19:03.3] SM: So is the solution is to just mob program all the time?
[0:19:08.3] ED: Well I think it is a really great story and mobbing is one way to do that and there are teams that manage to do it without mobbing all the time, but because they are engaging in that sort of discussion as they do their work. But it shows up the fallacy of we all have to have – if we just have five superstars we’ll have a great team because it really requires the specialization of each person as well as their ability to learn near neighbored domains and absorb from other people.
[0:19:42.4] SM: And as a manager or a team lead, how have you found effective ways to foster that communication within the team if they are not doing something like mob programming?
[0:19:52.2] ED: I think pairing helps. I think if you can do an ego list reviews. That helps, which is something we use.
[0:19:59.6] DA: What is an eagle list review?
[0:20:01.7] ED: It is a Weinberg style technical review where you are actually looking through each other’s code and examining the code not the person, right? So there are particular protocol is you follow that makes it not a horror show.
[0:20:20.4] DA: As many PR’s as often bump into.
[0:20:22.4] ED: I know. So that can help I mean I’m at various times done sorts of chalk talk about it or we’ll 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?” So it is 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:20:52.4] DA: It sounded like a lot like it comes back to feeling safe. Like doing a code review in a way that doesn’t feel like an attack or like considering alternatives even if we may not go with them just for the sake of better ourselves and considering what might be even if we don’t actually go through that.
[0:21:16.0] WJ: I read an article in the Harvard Business Review recently that talked about this. It sounds like very similar to what you are talking about with the Weinberg style reviews. The idea came from Pixar and 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 and I was surprised at the rule.
I mean, so they began by saying, you know obviously this is an eagle list place and we’re going to provide criticism and it is going to be hard. You know, we all have to trust each other it would be safe and that is an easy thing to say but often times 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 and the final decision is always going to continue to lie with the person who is actually doing the implementation.
The people who were actually writing the script or in our case, the people who are actually writing the code and we tried that on my current team and it really did change the vibe.
[0:22:37.2] ED: That’s super interesting because that is one of the general guidelines for a Weinberg style review is that ultimately, the person who wrote the code makes the decision.
[0:22:46.3] WJ: And it was hard. It was awkward and difficult, just like in Pixar meetings, they say that it always is and I remember we got to a point where everybody disagreed and it seemed like we were getting more and more suggestions and we were not getting any closer to a consensus but we pushed through it and eventually, we started to hone in on things that actually felt better and I don’t think that we got to a perfect solution but I do think that everybody left that meeting feeling like we had left it significantly better than we found it.
[0:23:17.5] DA: Good stuff, yeah. I mean, like those kind of exchanges too people can become very invested in their ideas and their expertise being like an extension of themselves and so by choosing one expertise over another one design it for another can feel like a personal attack and an eroding of your values.
[0:23:39.6] WJ: What do you mean you don’t like my method name? Does that mean you don’t like me?
[0:23:46.3] DA: Ah you finally figured it out, yes. It was the method names. Yeah it’s intense and there is an interesting comparison between like there is the legend of the programmer and where the programmer goes into a room by himself and locks him inside there and writes until 3 AM and whatever. It is very legendary solo thing but programming isn’t like that anymore. It is a team sport and you have to be good with people in order to really make a great thing because it’s just too complicated for one person who locks himself in the room.
[0:24:27.8] ED: I think with a few exceptions it is always been that way. Because I was writing code in the 70s and you know the best code always was you’d work on something and you get some input. You’d work on it you get some input. It wasn’t the lone person sitting in a room. You know Allan Turing could probably do that but the rest of us, it is definitely a matter of communication and collaboration.
[0:24:54.5] DA: Yeah and sometimes it felt like requirements, documents and other things that kind of just put up barriers and it’s okay. Well we don’t have to talk.
For those at homel, Esther looks like she’s about to vomit. Just barf.
[0:25:13.9] ED: Yeah, there are ways to put distance between people. The sad thing is the people who might write that document might 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. So it was a quest for efficiency that didn’t actually helped.
[0:25:34.5] DA: It was fun while it lasted, we’ll say.
[0:25:38.7] ED: No, I work that way and it was at one point and it wasn’t that much fun.
[0:25:45.1] DA: Cool, yeah. So thankfully we are talking about collaboration and gathering together. Yeah, so I really feel like we went through a lot of these roles today on this podcast and thank you for being a teacher Esther and teaching us about these roles. We even see them as partners as always. Esther, do you have anything you’d like to plug or any way that people can reach out to you?
[0:26:11.9] ED: Well, I think we also modelled continuous mutual help and I will send a picture of that grid so people can look at it in the show notes.
[0:26:24.9] DA: Oh yeah, I think that would be super helpful.
[0:26:27.0] ED: So I will do that. The other thing I should mention is I have a book coming up this summer, which is super exciting.
[0:26:34.2] SM: What?
[0:26:34.6] WJ: That is very exciting.
[0:26:35.8] ED: Yeah, Seven Rules for Positive Productive Change: Micro Shifts, Macro Results.
[0:26:42.0] WJ: By the time the book comes out it’s going to be eight. I can feel it. No, we’re already to the galleys, when is it dropping?
[0:26:50.3] ED: Well, I don’t remember the actual pub date off the top of my head July but I am looking at the copy editing now. So traditional publishing is a wonderful process so anyway. But coming out this summer.
[0:27:04.5] SM: That’s fantastic.
[0:27:05.4] DA: All right that is going to be a blockbuster I am sure.
[0:27:06.8] ED: And if people want to get a hold of me it’s pretty easy. I am at esther@estherderby.com or @estherderby on Twitter.
[0:27:13.8] DA: That is easy to remember. All right, well it was a pleasure.
[0:27:17.6] ED: Yeah, it was really lovely. Thanks for inviting me.
[0:27:20.2] SM: Thank you Esther.
[END OF EPISODE]
[0:27:21.5] 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 and never miss an episode, subscribe now however you listen to your favorite podcast.
On behalf of our producer extraordinaire, William Jeffries and my amazing host, Michael Nunez who is out being a dad and me, your host, Dave Anderson, thanks for listening to The Rabbit Hole.
Links and Resources:
Seven Rules for Positive, Productive Change
