IT Team Mentorship: How to Mentor IT Teams and Troubleshoot Like a 50-Year Database Veteran

Jay Bradford: What is going on? This is Jay and Michael on the IT Directors podcast. And we have a fan favorite back on the show — the legend himself, the myth, the legend: Rick Goudeau, employee number two at Clear Winds.

Michael Thomas: We found out you can find him on a Civil War battlefield reenactment, or who knows where. This man is a man of many talents.

Jay Bradford: Rick, thanks so much for joining us again today, man.

Rick Goudeau: Yeah, y’all had said we really didn’t get into some of the skills and behaviors and things that worked well for me in my career. You asked me for a title, and I thought “Tales From the Old Timer” sounded better than my original idea, which was “Tales From the Curmudgeon” — because I didn’t think I was irascible. Some people may disagree with me. But I have been around for a while, and I am certainly elderly.

Michael Thomas: Well, for those who didn’t catch the first episode we had with you, can you share a short version of your story up to this point in your professional journey?

Rick Goudeau: Last time, I focused on my experiences as a DBA and a systems person — the history of it, how I got into IT. This time is more my personal history: the skills and talents I picked up over the years, and the people who helped me and the people I’ve helped. We thought this would make a good conversation for another episode.

Jay Bradford: Over 40 years of experience in technology.

Rick Goudeau: Fifty. Over 50. I started in the ’70s.

Jay Bradford: Man gained a decade of knowledge quickly — I stand corrected. Over 50 years.

Rick Goudeau: Don’t cheat me out of a decade.

Jay Bradford: It’s because you look so good, Rick, I didn’t know! But over 50 years in the technology ecosystem — database specialist, self-proclaimed, by the way. Rick, you’ve done everything. We talked about database administration and the different database models in the last episode. But today we wanted to give our listeners and viewers something a little more personal — what led you down this journey, and some of the skills you’ve talked about.

Rick Goudeau: I was kind of outlining what behaviors you need to embody to be successful in computers, to be a good mentor and a good team player. I put a few categories together, and of course I have a story or two for each one.

One of the first things is: as a developer, as a systems engineer, you’ve got to be a diagnostician. For me, that goes back to one of my favorite fictional characters — I loved Sherlock Holmes growing up. He had that quote: “Once you’ve eliminated the impossible, whatever remains, however improbable, must be the truth.” One of my favorite stories was “Silver Blaze,” where the key piece of evidence he observed — because he was highly observant — was that the dog didn’t bark. That broke the case for him.

I always look at troubleshooting the same way. You get a whole range of error codes and messages and people saying, “Oh, this isn’t working.” Okay — well, what’s not working, in the not-working? You have to draw that out and observe repeatedly, looking for patterns, inconsistencies, almost anything, looking at the whole picture to understand the problem.

That was fictional, but in real life, I’m currently working a problem with a client — this is happening today — where they’re implementing new organizational units. As they set up new org units, a certain process breaks: first for one unit, then two, then three. It shouldn’t be happening that way. Eliminate the impossible — I’m convinced there’s a problem in how they’re doing the setups.

Which leads to my second topic: be methodical. Methodical doesn’t mean slow — it means being consistent, systematic, having a process. Before I do anything, I sit down and write out what I’m going to try to accomplish and the steps I need to take. That’s what I told this client to do: document every piece of what the setups are, then test the environment, test the process that breaks, and find exactly where it’s breaking, because that’s about the only thing I have left.

The reason I do that is Oracle E-Business Suite, which I support, has upgrade processes that can run two to three hundred steps. You have to note down every one of those steps, because they have to occur, and occur in order. I take the Oracle documentation and build my own copy of everything, with the exact commands I need to issue, and go through the whole process. That way, once I get through it on test, I have to do it again on user acceptance, and again in production — and by the time I get to production, I’ve got a process I don’t have to rethink from scratch. It goes quicker. And as a side benefit, I have documentation at the end, so if I have to do it again years later, I can.

Michael Thomas: I remember you sharing a bit about how documenting all your steps has served you well — you’ve encountered the same type of thing 10, 20 years later. Do you have a standard approach, like “here’s how I’m going to approach this project”?

