231. Prime Directive

Star Trek fans will know that the Prime Directive is the unbreakable mission statement of the Starfleet. It's a guiding principle, deciding the course and tone for whatever the team encounters. As you’ll learn in today’s episode of The Rabbit Hole, however, the prime directive is an important concept for software developers too! Michael Nunez, Dave Anderson, and Sophie Creutz dive into Norm Kerth’s Retrospective Prime Directive and break it down phrase-by-phrase to illustrate how it applies to an agile workflow. We also share some of the other prime directive texts that we discovered, including the Team Building and Futurospective Prime Directives, and touch on their focus on psychological safety and bringing people together for a specific cause. All this and more when you tune in today!

 

Key Points From This Episode:

  • The Retrospective Prime Directive, as per Norm Kerth in Project Retrospectives.
  • Unpacking the Retrospective Prime Directive to illustrate how it applies to an agile workflow.
  • What it means to understand and truly believe that everyone did the best job they could.
  • Deconstructing the phrase: given what they knew at the time.
  • Why it’s not a question of individual skill or ability but rather how knowledge is disseminated.
  • The importance of education and self-awareness.
  • Other prime directives: the Team Building and Futurospective Prime Directives.
  • Their focus on psychological safety and bringing people together for a specific cause.
  • Finding the prime directive that works for you and your team.
  • And much more!


{{addCallout()}}

Transcript for Episode 231. Prime Directive

[INTRODUCTION]

[00:00:00] MN: Hello. Welcome to The Rabbit Hole: The Definitive Developers Podcast, living large in New York. I'm your host, Michael Nunez, our co-hosts today.

[00:00:08] DA: Dave Anderson.

[00:00:10] MN: Our co-co-host.

[00:00:11] SC: Sophie Creutz.

[00:00:13] MN: Today we'll be talking about the prime directive.

[00:00:18] DA: Oh my gosh. This is that one from that episode of Star Trek, where they take over an alien planet that doesn't have sufficient technology, right? Like it can't defend themselves.

[00:00:28] SC: It is, yeah. They come to that planet that is still stuck back in the Middle Ages and they introduce light speed and hilarity ensues.

[00:00:40] DA: Yes, it's a big surprise for people who are expecting a podcast about software development and agile and instead found Star Trek.

[00:00:47] MN: There you go, the classic, classic switcheroo, right under your ears, if you will.

[00:00:53] DA: Yeah, it’s a pivot, no, but the prime directive is important for software development as well.

[00:01:01] MN: We'll be talking about different types of prime directive as well. Something I learned as you were discovering content for this particular topic, but there's more than one prime directive that everyone will be familiar with and be more than happy to explore that. We're also going to take the prime directive that we know, and then we're going to break it down, phrase by phrase, and try to figure out what those things mean.

[00:01:27] SC: Yeah, yeah. Let's dig into that. Now that we've done our requisite nod to the Star Trek Prime Directive. You're welcome trekkies out there. The prime directive that you might be most familiar with is one that's used during a retrospective, right at the beginning of the retrospective, viewed as a way to think about how the team interacts during the retrospective and go ahead and read that.

[00:01:52] DA: Yeah. I think just abstractly too, it’s a uniting principle, a way to describe the values that you're bringing into a discussion. I think it's perfectly wordsmith.

[00:02:09] SC: Yeah, Norm Kerth did a good job of writing this. He says, “Regardless" –

[00:02:13] MN: He did the best – he had the prime directive in mind as he was doing this. Go ahead. Take it away, Sophie. 

[00:02:21] SC: “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

[00:02:37] DA: There's always a standing ovation after.

[00:02:40] MN: Someone does that, clearly. One take, amazing. [Inaudible 02:45]. Thank you.

[00:02:49] DA: Yeah. I love the phrasing of this so much. It's so dense. I know, it may actually be too long of a sentence, but I can't tell you if the grammar is good, but the intent is so solid. I love how it just kicks off right away. “Regardless of what we discover,” with an intent of curiosity. It's like, “Hey, we're here to dig in. We're here to dig deep and ask questions.” That’s a great framing for a retro. You want to be curious and open to discover new perspectives when you're doing a retrospective, when you're asking, “How can we improve? What went well? What went wrong?” You can ask those questions, first and foremost.

[00:03:32] SC: Yeah, definitely that mindset of curiosity is evoked by the “regardless of what we discover,” right? Indeed, it is about discovery. What can we discover together? Yeah, that's one part of it that's really well considered as it feels each part of this is.

[00:03:50] MN: Now, I'm interested to break down the entire sentence. We took, if we were programmers for a second, and we did a slice on the comma, there's that sentence –

[00:04:02] SC: The good old Oxford comma right there. It’s where the comma –

[00:04:05] MN: Exactly. So we spoke about the array zero is the “regardless of what we discover,” right? As mentioned, the mindset of curiosity. The next one would be “we understand and truly believe that everyone did the best job they could,” right? So let's say that, right? So –

