Becoming An Engineering Manager Without A Technical Background

I think you can have standards for what it means to stay technical in your organization, but I don't think forcing managers to code is necessarily a good thing.

Welcome to the Ladybug Podcast. I'm Kelly.

And I'm Emma.

And we're debugging the tech industry.

AI is evolving at an incredible pace, but knowing how to apply it effectively is the real challenge. How do you design agentic systems that actually deliver at nodes? 2025 pioneers in AI engineering and machine learning will show you how they're using graph technology to give AI the context it needs. Powering agentic workflows, improving retrieval and enhancing knowledge. Graphs at scale this free online conference on November 6 features over 140 technical talks from developers to data scientists and engineers solving real world problems with graph powered AI. See the full agenda and [email protected] nodes.

Hi Emma. Hey, how's it going?

We're not good at intros or conclusions, are we?

No, we're not. I'm actually really great at conclusions, thank you very much.

Now that makes one of us.

No, it's. We were just chatting before we started recording and so it's always funny to like stop chatting and be like, hi, good to see you.

At least there were no like dead squirrels in your car this time.

No dead rats, no dead squirrels, no dead mice, nothing. No, no, I. Yeah, that's. It's.

Your things are smooth now, are they?

I'm dead vermin free. Yes. Off to a better start.

And what are we talking about today? Today we're talking about how to become an engineering manager without a technical background.

And do you have a technical background?

I do. I went to disappointed.

I do. Well, I feel like it would be.

Almost more interesting if I did. But you don't have a quote unquote traditionally, like you didn't go to computer science through a degree, so I guess that's good if one of us did. But yeah, I have my bachelor's in computer science and always thought that I would get my master's in management, but never needed a master's degree. I just worked my way into engineering management with a bachelor's in computer science. But how about you?

I. I taught myself how to code when I was 11 through a book, so that is the non traditional side of things. So like, do I have a technical background? I mean, I know how to code, so I guess in a way, yes. But I, as you said, like, I did not go the traditional path. I have three degrees from the University of Georgia that are psychology, public health and Social. So none of which are anywhere close to computer science or software engineering, which has been really fun because I, when I was like actively coding still, it became a game of I know what to do and I know how to do it. But I can't explain to you why this is the best way to do it. I just know that like it feels right in my heart. Like I'm just like coding based on vibes.

I mean, I guess you just gotta roll with it. But the big question is, should you even become an engineering manager if you don't have a technical background?

I think it's still an okay thing to do. I do think that you have to have an interest in the technical side of things if you're going to manage a technical team. You don't have to know the ins and outs of react or anything that you get through your computer science program, but you need to be able help your team navigate system design exercises and trade offs of, you know, you might not know. Like I don't know if we should use Rust or go for this, but you need to be able to help them talk through that. Like, what are the pros and cons? What is the business reason behind using one or the other? What, what might we look like, what way, oh my gosh, what might we be looking like into the future if you wanted to, uh, like is this going to still be supported three years from now or a year from now? These are the kinds of things you do need to be able to have conversations around, but you don't necessarily have to know how to write all the code.

Mm, yeah, I think you definitely, if you're interested, should pursue it. Um, some of the best managers I had have not been traditionally technical. Like my first internship manager when I was at IBM, he was an English major. So yeah, I mean it makes it easier if you have a technical background, whether that's self taught, computer science degree, whatever that may be. However, I'd be remiss to say it's not going to be more challenging for you. So I think you absolutely should. And in fact many backgrounds that are quote unquote, non technical almost set you up for success in many other ways with it. Like if you have a psychology background or even like a music degree, like the creativity, the creative side of your brain is going to serve you well in this career. It's just that becoming and staying technical can be a lot trickier for you.

Yeah. And I will say, whether it's right or wrong, it could be a little bit more difficult to garner Respect from some folks on your team if you are non technical because they're going to feel like they like you don't understand them.

Yeah, yeah.

I'm not saying it's right, but I'm saying like again, human nature, that is.