Rick Goudeau: Usually, when it’s a vendor system, my standard approach is to consult the vendor documentation and then tailor it to your environment, because vendor documentation is usually generalized. I want to tailor it so I know that to do this step, I have to execute these three specific commands. That’s always my process: start with what the vendor says and work out from there, or start with what I think is the most likely problem and work from there, and figure out what tests I want to try.

Jay Bradford: You mentioned the dog not barking, from Sherlock Holmes — now y’all have got me interested. I might have to go watch that episode. Don’t spoil it for me.

Michael Thomas: It’s a great book — I loved it as a kid. But you don’t even know to watch or listen for the dog not barking without life experience.

Jay Bradford: Part of it is observing everything. One thing I picked up from Don Good is: when something doesn’t make sense, go back and read the whole email chain. All of a sudden, it’s like, “Oh, that’s what they’re talking about.” That’s being observant and detailed through the process. When someone sends me a long email chain, I’ll go back and at least browse it so I can see what was going on. That’s when I realize, “Oh, they’re implementing something new” — or, “It was working here, but it stopped working here.”

Rick Goudeau: Those are the little evidence facts you have to build. There’s my inner Sherlock Holmes coming out. When you’re brought onto a new project, are you looking at the shiny, beeping, obvious problems, or diagnosing further?

Michael Thomas: What do your steps actually look like? You don’t just accept the shiny, beeping problem — you have to go look at how it got there. Almost always, you get told a problem, but the real issue is in how they got to the problem.

Jay Bradford: So you have to work your way back from the problem. When someone calls and says, “My database doesn’t work” or “The software doesn’t work” — that doesn’t actually describe the problem to you?

Rick Goudeau: Of course it doesn’t. How many times over 50 years have I gotten that call? “Rick, the software doesn’t work.” That’s a description, not the problem. Or, “This system is down.” Well — what part of the system is down? A lot of these systems have a dozen or more components, and component 15 is down while the other 14 are working fine. They don’t tell you that until you go and ask. That goes back to being detailed and observing. I’ll file a lot of things away while I’m working a problem — “that’s interesting, let me keep that in mind” — and set it aside while I keep working. Eventually a pattern starts to emerge.

Jay Bradford: Something I thought about while you were talking, Rick — how much of the human element, being observant and detailed, has helped you over your career in database administration, design, and implementation? There’s a lot of human involvement in gathering this information.

Rick Goudeau: I’d say 60/40, maybe 70/30, human — because a lot of our issues aren’t technical issues, they’re understanding issues. There are implementation issues too. It’s not often the technology itself — occasionally it is, don’t get me wrong, but that’s rare.

Another thing I love is that I’m always a curious person. Here’s a story: I worked with one of our Clear Winds guys — I can name him, James Hammock, our director of development, AKA Hammering Hank. He and I were working a thorny problem — I like that technical term, “thorny” — with WordPress. The admin panel for one of our sites just wasn’t coming up. Something online said, “Set this parameter in the WordPress config.” James looked at it and said, “Yep, setting that config works — that’s how it’s working. But why didn’t it work before? I’ve got to figure this out.” And I thought, yes! That’s what I want to hear. He sat there, we dug through the code together, and he explained a lot to me — I learned a lot about how WordPress works from him.

Michael Thomas: I love that, because a lot of people — whether they’re in production or some other part of the business — just need something to work because it’s serving other people or their other responsibilities. If you just fix it and move on, it’ll happen again. Having that next level of “how did we get here, and how do we set ourselves up for success” is what matters.

Jay Bradford: That’s interesting you bring that up — I was on a call with Hammering Hank on the way to record this episode. I asked him why a tool I built with some AI coding — we’ve got a whole application around it for quoting — now takes four or five times longer than it used to. I did some research, and it came down to the model — the underlying AI model — having changed. The model I originally built the code on is now outdated, within just the last six months or so. It’s still accurate, still great, but a little slower, because it doesn’t understand the logic in the application the way the original model did.

Rick Goudeau: That’s the real fear I have with AI — not the technology itself, but that people take the results of AI without looking into what it means, what model it’s using, what’s going on under the covers. I always view AI as a starting point, not an ending point. As long as we keep that mindset, AI will be a tremendous tool. But the moment we start assuming “AI says it’s right, so it must be right” — that’s a problem.

