Today we continue our exploration of the Aristotle Project, and we are joined by Sophie Creutz to discuss dependability. Dependability is one of the factors that Google found to be most impactful on the success of a team and to kick things off we run through this list again, as well as some of the surprising things that are not correlated to a team's success. With Sophie's help, we look at the efficacy of a Scrum of Scrums, how to balance informative communication with remaining concise enough, prioritizing the team mentality, avoiding the bystander effect, and a whole lot more. We believe that the measures you take for your team or set of teams are essentially there to foster dependability in light of the fallibility of humans and that a lack of ownership and a negative herd mentality are the biggest enemies to your team's success. So for this brief yet enlightening chat on how to sure up your projects and the teams that work on them, join us down The Rabbit Hole!
Key Points From This Episode:
{{addCallout()}}
Transcript for Episode 222. Aristotle Project — Dependability with Sophie Creutz
[0:00:00.5] MN: Hello, and welcome to The Rabbit Hole, the definitive developers podcast, living large in New York. I’m your host, Michael Nunez, our co-host today.
[0:00:08.9] DA: Dave Anderson.
[0:00:09.1] MN: And our guest extraordinaire.
[0:00:11.4] SC: Sophie Creutz.
[0:00:12.2] MN: Today, we’ll be talking about the Aristotle Project, mainly about dependability. Before I begin, I mentioned that Dace was out on vacation. He’s going to get married soon. But in the topic of dependability, Dave is here right now, still with us. What’s up, bro?
[0:00:29.2] DA: I had to come through.
[0:00:30.9] MN: You had to be dependable.
[0:00:32.5] SC: You had to come through.
[0:00:33.5] DA: Yeah. I mean, to say nothing about work-life balance. But yeah, where’s dependability into work-life balance? I imagine there’s probably some kind of boundary that I should cross, but here I am.
[0:00:48.4] SC: I guess the boundary is like, where can you – if you cross the boundary, then you are no longer dependable in both your work and your life, maybe.
[0:00:57.6] DA: Yeah, that’s true. Yeah. I guess if you go too far, then it will all fall apart or at least one part will.
[0:01:04.7] MN: Yeah, the balance of dependability between work and life is a balance of itself. Today, we’ll talk about what are some tips or ways to increase dependability. We try to define it according to Google Aristotle Project and things we’ve seen out there that worked for us.
[0:01:25.3] SC: Yeah. How do you know if you are being dependable or not, like what does it look like from the outside? I think there are some things that Google found that maybe are a little bit surprising that I wouldn’t have thought correlate.
[0:01:38.8] DA: I missed the last episode. What is Project Aristotle?
[0:01:42.6] MN: Oh, yeah!
[0:01:43.7] DA: Can you run it back for me?
[0:01:44.3] MN: Sure. For those who are jumping in the middle of the series, the Aristotle Project was conducted in various Google teams and have realized that in order to have a successful team, you will need to have five different attributes across that team. The list is going with – starting with psychological safety, dependability.
[0:02:09.4] DA: That’s today.
[0:02:11.1] MN: Structure and clarity. Meaning, and impact. When you have those five things together that will increase the effectiveness of the team and an increase the effectiveness of the teams at Google. Maybe we had a discussion on psychological safety and then there’s a list of things that actually do not correlate to an effective team. I can go over that list that really quick. Co-location of teammates, sitting together in the same office, not really that effective, not relevant. Consensus-driven decision-making, not so much. Extraversion of team members, individual performance of team members, workload size, seniority, team size and tenure, not really relevant I guess in the sense of the effectiveness of a team for Google was the five things I mentioned before.
[0:03:02.2] SC: Yeah. That’s what their research found at least, is that these things that maybe in the common narrative, we think will determine the success of a software development team. As a matter of fact in this, it turns out they are less relevant than these five factors that we’re discussing.
[0:03:18.7] DA: Wow! Okay. Dependability is a big one. Sophie, what was the surprising finding with that? How it could lead?
[0:03:29.7] SC: Yeah. I thought that was kind of interesting. In their team effectiveness discussion guide, they mentioned that one thing. Okay. Signs that your team needs to improve dependability. One is, team has poor visibility into project, priorities or progress.
[0:03:47.0] DA: Interesting. I guess, if you’re just working on a bunch of random things that and you’re not tracking it in any meaningful way, like you’re backlog or measuring how close you are to being done on like a large feature epic, than you may be less dependable.
[0:04:10.9] SC: I think that’s part of it. Yeah. I guess, also, if you don’t have good like cross team communication. Is that a better word for that? Like inter-team knowledge or just like elimination silos or understanding like other people’s roles and that kind of thing. I think that’s what this is getting at maybe a little bit.
[0:04:32.2] MN: I think we’ve mentioned very briefly, but the idea, I imagine one way to mitigate cross team or to ensure there is cross team communication is, Scrum of Scrums, where you have like the Scrum Masters from each team meet and they have their daily standup across each other. That way you have – everyone has information about everyone else’s team at some point in time. It’s a way as a tool that I seen being used. Scrum of Scrums is pretty crazy, because it’s like one level above the team that you’re currently on to share information and ensure that the projects are going.
[0:05:06.5] SC: Can you remind our listeners probably a little bit about what Scrum of Scrums looks like.
[0:05:11.1] MN: Yes. It’s like – you have your Scrum with your individual team, if you’re working on the checkout page, I guess if you will, there will be a daily stand up there. But then that information then gets bubbled like the summary of all those standups go with another individual. It could be a team lead or it can be with the scrum master of that team. They meet with other parts of the organization, other parts of the application. If you’re working in the checkout page, there’s probably a team working on the product page, there are teams working on the search page and that kind of stuff. Then the standup update for that gets shared across those teams with those individuals, so that if you’re working on the checkout page and you’re dependent on something in the product page, then you can hear the standup update or the project page by going into that standup session.
[0:06:00.2] SC: I love that. What a great idea.
[0:06:01.8] MN: Any information that is needed get translated back to the person who attended to then talk to the team, to talk about what happened during the Scrum of Scrums.
[0:06:10.2] SC: Okay. Potentially, there is still little bit of a game of telephone it sounds like, if not everyone is attending Scrum of Scrums.
[0:06:18.4] MN: Yeah. I mean, that would be a huge meeting. If you merged teams and that would do it. But that is one way –
[0:06:25.3] SC: So then I guess, also the requisite question here is how far does it go, right? Is it scrums all the way down?
[0:06:32.5] MN: Scum, scrum, scrum and then you got scrum of scrums, of scrums of scrum. I think the very next – I think if you had to do Scrum of Scrums of Scrum at that point, I think that you would – one way I’ve seen information kind of disseminated across an organization, like I guess organizationally would be to do your demos and invite everyone, because then everyone gets a chance to see that stuff that you’re working on.
[0:06:57.1] SC: Right! You just have to promise popcorn or something like that, so that everyone will come.
[0:07:02.6] DA: Yeah, electronic popcorn these days.
[0:07:05.6] MN: Mm. Uh-uh.
[0:07:05.8] DA: Yeah. I feel like even if you’re applying like a tool like that to broadcast the visibility of your progress, it can still be like kind of a word soup or not clear about like what exactly the goals or priorities are and like what kind of meaningful progress is happening. I think it’s still important to be like really clear and crisp about what the priority is, what your goal is and like how you’re inching forward. Because I could totally see the Scum of Scrums just turning into like a real slog, where everyone was just like listing out every single thing or it’s kind of diffuse, like too much information.
[0:07:54.5] SC: Right. So not too much detail, but also like kind of clear and concise. So you wouldn’t give an update that was like, “Okay. Our team worked on some stuff, and we fixed some bugs and it was great.” Probably one of – What do you think, Dave? How would you be concise and yet informative?
[0:08:17.0] DA: I mean like, you have to communicate to the audience that’s most important or like, that’s receiving the message. But I think, with like this Project Aristotle, it sounds like we’re really concerned with like the team being the unit. Like if there’s like interdependencies between the teams, then hopefully, you’re getting that kind of information.
[0:08:40.5] SC: That’s the best [inaudible 0:08:40.8] to bring up right like –
[0:08:42.5] DA: That helps.
[0:08:43.2] SC: Yes. Are there dependencies between what your team is working on? What other teams are doing? Are there interior dependencies between team members on your own team too maybe.
[0:08:55.4] MN: Right. I think going and looking at the team itself, in our standup, I would imagine that there are – there might have been a test or something, some signs of test that had happened to determine how do you know that you’re teammates are dependable and this dependability is important? I think it starts at the lowest part of the team itself, of the organization.
To me, the first thing that came to my mind when I read about dependability and like how do you increase that would be like drafting or having a working agreements meeting. Has anyone ever attended like an official, you sit down working agreements meet? I’ve only done it once, and it was really, really interesting and I thought that those were pretty cool. I want to hear your thoughts.
[0:09:47.8] DA: I’ve definitely done it a bunch, like – I think it’s great too when there’s a new person who comes onto a team to kind of like revisit that. Like a lot of things about working agreements are like more mechanical, and like how do we work, when do we work, things like that. But I think that’s a great idea, like why not build in this commitment to feasibility of what our priorities are and how we’re making progress into it. Working agreement like, say, “Hey! We are going to make it a priority,” and kind of drive towards dependability through that.
[0:10:25.9] SC: Is that a place too in the working agreements meeting, where you can talk about if something does happen, how to address it. For instance like, if dependability does become an issue, how do we proactively communicate with each other about that or if there is going to be a delay, how do we bring up that? It could be a little bit of an elephant, right, like if someone’s not doing their work. If feel – yeah.
[0:10:52.5] DA: Yeah. I mean, I guess like retro would be good place to talk about that too, where maybe you see someone or like a situation where we’re not talking about delays, or like no one’s taking up specific responsibility for a task, then that’s a good time to be like, “Hey! This is a really specific instance where this happened. How do we fix that going forward?”
[0:11:17.3] SC: Right. How do we examine why this occurred? Because as we mentioned, this is not just like an individual mentality kind of thing. It’s a team mentality, right? If something is going wrong, we want to address it as a team as well. I think in that regard, it’s also important to be super compassionate, especially these days, right? Because there’s so much going on in everyone’s life. It seems quite unlikely that if there is a delay of someone from the outside seems to be less than 100% dependable in that moment. It’s probably not because they just sat down one morning and thought to themselves, “You know what I’m going today? Nothing.”
[0:11:58.4] DA: Knock it off. I like the term in these white papers that are linked in the rework document, where they’re talking about social loafing, and shirking, free writing.
[0:12:14.0] MN: No, free write. I mean, I think –
[0:12:14.9] SC: Free loading?
[0:12:17.1] MN: I think that that goes back to having psychological safety amongst your teammates too, because say for example, on the working agreement, you have – no one should be late to meetings, like plastered. I don’t know – before, back in my day when we were going in the office, we had our working agreements like on the wall, like everyone was able to see this piece of document. I was like, “Okay. That’s cool. We have it on the wall.” But the idea of like, say one of the items were, no one should be late to meetings. We find that Bobby has been late to standup the past couple of days. Like, you can’t just be like, “Yo! Bobby is out here slacking. What’s up? Step it up? Bobby, stop playing.”
You would go in and say, “Hey! What’s going on, Bobby? Is everything okay? Is there anything you want to discuss? We had the working agreement meeting. Item number three says, don’t be late to meetings and I’ve noticed the past couple standups, you haven’t been able to make it. What’s up? Everything good?” Versus, “Yo! Why are you late? You should be in meetings on time. We all agreed on that one.”
[0:13:24.4] SC: Or even worse, don’t address it and then when Bobby gets assessed for — when he’s maybe going to get a raise or not, or whatever, then that’s the point at which he finally finds out. Right? We don’t want to leave it until –
[0:13:38.2] MN: Exactly. Like the psychological safety is needed for dependability, so that when people falter for whatever reason because life as we all agree, happens.
[0:13:49.2] SC: Humans are naturally fallible.
[0:13:52.2] MN: Yes. You are sympathetic to or empathetic to them being able to help them become more dependable.
[0:13:59.4] SC: Yeah.
[0:14:00.0] DA: Totally.
[0:14:00.6] SC: What does that look like?
[0:14:01.7] DA: I mean, that sounds kind of like psychological safety, right? Kind of fostering that among team members.
[0:14:08.9] SC: Like I could say to Bobby, I could say, “Hey! Have you heard about these alarm clocks that will run away from you, they’re on wheels and then they will go off and they will just start moving around your house? It’s a real thing.
[0:14:23.9] MN: That’s crazy. It’s like a rumba, but for alarms?
[0:14:27.4] SC: Yes. Put it on the rumba.
[0:14:30.4] DA: Pretty sure my dog would have ate that.
[0:14:32.8] MN: Oh no!
[0:14:34.8] DA: Yeah. There was another point in this guide about dependability that I really liked as well, that resonated with me, this idea that like if you have diffusion of responsibility and there’s no clear owner for a problem that comes up or something that needs to get done, then that could negatively affect like the output of your team. I feel like there’s a lot of things that I’ve seen over the years where it’s like, “Oh, yeah. This build stuff always fails. It’s not my problem.”
[0:15:10.3] MN: Yeah.
[0:15:11.6] DA: Yeah.
[0:15:12.6] SC: Yeah. That herd mentality, right? I am a member of a group. I’m a member of potentially quite a large group. Therefore, why would it fall to me to address this.
[0:15:22.4] DA: Right. It’s like, “Oh! There’s so many teams who are affected by this.” But like, clearly, someone else is going to take ownership of this and carry I forward.
[0:15:33.3] SC: Yeah. In that case, the responsibility has diffused so much that it basically disappeared.
[0:15:40.9] DA: Yeah. Like some companies like Facebook, they actually have principle that like it’s everyone’s responsibility to fix everything, or like it’s your personal responsibility. If you see something, that’s your responsibility.
[0:15:57.4] SC: If you see something, fix it. But if everyone sees it simultaneously and fixes it simultaneously, you’ll have 20 different solutions.
[0:16:08.5] DA: I mean, I guess, there’s probably like an element of communication or like broadcasting. It’s like, “Hey! This is messed up.”
[0:16:15.1] SC: I found this thing, I’m going to fix it.
[0:16:17.3] DA: I’m the guy. I’m the person who’s going to go in there and deal with that.
[0:16:20.5] SC: I’m the one. I have raised my hand.
[0:16:22.9] DA: Exactly.
[0:16:24.0] SC: I am doing it.
[0:16:24.4] DA: Yeah.
[0:16:25.3] SC: Yeah. Do you think that’s hard for people to do though if they’re already maybe overwhelmed with their workload or something like that?
[0:16:32.3] DA: I think so, yeah. Like there are like priorities that you’re trying to complete. That’s why that responsibility gets diffused in the first place because you’re like, “I can’t deal with this right now.”
[0:16:44.0] SC: Right. Maybe I’m not even supposed to, because I’ve been told I have other priorities.
[0:16:49.1] DA: Right. Yeah, totally. You got to ship that button. We need that button out there. Don’t worry about the CI.
[0:16:57.7] MN: Well, isn’t that a case of bystander effect. I had to do a quick Google. I’m not the smart people. But the idea that like the more people who are around a particular problem, the less likely someone will address that problem.
[0:17:13.4] SC: Yeah.
[0:17:14.5] MN: If 20 engineers saw something, are all 20 actually going to do it or is it going to be like, “Bobby, will take care of that. Bobby is on that.” or like, Bobby is, “Oh! I think Lucy might take this one." And so on and so forth. Then lo and behold as Dave mentioned earlier, that build pipeline stays 15 minutes because everyone else thinks someone else is going to do it.
[0:17:37.0] SC: Yeah. Bystander effect. You could tie this into social issues too, right? I don’t know if you remember that expression like they came for my neighbor and I wasn’t this kind of person, so I didn’t help. And then they came for my other neighbor, and I wasn’t them so I didn’t help. Then they came for me and no one helped. So, yeah.
[0:18:01.5] DA: Everyone is just looking at the pipeline until it is you who’s been sitting there for 30 minutes because your pipeline build is very, very slow and no one is fixing it.
[0:18:12.9] SC: Right.
[0:18:13.7] MN: If you do see a slow pipeline or something that could be worked on, you know, bring it up in retro, make sure that I gets addressed and we’re going to sign it to someone as Dave mentioned, having clear roles for someone to pick and do those things. Then that person completing it makes them more dependable in the team at the end of the day.
[0:18:33.2] SC: Yeah.
[0:18:33.1] MN: One more tool I guess in Agile and XP would be the iteration planning meeting and the commitment ceremony where everyone is looking at the amount of work that they’ve done last week, checking their velocity. Then this week, they’re going to choose the amount of stories that they’re going to do. At the very end of that meeting, it’s like, “Hey! Is everyone cool with the 17 points last week? We’re going to do 17 on this one. Everyone okay?” And you make that commitment, and you complete it and you make sure that you do. That’s probably another tool that we have in our tool box for us to do that.
[0:19:07.4] SC: Right. Something about articulating that commitment with other people listening I think probably helps you to accomplish it.
[0:19:17.5] MN: Yeah. I mean, I’m sure there’s a whole lot of other dependability tools that exists out there.
[0:19:23.7] SC: Well, Pomos, I mean, personally I find Pomos to be incredibly useful for dependability. For those of us who don’t want to use that specific lingo, Pomos is your Pomodoros, which is just a timer system, right? You can do 30 minutes on, five minutes of break, 25 minutes on or 10 minutes of break, et cetera, et cetera. It’s just helpful to keep yourself focused in these increments of time, and then also, force yourself to take breaks as well, which resets your mind and helps you reapproach the problem in like a calm, logical manner.
[0:20:07.7] MN: Yeah. I think with the Pomos, definitely builds dependability in that regard because you’re dependable on those 25 minutes, and then five minutes, you can do whatever you want. You come back for the 25, and you go back to the five or whatever you want.
[0:20:19.1] SC: Although ideally in that break of time, you’re doing something that is a bit of a contrast from what you are doing before so you are going to try and not look at a screen. You’re going to go look at the treetops, you’re going to go say hello to your pet fish, something like that. Yeah, just something that isn’t looking at a screen and programing.
[0:20:38.0] MN: Yeah. Awesome. Next up, we’ll be looking at the structuring clarity aspect of the Aristotle Project, which will be very, very interesting. Looking forward to that. Let’s all be dependable out there for our teammates and for ourselves.
[0:20:53.7] SC: Get that alarm clock, yeah.
[0:20:56.2] MN: Get that alarm clock. I definitely need it. I think we should put the link in the show notes or something.
[0:21:01.3] SC: Yes. Yeah, I think we should.
[END OF EPISODE]
[0:21:06.1] MN: 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 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, Dave Anderson, and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
[END]
Links and Resources:
