Being a "non-technical" engineering manager in an industry that treasures technical skills - LCPS01E02
Listen on all Podcast Platforms, like
Spotify, Overcast, Apple Podcasts, iHeartRadio, Amazon Music, Google Podcasts
Episode Summary
What should engineering leadership roles look like, and how "technical" should managers be? What's been a hotly-debated topic in tech for decades has gotten very real, very often for my guest today—because he’s always been a bit of an outlier: My guest Jay has been an engineering leader for over a decade, has led teams of many different shapes, sizes, and disciplines all throughout the industry. And, unlike the more common path of transitioning from software engineer to management, he wasn’t an engineer before becoming a manager. In an industry that highly values "technical skills" and where there's low consensus on what skills make a good manager, he's grappled with finding his place, having an impact, and how to grow his career onward.
We talk about:
What does it mean to be "technical" as an engineering manager? How important is it?
What makes a good manager and leader? What makes them successful?
How are companies thinking about great engineering leadership? How's this been changing in the last years?
Learning and teaching management skills
Hiring and interviewing for management roles
Jay's calls to what companies can improve
Advice for any other managers grappling with the tech industry changes
Links:
Full Episode transcript
What should engineering manager & Leadership roles look like in 2024?
This is part two of our mini series about different shapes of leadership - in the last episode, I spoke to an experienced tech lead with a more traditional career from engineer, to tech lead, to technical lead of leads.
Chapter overview
00:00 Introduction and Overview
09:20 What does “being a technical manager” mean, and what skills make an effective manager?
35:49 Shifting the Focus from Technical Metrics to Team Well-being
47:01 Challenges and Misconceptions in Engineering Management Roles
55:05 Understanding Success
01:03:43 Management as a Separate Skillset, Navigating Leadership Roles and Job Searches, and Jay’s advice for others
01:13:21 Advice for anyone navigating these questions about what leadership roles in tech should look like, and how to deal with the ongoing changes in the tech industry landscape and their impact on leaders, and an outlook for the future of leadership in the tech industry.
Thank you for joining me on Leadership Confidential.
Transcript
Jay: and then the counter example to that is Ted Lasso, which you know, is, is my whole kind of like current, like Ted talks earlier on in my head that Ted Lasso would make an excellent engineering manager.
But, uh, I was, I was gonna say like, are,
Lena: Are you the Ted lasso of, of the tech industry? .
Jay: I think that I wouldn't ever describe it that way. Uh, I don't think I'm nearly as as funny as, as Ted Lasso is
Intro
Lena Reinhard: This is our mini series about different shapes of engineering leadership roles. In our last episode, which you should listen to, I spoke to an experienced tech lead with a more traditional career path, strong word, I know, who went from engineer to tech lead to technical lead of leads. Today, you'll hear from someone for whom the question of what engineering leadership roles should look like has gotten very, very real very often because he's always been a bit of an outlier in this industry.
This is Leadership Confidential with Lena Reinhard. Real talk on more than two hard things in technology, finding community and becoming the engineering leader you can be.
After a decade of boom, the tech industry has been going through tectonic shifts. Sorry for the pun. And a lot of these changes have played out directly in how engineering leaders spend our time.
There are fewer people for the same or even more work. Morale is low in many places and change fatigue is high. Where tech companies used to fight to hire and retain great talent in the 2010s, now productivity and efficiency have become the focus, making emotional labor a big part of many leaders day to day work.
Many also tell me about the return of the tech lead manager, as in someone who's responsible for everything from technical strategy and decisions, architecture to people management and hands on coding. As a result, a lot of engineering leaders have big, big questions about what their roles look like now, concerns about what skills they need to develop, ideally yesterday, and where their careers will head and how to keep up in an industry where change is the default.
I'll share my thoughts about this with you at the end of this episode.
My guest today: Jay
Like my last guest, my guest today has also been in the industry for around 20 years, but had a very different path. We're calling him Jay. That's not his real name, and we've altered his voice. Jay has been an engineering leader for over a decade, having led teams of many different shapes, sizes, and disciplines all throughout the industry.
He wasn't a software engineer before becoming a manager. He believes strongly in servant leadership, building trust and psychological safety and diversity as a virtue. He currently leads a team of five people at a mid sized e commerce startup. Jay and I talk about managers being technical or whatever else makes a good manager, hiring and interviewing for management roles these days, and the question, if there's space for him in this industry, Let's get real on more than two hard things in technology with Jay.
Getting real with Jay
Jay: I got laid off from a former position in, actually it was almost a year ago, actually it was a year ago today, so it was last December, it was December 2022. Uh, and, yeah, and in my, you know, in my experience, I've been doing this for a little while, and in my experience, it takes me, two to three months to line up something else.
And this time around, uh, you know, I got laid off kind of at the very beginning of, of honestly was still like a year of layoffs. Um, but I got laid off in the beginning of that. And it took me six months to find something which was, uh, longer than usual and also a lot more stressful and a lot more emotional than usual.
Um, and yeah. Something that I very frequently, like came into conflict with during my job search was a job opening for a company that I liked managing a team that I knew I can manage in a part of the business that I was familiar with. You know, I, I knew I could do the job, but. The job requirement would list, you know, three plus years of engineering experience or five or seven years of engineering experience, uh, and then, you know, by comparison, you know, zero to one years of, of management experience for an engineering manager role, uh, and I would apply to those jobs anyway.
But very frequently I would not get, you know, a call back because I don't have any engineering experience on my resume or I would get a call back and they would say, Hey, okay, we're going to have you go through this technical challenge. And I would have to sort of stop the recruiter and say, Hey, listen, like that's not me.
I'm not going to be able to pass a technical challenge. I'm not going to be able to do like a coding exercise. That's just not my, my skillset or my background. Um, so it, it is definitely still, even though I've been. At my, you know, at my current organization for, for like six months or so, it is still definitely very top of mind and I'm still seeing people who I know are very good at this go through, um, you know, go through job search challenges, um, cause the industry still continues to be very tumultuous.
Um, and I, I think especially now where they, you know, I think that the industry is a little bit more volatile and especially now. When I think, you know, maybe more than ever, people need good managers and good mentors and good, you know, good guides for their career. Um, and good management is very much an asset.
I, I do think that it's a pretty big mistake for companies to be prioritizing, you know, first and foremost, the technical expertise when I think they should be prioritizing first and foremost, like the management expertise.
Lena: Thanks for, for sharing that with me. And honestly, I mean, that, that sounds really rough.
Um, I mean, I also, I know you have a lot of experience that you've been in the industry for quite a while and you've been in various management roles and different companies. Um, and it sounds like that's a stark difference between just how long it would take you in the past to find a new job versus now, like maybe one portion might be the whole, just where the industry is at.
Um, and that's. It's also aligned with what I'm hearing from a lot of people, but at the same time, it does sound like specifically the, yeah, how, basically how strong are your engineering skills? Um, was a huge factor in that. Yeah. I also know that this is a topic of hot debates in the industry and has been for quite a while.
I would just love to start with a couple of. So just to check that you and I are at least talking about the same thing. Um, so, you know, you, you dropped the term sort of managers being technical. Um, it's like a couple of times. Yeah. What does that mean to you? Let's have you start there.
Jay: Yeah. I think when I say, you know, managers being technical, I think what I'm expressing is that you have been an engineer, you know, previously you were an engineer in a former life before you transitioned into being a manager.
And if need be, you can write code, you can commit code, you can review code, you can kind of keep up with. Any of the engineers on your team, up to and including the very senior ones, and I think that's the expectation of the role. Stereotypically, is that you have sort of reached Maybe not the pinnacle, but certainly a very senior place in your engineering career, and then you transition into management.
Uh, so when I say, you know, a technical manager or manager from a technical background, um, that's typically what I mean is that they've, they can really keep up with even kind of high level complicated, you know, engineering tasks, initiatives, that, that kind of thing.
Lena: And like high level meaning, um, quite advanced.
Jay: Yeah, quite, quite advanced. I think both in terms of scope, in terms of like, this is an, you know, an architectural kind of 10, 000 foot decision, or this is a decision that's going to impact us down the road. Um, but then also kind of thinking about it in the other direction, keeping up with the very, very fine details of, you know, how you're going to execute a task, you know, what, what different, you know, approaches you're going to take for a very specific like execution or, or function or whatever in, in the engineering work that you're doing.
Um, whether it's, you know, again, whether it's that 10, 000 foot view or that like very, very, you know, opinionated detailed view, I think the expectation is that a, uh, a technical manager or a manager of a technical competency can really like get in the weeds in either direction.
Lena: Which is really interesting to me because in my experience, Yeah.
Jay: Absolutely. And I think they do. And, and, and it's, it's one of the reasons why I'm not a fan of vesting that kind of expectation in your engineer and managers is, is because, you know, they're all doing a different job all day, every day, or at least they should be. You know, their, their purview is very much not making these kinds of technical decisions.
They're not doing the work day to day, they probably don't see all of the context surrounding a decision. Uh, so the farther removed they are from the work, I think the less appropriate it is. That they make those decisions or they sort of have, you know, kind of ultimate authority to make those decisions, but that's what a lot of companies are sort of expecting from their engineering managers and vesting them with that authority to, to break lawn jams and to kind of make those, those decisions and the, you know, the, like I said, the longer they manage people, the less they are to do that.
And so that's where I think the expectations and the realities start to kind of diverge.
Lena: Um, and you just kind of described some bits of it, um, but I'd love to hear a bit more about it. What do you actually think makes a good manager?
Jay: Yeah. I think being a good manager, I think first and foremost, really requires a lot of attention people and the dynamics, you know, around and between people.
And again, that's agnostic of what they're doing. Um, I think you have to have a very high awareness of what they're doing and how they're doing. And so, you know, that's where you, you do have to be able to, to talk their talk, even if you can't necessarily walk their walk. And I've, you know, I've been doing this for long enough and I'm familiar enough with, with computers and I'm a huge nerd and I have been since I was like 12.
So like I, I can keep up and you know, I can follow along if someone's talking to me and I can follow along in a whiteboarding session and stuff like that. Yeah. But, you know, beyond that, I really think it's just paying attention to people and paying attention to, you know, how they're communicating, how long it's taking them to do something in comparison to their peers or to how, how they usually, how they usually behave, you know, how well your team is helping each other out, how well your team is kind of stepping into leadership vacuums or like task vacuums.
Um, I think, you know, so much of it really just boils down to, to, you know, to being very attentive to the people dynamics on the team and to a very gently kind of tinkering at the margins where you can while you build the trust that you need to effectively really dive into the heavier like coaching and mentorship.
You know, kinds of things that you will need to do to push people on in their careers. I, I think it, you know, I think it requires a lot of time and patience and trust. I think it requires being very authentic with your reports. And I think that the best managers That I've worked with, you know, really go out of their way, not to really be a friend, but to be a safe place to, to listen and talk and, and, and work on things that are kind of difficult to work on.
So I think, you know, you, you play a little bit of therapist. I know that might sound a little gauche or whatever, but you play, you play a little bit of a therapist, you play, you play a little bit of a coach, you play a little bit of a mediator, um, you play a little bit of a planner. Um, and you kind of play a little bit of all those roles and just help everybody be a little bit better.
And I think that that ultimately is, is what makes a good manager.
Lena: You know, you've, you've talked about success a few times, like what were your greatest successes as a non technical, non engineer manager?
Jay: A former director of mine said something that I think will probably stick with me for a long time.
Whenever anyone on my teams. makes a big scary life decision. I know that I'm doing a good job. And by that, like having a baby, buying a house, moving, you know, like getting married and stuff like that, where you, you have to not be worried about work and money, uh, especially in the United States to, to, to be able to comfortably and safely make those decisions.
Uh, and, and I really feel like that's very true. And so, you know, whenever someone on my teams. makes a big monumental life thing. Whenever they, they say they're going to have a baby or they're getting married or they're buying a house or whatever. I feel like that is good feedback because I feel like I'm making them feel like their job isn't something to worry about and they can like provide for their, their family.
Um, and I think that the one other thing, the one other thing that, that I'm, I'm really proud of is I had an employee who, um, um, Uh, was simultaneously really not executing at their level, uh, and was going through a really difficult, uh, this was someone who, who lived very far from their family, but on a different continent during COVID, during the height of COVID, uh, so that would have been, you know, late 2020.
And to go visit Emily was basically like, my folks are sick. I have to go visit them in case this goes sideways. Uh, and this was when like getting on as just pre vaccines isn't being I'm playing with scary. Um, and while they were gone. Uh, they, they, you know, they tried to work remotely and it didn't work out very well, but I couldn't really talk them out of it.
You know, I tried to say, like, you do not need to work during this period. Your life is complicated enough. Please don't work. But, they were young and I think they, they, I think they kind of had that. tickle in the back of their brain of like, I'm not doing well and so I need to prove that I can do well.
And so why don't I take on this insanely difficult set of circumstances to prove that I can do well, which didn't work, but I can very much understand why. So I couldn't really talk them out of it. Um, and working with them through that period, I think a, to just support them and going home and coming back.
And, and tried and trying to make sure that work was like the last thing that they felt like they had to think about, but then really digging in with them to understand, you know, Hey, you know, why did you feel like you had to work during this period? You know, what, what about, what about your current situation and your current performance really led you to feel like you had to double down and then digging into the ways this person… Kind of was coming up short and it was not really achieving relative to their peers on the team and, you know, creating a space that was safe enough for us to talk about it. And then, and then once everything was kind of out in the open and once all the cards were on the table and once, you know, we were both in agreement about like, okay, this is the stuff that you're not doing super well.
Then it was, then it was about actually improving that person's performance and then it was about feedback and about, you know, coaching and about, you know, sort of pointing out the ways in which they were coming up short. And one of the things I, I, I like that I did is I reached out to the other people on the team and I said, Hey, this person would really like help with, with these things.
Um, and I checked with the employee and said, Hey, I would like. to ask your teammates to help you with this. But I know this is kind of a sensitive thing. Would you be okay with me asking them to help you? And they were, they were, they were all for it, which is great. And speaks volumes about, you know, how humble they were, um, and how, how low ego about it they were, which was a huge.
I'll been actually like diagnosing and fixing the problems and then, you know, over time with the help of their teammates with, with my help, um, they really got better. And then it was more transitioning into like more of a sponsorship versus coaching dynamic and saying, Hey, okay, I do think that you can handle this.
Let's actually get you some opportunities. Let's actually put some work in front of you and see if you can do it. And they did. And now they're doing really well. Um, and I think that's You know, they were kind of on the verge of a, of a pit, like on the verge of a performance improvement plan. And I think that's, it's, it's not.
But often you hear about that, about like someone, you know, kind of doing a 180 and going from, you know, kind of rocky territory where they're really just genuinely not delivering to doing very well. And I think it's a lot of it is, you know, due to that person again, having a low ego and being humble and sort of agreeing that they weren't executing.
Um, but I, but I also, like, I also take that as, as sort of a success on my part.
Lena: Well, that there is, it does sound like there is a, again, basically creating an environment where like that person is first of like, they're, they are supported through just the personal hardship and the situation that like, they can't change, the company can't change and you're not there for them, giving up on them in that time. I want to call out a couple of things that were really interesting to me. I think one bit is the sort of technical versus non technical dichotomy. Um, I feel like that comes up, comes up quite a lot in these conversations about, you know, like, Oh, Can, can non technical people be good engineering managers?
Like how technical does an engineering manager need to be and all that? Um, and I think the dichotomy just isn't helpful as a framing. I mean, you, you, you used it and this is not about you, but because it's just very, very much not sharp. Cause like you even, you know, you called out yourself that like, It is important to be able to follow along to reason with people, at least at a, at a high level of generally understand what is going on, what they're talking about, which honestly, I don't know if everyone means that when they say, you know, people aren't quote unquote technical.
Whereas like basically it sounds like the really important part from your perspective is basically like what capabilities does this person bring, like the manager of the team and what is the aim of their role where like what I've heard from you is basically the role is about, um, Building great teams, um, helping people grow, helping them overcome obstacles, um, using tools like coaching, mentoring, um, facilitation, recognizing team dynamics, probably a lot of systems thinking there as well.
And sort of the flip side or the, the kind of more technical, um, to use that term, um, way of like living that role. Could be much more about like actually writing code, um, actually collaborating with the team on a day-to-day basis, um, pushing tickets through and all of that. And basically where it's more the focus or at least the idea seems to be much more about the manager as someone who gets things done with the team and works on similar tasks to the team.
Like, does that, does that actually jive with you? What do you think?
Jay: I, yeah. I mean, I've, I've definitely seen that. Um, like, you know, sometimes you'll, you'll see, you'll see people either describe themselves as a player-coach or you will see, you know, like job descriptions, you know, say we're looking for a player coach who can really, you know, sort of split duty between, like you say, pushing tickets through actually doing individual contributor work and the management stuff.
Um, and I think. 90 percent of the time that is just combining two roles into one, you know, and I, and I don't really think that's setting anybody up for success. I think that's really just a company saying, well, the management stuff is easy. And it's kind of a throwaway task and anybody can do it. And so let's just get someone who can do 90 percent of the individual contributor work and all of this other management stuff, because we don't want to hire two people who have the budget for whatever.
I don't, I don't think that's personally really functional or, or setting individuals or a team up for success. Um, Similarly, I, I think it's not that having that technical background is bad by any means. But I think it's, it's, it's just a tool in your toolbox to allow you to relate to your team and solve problems.
And on some teams that might be a lot of the problem, you know, on some teams, if you hypothetically, if you have a team full of junior engineers. Um, and they really need technical mentorship and technical guidance, and they need someone to really level them up. I could see how having that background and having those skills and being able to say, Hey, don't do this, do that, you know, Hey, you, you know, you really need to shift your perspective and you need to do this instead, or, I mean, let me review this code with you.
Let me show you how this is done. Um, I could see that being of value, but I think in the majority of teens that are on the more senior side. That are not, their primary job is not to grow, their primary job is to ship value, you know, that tool might get pulled out of your toolbox every now and then, but the vast majority of things that you are going to be trying to improve are going to more delivery and collaboration focused and less technically focused.
And so you need to have those tools in your toolbox. You need to know how to, you know, help someone be a better communicator. You need to know how to help someone like run a collaborative project that they've never run a project before. You need to know how to, you know, You know, get your high performers more opportunities and get them out there actually doing what it is that they do best.
You know, you, you need to have a lot more tools in your toolbox that are much more diverse and people focused. And you know, having the years of experience as an engineer doesn't, doesn't necessarily mean that you're good at that stuff. Um, And, you know, by the flip side, just because you've been managing a team for forever and you are good at the people stuff doesn't mean that you have the technical skills, even if you had them at some point in the past.
Um, so I think, you know, the mistake that I think the industry makes so often is over indexing on the technical toolbox and not investing at all in the people toolbox. And then you get into situations where 99 percent of the problems are people problems and you're not able to solve them.
Lena: Yeah. Yeah. And I think that part that you just mentioned, I keep seeing a lot as well like that.
I believe there is a systemic even misunderstanding of what people's skills even are and what shape they can take and what impact they can have, honestly. I mean, a lot of people say they don't understand what a manager does on any given day. And I honestly, I get that. I think a lot of managers are. And I would include myself in that.
Like a lot of us aren't really great at talking about what we do and how this work works and what it really, um, what it can do if it's, if it's going well, whereas like, um, because there is so much ambiguity involved in, I think, uh, it's, I see you nodding heavily. I think a big part of the work is that it's, it's never really done.
Um, there is a lot of just like pushing an endless, a boulder up an endless hill and So it's often it's very squishy work, whereas like a lot of engineering problems, yes, are very hard, but they're also to some degree, at least contained and there is visible demonstrable progress or not lack thereof. Um, and I think that is something that.
That adds, I don't, I don't think that that justifies the sort of systemic undervaluing of like people skills. And at the same time, also, I think a lot of engineers aren't interested in that career because it is a different career, um, to like work with humans, work with people. And that like, I mean, fortunately there's been a little progress, but I also think we're currently really regressing in that sort of default assumption that once you have reached a certain Proficiency as an engineer, you should automatically become a manager.
Like that is awful. That has given so many people, like so many engineers, terrible new careers that they didn't want and set them up for failure and gave a lot of teams managers that they shouldn't have had.
Jay: Yeah. Where I really started nodding was when you said, That leaders don't know what good management looks like when it's done well.
Um, and I think there's so much to unpack there because like a good friend of mine, um, who's been in the industry longer than I have, who's a couple levels higher than I am. Uh, he, he writes a blog and one of the blog posts that he wrote that I love is basically about just managing by vibe and having that.
Genuinely be what you are, what you are, you know, the criteria for whether or not you are doing a good job. Genuinely should be, like, what is the vibe on your team. Um, and in complete seriousness, and basically throwing out any, any sort of like, any, like, listen, we, you know, but we tried to make, you know, this number go up, you know, we try to make velocity go up, we try to make the number of tickets go up, we try to make the lines of code go up, throwing out all of those expectations and really genuinely talking more about, hey, listen, if I'm doing a good job as a manager.
Like, none of my people are gonna be a flight risk. I'm gonna have super high retention on my teams. Everyone's gonna like working with the people on my team. They're gonna be a delight to work with. They're gonna run things well. And then, and they end, end in the metrics as sort of a second order consequence of managing to the vibe.
The, the metrics will get better, and it's not that they can't be tracked, it's that they shouldn't be the thing that you're rating yourself on. Um, they are like a second order consequence of taking care of your people. Um, and I think, like, like you said, when When there is just one path for progression, and when you sort of reach the, you know, the, the, the phase of your career as an engineer, where now the only place for you to go is to start managing other people, like you said, there, there are lots and lots of people who don't want to do that, who aren't suited for it, who've never been trained for it, who have never had to do it before, and I think when you have people like that, who are put into those positions, you get really bad vibes.
And when you have really bad vibes, when there's no trust, there's no safety, there's no consistency, everything feels kind of scary and fraught and fragile. Um, then the metrics start going down, they start going backwards. But again, that's a consequence of the skill of the manager and the experience of the manager.
Um, so, so yeah, I think, I think all that is, is absolutely true. And I think something that we can do better. As, you know, as a cohort in the industry, as, as managers is really like get loud and explicit about this is what it looks like when it's done well. And the, the common conception of how we examine success and how we, how we look for success and what success criteria is for a manager and by extension their teams and their people is, is just fundamentally wrong.
And we have to start thinking about that differently. Right. In order to understand why this Profession is even valuable and when it adds to companies, because I think it is tremendously valuable, but I think a lot of people just don't understand the value.
Lena: Yeah, well, I think there's even a lot of it is also rooted, I think, in hero culture, which is still quite ingrained in the industry and that idea that, you know, you just have this one engineer who saves the day and they're the.
The person who works the weekends or the late nights and they're really, you know, you can give them any kind of work and they'll push it through and whatnot. And so much of the research shows that like longterm, it's about great teams and not about that one person because like one single person next door, you know, I've worked with engineers like that were fantastic.
Um, but if If you're not careful, people burn out and also like no single individual should have that kind of responsibility. And, um, I think that is part of that conversation as well.
Jay: And, and very often in my experience, that's the manager is the, the manager is, you know, sort of like the, the, the pinnacle among meatballs.
The manager is the person who parachutes in to save the day. The manager is that like. 10x engineer, I'm air quoting super duper heavily. Uh, you know, they are that 10x engineer that is expected to like parachute into incidents or take on the really hard work. And yeah, I think that's absolutely setting the team up for, for an, an underwhelming experience and best and like failure and burnout at worst.
Lena: And in your experience, what do you think those expectations of companies are coming from?
Jay: That's a good question. I think. I think a decent amount of it is just an uncritical. Reliance on tradition, you know, I think the, the trend kind of the very traditional view of a manager is that they, they start off doing something low level, they rise up through the ranks, they do all of the jobs and eventually they take over as a supervisor, as a manager, as a, you know, that's, that's a very kind of stereotypical worker transitioning into manager pathway.
Um, And, so, I mean, frankly, I think it's, that explains a lot of it, is, oh, if you're an engineer and manager, that means that you were an engineer. You know, just like if you're a forklift manager, that means that you once drove a forklift. You know what I mean? I, I, I think genuinely, I think a decent anonymous just comes from just lazy tradition and, and, and not really examining whether or not that works.
Interesting in
Lena: an industry that's that prides itself on like, you know, innovation and, and there were just disruption. Cue the air quotes here, but go on, sorry.
Jay: Yeah. And, and, and, and, and, you know, we could spend an hour talking about how that, that doesn't actually match up to, to reality and, um, and, and then I, I also think that there is the.
Yeah. Yeah. More forward thinking view that if you're going to be managing people, you should know what they're talking about and that if you are a mentor and you are a coach, you do need to have. Some level of familiarity with what you're teaching and what you're coaching. I don't agree with that personally, but I do understand where that comes from.
You know, if, if I'm going to, I'm going to use a silly example, but like, if you're going to coach a soccer team, you should know how soccer works and how you play soccer and how. Soccer players were, and then the counter example to that is Ted Lasso, which, which you know, is, is my whole kind of like current, current, like Ted talks earlier on in my head that Ted Talk, Ted Lasso would make an excellent engineering manager.
But, uh, I was, I was gonna say like, are,
Lena: are you the Ted lasso of, of the tech industry? .
Jay: I think that I wouldn't ever describe it that way. Uh, I don't think I'm nearly as as funny as, as Ted lasso is, but I, like I said, I do think that like. That there are a lot of lessons to be learned from, like, from Ted Lasso, and then from the idea that, like, someone who doesn't know the minutiae Or be like the intimate details of like, you know, the game of soccer or the rules or whatever can still like bring out the best in people and still recognize dysfunction can still turn dysfunction into, into, you know, into function.
And I think so much of what we do with engineering managers really just boils down to people problems and solving people problems and, and helping people be their best and work together and communicate and collaborate. And none of that has to do with. Uh, so that, you know, that's kind of, that's kind of, you know, where, where my, my view sort of my ends in a nutshell.
Yeah. And I, I mean, and honestly, I think it would be, it would be a mistake to sort of leave out the fact that like I've done that badly before too. And I think a part of growing as a manager. And this is why, and this is frankly, this is why companies should hire folks with lots of management experience is because if you haven't been in this, in this kind of role for, for years, you won't have made mistakes.
And like, I have like managed people out with a PIP because I didn't know what else to do. And I didn't know how to fix it. And I didn't know how to create safety for them. I didn't know how to talk to them and it can be really, really scary as a manager to dig into those conversations. You know, you, nobody likes being a bad guy.
Nobody likes giving people bad news and, and you just aren't, when you're a young manager, when you've never done it before and you don't have good mentorship because we don't hire people with these skillsets, you don't know how to have these conversations. You don't know what words should come out of your mouth.
And so I have, you know, just kind of managed people out because I didn't know what else to do and neither did my leadership. And I have like given people impossible, impossible pits and just been like, this, this is your, this is how you keep your job. And everyone involved knew that they were going to keep their job.
And it was because no one knew how to do it. No one knew how to have effective like coaching and mentorship conversations and processes. And so, you know, one of the only ways that you can get good at that stuff is by screwing up. If we are constantly saying, well, you need seven years of engineering experience because you're an engineering manager, but you only need one year of management experience to manage a team of 10 people of, you know, a diverse backgrounds, diverse experiences, diverse tenures, you're not going to be able to help those people when they need help.
You can help in code, but you're not going to be able to help them when they need help with the other stuff. And that's. I think, again, doing, doing the industry and doing, you know, your direct reports and doing your teams like a huge disservice because just like you're hiring engineers for the experiences that they've had and the lessons that they've learned, you should be hiring managers for the experiences that they have and the lessons that they've learned because I wouldn't have been able to do that in my first year.
I didn't. I, people have quit because of me. And I think every manager who's been around for a while can say, Hey, Oh yeah, I screwed up. People quit because of me. I pushed people out of, of, of jobs and it's just a part of growing through this, this role. And you have to, you have to prioritize building up that, that, that knowledge base at your organization.
Otherwise you're not going to be able to fix these problems.
Lena: I kind of actually want to pick back up when you talked about essentially what I would take as a lot of management has been taught in companies through people making mistakes. And a lot of us have made. A lot of mistakes. I mean, I would honestly include myself in that.
And what I heard, and let me know if I misunderstood is essentially like we need to take management and just people things as a practice more seriously, also so that we can stop. just learning through mistakes and stop making mistakes as like the primary way of actually learning that discipline. Um, and instead like, yeah, take it seriously and like teach people and train people and actually doing this well and remove some of the learning through mistake and harming people in the process.
Jay: Yeah, absolutely. Like I, I was, I was thinking about it and like, uh, you know, anecdotally, I, one of my. One of the people that I've recently managed is sort of, as a junior engineer, this is their second career. Um, so we, you know, we recently had, you know, like a fairly gnarly incident. You know, our, our, our application was down, you know, we had to update the status page and do the whole thing.
Uh, and it was this person's first incident ever, uh, and, and they were freaking out. They were like, Oh my God, the site is now, Oh my God, Oh my God, what do we do? No, they did not cause the incident, uh, but they were observing and they were observing us all sort of like sprinting into action. And when you've, when you've seen, you know, umpteen incidents before.
You react very blase to the fact that the site is down. You're just kind of like, okay, let's let's go through the motions Let's stand up an incident. Let's get on the call. And she was this this person was was freaking out And I you know, I was talking to them afterwards and hence we're dealing with like the emotional come down Of this incident that they helped that they helped remediate And I was saying, hey, like, you, you know, the next time it'll be easier, like, you, you get used to it, you get used to the adrenaline rush, you get used to, you know, diagnosing, you get used to all the tools and technologies and you just get used to fighting fires.
Um, and it, it occurred to me as we were talking that we treat going through incidents and even causing incidents as a badge of honor. Like that's the, that's the recurring joke when you're an engineer is like, if you haven't taken prod down yet, you're not a real engineer, you know, it's like a badge of honor type thing.
Uh, and, and there genuinely, I really do think that there is some wisdom in that, that there is wisdom in like, Hey, listen, everybody, everybody messes up. It's not about lame. It's about learning and growing and you kind of have to go through this because we're earlier strides. And it's not about hazing or anything like that.
It's just about like, this is an experience that you will get. And it occurred to me that we don't have that for managers. We don't talk about managers that way. We don't. We don't tend to say, oh, you've never had to deal with a pit before. Oh, you will, you know, like, oh, you've, you know, oh, this is your first time, you know, having performance conversations with someone.
Oh, you will, or, oh, this is the first time someone quit, or this is the first time that someone requested to move teams or, you know, any of the really difficult things that we deal with as managers. If you can, if you could consider any of those things like an incident. For a manager, we don't talk about kind of building up that institutional knowledge of, Oh yeah, you'll, you'll go through lots more of these, you know, Oh yeah, that's your first time, but don't worry, you'll get better.
Uh, we don't really have that as managers. And again, I think it's precisely because we don't really value. Building up that like resume and that body of experience as a manager, you know, we're, we're perfectly okay with, Oh, you've never managed people before. That's fine. Or you only have a year of management experience.
So that's fine. And
Lena: as if it's not going to make a difference if they have that experience or, you know, if it's just a year. Yeah,
Jay: yeah, exactly. And I think managers like by their. By their definition, kind of have to be senior, you know, you, you have to have a decent amount of experience to responsibly manage other people.
But if you're bringing in people who have no management experience, that's kind of like hiring a junior developer to take on senior developer caliber work and senior developer scope of work and difficulty and challenges. And it probably won't end well. I think a lot of that is missing. You know, I've, I've, I've been in places that had ladders for managers.
Um, you know, the same way that we have ladders for engineers, but it's difficult to grow as a manager. You know, you only have so many positions, you know, there has to be a need to have a senior manager or a manager of managers. Um, so I, I think it's, I think it's hard just by virtue of the relatively few positions that there are.
But I also think that companies by and large just don't invest in growing their, their management talent the way that they invest in growing their individual contributor talent.
Lena: Yeah. Yeah. I honestly, I mean, I, I think I would agree. I, um, I liked the comparison you drew to like bringing production down as an engineer.
I would even take that one step further. And basically I think the, the blast radius for managers making, um, The equivalent effect, bringing production down as mistakes, like it's just so vastly different because then we're not talking about tech, which like, obviously it's going to cost stress and cost a lot of time.
It's going to cost money. It's probably going to cause angry customers. I don't want to sort of downplay bringing production down at the same time. Like a lot of companies do have at least somewhat of a process. That's the right way of dealing with that. And ultimately like there's the impact is at least somewhat contained, but like when we're talking about manager errors, yeah, we're talking impact on like people on their wellbeing on their careers.
Um, like there are a lot of things that can go wrong in people management that just have a very different caliber of impact. I also did want to briefly call out, you mentioned, you know, the whole topic of training a couple times. Um, I don't know if a lot of people are aware of this, but like, there are a lot of fields where like there is actively research being done on like all things, people and management, like, you know, for like psychology, um, even like things like organizational psychology is like a whole special field around it.
Um, and there are a lot of things that have sort of, even just in the last. Let's just make it the last five years that have come out, like, for example, you know, I really don't, like, I understand anyone who doesn't know this, but like Maslow's hierarchy of needs has been disproven for a very long time. Um, take the like Paloma Medina released the biceps model of human core needs under an open source license.
There are other models now, like Dan, Dan H. Pink's, um, book and drive is really good as well about things that motivate people. But like there are, and again, like I don't fault anyone who's never been taught, um, any of this, but like there is basically, there's a whole field. of like research into essentially why humans behave the way that we do.
I was also actually looking yesterday. Um, I'm working on, or I did just work on something about inertia in teams. And essentially when people, leaders often complain to me that basically, Oh, no, one's taking ownership in my team. Um, and the dynamic that I used to diagnose that as an inertia trap and. Um, one thing that, for example, I learned is that, um, I was taught when I took a first aid class that, um, there's such thing as the bystander effect.
Um, so the hypothesis that, um, people basically, when they're in a group and there's an emergency happening, people basically will not do anything because other people are around. Um, and that actually has, um, Um, which I wasn't aware of until yesterday, um, that's been disproven. Um, so there is, there is research that shows that actually in emergency situations, people will actually come to the aid of strangers, but, um, it turns out that the bystander effect does actually happen in workplaces.
Um, so where people, even though they know each other, um, like people basically will rather spread rumors and gossip just among employees. And so the more people talk about things, the less likely it is that feedback actually reaches managers. Which I thought was highly interesting.
Jay: No, I mean, I, I think that's super fascinating.
And I. I, I think it, I think it does speak to the level of, you know, underinvestment and, and sort of disinterest in, in people management as like a practice and as a skill set. And I think tech is so infinitely passionate about tech and it's so infinitely passionate about, you know, what's the best coding language for this?
What's the best framework for this? How can we squeeze this, you know, more, more cycles out of this thing? this, you know, this server, you know, how can we push the envelope further on technology? You know, I think we're so, we can be such like purists and perfectionists when it comes to the technical systems that we work with.
But yeah, I, I guarantee you that if you interviewed, you know, HR people, you know, organizational leaders, directors, you know, if you interviewed people across the industry, less than 1 percent would track anything that you just said. You know what I mean? Like, the, the, it's not even on people's radar. The fact that there is a good and a bad and the fact that there is a proven and a disproven, the fact that there is, you know, a success and a failure and that you can apply a rigorous kind of scientific, hey, no, we kind of know what we're talking about to people and to people management and to like big groups of people.
I don't for a second dispute that that's true. I know that that's true. And I know that you will never get people to kind of acknowledge and agree with that yet in the industry because it's all just, you know, kind of on gut and on feel. And it's, you know, there's just a, I think a fundamental sort of lack of acknowledgement of like, yeah, this is.
This is a, a science and a profession and a skill that you can pursue, you know, yeah. And I think, you know, so much of that couldn't be mitigated on the front end by really, you Um, you know, indexing hard on, you know, okay, have you done this job before the job being managing people, managing the team, um, you know, have you done this job before?
Um, and I think, you know, in the interview process, at least in my experience, a lot of the questions that are asked are genuinely very good. You know, you do get asked, have you ever turned somebody around on a pimp? You know, how, how have you dealt with, you know, delivering critical feedback, you know, and talk to me about.
You know, times where you managed through adversity or, you know, I, I think the interview processes are decent, but again, if, you know, it's a funnel problem and if you're only, if one of your dates is, okay, well you have to have seven years of engineering experience, regardless of anything else, I think you're, you're going to face a serious funnel problem where You know, if you're asking for, you know, five times the amount of engineering experience as you are people experience, you're, you're going to get a certain set of candidates that probably don't have the, the level of experience and skill on the, on the people management side that you actually really need.
Lena: Yeah. I will say that unprompted, this is the fourth time this week alone and it's for reference, it is Thursday afternoon where I'm at, um, this week alone that I'm hearing from someone who has. a long history of management experience. The other three people I've heard of also all actually have an engineering background and like you, um, and all of them right now are looking for new roles actively.
And all of them this week failed a technical interview because all of them have not In programming in the last couple of years, because they had higher level roles or just the scope of their role was different. Um, and in at least 2 cases that I also heard off, um, these people basically were even told about the technical interview and sort of somewhat of the scope.
And in those cases, the interview was also very different from what they had been told to prepare for. Um, and I know at least of 1 of those people who, um. Wanted to leave the interview and cancel 15 minutes in because they basically said, yeah, there's no way I'm going to succeed in this. And that's, that's obviously anecdotal data, but that's the kind of stuff that I hear a lot about and I find it tough.
Jay: Yeah. And I, I've heard that too. I've heard from, you know, a former colleague of mine who was searching a little while ago, who is, who's now at the director level, what, who was an engineering manager, pure of mind. Uh, who again, like they front of him and said, Hey, you know this, we don't have the same expectations of you as we would an individual contributor.
We know that you're higher level. We know that you're a little bit removed from the day to day, but we still want to put you through the technical just to make sure that you have the basics. And then when they got into the interview, it was very much. And a regular standard, you know, individual contributor, you know, coding exercise and they kind of struggled through it and ultimately didn't get that role.
And yeah, you know, it, it had so little to do with the job, it has so little to do with it. You know, the day to day requirements of the job and it was, you know, it was really, you know, kind of flabbergasting and frustrating to this person, but ultimately that was also a signal for them that they didn't want to work at this place anyway.
Lena: is a bi directional interview after all. Um, and I'm glad that, yeah, it, it still sucks. Um, and I'm, I also, I do appreciate that you just called out this bit that this is not. The work, like I appreciate that a company may say basically, you know, what, what they were at least told was going to happen on, Hey, we want to understand if you can grasp the concepts or reason about technology to some degree.
I think that makes sense. If you're going to work in that area, um, like, you know, to your forklift, um, manager comparison from earlier, like if you've never seen a forklift or been around one and can't distinguish it from an excavator, you're probably going to have a really hard time. But at the same time, there's, I remember there was a, this is going to be a super weird tangent, but I'm going to take it right now, but there used to be a game show in Germany about basically people placing a bet that they could do really ludicrous stuff.
And one really popular one in the nineties was, um, and I'll see if I can include a video in the is that, uh, a forklift driver. Made a bet that they could take a thread and pull it through a needle, like thread, thread the needle with the forklift.
Jay: Right. Literally threatening you. Oh yeah.
Lena: Yes, exactly. But like using, using a forklift and obviously like they did it, they were a fantastic forklift driver.
Um, but that's probably also not the manager, like the level of forklift driver that you need to be, to be a good forklift driver manager. Um, that also, by the way, the forklift thing, they also released like that game show, they released a computer game that was one of the first computer games that I played as a child in the nineties.
Um, so yeah. Yeah. Thanks. Um, and, um, yeah, you could, you were the forklift operator, um, in that scenario. I'm, I'm, thank you for bringing that.
But, um, so yeah, the, the point I, I love the point you made that I think there is a big challenge in a lot of companies that they don't understand really what the job should be. So basically a lot of the misconceptions are just, Permeated and they kind of keep being repeated and then they're, they're repeated in interviews.
Like, I'm really glad that for interviewing software engineers were at least broadly, I think there is a bit of a consensus at this point that like whiteboard interviews, we're just having people write down algorithms are just a terrible idea because they're not mapping the job that people are actually going to do.
And that like an interview should match the job as closely as possible. I think we're there with engineers, but I think with managers, there's still so many question marks and companies not knowing what to hire for, let alone how to assess for it. You mentioned behavioral interview questions. Like, those are great, but honestly, I know a lot of companies that don't know how to assess the answers beyond someone.
Taking check boxes for certain words that someone drops. Um, so I think we're just, we're way behind and even, and it shows just again, the understanding of what these roles even should be, let alone then how to assess whether someone will be successful in them.
Jay: Yeah. And I, you know, you asked earlier about, you know, how.
How, how would you describe success as a manager? And I think if a company doesn't understand what successful looks like for their management roles, if they don't have a good, you know, conception of what they need from a given manager, they're not going to hire the right person, or at least they're going to have a really hard time hiring the right person.
And they're going to have a very hard time matching up. You know, the candidates who might actually be successful with, you know, an interview process that ensures that they get someone who's going to be successful because there's just a fundamental, I think, kind of a lack of understanding of what, you know, what inputs are, what outputs are and, and how to gauge those things in the interview process.
Uh, I, I think there's, yeah, I think, I think I, you nailed it. I think we're 10 years behind on tech. Management interview processes. We're probably like 10 years behind.
Lena: Yeah, absolutely. And I, I think the bit about how do you help someone be successful in this role in the next step that companies really struggle with, I'm actually just working on an article.
Basically for senior leaders, like, you know, executives, um, especially first time executives in engineering, for example, like what I see on a regular basis is that even when managers already have that experience, they, and they are hired for that experience. A lot of people around them really struggle with how to set them up for success.
You know, things like rudimentary expectation setting, um, or how to give feedback on a regular basis. like practices that are at least in the engineering manager, one on one trainings that now exist, fortunately, like that are taught there. A lot of people still just don't know how to do well. Um, and so again, we just, I think we, we, we keep landing at this point of like, we are repeating the old patterns.
The last question I have on this sort of how we treat people as an industry topic, I saw the other day, I saw one of those LinkedIn posts and bear with me for a second. It was very accidental. It's not anyone in my network. I don't remember the name, but it was something along the lines that I've read quite often, which was basically, Hey, Hey, I've been a software engineer for 15, 20 years, um, and I've been in this industry for so long now.
And it took me this long to realize that 99 percent of tech problems are actually people problems. And now I've understood this and this has opened up a whole world for me. And people, you know, it had so many shares and so many likes that people were so enthusiastic. Like, oh, this is so cool. So now, you know, I see that.
I also hear things on the flip side, like what you're describing, like the experiences that I'm hearing. I mean, experiences that I've also met myself. Um, someone, you know, that and those things both co exist. Um, the, you know, the whole software engine, you're realizing, Hey, it's all about people. And you're not, you're not.
It's not about them individually. They're congratulations. Like I'm, you know, I'm happy for them. Um, no shade on that. Um, at the same time, you know, people saying, Hey, I realized this. And then at the same time, we're talking about how essentially. There still seems to be the systematic undervaluing or even under acknowledgement that this is real and it's important.
Where do you think that dichotomy is coming from? Because like there must, like someone is approving those job postings of those engineering managers with the seven years of engineering and one year of management experience.
Jay: Yeah, that's, uh, that's a great question. I wish I had a good answer because it is flummoxing to me.
You know, I, I think a little bit of it is just again, sort of the, the lazy, easy sort of inertial. Well, this is how it's always been. So this is how I'm going to keep doing it. You know, I, I do think that there's a decent amount of that we're going to, yeah. And we've all, we've all, anybody who's hired a role.
has recycled the previous job description over and over and over again into perpetuity. So like, I, I do, I think that a decent amount of it comes from, from that. Um, and I also think that, you know, like when you're talking about engineering, when you're talking about technology, I think one of the, one of the things that I genuinely am envious of when it comes to my engineers is that they are constantly chasing.
They are constantly chasing this, it works moment, you know, they are constantly chasing this moment, this like euphoric moment where they finally did everything, talking to everything else. They finally solved the problem. You know, they, they run their tests, they all pass, they look at it in their environment and it all works and it all clicks in and it all, and it's, it, it, it, that feeling is very binary.
That feeling of, okay, five minutes ago it didn't work. And now it works. It's very binary. And it's the same, it's the same feeling that you get, you know, like when you, when you fix something around the house, when you fix your car, like when you, when you turn over the engine in the car and it finally turns over, I really, I'm genuinely deeply envious of that because as leaders, we rarely have that kind of feeling.
We very rarely have that kind of feeling of. I shipped that thing and it worked. And so I, I feel like that, you know, again, it comes down to like not knowing what success looks like and admitting that for us success is a very different thing and it's very different to measure. And so I think a lot of it comes down to that is that it's, it's a lot easier to describe a technical role than it is to describe a non technical role.
That when we're choosing what to value, I think there's a lot of implicit bias that goes on. But I think it's, it's very easy to value something that, that works, that you can point to that person or that thing and say, they made that work. They shipped that thing. They built that bridge. They fixed that engine and whatever, wherever, wherever.
And so I think that. You know, that bleeds through to like what we value in the industry and that has really wide ranging repercussions. That's a huge ripple effect. And I think you see it in sort of perpetually valuing the technical experience, even though you have LinkedIn posts like that, the, Oh, 99 percent of problems with people problems.
And even though you will get most leaders to admit that, it'll certainly get people leaders to admit that at some point. Yeah. I think any, anyone who's kind of been around the block and has got a decade of experience will tell you that the problems are communication problems or people problems or collaboration problems or feedback problems.
But I think when you sort of go back to like our DNA as an industry, we are still so rooted in that, that binary, Oh, they, they shipped the thing that worked. I think the, the, like the, the knock on effects of that, we, we see them in, in what we value and that's what we value. Right.
Lena: Yeah. And I would even like, thank you for entertaining that big question.
Like I, I don't have answers either. I also just have a couple of hypotheses, but I, I loved yours and I want to even expand on the last one a bit because that's something I've been thinking about a lot, um, which is I believe as an industry, we fundamentally struggle with ambiguity in that. I see that as one of the biggest things.
Many engineers, even most engineers struggle with as they move into higher level roles. I see that in the way that we treat engineering management. I see that in how, um, specifically tech companies are struggling. Oftentimes our engineering departments are often struggling to work with cross functional teams with non engineering teams.
Um, and specifically when it comes to, um, They get dealing with things that are ambiguous in scope and that aren't like solvable through coding and that probably are never really solved. And I feel like that is, that is related to a lot of those issues.
Jay: Yeah. And I think, I think we, as far as like engineering culture goes, ambiguity is something that you can code away.
You know what I mean? Like, and we talk so much about, you know, yeah, it's the whole, you know, we talk so much about, you know, engineering paradigms that completely reduce ambiguity, that remove the need for refactoring down the road, you know, ambiguity is tech debt to an engineer. But for, for a people manager, for, for organizational stuff, ambiguity is not something that you can just try harder to fix until it's fixed.
You know, it takes time, it takes patience, you know what I mean, like, uh, dealing with personality problems, with people problems, with or structure problems, you know, a lot of the times it's like if you try hard to fix that in a hurry, it blows up in your face. You know, it's, it's one of those things where like kind of the harder you try and the more, the more harder you push on those things, sometimes it really does have a disastrous effect.
And yeah, I think we're, we're terrible at that and we, we don't, we don't acknowledge that it is a, it's something that can't be solved by just Focusing on it more, it won't move any faster by focusing on it more, you know, which is to say that it can be solved, but it has, it has to be treated very differently.
Lena: Well, I think in most cases, the job isn't to solve the ambiguity, just like for a lot of engineering or even business problems at some point, you know, you have a principal engineer and their job is to either find business problems or take existing ones, break them down and solve them. As much as possible for engineering work, the leadership job, I believe, is just holding the ambiguity, like I used to, to, to compare it to like that, uh, slime.
It's just, you know, sort of ambiguous mass and you can't really shape it. Like you can, you know, break things out from it.
Jay: Yeah.
Lena: Um, You, all you can do is like, you know, try and make progress with it and despite of it. And yeah, yeah. Sometimes you can actually solve a chunk of things, but like, it's just never done.
And that is a very different way of working and also being successful. What do you, What do you think companies should be doing differently? Like your top five things.
Jay: My top five things, I think.
Lena: Or ten.
Jay: One, there's not going to be an order. There's not going to be any kind of order. But. That's cool. I think prioritizing.
Management experience just as much, if not more so than technical experience, I think would be a great place to start and really sort of insisting just like we insist, hey, we're hiring you for, you know, a mid level position. You need two years of experience. If we're hiring you for a senior level position, you need four years of experience.
I know that those are just ballparks, but having ballparks for management roles and having them in. That expectation of you've done this job before, you've learned these lessons, you've internalized things, you've made mistakes, you've grown as a result. I think treating, treating management like management and not, you know, uh, a weird bonus skill that you may or may not have on top of your, your technical skills, I think would be a good place to start.
Um, I think Having conversations and evolving our understanding of what successful managers do, I think would be tremendously valuable, because again, like we've said, we, you know, it's, it's really hard to expect organizations. To do any of this stuff well, if they don't know what the upside is and they don't know what the value of it is.
So I think, you know, as an industry, I think that we have to get better and we have to get clearer about, you know, okay, this is what we're expecting from a manager in this role. This is what success looks like, you know, this is what, you know, a stretch goal would look like. This is what, you know, meets expectations, exceeds expectations.
This is what that looks like. Getting clear about that, I think would be helpful. Um, I think also, you know, putting, putting the upper levels of, of leadership and management under the same kind of magnifying glass, I think would be tremendously valuable. You know, I think for all of the, for all of the dysfunctions that we talk about for like line managers, you know, for, for engineering managers, for senior managers, I think that same dysfunction, that same lack of clarity, that same lack of what success looks like I think that also exists at the upper levels of the director level at the VP level.
Um, and so I think getting very, very clear about like, what does the director of engineering do? What do I want it to do at my company? And what does success look like? What does failure look like? What do I expect this person to have on their radar? You know, I, I think if you talk to, you know, a hundred different companies, you'd get a hundred different answers to that question.
And I think that's a big part of the problem. Yeah, yeah. Because you know, because if we are bringing in junior managers, they are going to be able to grow without good mentors and coaches and leaders of their own, just, just like engineers. And very frequently. You know, and I've, I've certainly had this experience where, you know, I, I come into a company and I just get nothing from my director.
I just get nothing from my, from my, from my leader who's supposed to be my coach and my boss. And, you know, you can tell that they care and you can tell that their hearts are in the right place and you can tell that they want to do well, but they're just in no way equipped to do so for any, any number of reasons.
So I, I think, you know, getting really clear about that would, would really start to grow the managers that we have, which I think is really important. I think, I think, you know, in tech, I think we do a decent job at. Understanding that growing technical talent is important. Uh, you know, I, I've been in places that, you know, there's Munch Learns for engineering, you know, we, you know, we, we give people budgets to, to, to go to conferences and, and, and things like that.
We, we understand that, You know, always wanting to learn and always pushing the envelope on technical skills is important. And we understand that you have to grow people and you have to develop people for a number of smart reasons. And I don't think that there is an equal level of interest or investment in growing people managers.
And so if the interest isn't there, it's never gonna happen. And if the investment isn't there, it's never going to happen. And so I think Across the industry, I think we need to see like a big increase in, in the interest and enthusiasm and the acknowledgement that this is important as a certain place.
And then also there just needs to be a lot more money and a lot more opportunities and a lot more, you know, just like we send people to conferences and we put them up in hotels and we give them budgets and we encourage them to be speakers and you know, blah, blah, blah, blah. Uh, we have to be doing all of that.
For our, you know, for our leaders as well. And there needs to be, there need to be more conferences. There need to be more like management focused conferences. There need to be more management focused tracks at conferences. Um, so that, and that's, I mean, that's four things. What would a fifth going to be?
I'm trying to, I'm trying to do five. Um, and I think, I think maybe, I mean, this is, this is maybe not as, as well thought out as the other four. Honestly, I also think. just getting really, really clear about what an appropriate level of load is for a manager. You know, like I, I, I've personally been at companies where they have tried to convince me that managing 15 people is appropriate and that I should be able to manage 15 people, do performance reviews, contribute to like organization wide initiatives.
And be working on my own like professional development and always been pushing myself further in a 40 hour week. And that's just so unhinged and disconnected from reality. I can't even.
Lena: Yeah. You
Jay: know what I mean?
Lena: Yeah. I really liked the way you just outlined this because there is a, also I love that you kept yourself to the five because honestly I lost track at some point, um, um, I'm glad you counted.
Um, The, the thread for me, um, that was really interesting was basically I, I took it or would try to summarize it as take it seriously, like take it seriously as a distinct practice and as a field that requires and deserves expertise, because there's also the flip side that like the people in our organizations, they deserve to be treated with expertise to work with people who are good at what they do.
And. Not just, and that's no shade of at any engineers who are thrown into this work, but not just at people who are basically forced to take on that kind of role, because it's the only way for them to earn more money or get a bigger title. Um, and so there is like, take it seriously. Understand or make clear what it actually looks like, what it means, what the expectations are, and then also hold people to a standard, like hold managers accountable, hold your leadership and executive teams accountable.
Um, and, uh, don't just, um, let people fumble around, but like actually treat it as a distinct practice and again, bring some expectations and accountability to it.
Jay: Yeah, I think you summarized it really well, and I think honestly you came up with a better thing, maybe a sixth thing, which is, you know, treat it as a separate skill set and don't force people into that role.
You know, don't have that, that one, that one career progression where at a certain point you have to start picking up direct reports. Uh, and I, I think we do a decent job at that, and I think at this point in my career I've worked for more places. Then, then not, that treat it as a separate discipline. So like, the acknowledgement that it is a separate discipline, I feel like that is the permeating the industry and that that is kind of the way that the wind is blowing.
And that I would be surprised to see like one career ladder instead of two career ladders. You know, I think that has maybe reached critical mass, but I think that's the, again, the bar is the bar is on the floor. That's the absolute most minimum basic thing. Um, so yeah, just, just making sure that people have Pathways to more senior roles that don't involve direct reports. You know, that you can grow technically and you can grow as a manager, but you do not have to, to, to, to do both.
Lena: There are people out there, you know, like you have a similar background to didn't come up in the industry as engineers. Um, what advice do you have for others who are, you know, also grappling with these big questions about sort of how to be in this industry and how to be successful in it?
Jay: That's a really good question. Um, I think, I think I would really. I think I would really push people to like trust in their skill set and trust in their background and, and, you know, uh, I would really encourage people to, to, to view their, you know, their, their, their diverse experience and their non traditional experience as an asset rather than a liability.
And I know that that is very often not mirrored back to them by the industry. Uh, but I really genuinely do think that it's true. Uh, and that the more folks that we have coming up in the, you know, like the leadership and management roles that come from non traditional backgrounds, like if, if diversity is a virtue, which I strongly genuinely believe that it is.
this is important. Like bringing people in from diverse backgrounds who have diverse experiences, who have diverse perspectives is a virtue. And I think over a long enough timeline, I think the industry will reflect that. I just think in, in, in, in the micro sense, as opposed to like the macro sense, I think it can be very hard.
Um, I think, you know, I think really, really develop your network. And I don't mean that in a slimy way. I don't mean that in like a, Uh, you know, attend all the mixers and hand out business cards and treat it as a transaction way. I really don't mean that because I don't think that's very valuable. But I do think that, you know, if you are lucky enough to work with someone who you like, who, who you think is a responsible person, you would trust with a team, stay contacted with that person, like stay in touch with that person.
Um, if you are lucky enough to have a boss. Or a skint level, who you really like to work with, who you respect and who values you. Stay connected to that person and, and really develop a network of like minded folks because, you know, I think we, you know, fundamentally we do work in a very volatile industry and, you know, the chips will be down for you at some point.
And that network, if it doesn't translate directly into another employment opportunity, it will be just immense. value to you as like a safe harbor in a storm and you will have friendly faces who are encouraging you and who will reach out to you. And I think that's, that's tremendously valuable regardless of whether or not, you know, it leads to anything directly.
Lena: I love that. And do you have, since you just alluded also to the whole topic of job search, I know a lot of folks are looking at the moment, like you've fortunately found, um, a company again, you work with, but do you have specific advice when it comes to like looking for, you know, these kinds of jobs that you're describing, um, about, you know, they're good management jobs and good companies to work with?
Jay: Yeah, I, I think they're out there. And they're, you know, they are the exception, which sucks that they're out there. And I think just know, you know, what you can do and what you can't do. And, and don't be afraid to prioritize your job. Search accordingly. Like I, you know, like I, I, you know, walked away from, from interview processes and from companies that I knew weren't a good fit for me.
Um, and. There's no, there's no shame in that. There's nothing bad about it. You're not going to do any harm to your reputation. The CEO of a recruiter reaches out to you, especially if you're new to this industry, it can be really exciting. And you can really start sort of doing your host up at that old, you know, some of these reaching out to me, you know, this is so exciting.
And, you know, if you think it's gonna be a good opportunity, and it looks like it's not, and it looks like it's a good fit, and you know that you are in a good fit for that organization, that organization also isn't a good fit for you. And there really is no shame in just saying like, Hey, this isn't gonna work for me for reasons x, y, and z.
I'd still love to stay connected. Here, here's who I am, here's what I do, here's what value I can bring to your organization. And if you, if you Have something that fits me. Please reach out to me. Like I think that that is a great thing to say and just just keep looking. Um, you know that they're out there and when you see the right opportunity, you'll you'll know it.
And you can run full steam at those opportunities and really trust that like you're throwing your hat into a ring that, you know, like you have a really good shot and that, you know, you can do a very, you know, a very, uh, a very good job at, at sort of selling yourself, uh, for those roles. They're, they're out there.
Uh, they exist. There are companies who share this view of what people managers should do. Uh, they're, if you were in parlor between then I would like, but they exist.
Lena: Love them. Thank you. So, so much.
Jay: You're welcome. Thank you for having me. I appreciate it.
Lena’s thoughts and recommendations
Lena: All of these big, big questions that Jay spoke about have been a topic in the tech industry for a very long time. Think back to 2002 when Google removed engineering managers for a while to show they weren't needed. With pretty bad results. This is also a hot topic where many people have many opinions and many of them strongly held.
I promised I would share mine. So here they are based on my 20 years professional experience in various industries, including tech. I'll talk a bit about what I found leadership roles have in common, what sets them apart, and what that means for which leader is right for which company, as well as what to do if you're a leader and unsure about how to navigate the current changes in our industry and my outlook for the future. I'm going to try and outline a bunch of different aspects to this topic and hopefully bring a bit of nuance to it because I think it's important. Which also means that this is going to take a bit longer. If you'd rather read instead, find all of this on bit.ly/engleadershiproles.
The tech industry especially likes to go into extremes. Think of herd mentality, hype cycles, and pattern matching. That even goes for debates around management roles. For a long time, becoming a manager used to be the only way to make more money and move up the corporate ladder. That's also meant that a lot of people who've been in the industry for a while had managers or became managers that didn't actually really want to do that work for the sake of the work.
In the 2010s, the idea of people management as a separate and distinct career path took a bit more hold. Unfortunately, in some cases, it also really overshot into that direction. And as we mentioned in the episode, there's currently a correction, likely also overcorrection, into the opposite direction again.
As an industry, we really like binary thinking and strong opinions. And those are understandable, they feed the algorithms, but they're also not always helpful for these kinds of conversations. I want to share some truths with you that I found about engineering leadership in my career so far. First of all, It's important to keep in mind that the tech industry doesn't exist.
There are huge differences. And I know I often talk of the tech industry as well, and I'll probably keep doing that for a while, but for the purpose of this conversation, it's important to keep in mind that there are lots of nuances. For example, a distinguishing factor is, "tech" the product of your company, for example, in a software as a service company, or is it much more of an aspect of running your business?
When I worked at a bank in 2005, I spent the first four weeks of my training in the literal filing department. Digitizing and shifting business models was still only in progress back then. Another factor to consider is the funding and goals of the company that result from that. VC funded companies tend to go for big growth, fast exit versus bootstrap companies that have a much steadier and slow growth very often, or even to stay stable.
Then is your company in growth or maintenance or decreased mode makes a difference. What sub-industry is it in? Just one example are health tech companies in Europe, and specifically Germany, that deal with very, very tight regulations around compliance. In contrast, quote unquote platform companies like Uber or Airbnb, where regulations often came in after the fact, if at all.
Then, what type of customer and market segment is your company serving? Is it in B2B, B2C? That's going to make a huge difference. Tech companies are also different by region. A lot of thinking and conversations about the tech industry are very U. S. centric, but there are differences even in the U. S. between, say, Silicon Valley companies and companies in Washington, D. C. that are more government adjacent. And there are, believe it or not, many tech companies outside of the U. S. And then another factor is AI, question mark, question mark. Many companies are getting heavily invested in this right now. And on the flip side, amidst the ongoing hype and speculation, there are still lots of unanswered questions about what it's going to substantially change in our industry.
The second truth about leadership, you don't have to be technical or an engineer to be a terrible manager. Third truth. In the tech industry, a lot of leaders don't have a lot of training in business and how to talk to business people, but that's a foundational part of why those rules even exist.
Management is a business role. Most leadership roles are at least in part a business role as well. Fourth truth. Leadership is a skill set. It's not in titles or roles. Leadership can be learned and leadership is at all levels. Fifth truth. A lot more organizations underestimate the complexity of people issues and overestimate the complexity of technical issues.
A lot of leadership work sounds pretty simple in the books, in theory and in the abstract, but a lot of it is just Good habits and consistency. And for anyone who's ever made the New Year's resolution to go to the gym four times a week or cook healthier dinners every night, you probably know good habits and consistency can be really fricking hard.
I run organizational assessments a lot, and I can tell you a lot of companies struggle with similar issues. Like, having a strategy and goals that are clearly defined and understood by everyone. Everyone also knows how their work relates to those goals and how the success of their work is going to be measured.
Communicating regularly and openly about what's going on in the company. Prioritizing and focusing on the most important things. Also, having fewer than five top priorities. Shockingly hard. Sharing feedback regularly so people can improve. Genuinely listening to that feedback and also following up on it, taking ownership and being accountable for their work, following up and following through on their responsibilities and actually learning from failure and doing better.
Those things that sound quite basic to you, maybe those things are leadership hygiene. They don't sound exactly like innovation, but they are what makes innovation possible. But in order to get there, they take consistent work, time, and thoughtfulness. Doing all of those things consistently, consistently well, and consistently well throughout an entire organization of humans that changes over time.
That is really, really, really hard. I always say that one of the most relieving parts about leadership work is that the issues are the same no matter where you go. And one of the most frustrating parts about leadership work is the issues are the same no matter where you go.
Sixth truth about leadership: Companies are different and the challenges are similar as we've seen so far. That also means what often doesn't work long term sustainably and in a regular business that doesn't just exist to burn money. That's the extremes and the extremes are, for example, leadership roles like a role that is pure people development or pure tech and disconnected from delivery or business results.
What doesn't work either typically are roles that have a very broad scope and context. Those tend to be roles that are a mix of basically everything. Like people management, mentoring, and development, plus technical leadership, strategy, and decisions, plus delivery management with some components of product and project management, plus hands on coding.
Those kinds of very broad roles, like people who are in them tend to do one or two of those things quite well. And the things they do well are often the ones that they have more expertise or interest in, or also the ones where there's more organizational pressure, and they tend to neglect the others. We have a word in German for this, and I promise it's not an insult, even if it sounds this way. Initially, the German word is , but more slowly, AYA literally translates to egg laying wool milk pig. That's a German idiom that describes the ideal of an imaginary hybrid livestock, which combines the advantages of different types of animals.
We use it to describe a person, a thing, or a solution to a problem that on the surface seems to only have advantages, satisfy all needs and all requirements. But exactly because of that, it's not real. If your org has such broad roles that attempt something like the described egg laying bullmilk pig. And if you're in one of those roles, it can be wise to be explicit with your manager about which parts of your role take priority.
Maybe that also changes over time and which ones take more of a backseat. Now, all that said, what makes a good engineering leader? Technical and people leaders who are good at their roles have a lot of skills in common. And I want to share a couple of those. They're great at handling complexity, ambiguity, and nuance. Like you can tell them, Hey, here's a problem, please figure it out. They're great at managing change.
They're also good at holding and sharing the purview of certain context, knowledge or subject matter expertise that can be at the system level, like in technical systems, understanding certain architecture overall in technical systems or on the people and organizational system side, like understanding the organization inter team and cross team dynamics and interfaces between teams.
They're, of course, good communicators. They translate context between levels and functions so that people who are working with them have the context that they need to do their job well and be aligned with the bigger picture and what's going on around them. They're also highly adaptable to changes in business needs, priorities, and people, and often even to changes in their own roles over time. They're great at switching contexts from like different levels, like talking to individual engineers, debugging an issue, and then presenting a proposal to an executive all over the course of a couple hours.
They switch context between topics like people things, technical things, and customer things. As well as different interaction modes, like department presentations, one on one conversations, and a leadership meeting. Great leaders are good at making decisions in the interest of the business, often with limited information.
And they make decisions that are good for the whole of the organization, knowing that those decisions will often also not be what's best for every individual in that organization. They also have a sense of what fires they need to let burn and which ones they need to put out. There's always more to be done than there's time, energy, capacity, and people.
And grade leaders are accountable for results and outcomes of a team, set of teams, department, or organization, and they take that accountability seriously. You may notice that these skills and the resulting roles tend to have a lot of overlap with other roles that have different names, like technical lead, engineering lead or manager, team lead, product manager, and product manager.
This also means that what shape of leadership role is best for your organization will depend on which of these skills you need the most. Say your startup is very small. You have 10, maybe 20 engineers. You probably just need people to be very hands on in programming. If you run a very highly specialized research and development organization, you need a lot of deep knowledge and subject matter expertise.
Say your organization is going through a lot of change, ambiguity and complexity. You probably need people who are great at communicating, coordinating and helping other humans handle those changes. Or if your company is growing fast, you probably need a lot of skills in hiring, onboarding, integrating new team members and building teams that perform well and so forth.
All of this is why I think instead of asking how technical should an engineering manager be, I think we should ask instead. What impact do we need? What problems do we as a company need to solve now? And what problems do we expect to come up in the future? how will we know that this person, this leader is doing well?
My outlook for the future is that I think it's going to stay weird for a while. Many leaders right now are in positions that are at high danger of burnout, especially with very broad roles and very high workloads and a lot of uncertainty to deal with.
I also expect as an industry, we'll see a correction again over the next years.
After all, this is an industry that likes the extremes and is in constant flux. And the amount of change and flux is very high right now. The current setting is hyper focused on efficiency in a lot of companies, but that setting is also not sustainable for a lot of them. As markets change and recover, this will shift again, probably again into some overcorrection territory, or maybe even a less extreme setting.
If you're an engineering leader wondering about what that means for you in the next years, here are my last thoughts on this. I found that in leaders, a broad skill set is helpful, and so is adaptability. It might be really hard right now to figure out what skills you really need to focus on, especially if a part of your role is hands on coding.
Speak with your manager about this. There are some universal leadership skills to get good at, and now is a great time to focus on those. Up level in your leadership skills. Being able to manage ambiguity and complexity will become increasingly important. Get good at business things. Speaking business language will be really helpful in how you frame your work and no matter what exact shape your role takes.
Get good at managing up. There will always be work that you can't do, or you can't do it as well as you like. There will always be very busy bosses, and you will always have to figure out how to get on the same page with them. This is a great skill to have. Get good at talking about the impact of your work, especially if you're in a middle management role where your work and its impact are less directly visible.
Also, find a company that's the right fit for you at this point in time. We'll soon have an episode about how to do that. Lastly, managing in a downturn is draining and many leaders only get very little support right now, but want to give a lot of support to their team members.
Don't let all of this grind you down. Be mindful of your own capacity and limits. Don't overextend yourself and take care of yourself. Connect with other leaders, with your peers, either at your company or outside, and be the leader that you want to see in the world, or at least, you know, become it.
Credits & Production Notes
Leadership Confidential was created, produced, and presented by me, Lena Reinhard.
Our guest's voice was digitally modified.
Theme, original composition, and mixing by Esteban Del Pino.
Production assistance, guest support, and social media by Sly Stark.
Thank you for listening. I'll hear you next time.