Jay Bradford: And when something breaks, how do you fix it? That’s where the life skills of a guy like Rick — or Hammering Hank — come into play. That’s why I called him: “Something’s wrong here, let’s walk through this.” I had enough of a skill set to know something was off, but we peeled it back together and figured it out.

Rick Goudeau: That’s problem solving. Curiosity — I’ll bring it back to how I grew up. My parents were both librarians. I’m sure it was a thrill a minute in the Goudeau household. But one of the lessons I learned early was never say “I’m bored,” because the moment I did, my dad would grab me, drag me into a room, point to two walls of books floor to ceiling, and say, “Pick one — you’re not bored.” I’d read something, find a reference, get curious, go look up that reference, find a word I didn’t know, and go figure out what it meant. I could spend hours on it — history, art, science, geography, all sorts of things.

Jay Bradford: You learned to be a critical thinker, because you studied and researched things for yourself.

Rick Goudeau: You learn how to do research, how to ask questions, and how to take one thing and follow it to the next. That’s a huge thing my parents taught me — maybe by accident, but honestly, I think it was deliberate. He knew exactly what he was doing.

Jay Bradford: Where did you grow up, by the way?

Rick Goudeau: New Orleans.

Jay Bradford: I thought so — you can tell by the way you say it. It’s “New Orleans,” not “N’awlins.”

Rick Goudeau: Right, it’s New Orleans. Great eating, great town. Most of my family still lives there, and one of the things we always do when we’re back is find good food.

Michael Thomas: What’s your favorite place?

Rick Goudeau: For something fancy, it’s Ralph’s on the Park — part of the Brennan’s family, right by City Park. The chefs are very aggressive about trying different things, and I’ve never had a bad meal there.

Jay Bradford: Have you ever been to the World War II Museum in New Orleans? I went back when it was still just the D-Day Museum, and again later when they added the Pacific wing — that section was incredibly well done because they’d gathered so many more artifacts by then. I thought it was interesting that it was in New Orleans of all places.

Rick Goudeau: There are two reasons. One: Stephen Ambrose, who wrote “Band of Brothers,” was a professor at UNO. Two: the Higgins boat — the landing craft used in the war — was actually a flat-bottomed swamp boat built in Louisiana by a man named Higgins, and adapted into a landing craft. That’s great history right there. I just can’t let things sit — I have to go re-investigate.

Jay Bradford: I took my whole family — my two sons, my mom, my stepdad, my wife. It was great. The whole time I was thinking, “Why is this in New Orleans and not Washington, D.C., or Boston, or Chicago?” Now I know — the Higgins boat connection. That’s great.

Michael Thomas: Rick, you mentioned a minute ago — don’t let us forget about your mug.

Rick Goudeau: Right, that ties into mentoring. You saw that I was just mentored by James — Hammering Hank — because I learned a lot about how WordPress works. It’s a two-way street with mentoring. If you help people, it should be organic — just part of your nature.

Here’s a story: one of my favorite ones. A young woman accidentally deleted the production database at her company and was pretty distraught. My first response was, “Let me tell you about the time I had to restore a disaster database back to production.” Here’s what we did: we found the backups, found the archive logs, found the current redo logs. We went through all the pieces we could find, and we were able to recover the database back to the exact moment it had been overwritten. Those things happen. She thought she was going to get fired. I told her, “No, we’ll fix it. We’ll get going from here.”

Jay Bradford: Rick, I could’ve used you about 15, maybe 20 years ago. We had an Oracle database — I won’t name the system or the employer — our whole student information system ran on Oracle. A young man did that very same thing, and we could not restore it. It would’ve been nice to know you and Doug back then. But go ahead, Rick.

Rick Goudeau: That’s part of mentoring — I hope she learned a couple of things from it. It was a learning experience for both of us.

Jay Bradford: You learn when you fail, not when you succeed.

