Have you ever experienced a post-project meeting that seemed more like a game of point-the-finger and less about lessons learned? We have! That’s why we brought Russ Thomas on the show for Episode 61, “The Debrief”. Russ gives the who, what, where, why, and how of a good debrief. He also shares his first experience with the debrief as a deputy sheriff, as well as how a debrief could be implemented in a corporate setting.
Episode 61 Quote
“It’s really good if you already have a culture that is good at getting together and celebrating your wins, because hopefully you can kind of meter those back and forth and hopefully you have more of the good ones than the bad ones. But in either case, if they only ever get together to talk about what went wrong or whose fault it was then yeah, those kind of get togethers really have a bad connotation.” – Russ Thomas
Listen to Learn…
- The origin of the debrief and why it’s so important
- The difference between a good debrief and a bad one
- Why finger pointing is the last thing you want in a debrief
- Recommended scripts that effectively end the “blame game”
- How to make debrief attendees feel at ease
- The only two questions you ask in a debriefing session
About Russ Thomas
Russ is a SQL Server DBA, blogger, speaker, and trainer in Denver, Colorado area. He’s was formally a Sheriff’s Deputy in Washington State, which is how he learned about the Debrief. Follow him on his blog or on Twitter @SQLJudo.
Russ Thomas on LinkedIn
Practical SQL Server In-Memory OLTP Tables and Objects
Practical SQL Server High Availability and Disaster Recovery
Entity Framework Database Performance Anti-patterns
SQL Judo’s Monthly DBA Challenge
Debrief, It’s Important (Part One)
Debrief, It’s Important (Part Two)
Transcription: The Debrief
*Untranscribed introductory portion*
Steve: I’d like to welcome Russ Thomas on the show today. Russ and I go back, oh, quite a ways through various SQL PASS events. And I know I’ve heard him present on a couple topics and one of the topics is “The Debrief”. Which is something I original heard him talk about at I think SQL Saturday Portland a few years ago. I’d like to say welcome, Russ.
Russ: Thanks guys!
Carlos: Yeah, thanks for being on the show today.
Steve: So, with the topic being The Debrief, can you tell us a little bit about really what it is and why you’re so passionate about talking about it?
Russ: Uh yeah. So, as Steve said, one of the ways we both know each other is we are both from the Pacific Northwest, at least recently. And met a couple of time and hung out at SQL Saturday in Portland. And my very first SQL Saturday ever was on “The Debrief” and where that came from is, um, before I returned to the private sector I worked actually for the Clark County Sheriff Office. Clark County is right there in the metro area and I know Steve is an EMT, a volunteer EMT as well, and so we’ve kind of started talking about that. And in that environment a debrief or sometimes as they call it, “after action reports” is pretty common. I can only imagine that it’s also very common in the military. I know it’s common in hospitals. And anytime you have, you know, kind of high liability incidents that involve humans, you’re going to have things where it’s really healthy to go back and look at what you did, look at decisions that were made, and really kind of try and learn how can we do this better. And I transitioned back to the private sector, it kind of surprised me how often there’d be big money-losing events, maybe sometimes hundreds of thousands of dollars, maybe even more where you know, you’d pick up the pieces and maybe servers would get put back together. Possibly there was an email that went out about hey, someone needs to fill out a root cause analysis so that we can report up to the chain what happened. But there was never any sort of, kind of, organized debrief where the people who were involved can kind of wrap their heads around what happened and learn from each other. And just work better as a team. Specifically, for me as a database administrator in an operations environment, I kind of saw this lacking. Or when it was done, I think it slipped into one of the main reasons people fear a debrief. It kind of turns into a, “Hey, let’s find out whose fault it was” session as opposed to a, “Let’s find out what we can learn and how we can improve as an organization”.
Steve: And you know, I’ve seen it go that was so many times in the past where it really just turns into a witch hunt to figure out who can we blame for the problem? And that leads to no one even wanting to be part of it.
Carlos: And that was my experience, actually, when Steve and I talked about the idea of the debrief. One of my experiences and the best example was a big project, right, and millions of dollars. Now it was actually, it ended up successful. So the idea was, “let’s get back together and kumbaya, let’s review what happened.” And there was this one, it was all about configuring the servers. We were getting delayed in this one little section and the knives then came out. I was like, “Well, I could have done better in this situation.” Well the knives came out and afterwards, my manager wasn’t in the meeting, he came up to me afterwards and was like, “don’t you ever try to fall on the sword again!” And I thought, “Oh, well, why did we have that meeting again?”
Russ: [laughs] Right.
Carlos: And so I guess it would be interesting to kind of see your parallel. Maybe the current state of things with how things could be and how we could make that, those environments, better.
Russ: Yeah. And it’s interesting that you bring up, “Hey let’s bring everyone together to talk about how awesome we were with this successful project.” To me, that’s really important if you’re going to have the occasional debrief to decide why everything went to heck. It’s really good if you already have a culture that is good at getting together and celebrating your wins, because hopefully you can kind of meter those back and forth and hopefully you have more of the good ones than the bad ones. But in either case, if they only ever get together to talk about what went wrong or whose fault it was then yeah, those kind of get togethers really have a bad connotation.
Steve: And I think that’s one of things that in agile methodologies they refer to it as “the retrospective”. Where they do it after every cycle. They do the equivalent of a debrief and you get to a point where you can celebrate the wins as well as deal with the losses.
Russ: Yeah, I have only recently become familiar with you know, agile and scrum and some of those methodologies. As I have seen those take place, I think that’s one area that maybe development or at least devops with scaled agile kind of has a foot up on your typical operations environment. And let’s face it, we’re all in IT where we’re not necessarily blessed with an abundance of people with great personal skills anyway. And I say that completely looking in the mirror as well. Sometimes I want to sit in my cube and be left alone and play with my toys.
Steve: So given all that then, why is the debrief so important in the operations or IT environment?
Russ: So, what, going back to my history where I learned the value of it. I’ll tell you a quick cop story. And if you go out on my blog at sqljudo.com, this was my very first blog post. So this and SQL Saturday is where I got my start in getting more involved in the community of our awesome SQL Family.
Carlos: And we’ll have them in the show notes, Russ. SQLDAtaPartners.com/debrief. And we’ll have the links up there for people to get at.
Russ: Nice! Cool. So we’d gotten called out to do a search warrant. We had to go out and arrest the guy for the DTF, because they wanted to arrest him. They said that they didn’t have anyone to do it. So we got the search warrant details, no big deal. Um, we get on scene and dispatch tells us, “hey, it’s very likely that they only speak Spanish in the house.” So I was brand new rooking on the team very green, but the only Spanish speaker that could be found. So I was given the job of Mr. Microphone, which is the guy that issues the commands, directs people what to do, brings people out of the house and tells them… and this is kind of a critical job because if you’re giving them poor instructions and they end up doing something not to the liking of maybe the handcuff team or the guys who are all spun up and not sure if they’re going to resist arrest or run or whatever, especially because I’m speaking in Spanish so they don’t know what I’m telling him.
Russ: So I’m trying to communicate with the Sergeant on what I’m saying, then say it, then issue what they want me to say back and forth. Well all that went off great. Um, but afterwards once we’d gotten the guy out of the house and gotten him secured, my job was then to transition into a kidn of a support role and kind of be the guy who has, you always have options for escalating force, so my job was going to be the less lethal guy in case it really went bad. But because it was a high risk warrant there were people with guns drawn, after it was done I ran over to my spot on the less lethal situation and walked right in front of all these guys with guns drawn right in front of the suspect and took my position. Um, we got the guy arrested, everything was safe. He was actually a very n ice guy, was very cooperative. So the sergeant says, “Alright! Let’s go in front of this tree.” And right away they were like, “Russ, you could have gotten someone killed including yourself.” And I was like, I thought I was the only one who spoke Spanish? What did I say? And they were like, no, afterwards you walked right in front of all your fellow officers with guns drawn, and they said that if it were to have gone bad, you would have caused them to hesitate because you’re now in a dangerous situation. You know, so I’m feeling two inches tall as a brand new deputy, and I want to earn the respect of the guys I’m working with. But, within just a few minutes after getting reamed they’re calling out what a great job I’d done with the commands, how smooth everything else went, and a couple of guys pulled me off to the side and were like, you know this isn’t going to be the last time you get yelled at. That’s what these things are for, but we’ve all been there no big deal you’ll learn and next time you’ll know. And to me, it almost made me feel part of the club after the whole team made it obvious that this was very common, this was something that they did, and everyone would get the turn to be the guy that got used as an example as to how we could do things better. Um, so for me it was almost kind of an endearing memory.
Carlos: Interesting. And I think to just apply this to the DBA space if you will. We’ve all done something kind of boneheaded. For example, I’ll never forget the first time I left a transaction open.
Carlos: And all of a sudden the database everyone’s like, “Hey we can’t get into the application. Who’s this ID?” And I’m like, that’s my ID. And they’re like what’s going on? And they’re like, oh, you left the transaction open. You gotta finish that. And then oh okay, now I get it, ha ha. And you all move on. And it kind of almost seem like the critical component of the debrief is being able to assess, this is an area we can improve in and this is an area we did well. How do you kind of build up that culture so that you can kind of get that feedback, and give it as well since there’s almost a skill there as well, to make it beneficial for everybody?
Russ: Yeah, I totally agree. And I bet me, you, and Steve we could waste probably three hours on boneheaded moves we’ve done. How many times have you had that stomach drop going, “Holy crap, am I connected to production?!”
Carlos: Or, there’s no WHERE clause?
Russ: [laughs] Right! So to me, when the debrief is done if you are a person who has skin in the game, if you have someone putting pressure on you or you feel like there is someone who’s looking to cast blame and make sure they remove themselves, somehow you’ve got to go either high enough up the chain or maybe sideways. Find someone who can kind of mediate those first few, who just absolutely has no skin in the game. They just don’t care if there was someone at fault or if there was, why. And it has to be someone with the interpersonal skills that is really kind of good at, interesting one of the reasons my blog is called SQLJudo is that one of the skills they teach in law enforcement is the skill called verbal judo. And the 2hole concept being is how do you use your words to accomplish productive and positive results? And interesting thing about judo is, how do we achieve a good outcome for everyone involved with the least damage as possible? So verbal judo is kind of the same way. I’ll give you an example that happened to us the other night. We lost our really critical availability group because as part of some initiatives some firewall ports were closed. And these firewall ports were closed weeks ago. But you don’t know that you need some firewall ports until you’re trying to do a failover.
Steve: Oh boy.
Russ: Once you enter that zone, there’s no guarantee that you’re going to be able to fail back. What happened is that we lost the whole cluster and the whole AG everything just collapsed. And it took 12 hours or so to figure out what the heck happened, and we grabbed a couple of people and got everyone in a room and we said, let’s go back as far back as we need to figure out what happened. And I was really, really pleased with the guy who was running the debrief. Because he was very sterile about it. And he was like, “and then on this date firewall port whatever-whatever-whatever is closed. And at no point were any of the actions ever tied to a person. UNLESS there was only person in the room who knew the reasons or the justifications, but even then it was kind of, it was very clinically removed from the human who did it versus the reasons behind it versus the order in which it happened.
Carlos: Sure. Even something like that, right, they close the firewall because they got a ticket to do it. It wasn’t like they were like, “Hey, let’s see how many firewall ports I can close before somebody complains.”
Russ: Yeah absolutely. And I’ll be honest, I myself went into the meeting a little bit looking for blood, because I lost a weekend I had planned to do something else with. I had business and everyone else up my chain and all over this environment went down. And you know, I’m like, “Hey, this ain’t my fault.” So I ended up having to kind of rein myself in a little bit. But it was good to have a mediator.
Steve: So let’s say that we’re at the point where we’re buying off on the idea of the debriefing and something happens. An event is just completed that caused us to want to have a debrief. What are the elements that would cause us to want to have that debriefing meeting?
Russ: Yeah, um, so first and foremost I think the two big questions, and one of my favorite questions that I have learned as a manager is, “What would perfection look like?” Establish right away what is, what was the objective with the actions being taken, the outcome that was desired, and right away you establish intentions were good. And that immediately kind of puts people at ease. You say right away, “Intentions were good. We wanted to accomplish something positive.” And then you can kind of start deconstructing what kept us from achieving the desired outcome? Um, so the two big questions are, “What was the objective – what would perfection have looked like?” And “What kept it from being perfect?” And then as you deconstruct those things, you may have some, what was timing? And break down those items individually, again as, “So, firewall port was closed on this date as per this request. Knowing now what it caused downstream, the big thing is that we don’t wreak our AG cluster, that’s the big objective. With that in mind, what could we have done way back then?” And establish right away that obviously there are too many moving parts here. You wouldn’t necessarily know that it was going to happen. How could we have known, right? And to me, once you establish what the objective is, establish that everyone’s intentions were good. From there, really deconstructing how you could have gotten to a perfect outcome. It kind of just guides itself at that point. You have to have someone in the room who’s willing to know the balance when people, sometimes people need to vent. But when that venting becomes less than constructive to the objective. You say, “you know what? I will follow up with you later and give you all the opportunity to vent. Right now, let’s focus on why didn’t we achieve this perfect objective?”
Steve: So is that the role of the moderator to be jumping in and doing it at that point? Or is that just other people in the team who are going to say, “I’ll follow up with you on that later?”
Russ: I think it works best when people in the room are involved enough in the situation in order to self-moderate, I think that’s best. You have to have a highly functional team for that to work. EVentaully, every conversation is going to devolve to the point of being unproductive and people’s feelings are going to get hurt or, you know, other unproductive results so, ultimately someone in the room is going to have to take responsibility for the debrief and recognize, “Okay, I need to step in here.”
Russ: It would be fantastic if that was never needed, but yeah, at some point whoever is calling the debrief, there needs to be someone who their objective is a good healthy debrief.
Steve: Okay. So I guess the next question is, for that debrief to be successful, what are the things that you really need to focus on there?
Russ: Yeah, um, the items that you have identified that went wrong, right? You do have to dig in and establish what went wrong and why it went wrong. There’s going to be a human element where people make mistakes and people made mistakes. It might even be serious mistakes, right? Unfortunately, that’s part of establishing why the ideal objective wasn’t met. If you as a moderator recognize that it’s something that can’t be done in a group setting, then it might be better to meet with people individually. There again, that’s where it’s really important that the person who is establishing that debrief doesn’t necessarily have any skin in the game other than the debrief itself. Or has the trust of all the members in the team that they, the objective is to learn and grow as a team. But ultimately, you’ve got to be able to dig out those true o=honest assessments of actions taken and what the objective was and why it went wrong. Even if it is a little bit painful.
Carlos: Russ, one of the thoughts I had was I that reasons like root cause where, like, “Hey this is what went wrong” and people not owning up to it is because in the end, they’re going to get there’s going to be additional processes that come in place as a result. So let’s take for example the simple transaction, keeping the transaction open which was the example I used earlier. What happens when someone then dictates, “Oh now we have to ensure that there is a commit at the end of every script that gets run”. And you’re like oh my gosh, really? I feel like there’s now more work when I know what I did wrong and I can take steps to prevent that. I learned from it. But I don’t necessarily want to end up with this big process now as a result. Does that maeks sense?
Russ: Yeah, absolutely. Because it’s interesting, that’s not where I thought you were going. Yeah definitely, there is definitely a fear of additional policy, additional red tape, additional procedures. You know because, any of us who have worked in any sort of production environment know, cowboy is always faster.
Carlos: [laughs]Steve: Oh yeah.
Russ: It’s just that occasionally it goes wrong.
Carlos: Occasionally the horse bucks, you know?
Russ: Yeah. So yeah absolutely. Um, you know and how do you get around that? That is an interesting problem. I think there needs to be ultimately running the debrief it would be ideal if you could separate that from policy decisions. You know, there has to be trust…
Carlos: That’s an interesting concept. The goal of the debrief is not to come out with a, “here’s how to prevent this from ever happening again”?
Russ: Or at least, not to come up with preventing this from happening again via edict or policy. How do we prevent this from happening again via just learning from our mistakes or identifying if our existing policies caused it themselves? But oh it’s difficult, yeah. There are three major management styles and one of them is definitely, “well if I make an edict then it will be so.”
Russ: Yeah, reality just doesn’t work that way, right?
Steve: Right. So one of the things that in big crises that I’ve had to deal with throughout my career often times they lead into the wee hours of the morning or even further beyond that and you’re dealing with an outage and you’re dealing with an outage and at the end of it you get things working eventually. Sometimes it’s your fault and sometimes it’s cleaning up from someone else’s problem, but you get to the end of that and there’s sort of like this state of uncertainty. Like, “Oh my gosh, we could have lost that part of the business if this hadn’t been fixed.” Or whatever it was at that point in time. And that uncertainty can lead to a lot of stress for people who work in the IT environment. And it’s stress that probably doesn’t need to be there for long-term. But kind of leaves people hanging and wondering, “Am I in trouble for this? Am I the hero for this? Did I screw something up? Or did I save the day?” I think that having that debrief really helps bring closure for those types of events so that you can the move on to the rest of your work or the rest of your life, whatever it may be, and not stress over it anymore. Have you seen that similar type behavior there?
Russ: I have, I have absolutely. Because I have seen entire departments who really distrust each other. I hate to keep picking on security, but the security, oh boy what a tough situation those guys are in. Where no one knows if they’re doing their job, right? We don’t know if we’ve blocked a good hack attack or if we’ve blocked a business-ending virus or some sort of encryption for a ransom scheme. No one knows if those guys protected us from that. But boy, we sure know when we can’t talk to a production server because of a firewall or we can’t use an application that we know would save us hours and hours and hours because we know it hasn’t been approved through the proper vendor list or what-have you. So it’s very easy for departments like sys admins and DBAs to not get along, or DBAs and the security teams not getting along. I have personally seen these debriefs actually bring these teams together because you realize how hard each other’s job is. And when you ask, “What would perfection have looked like?” sometimes it is healthy to really recognize that hey, the reason I got this done was because I have three levels of management breathing down our back that we have to comply with this edict from an outside auditor or something. And you know what I mean? And to kind of put yourself fin their shoes. I’m going back to something you said, working on an issue throughout the night where you’re completely frazzled and you’re completely stressed out about it anyway. I think that’s another huge art to a debrief, because when do you call it to be recent enough within close proximity to the event that people remember what happened? But you kind of have to do it when the feelings aren’t really raw or really down on sleep. Boy, there again that’s another big balancing act.
Steve: So you wouldn’t want to necessarily do it after 18 hours of battling some database issue and everyone needs to sleep. But you might want to do it the next day when everyone’s rested and in the office.
Russ: Right, exactly. It never hurts to have a decent lunch catered and say, “Hey, we don’t want to interrupt your day, but we’re going to have nice little lunch catered. Come on in, get some food, and let’s figure out what happened and what went wrong.”
Steve: Yep, okay. I know one thing I’ve used in the past is referring people to your blog post in the past. Just saying, “Read this over and let’s talk about let’s talk about doing the debrief after you read what Russ has posted there.” And I know that’s been incredibly valuable for me for a couple of people I’ve talked with. So thanks, I do appreciate that. I guess before we move on to the SQL Family wrap-up end of it, is there anything else you want to follow up with on the debrief?
Russ: Uh, no, just the realization that in the real world, they’re hard. Even me when I’m a fan of them, when it comes time to call one it’s like, “Oh man my goodness. I’ve got fifty things on my plate. My coworker’s got fifty things on their plate. We talked about it in email, isn’t that enough?” And you know, frankly you can overdo it, right? You can micro-analyze everything where people are afraid to move, but it is important and if nothing else, just for establishing that people are human and hat you’re allowed to make mistakes even if for nothing else, that. I think that’s super valuable. But at the same time, right, sometimes you do identify that maybe you have a team member that really isn’t a great fit for their job, or they don’t have the competency or don’t have the integrity, unfortunately I’ve seen that as well. You have someone who just can’t be honest about their own skillset and way they do things. They’re going to find a reason to make it someone else’s fault even though everyone else in the room knows that isn’t the case. That usually leads to a different conversation that doesn’t have anything to do with the debrief, at least directly.
Steve: Yep. It’s sad when integrity is a bigger issue than the competency. But it happens.
Russ: Right, or integrity becomes the bigger issue than even the event that brought it out. You’re going to lie about submitting a ticket or a change over a stupid two-row update statement? Come on now.
Steve: That comes back to what you said in the very beginning about having trust in the entire team. If you don’t have that, it doesn’t really work very well.
Russ: Yeah. It is definitely a balancing act.
Steve: Okay, so we generally have the SQL Family at the end here and let’s just jump into that, with the first item being technology changing so quickly. What kind of things do you do to keep up with the changes?
Russ: Um, well, I’m one of those lucky people who does something I really like for a living. So me, I kind of just nerd out on watching either Pluralsight videos on technology videos I’m in. You see me at SQL Saturdays.
Steve: Oh yeah.
Russ: Typically at least one session I go to will be something I’ve never heard of, because anytime I see something I haven’t heard of, in the back of my mind I go, “What if my job requires that?” Natural curiosity doesn’t hurt. But just getting out there and uh, as selfish as it sounds, one of the reasons I like getting involved with teaching at SQL Saturdays is because trying to get in front of people and act like you are any kind of intelligent about a topic is a really good motivator for getting intelligent about a topic.
Steve: Oh yeah, that is so true.
Russ: I sheepishly admit that I’ve submitted sessions I know nothing about in order to motivate me to really learn a lot about it.
Steve: Yeah, that’s a really good way to learn. I know I’ve done the same thing.
Very good. Russ, if you could change on thing about SQL Server, what would it be?
Russ: Uh, more Pokémon.
Carlos: [laughs]Russ: Um, so that is a super interesting question. Um, I see where our industry is going as a whole, right? And the people that have the complaints about SQL server being old school. You know, relational, there’s still a reason that people want data integrity relational sets. I was a big fan when JSON came out, so if there was one thing I’d change bout SQL server, so if there was one thing I’d change about SQL Server and I realize that this is nigh impossible, like backwards compatibility and all those other things, but I never would have gone down the XML route with SQL Server with extended events or any of the metadata. I would have gone JSON from the very beginning and I’m glad to see it kind of catching up now. I would love people, I know there are a lot of people out there that cringe at the thought of a full JSON parser shoved into the SQL engine, but…
Carlos: Me being one.
Russ: I mean instead of all the XML parsing and all that stuff. It’s too bad that those worlds didn’t come together sooner where Microsoft could have jumped on that bandwagon because I do like the simplicity of the JSON approach.
Steve: Yep. Well you know it’s interesting because it took so long to get the full XML support in there to begin with. The full XML functionality wasn’t there until SQL Server 2000, and it wasn’t an actual native data type until I think 2005. So now JSON is just coming out at this point. I think it’s got a bit of catching up to do there. I’m excited to see where it goes.
Russ: Yeah, and I know that’s a sensitive topic for a lot of people but there are a lot of developers who would rather package their small datasets into a JSON object and store it that way. A lot of the times I’m of the mindset where if you can’t beat ‘em, join ‘em. And if you only have a small handful of items, whatever, put it in a document. I think that’s one area where postgres really gains a lot of fans is that it’s a little more mature in some of that area. Though it’s completely less mature in almost every other area, let’s make that clear. I’m still a Microsoft Database Stack guy.
Steve: Yep. Alright so what is the best piece of career advise you’ve received?
Russ: Um, this one took me a long time and when I finally got over it, it really helped my career. And I will tell this to anyone who works for me: your company views you as a resource. That sounds kind of harsh, but I’m talking about the sterile, nebulous, soul-less organization of your company. Your boss is a human being and might be friends with you. But the organization itself just sees you as a resource. And it’s not just going to hand you more than it can in any given moment, right? Think of it like a process. The computer isn’t going to just hand you more CPU and more desk space unless you ask for it and the best career advice I ever got was be honest about your own value and be honest about your boss about it. I’m not saying go in and say, “Hey, boss, this is what I’m worth. I demand a raise.” But at the same time when you are out looking for a career and you’re going through the interview process, no one is surprised when you say, “Hey, this is what I think I’m worth.” Um, you know and for people who like me, it was almost a taboo subject to say, I was like oh you know, pay me whatever you think I’m worth. It’s going to be like ten dollars. And so there again, it is kind of a sensitive subject but I’ve found in negotiations with things that I Need, negotiations with my career goals, negotiations with training, I’ve never once had a boss offended that I asked for money to go to PASS or asked for money to go to SQL Saturday in a city other than my own. Or because I asked for a subscription to plural sight. And that’s really where I’m going with all this. Now they don’t always say yes, and that’s okay, but I’ve never had a boss say, “How dare you ask that?” So for all these people wishing that these things were true in their place of employment I would say, have you asked? And have you put in enough effort where you could like make a case for it, right? This is how it would benefit the company and this is how it would benefit me. Once I started asking for things, I was surprised absolutely floored, at the number of times the answer was yes.
Steve: Wow. That’s a great, great piece of advice.
Carlos: Russ, our last question for you today. If you could have one superhero, what would it b and why would you want it?
Russ: So, I’m going to reveal way more nerd side than the Pokémon comment from earlier. I have kids, so I have a built-in excuse. Me and my kids, the original avatar not he planet with the blue people, the avatar with the last air-bender. ME and my kid watched that show religiously when it came out. We knew Nickelodeon Tuesday nights at 4. When it came out in the boxed set and dvd, we bought the entire boxed set. I know those shows inside and out, my kids know that show inside and out. I still think it was one of the best things ever put on TV. I would be Air bender. I would have air bending powers. I would sky surf and I would do all kinds of stuff.
Carlos: Very cool.
Steve: Nice, I like that.
Russ: And all my kids would tell you, at the drop of the hat, what they would be. I’ve got a daughter who would definitely be a water bender. My son would be a water bender. Yeah. We all know.
Carlos: Sure, sure. Now why would you want to be an air bender?
Russ: Just the ability to fly and just, yeah.
Carlos: To move around.
Russ: Yeah, just the ability to – the freedom. I love watching American Ninja Warrior, and I wish I were 80 pounds less and was 20 years younger because I would totally be in American Ninja Warrior.
Carlos: There you go. Well Russ, thanks for being here with us tonight.
Russ: yeah, thanks guys.
Steve: I think that wraps it up. Thanks so much.