Mailbag: Managers, Technical Debt

  |  Compiler Team  
Weiterbildung

Compiler • • Mailbag: Managers, Technical Debt | Compiler

Mailbag: Managers, Technical Debt | Compiler

About the episode

Since the debut of Compiler, our team has posed a few interesting questions, and the answers have gotten people talking. Do the words ‘manager’ and ‘leader’ mean the same thing? How can technical debt become more complex, outside of team areas of responsibility?

We revisit some of our past topics on the show and let others weigh in on what they liked, what they didn’t like, and what we may have missed on the first pass.

Compiler team Red Hat original show

Abonnieren

Subscribe here:

Listen on Apple Podcasts Listen on Spotify Subscribe via RSS Feed

Transkript

All right. Angela, It's the beginning of the year. And I'm curious, how do you celebrate the new year? Oh, wow. So, I like to celebrate my birthday. That's one thing. But it's also a time to look forward on the year to come, but also look back on the previous year. Yeah. That is one of my favorite things to do in the new year, too. And I thought that today we could actually look back at some of our early episodes from last year. Oh, I would love that. Yeah. What episodes do you have in mind? I thought maybe we could revisit two episodes that we got quite a bit of feedback on. Okay. And what were those? So, it was our very first episode. You remember that one? Oh, do I. Yes, I loved it. Should Managers Code? That was a great one. Yep, Should Managers Code? And then we're going to revisit visit our episode on technical debt. Oh, I like that. Let's revisit. Just get in the mail bag and see what's in there. Oh, I've got some... we got some mail, Angela. All right. Let's do this. This is Compiler, an original podcast from Red Hat. We're your hosts. I'm Brent Simoneaux. And I'm Angela Andrews. We're here to break down questions from the tech industry, big, small, and sometimes strange. Each episode, we go out in search of answers from Red Hatters and people they're connected to. Today's episode: mail bag. We're going to hear from you. All right. Let's start with Should Managers Code? Angela, do you want to jog our memory? This episode started from an email that went through a mailing list, and that's how the conversation started. There was so much response from internal Red Hat folks about should managers code? And there were opinions on either side of the aisle, and it was a really lively discussion. We decided to bring it to a podcast episode. And this is where the Laurie Krebs ratio came from. Remind us about that one. If you're a manager, 80% of your time is spent doing the managerial things. You're managing your resources, your people, handling all of the managing business. And 20% of your time is spent doing other things, maybe staying involved with tech projects or learning new things, staying in your craft. So, that's the balance that some folks are taking with managers doing the thing and managers managing. So, shortly after that episode aired, I got an email from someone. I didn't really know them, but they basically said, "Hey, I listened to this episode. It was good, but I was puzzled by a couple of things." Okay. So, I replied back to him. And then we decided, well, let's just talk on Twitter. So, that's what we did. And we talked there for a little bit. And then I thought, well, let's just talk on the phone. So, that's what I did. I called him up. Hello. Heiko. How are you? Good. How are you? Great. I'm in the office for the second time since the pandemic started. I'm in the office, too. So, there was a lot of small talk, but pretty quickly we got around to talking about the episode. And he described this experience of listening to it. And he told me that he was really agreeing with everything that we were saying up until up about the end of the episode. And it was the point where we were talking about the impact that people managers can have on the organization. Where I started to disagree was on two things. One, is this saying a manager or people manager is a leader? Because I don't think this is necessarily true. There are some people managers that are leaders, but others aren't. They are really just "managers" between quotes, filling Excel sheets, and that's it. So, he's saying that “manager” doesn't equal role necessarily “leader,” and “leader” doesn't necessarily equal “manager.” There are what he would call “technical leaders” that aren't managers, but nevertheless have a lot of influence within the organization and within their teams. They're usually more senior technical people who have been around for a while. They usually have, for example, the title of Distinguished Engineer or Principal Engineer. Right? Or Domain Architect or Chief Architect. Yes. Yep. Exactly. Angela, I'm wondering in the original episode, you were like, "I don't want to be a manager. I don't want to give up the work." And I'm curious what you think when I bring up this term technical leader. I mean, we have some in my immediate team, and these people are solid. They've been here. You go to them. They're helpful. They know the things. They push projects forward. They're doing it from a place of seniority, from a place of understanding, from a place of mentorship. They're doing it from just... it seems like just from a different place. So, Heiko and I, we talked about this for a while, and eventually we said our goodbyes. All right. Okay. Thanks, Heiko. Thank you. Bye. All right. Bye. After this, I got really curious about this concept of technical leadership. And I went down this rabbit hole, and I started talking to anyone who would talk to me about this. And eventually I ended up talking to someone who is a technical leader. My name is Rachel Sibley. I work at Red Hat. I am the QE technical lead for the automotive program. Their task is to take Red Hat Enterprise Linux and shrink it down to fit inside of a vehicle. They're going to take it. They're going to put it in a car. That sounds fantastic. It doesn't sound very easy, but... No. I'm sure the path that she's taken has prepared her very well for this role that she's stepping into. Yeah. So, her path, that is actually one of the interesting things that she told me about. I feel like originally I never really thought of myself as a leader, but after about five years of working as a contributor, I was promoted to a senior role. And at that time, I was already leading different initiatives, small test areas related to the work I was doing. It was a lot of fun, actually. Before we had software fault injection, I was using freeze spray and blow dryers to heat or cool the sensors. So, I just needed to make sure I didn't get too close to the boards or bad things could happen. She struck me as someone who's really scrappy. And it wasn't by aiming to be a leader that she became a technical leader. It was really just by following her passion for what she was working on that led her into that role. Yes, exactly. You really have to have that time under your belt and really understand the work. So, let's talk about the big project that she's working on now. Making an operating system smaller is quite difficult. And Rachel is starting this team, this QE team, from the ground up as their technical lead. And she starts this team from scratch, and she does a bunch of hiring. And eventually a people manager comes on board to share the load with her. One of the first things that I asked her was about the differences between a people manager and a technical leader. Here's what she said. It's definitely a fine line, if there is one, between people management and technical leadership. I think in both cases, we're leading people with mentoring. I think in many cases, a technical leader is responsible for leading or presenting on technical topics where the manager might be more involved with the organizational aspect where they're tasked with driving change at an organizational level. So, this is interesting. So, this is putting a much finer point on what a manager does. The people manager manages the people resources, the people aspect when she's talking about development and promotion and things like that. And she's leading the much more technical bent, where the team is going, their technical vision. I like that really fine definition of what these two folks are doing and how they're working together for the good of the team. Yeah. Remember the Laurie Krebs ratio? 80/20? Rachel has her own ratio. I try to do 50/50, but I don't always follow that. But I think that's my general rule. So, she spends about 50% of her time hands on keyboards doing work, and then the other 50% of her time leading. And we'll get to this in a second, but she talked about exactly what that entails. I wanted to get Rachel's take on what Heiko was telling me. So, I explained what Heiko told me when we talked on the phone, and she agreed. Yeah, I would definitely agree with that statement, not just people managers have the largest impact. That's not true. We have distinguished engineers or people working in a specific level that don't want to be a people manager, but they have just as much of an impact, maybe even a bigger impact, than a people manager could have depending on where they take it. So, let's talk about technical leadership itself. One of the things that Rachel said is really important to her in her job, and one of the things that she loves most about her job is helping other people get unstuck. All of us get stuck at some point multiple times in a month or in our career. It depends. Especially depending on the type of team you work on. If you're working on a team where there's a lot of iteration and there's a lot of changes and there's a lot of innovation happening, that's constant change. And of course, feeling stuck is something that I'm sure everyone on a team at some point is going to feel. It's hard for me to think of other options sometimes. And it's really good to have someone from the outside come in and say, "Well, why don't you try this instead?" Right? Right. And then the heavens just open up and you hear the angels sing. It's like, oh my God. Why didn't I think of that? That happened to me last night. Yes. Yes. Someone helped me get unstuck. It just so happens to be my people manager that did it. Yeah. Yeah, yeah, yeah. Yeah. He really helped me get unstuck yesterday, so I get it. Yeah. So, Rachel has some advice for people who want to be a technical leader in the future. Try to push yourself outside your comfort zone. Take on new opportunities even if you're scared to do it or lack the confidence. Overcome imposter syndrome. Know that you're valuable and everyone has to start from somewhere. If we don't push ourselves from time to time, we're going to lose out on some amazing opportunities. Preach. Is she talking to me? Yeah. Wow. Yeah, that one hit me too. Angela. That one hit me too. I think back to what Rachel was describing to me as her early career when she was an intern or in her entry level positions where she'd be in a meeting and someone would call on her, and she would immediately get embarrassed. I have been there. I've absolutely been there. She slowly over time pushed herself out there to take on more responsibilities and do more things. And in her own words, she just naturally started falling into this role as a technical leader. She did what she said. She came outside of her comfort zone. That's literally where the growth happens. Yeah. And just as a final thought on this, I do want to say that all of this looks different from team to team and even from organization to organization. There's really no one way to think about the differences between technical leadership and people management. All right. Up next, I want to revisit our episode about technical debt. Okay. Remember the question was, “Do we want a world without technical debt?” And I heard a lot of feedback. It really resonated with a lot of people. Indeed. I got a lot of feedback on Twitter about this episode as well, so I think this is something that we need to revisit. In that episode we talked. And this is on purpose. Right? We talked pretty abstractly about technical debt. Yeah. If you remember, we introduced this idea that technical debt is neither good nor bad. Yes. It just is. And we also talked about this fundamental tension between technical debt and innovation. And a lot of people were curious to know more about how people really experience technical debt. I also wanted to know about how people were managing it. I wanted some advice, really. So, I did what I do. Yes. What'd you find out? I started asking around and... There's a theme here. Right? This is what I do. And eventually I ended up talking to someone at NASA. Get out. Yeah. Like “we landed people on the moon” NASA. Oh, that NASA. Okay. Not to be confused. It turns out they have technical debt, too. My name is Jeff Walter. I'm the deputy manager and the system architecture and engineering lead at the Atmospheric Science Data Center at NASA Langley Research Center in Hampton, Virginia. Jeff, I'm just going to say it, has a really cool job. His team is responsible for archiving, distributing, and in some cases, as I understand it, producing earth science from remote sensing data products and airborne sources. That's a mouthful. Okay. That is a mouthful. What I take this to mean is that there are satellites, for example, and they're just collecting a lot of data about the earth. Right? So, this is everything from measuring ice to looking at cloud patterns to looking at how dust travels around the world. And so, all these satellites and all these airborne devices, they're collecting all of this data. And a lot of what Jeff's team is doing is they're taking that data and they are making it available to other scientists at NASA, but then they're also making it publicly available to scientists and really anyone around the world to use in their own experiments or to use in their own projects. Oh, that sounds fascinating. Okay. Right? And if you think about it, I mean, this is a lot of data. On your laptop computer nowadays, you might have one terabyte of storage space that you could hold all of your stuff, all your videos, all your pictures, everything like that. A petabyte is a thousand terabytes. So, if you think we have six petabytes, you can imagine 6,000 laptops stacked end to end, all the data they could hold. That would be how much data we have inside of our datacenter. Working with all this data and the support that his team gives to different research projects, it's led to their fair share of technical debt as they've grown over the years. On my mind lately, and for the last several years, is with our physical infrastructure, actually at the datacenter. This data center's been around for, gosh, probably almost 25 years now. So, we service a number of different projects and missions. So, in addition to our role as the DAAC where we archive and put data out to the public, in our computer center, we host the computing infrastructure that supports scientific research and development for a lot of the Langley earth science projects internally. So, for many of those things, some project or mission would come to us and they would have money and they'd say, "Okay, build this thing for me and support it." So, we got caught in the trap of saying, "Okay, the science guys want this, and they want it this way." So, I think by the nature of what they are doing, things have gotten really complicated. Because everyone seems to want something different. I can believe that. Depending on what your needs and what your priorities are, how you get there could very well differ from another team or another agency. Yeah. That's a lot of snowflakes. And that leads to some problems. Right? I mean, it's not sustainable, for one. Managing multiple disparate systems is overwhelming. And if there's no standards, it's very hard to control and keep track of and manage and maintain. So, I don't envy Jeff. Yeah. I'm curious. You are a Solutions Architect. And I think you had some experience, if I remember correctly, at a university that was pretty similar to this. I did work in higher education. I was a Systems Administrator. So, I understand what that means when a professor has a grant, and they have money to spend, and they want you to build something for them. It may not necessarily be in line with what the current infrastructure is, but they want what they want. Now, you as the engineer, you're stuck managing these multiple stacks. Everyone is doing something different. And I can see where this story is heading because I've been there. So, NASA's having the same problems that regular people have? I'm intrigued. I am so intrigued by this story. Absolutely. One thing that Jeff told me was that he knows that he might not see all the technical debt. He knows that other people who are often closer, like his developers, his engineers, they're going to know better than he does sometimes, most of the time maybe, what the technical debt looks like. And they've got to feel comfortable talking about that. It sounds like a culture thing. As long as the culture supports that type of thing and everyone's on board with that, I think that is a great idea. You can't not talk about it. I mean, I know we want to innovate and move faster, but we have to make time out of our schedules to address it at some point. All right. Let's get to some advice. I think the main thing I would say is be intentional about it. Don't ignore it. Or if you come across something or you have to do something that incurs technical debt, be sure you track it in a place that your team can see and in a form that you can come back to. And then revisit it. You have to be disciplined then about revisiting it. What do you think about that advice, Angela? His advice is spot on. You really do have to keep technical debt in the forefront. It needs to be brought up early and often because it's not glamorous. It's not one of those things that... It's not the latest and greatest feature. It's something that really has to be addressed. And if I'm being honest with you, it's really not the thing that people who are in the business of innovating really want to hear about. Yeah. But we need those folks that are mindful of this, who are keeping us honest, who are keeping it in the front of our minds. You have to remind folks and you have to give them the bandwidth in order to address it. So it's okay if you keep telling people that it's there. But if you don't give them bandwidth to address it, it'll never go away. It'll never reduce. Keeping it a priority is really key. This is why Jeff is suggesting that we keep it in our backlogs, label it technical debt. Yeah. And then keep it as an open conversation with your team. You just have to have the attitude and the assurance that it's safe for them to come to you with the truth. Because I tell my staff, it's like, "Look, I want you guys to come to me with problems. I want you to give me your unvarnished opinion of this." The other thing, too, is I think also to understand and to communicate that technical debt exists at all levels. You can have it at the function or method level where the way you coded something might not be ideal or you hard coded something in there that you need to go back and take out, some of that kind of stuff. But it can go all it can bubble all the way up. I think that really gets to technical debt is really interconnected, right, because the systems and the teams that we work with are interconnected as well. And so, I think what he's saying here is that we have to get really good at both knowing where technical debt shows up, and that's at all different levels. Agreed. And then also working together. Right? He says this is a shared burden. And making sure that you're all working together to understand it and address it. I'm reminded of what we talked about in the original episode, that technical debt is neither good nor bad. It just is. And I think that that can sound a little depressing if you say it that way. But I think talking to Jeff, I realized that his team has this really healthy attitude towards debt and this really healthy way of working with it. And I think ultimately that's what's most important. That was pretty dope. Those were two really, really good follow ups to those episodes. Yeah, and this is one of the things I love about this show, Angela, is that we actually hear from people. Isn't that awesome that people feel comfortable? After listening, they feel comfortable enough to reach out and tell us what they felt about that episode. And it opens up a little part of their world to the rest of listeners as well. I love that. I love that so much. Me too. So listeners, if you want to reach out to us, tell us what you think, tell us what's on your mind, you can send us an email. Our address is [email protected]. That's [email protected]. And we would absolutely love to hear from you. And that does it for this episode of Compiler. Today's episode was produced by Brent Simoneaux and Caroline Creaghead. Victoria Lawton is our Reba the Mail Lady. Our audio engineer is Elizabeth Hart. Special thanks to Shawn Cole. Our theme song was composed by Mary Ancheta. Thank you, thank you, thank you to our guests, Heiko Rupp, Rachel Sibley, and Jeff Walter. Our audio team includes Leigh Day, Laura Barnes, Claire Allison, Nick burns, Aaron Williamson, Karen King, Boo Boo Howse, Rachel Ertel, Mike Compton, Ocean Matthews, and Laura Walters. So, if you like today's episode, please follow us. Rate the show and leave us a review. Share it with someone you know. It would really help us out. All right. We'll see you next time. Take care. Bye-bye.

More about professional development

Keeping up with changes in technology requires training and and engagement with learning opportunities—either in a traditional setting, or individually.

Blog

Friday Five — August 15, 2025 | Red Hat

15. August 2025  |  Red Hat Corporate Communications

...

Blog

Developing a standard AI OS: Unlocking production-grade AI at enterprise scale

14. August 2025  |  Brian Stevens

...

AI inference

About the show

Compiler

Do you want to stay on top of tech, but find you’re short on time? Compiler presents perspectives, topics, and insights from the industry—free from jargon and judgment. We want to discover where technology is headed beyond the headlines, and create a place for new IT professionals to learn, grow, and thrive. If you are enjoying the show, let us know, and use #CompilerPodcast to share our episodes.