[00:04:21] DA: I feel you go split that one again. Like the, the is – or “we understand and truly believe.” That's like affirmation, strong affirmation, but then everything after that is like, that's the belief that you got to carry forward. 

[00:04:37] MN: Interesting. 

[00:04:38] SC: That's a good point, Dave, because then it's like, can you understand something without truly believing it or vice versa?

 [00:04:46] DA: Surely, yeah. Sometimes we talk about the idea of consent or dissent in governing the organization and you can – you don't need to truly believe something in order to be like, “Yeah, it's fine.” You can understand it, but you don't have to truly believe it to be like, “Yeah, that's fine.” But like, you have to really sing it.

[00:05:12] SC: Right. But here it seems to be calling for strong affirmation. Not only do I understand, but I agree with it. I truly believe it.

[00:05:23] DA: Yeah, so what are what are we actually believing in this statement?

[00:05:27] SC: Yes, so that's the there's four things here, I think. The first thing is everyone did the best job they could. Do I understand that? Do I truly believe that?

[00:05:40] DA: I think, this is a tough one to like truly believe. Sometimes, we’ll be like, “This guy just busted production.” I mean, I have been in projects in college and in high school where I'm like, “Yeah, I know, Bobby didn’t do the best job they could. I just know it.” It's the same – I had the same thought. 

[00:06:00] MN: Oh, yeah. That's true, but I guess there are other qualifiers here. 

[00:06:07] SC: I wonder though, too, whether it's not so much that we need to know that that is absolutely true, at every time. But is it maybe just that we should operate on that assumption? Like that's the mentality with which we're going into this?

[00:06:25] DA: Oh, yeah. I’ll take that.

[00:06:27] MN: Yeah, no, and I think that's what it is too, because if I came into a retrospective, like waiting to call Bobby out, because he destroyed production for whatever reason. How psychologically safe does Bobby feel? Knowing that Bobby was the person brought down production, and other people are coming into this meeting, ready to point blame, because Bobby didn't do the best job they could, because if Bobby did, then production would it be down.

[00:06:58] DA: Yeah. I think also that goes against the curiosity aspect from the beginning too, where it's like, if you come in with your knife at your side, ready to just get them in the back, you're already fully committed to doing a murder on Bobby.

[00:07:15] MN: Don’t kill Bobby, people. Just don’t kill him.

[00:07:19] SC: Not that you shouldn't analyze the problem and what happens, but that if you're going into it with more of this mindset of it is not about figuring out who's at fault. It's just about figuring out what happens and what we can do next, that kind of thing.

[00:07:37] DA: Right. Yeah. I mean, that's the other frame of the retro, which is continuous improvement and incrementally getting better as a team. 

[00:07:47] SC: Yeah.

[00:07:48] DA: What are these qualifiers?

[00:07:51] SC: All right, yes. The first one is, given what they knew at the time. See, I just put that back in context: did the best they could. We understand and it truly believe. Given what they knew at the time.

[00:08:03] MN: Right. What's the phrase? Hindsight is 20/20, right? What you weren't doing – what you were doing at that time with the information you had may have led to a decision that could be ultimately different when you realize it later in time, right? But you didn't have that opportunity to do that in the first place.

[00:08:22] DA: Right.  Well, obviously there was potential for a null pointer over here, and yeah.

[00:08:33] SC: But even beyond that, right? Maybe someone didn't know that actually, the designs had changed, but that information had not been disseminated to the front end developers. That could be a “given what they knew at the time” that might have led to something that needs to be addressed in a retrospective.

[00:08:52] MN: Or a classic component was built again that already existed in the system over. Bobby could have saved time had he known at the time. 

[00:09:03] DA: That's true. The question you might be asking is why did this take so long? Not even that it blew up production or something tragic happened, but just like, “Hey, I thought we could have completed this a lot quicker.”

[00:09:17] MN: Yeah. Bobby know that a component existed that they could have used.

[00:09:23] SC: Why didn’t Bobby know? I'm not so sure it's so much about Bobby's knowledge, skills, or abilities as it maybe is more of a reason to examine how the knowledge is disseminated in general or maybe how the codebase is organized or maybe why you have a mono repo? I don't know.

[00:09:44] MN: Right. I think that when you come in with that curiosity, that's the question that you lead to, rather than, why didn't Bobby know this component exists? It's like, we failed Bobby by not telling them that this component exists and how do we fix that? I think that the later comments that we have in the prime directive will allude to that as well.

[00:10:05] DA: Yeah, maybe we could just take the rest of the chunk in a go. It's “given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."

[00:10:17] MN: There you go.

[00:10:18] SC: So many factors that Norm Kerth has tried to make sure he covers.

[00:10:23] MN: Again, I think with the rest of that sentence, Sophie like the question you mentioned. Why didn't Bobby know that this component existed? We flip the question as, how did we fail Bobby in not informing them that these components exist or this resource existed for them? Because Bobby knew that the component existed, that's a resource available that was available to them, and they could have –