Yeah, that's true. I had a manager, a different manager who was non technical. I was like the only engineer on the design team and she was like a director and had no technical expertise and it made it very hard to have conversations with her. It didn't mean I didn't respect her. What I didn't necessarily appreciate was that she took no steps to try to understand how to manage me. That was the part I had issue with. Like she didn't understand my work whatsoever and made no attempt to understand it, which made it literally impossible for me to get a promotion or to get constructive feedback.

So yeah, I get it. I mean like I'm currently managing a video pipeline team and I barely know anything about video. I know the, the keywords that we use. I can tell you what HLS vs. WebRTC is, but I couldn't tell you. You know, as we're kind of working through our, our plan for the second six weeks of the quarter, it's hard for me to dive deep on that side, whereas I can dive really deep on the full stack side of things.

Yeah, and we'll talk in a second or I guess we can talk about now but like why is technical expertise helpful but not essential? I mean, to Kelly's point, you're not going to be the one doing the coding. Where I think it becomes helpful is when you are conveying status of things, trade offs, limitations to upper management or your peers or whoever it may be. And you need to be an advocate for your team and to be able to explain kind of like where you're at and like I said, any limitations or trade offs or whatever. Now you don't necessarily need to understand every single aspect to it. I think more importantly what I've figured out is relying on my team to help me understand it has been the best. Like I can't keep track. We have like 16 projects in progress at all times. Like even if I did understand all the nuances of exactly how they're building what they're building, I couldn't remember it. Yeah, so that's why I'd say it's definitely helpful, but it's not essential.

Yeah, I also think, you know, on the, the, there's a side of like managing the status updates, there's the other side of and And I'm, I swear I'm not being super negative here but like on the respect side of things it's easy for somebody to say oh it's just like it's going to take me this long because it's really difficult thing to do when they know you don't understand what's happening and so they can just like stretch the timeline or something like that. Yeah. Which is not okay.

I think that all boils down to trust and respect between you and your team members. So I think if you got it good foundation there that would hopefully alleviate a situation. But I have heard feedback like we do anonymous surveys across like our organization and I've seen comments come through before. They're like we should stop hiring non technical ems. And I disagree with that wholeheartedly. I think my question for that these, the people who think that way is okay, but tell me why, like can you explain why you feel that way? Because I don't agree with it. I think I know plenty of non technical, quote unquote non technical ems that have a better understanding of their tech stack than I do of mine.

So I think that's also the fact like how are we actually defining non technical?

Right.

Because somebody would argue that I'm very technical. Right. You know, again like sure, let's, let's, let's set aside the fact that I had been writing code for a while, over two decades. Yes. I don't have the degrees in computer science but I am in every other sense of the word technical. And like you ask somebody like you, you ask somebody on my team, like one of my strengths is being able to speak at that 30,000 foot view but also get really like down in the weeds with them to actually help them troubleshoot or understand what a problem actually is. So there's, there's that piece of like are we talking when we say non technical, are we saying like they do not have any background whatsoever in software engineering?

Yeah.

Okay.

Yeah. But it's ironic that you say that because like you're the one with three degrees, none of which have any technical like yeah, relation. I'm the one with a technical degree and I wouldn't qualify myself as being a highly technical em at this point in my career. Like I coded from what was it, 2012 through like 2022. Like 10 years I was coding. I was a software engineer at three different companies. I don't qualify myself as being highly technical and it's simply for the fact that I haven't kept it up to date. So it, they're not. Yeah. Like what does it mean to be technical? I don't know. I couldn't tell you because by all, for all intents and purposes I should qualify myself as being technical. But I don't. And I think it's just because I don't make a conscious effort to stay like. Or I shouldn't say that I don't prioritize like reading up on tech news and seeing what's up and coming like what are the new specs coming through and web development like. I don't. That's not your question.

Yeah, I don't.

So I think labels can hinder.

Like it can be a little gatekeepy.

For and for what reason really. But exactly what is the role of an engineering manager? What do they do and what do they do not do?

I mean your role as an EM is to make sure your team is delivering what they should be delivering on schedule with a high quality bar. Like there's a very important thing like indicated there, which means that your responsibility is not to typically in a lot of EM roles like not to write the code. Your team is capable of holding each other accountable for a high quality bar so long as you're helping them define what does that actually mean?