Rick Goudeau: Exactly. Another time, I had someone shadowing me. We were finishing up late in the afternoon, and I said, “We need to reboot the system to make sure Oracle comes back up cleanly.” We rebooted — it didn’t come up. I was desperately calling around to find a systems engineer still at the office, and caught a guy right before he left. We talked it through, and he said, “Sounds like it didn’t get to the pipe run safe — this is a Unix system, just type in an init six and see if that brings it up.” We did, and everything came up. I said, “We’re backing out my changes, and we’ll talk to the client on Monday.”

Monday, we go back and talk to the client, tell him what happened, and he says, “Oh yeah, I have a scheduled reboot every weekend — every morning I have to come in and type in init.” We found that out the hard way.

Jay Bradford: I had systems like that back in the day too — you just adapt, and document. Do you ever think, “No one else would’ve been able to get this back up if I hadn’t known that”?

Rick Goudeau: Fortunately, I found someone who did know. The real point is, the woman shadowing me said, “I was sweating bullets, but I didn’t see Rick break a sweat. He said, ‘I’ve seen this before — we’ll fix it, we’ll keep going.'” That calmness is a vantage point — it’s an attitude.

That reminds me of the mug I brought as a prop today. There was a college intern I worked with — I taught her database scripting, basic backup checking, and scripts for upgrades. She picked it all up and did great work. When she was graduating, I was really proud of her, and I went to everyone I knew in the company and said, “You need to hire this person, she’ll be an asset.” She did get hired, and somehow found out I’d done that — I never told her. So she gave me this cup. Whenever I’m mentoring somebody, I think of it. I’m still using it — forty years later.

Jay Bradford: That’s awesome. Mentoring, developing, and pouring into the next generation is so key, Rick, and I know you’ve done that — I’ve seen it in our office. I’m in that phase of my career now too.

Rick Goudeau: You can do it at any stage — that was only about my sixth or seventh year in my career when it happened.

Jay Bradford: It’s always about picking someone up. No one knows everything.

Rick Goudeau: No one does. What did I even outline today? Hammering Hank had stuff going on that I didn’t know how he did.

Michael Thomas: There are always people who know things you don’t. I think the lives you can impact matter — it’s one thing to do your role well, but when you bring others along and pour into them, you help them grow and you can change their trajectory. James doesn’t have 50 years like Rick, but I think it goes both ways — he pours into people too, and I’m sure Rick does the same for him.

Jay Bradford: A hundred percent. I’ve always wanted to pull people up — help them, develop them. You don’t know what you don’t know, so it’s always good to guide people and give them positive reinforcement.

Rick Goudeau: There’s a term I use a lot with people: I’ll give them a lot of information and say, “Look, I’m not expecting you to remember all of this — I just want you to know it exists, so later on you can look it up and go, ‘Oh, I remember that, something’s like that.'” That comes back to making mentoring organic — just part of your nature, not something forced because you’re a director or manager. You have to do it yourself, and your whole organization will follow if you lead that way.

Jay Bradford: I’ve learned that too — Michael and I talk about this a lot — just living intentionally, in every aspect of your life, and then it happens organically. If you’re intentional about helping — “I want to help our marketing team,” or engineering, or sales — great things get accomplished, and you can lift other people up. I want people to be better than me.

Michael Thomas: I think that’s the key — not being intimidated by that. I want to see people develop, even pass me. If I have to step away, I want my team to be able to take something and run with it. That’s the key thing: empowering people.

Jay Bradford: And Rick has over 50 years of experience doing exactly that, which is incredible. The first episode we did with you was fantastic, and this one has been great too — I’ve learned things just talking through this again. Rick, what’s next for you — what are you going to do post-technical?

Rick Goudeau: I don’t know. Some people say you probably never retire, and that’s probably right — I enjoy what I do. As long as I’m working with people and watching them grow, I enjoy it. That’s probably my father the professor and my grandmother the schoolteacher coming out in me.

Jay Bradford: Rick, thank you so much for taking the time today. You’re such a joy to be around, personally and professionally, and I know this is going to be a great episode for our listeners and viewers.

This is Jay, Michael, and Rick, signing off from the IT Directors Podcast. Go follow us on all the social platforms, check out all our episodes, and follow Rick — he’s got a wealth of knowledge. Thank you so much.