Should Managers Code?

  |  Compiler Team  
Sviluppo professionale

Compiler • • Should Managers Code? | Compiler

Should Managers Code? | Compiler

About the episode

Becoming a manager can be a triumphant milestone of working life. It’s often a recognition of leadership and, in the tech industry, technical skill. Many argue those skills necessarily become casualties to the management track. But it’s hard to let go of your creative side to make room for managing others. Can they do both? Should managers code? It’s an old question that never seems to receive a clear answer.

From the Red Hat offices to the moons of Jupiter, Compiler explores why it’s such a complex issue. We spoke with Red Hatters who are vocal about what role, if any, managers have in the code base—and why they fight to keep their hands on keys for as long as they can.

Compiler team Red Hat original show

Iscriviti

Subscribe here:

Listen on Apple Podcasts Listen on Spotify Subscribe via RSS Feed

Trascrizione

Alright, Johan, start us off. What do you have for us today? Well, I saw an email discussion the other day that centered around a simple question: Should managers code? And I was pretty surprised by the number and the depth of the responses. Yeah. Okay, so I actually saw this email discussion as well, and it was really interesting. Yeah, it really was. Yeah. But it had me wondering, since I'm not a manager, don't they code? What do they do all day? Manage? I'm a manager. Well, okay. Yeah, I get that, but don't they write code at all? And if not, why not? I had questions. Yeah. Well, I know one thing. That is a track that I'm going to avoid. I do not want to stop coding. Alright. Well, let's try and figure this out. 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. Today's question: Should managers code? Producer Johan Philippine is here to help us out. The whole idea for this episode started because I got this email. I'll give you... It's the actual imagery. I have an L-shaped desk, and on the short end of the L is my work computer with its multiple displays and all of that, and on the long end is my personal laptop. I'm going to introduce you to someone. My name is Chris Bredesen, and I'm a director of software engineering here at Red Hat. And I've been in tech for about 31 years. I generally will sit down in the morning and I'll look through some of my newsfeed and check my personal email if I'm not running late. I'll go through my feed reader, and I happened to notice this particular article, and I think the title of it was literally "Should Managers Code?" And so I literally emailed it to myself at Red Hat and then turned my chair 90 degrees to the left, waiting for that email to hit, and I think at that very second, I either forwarded it and stripped out the headers or just pasted it into that manager's list thread. So the subject of the email is "Should Managers Code?" and there's no introduction or anything. There's no like, "Hey, managers, check this out." He just puts the link right there at the top. Okay. And he's got this quote from the article, which says... "There's no consensus on the subject that I'm aware of. There are people that I deeply respect technically who really believe that coding is a lousy use of their time." And the article goes on to say, "But then anyone who's been in this biz for long has met Architecture Astronauts..." (and that's capitalized so you know it's an important and very well used term) "...Architecture Astronauts who could make a hell of a design chart in OmniGraffle, but are regularly really wrong on important subjects." And then Chris goes on to say, "I have had this conversation with people many times over the years. Worth reading, but in case you want a spoiler," and then there's another quote... "If you used to like to code but don't do it anymore, I suggest you see if you still do." What happened after he hit send? Well, pretty much exactly what he expected to happen. This is Red Hat, right? You're going to get conversation whether you want it or not. And sure enough, I think throughout that day there were lots of responses. I think it's very possible that once you get a few replies down the line, you've now lost the original article and now you're just discussing the last response, right? There's probably a law about social media there, right? You've clicked and you didn't read the article. But that's fine, right? It was all topical discussion among managers, and I think it was all really good. It blew up. It blew up. This thread got a lot of responses. Chris was... He said he got a pretty good kick out of watching the thread grow over the course of a couple of days. Why do you think there was such a big response? Did this hit a nerve? What was going on there? A lot of the managers at Red Hat come from a technical background, right? They love coding and it's hard for them to stop doing so. Mm-hmm (affirmative). Chris describes it as a kind of muscle memory. The muscle memory, as I said, of jumping in to fix the problem is very seductive and is something that I think is probably not a great behavior for leaders to do. So he was talking to his mentor about it and trying to figure out how much of his time he should be spending doing traditional managerial duties and how much he should be doing more of the technical things that brought him to Red Hat before he was a manager. We started talking about the balance between domain expertise and management expertise. So for a technologist, that might mean programming versus leadership. For someone in sales, that might be actual selling versus leadership of a team. So I asked her, "How much time do you spend actually managing a team, doing leadership, building leadership, and all of that stuff?" And he said he got some really good advice, so I went straight to the source of that one. My name is Laurie Krebs. I am currently the CFO of Red Hat. I think he asked me where I am in my career, what I see of me practicing my technical finance/tax expertise versus just leadership management, and I said, "Yeah, easily." It's less than 20%, so I said it's probably 20%. I still stay in that technical mindset, but it's 80% that I spend on the being a manager and leading the team. Really? Wait a minute. Wait a minute. So only 20% of her time is doing the stuff, and the rest is managing? How hard is it to manage? I don't know. Brent, tell me. Help me here. So I think it's pretty difficult. I think it may be more difficult than it can seem from the outside. But back to the question, 80% of the time spent managing, that sounds about right to me. I think that we should call this the Laurie Krebs ratio. Mm-hmm, mm-hmm (affirmative). Oh, I like that. I like that. I don't know if someone else has said this or if it came from an article or something, but to me, this is the Laurie Krebs ratio. And it's so christened, yep. The Laurie Krebs ratio. There it is. 80% managerial, 20% technical. Okay. Okay, so hold on. We know that some managers, they want to code. Why shouldn't they? Because there are some horror stories out there. I believe that. Yeah. We asked around for some examples of managers behaving badly, get some juicy gossip on tape, but people were, pretty understandably, reluctant to give many details that could trace back to any one particular person or situation. Yeah. I totally understand that. It is a big small industry, and circles are really, really small. You don't want to burn those bridges. You don't want to name names. Mm-hmm (affirmative). So while we don't have any stories to share today, trust me, there are some pretty awful stories out there of managers getting in the way of their teams or much worse. It's such a common problem that there's even a character in a book about DevOps processes who stands in as the archetype of, "Don't be that manager." What should a manager do to realistically keep to the Laurie Krebs ratio? It seems really hard, to me, to keep to that ratio. Yeah, that seems fairly common, but there are some solutions out there. I've got a few answers for you. The first comes from Mark Little. I'm Mark Little. He's a VP of engineering here at Red Hat, so obviously he's been on the management track for quite a while. And he's been a coder for even longer than that. I've been in the tech industry, depending on how you want to classify that, since 1988. And he never expected to be a manager, right? Just like you're feeling right now, Angela, he always told himself that he never wanted to move away from coding. I've been coding in one way or another since 1977. I love it. And I thought you could never do coding when you're a manager, so the further I get away from coding, the further I get away from what I love to do. And as he progressed in his career and eventually became a manager, he had that same kind of muscle memory problem like Chris described. I want to help get to the answer now, rather than in an hour or two hours. When Mark sees something that he wants to jump in on and help out, he gets a little devil on his shoulder, saying like... "Just go in there and tell them that this is wrong. They got to stop. They got to roll it all back." And then he's got the little angel on his shoulder that says, "Well..." "...You know what? This code is already in the product so we can't roll it back. We got to kind of roll it forward, and also you don't want to make people feel bad about that. They've done a great job. I can understand why they perhaps have gone down a road that I wouldn't have gone down if they'd know the internals perhaps as much as I do." So then you got to figure out how you can approach them in a way to help them understand that there are alternatives, and probably better alternatives, and then get them to change it and evolve it. So I've been in that situation a few times and so far, touch wood, we've come out the other side as a team together and it's been very positive. But Mark still likes to code, right? Does he still get to do that? He does. Mark has found a unique outlet for his creativity. Oh, I like that. Tell us more. I need to know what his outlet is. How do you reconcile this? So he sets himself some projects for his time off. When he's on holiday, he finds little tasks to do for himself. And right now he's doing what's called Advent of Code. Generally, the way it works is I think the first day of December, whoever's behind it, they release the first task for you to implement in any programming language, it doesn't have to be C++ or Java, and you have to try and accomplish something. And then once you do that, you can move to the second day. And the one he's currently working through right now is about getting Santa Claus, who's clearly some sort of alien, to Jupiter. And you've got to calculate the amount of fuel he needs to move his sleigh, and then you run into asteroid fields. You've got to plot the optimum paths through the asteroids, that sort of thing. Using programming to find these answers and solve these problems. He's found that to be a great little outlet for him to code. Why is Santa going to Jupiter? Because there are children on Jupiter. There are... I don't know. I don't know either. But I guess that's the point. It doesn't matter. The whole point of it, right, is that Mark is solving a problem through code. Mm-hmm (affirmative). Exactly. The problem itself doesn't matter. Right. Instead of getting in the way of his team, he's solving a problem for Santa Claus. Okay, so we've been talking about managers who subscribe to the Laurie Krebs ratio, and now I'm wondering, have you run into anyone who doesn't follow that rule? Maybe someone who is like 20/80 instead of 80/20? I did, actually. I spoke with Bob McWhirter. All right, so I'm Bob McWhirter. I'm a senior distinguished engineer here at Red Hat. I have been in tech probably since '97 or so. He told me that he had tried managing twice now. The first time, he did it for about a year and a half and it was a traditional managerial position, and it just didn't work out for him. The first time was when I first joined Red Hat at the beginning of my career, I guess about 13, 14 years ago here with Red Hat. I had been an engineer, but had decided that I had more to offer than just my knowledge of Java syntax and that I could come in and help manage something. So I joined Red Hat, and I was running the JBoss.org community side of things. I probably did that for about 18 months. It was not very successful because I realized that I really liked engineering. As a manager in that particular role, all I was doing was managing other engineers, and quite frankly, I was envious of the engineers getting to engineer while I did not. Instead, I got to play with spreadsheets and have meetings and a lot of email and that kind of thing. So he left and he came back to work on an experimental team. And he was a one-person team at this point, kind of looking far in advance, three- to five-year timeline. What kind of technologies, building on what we know today, would be interesting to have in that timeline? So at that point I had 100% coding because there was no one to manage, but then as we grew the team, I still managed to keep relatively high levels of coding for a very small amount of managing. How much time does he actually spend coding? How much are his fingers on the keyboard? So in the email thread he said most of his time, so I assumed it would be about 50/50. When I talked to him, he said... I probably code 90% of the time. Wow. Right, so he didn't just flip that Laurie Krebs ratio. He flipped it and reduced it even more. That doesn't make sense to me. I don't understand how he's able to do that. Well, he can do it because he's kept his team structure fairly horizontal, right? It's a pretty flat team. And that's only possible because of the kind of team he's leading. He's really an engineer/manager, where he handles some of the managerial duties that he needs to without actually having to integrate with the rest of the company, without having to put in deadlines, without having to enforce a lot of things that typical managers would. It sounds like this is a really special case. I'm curious what Bob would even say about this or what you would say, Johan, that other managers probably couldn't do this, and maybe even shouldn't do this. Yeah. When I asked him about that, saying "Well, you've clearly found something that works for you. Would this be something that other managers could implement for their own teams?" he told me straight up that, no... I've got six senior engineers, and so that's a much different scenario than if you got 35, ranging the gamut from associate engineers to seniors. It's a unique situation where as soon as you add a deadline or as soon as other parts of the company start relying on your work, those managerial duties become that much more important. So we're talking about whether or not managers should code, and Bob presents a pretty unique answer. For him and his team, it seems pretty essential that he does code. He told me that they even tried at some point to hire a non-coding manager for his team to handle the administrative stuff. Oh. Okay, that's really interesting. How did that turn out for them? Not so great, apparently. Yeah. The manager apparently didn't have all that much to do, and the team wasn't really meshing well and working with a manager. Did they have to go back to the way things were? Did they try to work it out? What happened there? Essentially, they went back to this kind of flat structure with Bob in charge. Angela, is this the type of manager that you would like to be? If there were ever a manager position that allowed me to do 90% of what I'd like to do and 10% of actual managing work, that would be the managing position for me, so this might be it. So I don't want to give up putting my hands on the keyboard. I don't want to give up doing the technical things, because that's what I love. If 80/20 rule is what's ruling the industry, why would any technical person want to give it all up and become a manager? Well, there's a bit of a trade-off to that too, right? They gain something from becoming a manager. I spoke with Shoshana Collins. All right. My name is Shoshana Collins, and I've been working in the field of analytics for about eight years. She's a manager here at Red Hat, and she told me how that transition can be more extreme than expected. Well, I think there's a sense of self that is invested and a self-image as a builder, as someone who creates, and it's hard to let go of that and close the door on it completely. I think I'm not ready to close that door. And I asked her how much time she actually spends on coding and on technical tasks. Do you think she's closer to Laurie Krebs or Bob McWhirter? She strikes me as more of maybe a 50/50 or a 60/40. Okay, so I think she is 80/20. Really? I think she uses the Laurie Krebs ratio. That's exactly right. In terms of actual hands on keys, I spend about 20% of my time now actually using the skills that brought me to Red Hat. How do you keep your skills sharp if you're only giving up 20% of your time doing the hands-on thing? Technology changes pretty quickly, so how do you keep your skills sharp when you do that? Well, what Shoshana does is she arranges her time in a way where she can take some small projects every week. And those are very simple. They're just SQL queries, little data pulls, little mini models or analyses that I can do that won't block my team. I'm not on the critical path of development for a major model or deliverable. They're small projects that she can do that won't block her team. But she also talked about it in a way that really struck me, which is that these little problems are more just to get a little bit of daily practice. And that's just because I think it's hard if you take a break for days or weeks. You have that cold start problem where it's hard to context switch and get back in. And she likened it to playing scales on the piano. It's keeping your fingers nimble, but it's not making your soul sing. Okay, so I'm going to return us back to our original question: Should managers code? What do you think, Angela? After listening to Johan's stories, you do see that there's a downside to it. But looking at Shoshana, if it's something that you really want to do and you're good at it and you want to stay good at it, why can't you have those opportunities to stay active and to stay involved? This is still a hard question, if managers should really be coding or not. Yeah, and I think sometimes we think of moving from an individual contributor to a manager as being really linear. I'm starting to wonder if maybe we should think of it as something else. Once you're a manager, that doesn't mean you have to stay as a manager for the rest of your life. What if you wanted to go back to being an individual contributor? I don't think that that's a failure, especially listening to everyone talk about their love of what they got into this profession to do. I don't think that's a failure. I don't think it's a failure either. I think it's a boon, actually, because if you go out and come back, you bring back all of the growth that you've attained with you. So you're super-powered because you've gone out and you've seen and you've done different things, and you bring that back with you. And it's funny that you should mention it that way because I spoke to Shoshana about this very idea, about what kind of pulls her back to wanting to be an individual contributor again. I really want to get better. I want to get better. I still do love it. There's so much to learn. It's changing all the time. Even with all her years of experience and the practice that she's put in, she wants to keep learning, and that's not easy. You can't do it in a cursory, light read in an evening or on a weekend. You have to practice it. You have to be working with it. What do you think it is that keeps her as a manager right now? This is something that I asked all of the managers that I spoke with, and they all talked about what they gain from being a manager, right. They have to give up quite a lot of doing what they love, which is coding or the technical projects, but they also gained the ability to influence, to help others, and to really have a larger effect on the direction of the company and they're able to accomplish a lot more by being managers. The way that Shoshana described it, actually, she pulled up this quote from Antoine de Saint-Exupéry. Let me see if I can quickly pull up... "If you want to build a ship, don't drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea." I want to be that. I don't know if I am that, right, but in my role as a manager, I'd like to be teaching people to yearn for the vast and endless sea. Compiler is made by Red Hatters like me. Today's show was produced by Johan Philippine and myself. Victoria Lawton is the wind beneath our wings. She keeps us all on the air. Our audio engineer is Kristie Chan. A special thanks to Shawn Cole. Our theme song was composed by Mary Ancheta. Big, big thanks to our guests: Shoshana Collins, Chris Bredesen, Mark Little, Bob McWhirter, and Laurie Krebs. Don't forget the Laurie Krebs ratio. 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. If you like this show, please subscribe for future episodes. We would love to see you again. Love, love, love. Take care, everybody. 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.

Articolo del blog

Confidential containers on Microsoft Azure with Red Hat OpenShift Sandboxed Containers 1.10 and Red Hat Build of Trustee

30 luglio 2025  |  Marcos Entenza

...

Containers

Articolo del blog

Software-definiert zum modernen Fertigungsbetrieb

30 luglio 2025  |  Stefan Bergstein

...

Artificial intelligence

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.