What's your take?

Yeah, same. I mean the. I see it as two primary facets. The first being you manage people in their careers like any manager of any people organization would do. And on the other side you are kind of setting the priorities for your team both in a technical like strategy way, like identifying areas for improvement and prioritizing those strategies, but also in like okrs, like objectives in key results for the planning cycle and making sure those get delivered on. So yeah, that's kind of how I see it. But at least my opinion is I don't think EMS should be forced to code. I think you can have standards for what it means to stay technical in your organization. But I don't think forcing managers to code is necessarily a good thing. That's a whole other episode probably. But I do know plenty of engineering managers that code and that's totally fine. I've seen it also work against them where they are so excited about coding that they neglect their people in their organization. I've had managers like that who I could very clearly tell, like you should go back to engineering as an IC because you're not invested in the people side.

So I've seen the same thing and I think that's like that's an important thing. Again, we talk about the pendulum of going between An IC and emergency. And when you know if you want to code as a manager, my rule is you can code whatever is not critical path. Like you cannot work on something that is critical path because your first responsibility, like your number one responsibilities are people and this is their responsibility to deliver on this. If you want to, you know, build some kind of component for fun because you just feel like it needs to be refactored and it's not actually like blocking anything, have at it. So long as you're still prioritizing your team over all else.

Totally. But let's talk a little bit about your non technical strengths. Right. If you come from a background that is different than coding, for example, let's equate technical with having experience in coding for the rest of this just to keep it simple. I think the first skill that you might be able to bring are your communication, empathy, conflict resolutions, people management. Right. Like you having a psychology degree. You've brought a lot of that with you.

Yeah. I would also argue on the com. On the communication side of things, you're bringing such a different perspective that is actually critical to a team, like a team's culture to be open to those different kind of perspectives. So you're not like one like one line of thinking the entire time. So you're going to be able to like challenge others thoughts and create an environment where they feel calm, comfortable to have their thoughts challenged or to challenge others as well.

Totally. And in all honesty, I don't think managers should have the necessary to I guess depends on the org. I don't think managers should necessarily have the final say on these technical decisions that are being made. Like you should be relying on your team to evaluate and like yeah, I guess evaluate the different paths that can be taken and the trade offs and perhaps discuss them with you. But like if you are like constantly micromanaging and having your hands on every single decision being made, like your voice has a lot more weight than other team members and people are going to probably defer to you as the one who like manages their salary. So I don't necessarily think it's perhaps the healthiest to have an EM be so incredibly hands on. Unless that's what's needed.

Yeah.

From the team at that time.

Exactly. There are times when they're so deeply split that I'm just like okay, I'm going to make the, the final decision here but this is not a. I, you know, if it ends up not being the right move or whatever then fine, like I am, I'm doing this so we can keep velocity. I'm not doing this to insert my opinions. And that is the like, that is the core difference there. Right.

And another skill that you might bring as someone without a coding background are just your strategic thinking and like your prior or like your focus on achieving business goals, for example, if you come from what other backgrounds? I've seen a lot of like English majors, music majors.

I see a lot of music. Like the music to engineering pipeline is strong.

Yeah, it makes total sense. I was almost a music major. I almost swat switched colleges. I got accepted for music education and then I was like now. But it's just because like you're using both hemispheres of your brain simultaneously in many ways and it, it correlates quite well with coding, which doesn't necessarily have a one size fits all solution. So.

Yeah, yeah. And then I'd also say just like general project and product management, being able to, you know, actually see the execution of a project through to the end and bring a level of product thinking to the engineering team to challenge your team to really understand customer needs and to develop solutions that are going to be serving the customer first.