[00:10:48] DA: Yeah, or maybe people were too busy. He's like, “Hey, what's up? What's up with this shared library. I would like to get more information.” Or maybe they don't have enough time to do the research. They just do – you just got to go and do what you got.

[00:11:05] SC: I wonder if this begs a larger question of analysis on each one of these areas, right? Because how can you determine, in a way that you can understand and truly believe it, what someone's skills and abilities are, what the resources available are, and what the situation at hand is? It seems to me, maybe you need a meeting just to determine, “Okay what was the situation at hand? Let’s set it out. Let's determine what it was.” Then what are the resources available? Let's make sure we know. Was that true for everyone on the team? Skills and abilities that one's a little bit more complex too.

[00:11:49] MN: I think it happens, like the more retros you have, the more of the people would be able to discuss the situation at hand and the resources available. That just happens over time because, when you – I'm going back to the Bobby components situation, but if Bobby didn't know that the component existed at the time, that meeting should discuss what resources were available, and why wasn't it informed and everyone aware, and then that may lead to an action out of being come up with a way to inform people of this resource that does exist.

[00:12:30] DA: Right. Yeah, it's like setting up a frame for like, “Okay we're going to ask the questions, and we're not going to throw people under the bus and these are the things that are constraints that we should consider on people.” Maybe that informs also the kinds of things that we might change coming out of it. How it – like you’re saying, given what they knew at the time, maybe we can educate people about components or different ways to handle outages or null pointers or whatever.

[00:13:04] SC: Right. Maybe there's a delta that comes out of discussing things with this as a frame of reference.

[00:13:10] DA: Yeah, or training people with skills and abilities or yeah, just getting a better understanding.

[00:13:19] SC: Yeah, for sure. Should we take a quick dip into some other prime directive texts that we discovered?

[00:13:28] MN: Yeah, I mean, the one that we were, as we were doing some research, we found some other prime directives, the first one being the Star Trek one. Just putting that out there, we’ll put that, and we spoke about the retrospective prime directive. The next one is team building. I think we found the link on funretrospectives.com. It's the team building prime directive. This is the first time that I actually read it. I wouldn't mind trying to read it to the audience right now, if y'all are okay with that. Here it goes. 

“Cooperation is the act of working with others and acting together to accomplish a job. Team is a partnership of unique people who bring out the very best in each other and who know that, even though they are wonderful as individuals, they are even better together. Coming together is a beginning. Keeping together is a progress. Working together is success.” That was so nice.

[00:14:30] SC: It's pretty inspiring. 

[00:14:32] MN: That is pretty cool. I guess. Yeah. I think that it's really cool to have that, because everyone knows or is familiar with the concepts of joining and storming and – forming, storming, I forgot the order –

[00:14:45] SC: Moving, forming, storming, and all those –

[00:14:49] MN:  This is like, I feel that would if I read that every morning in the team as we just started, I would find that we would be less stormy, if that helps. I don't know. I just, it is pretty colorful. I really like that prime directive.

[00:15:05] SC: Yeah, I think it's well written. I like this idea especially that forming, coming together, is beginning, but then that keeping together is progress, right? So that it is a constantly evolving way of, yeah, developing.

[00:15:22] DA: Right, the everyday act of delivering and then completing your goal, at the end there’s a success. 

[00:15:31] MN: Yeah, I mean, I think both of these prime directives are really well-worded frames, ways to focus on psychological safety and bringing people together for a specific cause.

[00:15:50] SC: Yeah, there's even another one, which we can mention briefly, which is the Futurospective Prime Directive. This one states, “Hope and confidence come from proper involvement and a willingness to predict the unpredictable. We will fully engage on this opportunity to unite around an inclusive vision and join hands and constructing a shared future.” 

You might say this is a little Kumbaya, but I think the intention is good. I think there's some good points in here. But beyond that, maybe it's an impetus for teams to consider finding which prime directive works for them, right? Do you want to incorporate some different guiding principles here? Perhaps you could even write your own.

[00:16:35] MN: Yeah, I think then important thing is to frame the activity that you're coming into, and finding the common purpose that unites you, removing the personal element, and focusing everyone as a team together.

[00:16:53] SC: Yeah, absolutely. Which I think is especially why it's suggested that, whatever prime directive you do choose, you have it in a place where it's visible while you're completing the activity so that it is an easy reference.

[00:17:07] MN: I mean, with these new pieces of prime directives. I'm looking forward to applying this to the workplace and everyday life. I love to hear the interesting and creative ways that other individuals will find when using these pieces of text in the prime directive or others. If you find other prime directives, I'd love to hear it. Feel free to hit us up. So, feel free to hit us up. 

[OUTRO]

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 you find their way into The Rabbit Hole. Never miss an episode. Subscribe now wherever 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:

Project Retrospectives

The Team Building Prime Directive

The Futurospective Prime Directive

The Rabbit Hole on Twitter

Stride

Michael Nunez on LinkedIn

Michael Nunez on Twitter

David Anderson on LinkedIn

David Anderson on Twitter

William Jeffries on LinkedIn

William Jeffries on Twitter