Absolutely. So the question becomes, how do you actually bridge this technical gap? How do you stay up to date? This is something that is probably my biggest struggle as an EM is making sure that I am knowledgeable enough to interface with these discussions and convey them upwards. And I'm still trying to figure it out. Like, I had explored different avenues such as, like, should I start getting back into coding and taking like smaller tickets off our board that have been like long running bugs. And my ultimate answer to that after discussing with my manager was that's probably not the best use of my time. Like, what's more important to me is to understand the context of everything being built in the history of our repository and all of the different technologies. And why are we deprecating some in favor of others and how they all fit together as opposed to fixing UI bugs. So this concept of pairing with engineers on your team is a great one, but I would say focus more on like, what are you building? Why are you building it this way? Oh, why did you decide to do it this way and not that way? Versus like, let me drive and I'll type and I'll come up with the coding solutions while we pair.

The other thing I will say with pairing is there is a power dynamic here, especially when you're pairing with one of the engineers in your team. Make it clear to them that you're doing this because you just want to Learn. This is not you critiquing their work. You are genuinely curious about how they're thinking about this problem because you want to better understand for your own knowledge. And that is a perfectly okay thing to say.

Yeah, yeah. It's all about like your what is your intention.

Right, yeah, I can see that getting really uncomfortable for the engineer.

Otherwise it just depends on your relationship with them.

I would also say, you know, it's okay to just learn some basic coding skills or like understand. I mentioned system design earlier on. I think more than coding skills, system design interviewing or just system design like just is such an important thing for you to know how to do no matter you know where you're at within the engineering org just because it's something that's going to come up in your day to day. There is a reason why, why a lot of companies do system design interviews and it's not because they want to, you know, stump you and make you feel that you don't know what you're doing. The whole purpose of a system design interview and or just system design exercise in a technical environment is that this allows you to reach into the creative side. Like how are you actually thinking about this problem? How are you thinking about like what else do you need to know to be able to solve this problem? And how can we you know, evaluate some potential solutions solutions without just like diving right in? This is something you see you know in as, as as folks move into like more mid level or senior engineering they become better at this space. But on the engineering management side of things, I think it's one of the most important things that ENS should learn how to do.

Yeah. And oftentimes your engineers don't have all the answers either. They don't have like full. They don't necessarily know like know all these ins and outs of systems design or alerting and monitoring or any of these things but they are the that ultimately figure it out. So maybe you know, follow along and figure out how they learn.

Exactly.

I think it's more important to make sure you're asking the right questions instead of knowing all the answers. Right. Or at least know knowing who to go to. Like oh, I need to learn, learn more about performance. Like you know, like as you're scrolling a long, long playlist with a thousand tracks in it. For example, how do we improve the performance there and why is it important to do that? Oh, I'll go to this person on the team because they're an expert in performance.

Perfect. Yeah, I completely agree. Knowing, knowing what you need to ask is it seems like a silly thing that you'd be like, it's, it's very obvious but it's easy to ask the wrong person the wrong question.

It is cool. Let's talk about. We've talked a lot about trust and respect, but that's the biggest thing is how do you gain respect from engineers who might be a bit weary of having a non technical engineering manager?

Yeah, show humility. Like number one, you know, you don't know everything, nobody does. But you are a non technical leader leading a technical team. Be humble about what you don't know and be curious to ask those questions. You're also, by doing so you're modeling a behavior where it's okay to not know how to do something or understand what something is you're making. You're creating an environment where people can ask these questions and by doing so you're then going to see your team ask questions similarly either to you or their peers if they also don't understand something. So honestly it's one of the best things you can do to just build, you know, build trust and respect with your engineering team. But also is a fantastic cultural move.

Yeah, yeah. I mean I'm very open with my team about like, hey, this is one of my top goals. This is how I plan to achieve it. Like I would love your feedback. Like I. There's so our repository is like so nuanced. There's so much history behind all the decisions that we've made. And I've mentioned before that we take on embeds like we want them to be six months minimum because of how long it takes to onboard even as like a senior engineer has been the company for like 10 years.

Right.

So there is a lot to learn. And what I started doing is I essentially created like a book like a Google Doc, but it's like 30 pages long and it's organized by like different topics like APIs or like what testing frameworks we're using. And I go into depth into all of them. Oh nice. And it's like from talking with people or like how are our biggest features architected and what teams do we intervene? Like it has all the information that I've curated by talking to people.

Does your team contribute to it as well? They can.

It's so it's basically a project that I started for myself and then the ultimate goal was like, hey, this is what I'm doing. I'm gonna like open this up. So you should leave comments or like if you want to fill out sections, I'm happy to like invite certain people who are expert experts on them to contribute to it. So. But it was more like learning in public. That's really what it was for me was like, hey, this is what I need to improve and here's how I'm doing it. Feel free to like tag along and help out if, if you'd like. I love that and that helped a lot. But I think the biggest way to build trust and credibility is promising to do things and doing them in a timely manner and not forgetting about it. And also advocating for your team and removing their blockers for them. If you can see a team member struggling to handle interpersonal relationships with stakeholders, for example, like they're not getting a response from a stakeholder that they really need an answer from to progress, like, hey, do you want me to like step in and tag, you know, the em of this team to get you a response? I know it's probably uncomfortable for you. I'm happy to do that. And you know, that can build a lot of trust.

Yeah, no, I completely agree. I think, you know, anything you can do to protect your team and advocate for your team is obviously going to be something that builds trust with them, no matter how technical you are. And in being able to identify when, as you said, when somebody is struggling is, is. Is so incredibly important. And like being able to advocate for dedicating time towards technical debt versus just doing feature work, like, these are the kinds of things that go a long way with the team.

Absolutely. Okay, so I feel like we cover most of the basics of this topic, but I'm curious, are there any resources or growth strategies or things of that nature that we think could help folks who don't have a background in coding?

I think one thing is, I mean, I think this is something that everybody should do no matter what is. Like if you can find a mentor that can help guide you, somebody who either was non technical and moved into a more technical role or somebody who already is technical and can help like fill those gaps in for you, like if you can find somebody to help walk you through that, it's so incredibly helpful. And also like, should your company budget allow or your personal budget allow, you can even go as far as getting a coach, somebody who really understands this space, who can, who can guide you from a paid perspective versus more of a mentorship perspective?

Yeah. One of my mentors was our staff engineer in our product area and we met like every two weeks or so and I just basically asked him any questions that I had and I'm fortunate that he was extremely humble. Didn't make me feel silly for asking things because I was definitely of the. The mentality at the time that, like, I should already know these things. I can't ask someone now. Like, it's been too long. Like, people are gonna think I'm unintelligent or, like, unqualified. And then I'm like.

The first.

The best time would have been to ask, like, back in the day. Right. But the second best time to ask is now. And, like, hopefully you're in an organization that supports growth without egos and you get the answers you need. There are a couple books that I would recommend and courses. So, like, I think we've talked about the Manager's Path before by Camille Fournier. This. She writes this from, like, a technical perspective. So it is one of the better technical management books that can help you navigate this career. Sarah Drasner also wrote Engineering Management for the Rest of Us, which is a short and sweet read. And then becoming an Effective Software Engineering Manager there was a chonker of a book, but it was really good. I read the whole thing and I really, really enjoyed that one. Do you have any books that you'd recommend for?

Um, I think, like, beyond these, like this, it's still not on the technical side of things, but, like, I still think you should read Radical Candor. Yeah, Um, I. You know, we talked about that one, I think, last week, and I think that was a. It's such a necessary one. Crucial Conversations as well is another one we've talked about before. Like, those are the two that I would say, like, you absolutely should read, because also it will help you with, you know, the humility to ask questions as well and how to handle conflicts when you're like, I don't understand what's happening, and therefore I cannot really show up for this debate.

Yeah. And then in terms of, like, courses, Kelly has an email course that I'm personally signed up for, and you can all sign up for as well. How often do you send out emails? It's not every single day.

The. Like, the. Just the newsletter, the Monolira. Typically it's once a week. I'm taking a little. I'm taking a little hiatus from it right now.

So. Yeah. There's also free code camp if you are interested in learning, like, coding basics and you don't want to invest a lot of time or money into it. Free code camp is fantastic. And Frontend Masters is one of my favorite platforms. There are a lot of really great coding tutorials I would say they're more like college style lectures. Specifically there's a nice course like Intro to Engineering Management that was co led by Jim Young and Ryan Burgess, both of whom did work or currently still work for Netflix. And I really like that. It's a good introduction to the, to the career. So yeah.

Let'S, let's round out with this is just more broadly talking about if you are a non technical leader managing a technical team. I think imposter syndrome can really come up pretty strong here. Like should I have a seat at the table? Like am I, am I even supposed to be here given the fact that I don't know how to code or you know, whatever. However you're defining non technical, it could be in any how. You know, I feel non technical all the time because I'm not writing code anymore even though I know how to write code. But like it's, we're all going to feel like a different way on that spectrum. So like how, how would you go about handling imposter syndrome here?

I think it's important to acknowledge your, your areas for improvement and like what you could be investing more time into to aid your engineers a little bit better. Like just pretending like those shortcomings don't exist is not going to help anybody. So I would identify and recognize them and see if there's a plan that you can put in place for yourself. To confident and competent and yeah, just focus like what are the things you do really well that maybe other managers don't? Right. For me it's empathy and communication and being consistent, following through on things. I think I do those things quite well and other managers might not. But at the end of the day my job is to care about people. So I think yeah, both sides like recognize your, your shortcomings but also like your strengths.

Yeah, yeah. And I would just say like, remember like your role here. Like what is the purpose here? And it's not about the code, it's about the people. Like your job is to advocate for your team and help your team grow and help them deliver against the business goals. And at the end of the day, whether you know how to code or not, you can still deliver on that particular goal.

Absolutely. So with that, do you have a resource of the week?

So I started reading Tiny Experiments and Laura Lecomph. I might be saying her name wrong, but I am like four chapters into this book and have immediately been like this book was written for me. I cannot, I'm so excited to kind of dive more deep into it because I'm so goal focused and outcomes focused. And this kind of reframes a lot of that to be like, let's look at breaking things down and not going for like, I want to learn French if I'm trying to learn French. And I'm like, I want to be, you know, I want to hit, let's say B1 on the, you know, whatever the skill of how well I like my fluency skill. That is like a very daunting goal for me because there's a lot of time that's going to need to go into that. So, like, taking it. Step back, just be like, okay, how can I just like set a goal to practice French for 30 minutes every day for the next 30 days? That it's such like a. It feels like it's one of those things where, like, you just need somebody to like, shake you and be like, no, like, this is what you really need to do. And it's been really helpful. I'm excited to read the rest of the book.

I might have to read that reminds me of Atomic Habits a little bit.

It does.

Mine is Management Fundamentals for the Modern Leader. Have you heard of it?

No. Please tell me more.

No, please, you tell us more.

Okay. So my newsletter is called the Modern Leader. I run a course called Management Fundamentals for the Modern Leader. I do this course both live and self paced, and so we'll include a link in the resources as well. But basically the course walks you through the main skills you need to be an effective leader in your organization. And this is actually one of those perfect things where, like, if you're not technical, that's totally fine because this is talking about, like the three pillars of trust, communication and empowerment, and how you can build around that to identify high performers and low performers. Oh, my gosh. Low performers on your team and how to work with them. Dealing with feedback, setting up like, like quarterly development plans for yourself and for your team. Lots of communication stuff. It's. It's actually a really fun course. I love teaching the live version, but I also recognize that the live version is at very certain times of the day and, you know, it's a little bit more costly. And so I do have a self paced version where I recorded all of the. I almost said episodes. This is not an episode. This is not a podcast. Kelly. I recorded all the lessons, so you can actually do it on your own time.

Fantastic.

Love that.

Yeah, go check it out with that. I mean, we've got one more episode left for the season.

Yeah, we do.

I don't believe that this has been.

A lot of fun to record as well.

It has. And if you don't know, like, speaking of finding yourself a mentor, Kelly was kind of my unofficial official mentor when I got into this, which is kind of how this podcast came about. So now all of you get to reap the benefits as well.

Yeah. Well, thank you so much for listening to our penultimate episode of the season. If you have any questions, definitely reach out to us. We'd love to answer any of your other management or leadership questions you have. Subscribe to us on your favorite podcasting platform. Check us out on YouTube. Subscribe to us on YouTube. Leave us a five star review because you love us. And we will see you next week for the final episode of the season. SA.