Transcript: Do Engineering Managers Need to Code? Leveling, Calibration & Craft
0:00 Brad Your ideal employee and the employee that's essentially going to run through the ranks are the ones that are essentially pushing the sliders forward on all of these skills.
0:10 Brad And when you're mentoring and coaching employees to grow their career,
0:15 Brad you should really, I think, be looking at the areas where they have room for improvement across that spectrum.
0:27 Scott Welcome to the Two-Headed Robot!
0:29 Scott Don't mess with the ocean,
0:31 Scott it tales in the compass song.
0:37 Scott stories untold.
0:40 Scott Welcome back.
0:41 Brad All right, let's get this thing going,
0:43 Brad Scott.
0:43 Brad Come on.
0:44 Scott Oh, man,
0:45 Scott we've been sitting around all day. We forgot to hit the record button.
0:47 Brad Oh,
0:48 Scott We
0:48 Brad geez.
0:48 Scott just had, we just basically solved.
0:51 Scott all the world's problems for y'all
0:53 Brad Exactly.
0:53 Scott but
0:53 Brad And we just we got
0:54 Scott forgot
0:54 Brad to hit that
0:54 Scott yep
0:54 Brad record.
0:55 Brad Forgot to hit
0:56 Scott so
0:56 Brad that record button.
0:56 Scott all right thanks for joining us everybody don't forget to subscribe rate and smash i'm
0:59 Brad Smash that subscribe button.
1:01 Brad All right. Anyway,
1:01 Brad Scott,
1:02 Brad welcome to another episode of the How Many CTOs Does It Take podcast.
1:06 Brad I'm Brad Hefta-Gaub. Man, you are.
1:09 Scott Scott Porad and it takes more than two that's
1:11 Brad It takes more than two to remember to hit the record button.
1:14 Scott right brad i got a question for you
1:16 Brad Yes, tell me.
1:18 Scott In my company that I'm working at right now, we do twice annual performance reviews.
1:23 Brad Okay.
1:24 Scott The big one happens in the fall starting September 1st, runs for about six weeks, and then we do kind of a smaller one that happens like in April.
1:34 Scott So we're going into the big one.
1:35 Brad Yeah.
1:36 Scott And there's some stuff that my team does really good with reviews.
1:41 Scott And one of the things they do is we have what we call a pre-calibration.
1:46 Brad Yeah.
1:47 Scott And what that means is we have an engineering level competency guide.
1:53 Scott So you can imagine this,
1:55 Scott it's a spreadsheet that has down the left side and each row is a competency that an engineer.
2:04 Scott might need to have they're
2:05 Brad Yeah.
2:05 Scott grouped into some groups and then the columns are the different levels like engineer senior engineer staff engineer etc and as you might imagine as you grow up in the levels the competencies develop and grow and things like that and so we have a process whereby every engineering manager
2:28 Scott for every single engineer gives them a grade on every single competency.
2:34 Scott We're trying to minimize subjectivity.
2:39 Brad Totally.
2:39 Scott And it's not, you know, it's not an ABCD grade.
2:42 Scott I think it's zero through three and zero is not applicable.
2:47 Scott The person hasn't had a chance to do this and three is, you know, they're perfect every time and, you know, everything in between. Right.
2:53 Scott And it's been a really good tool for calibrating so that people are,
2:57 Scott it's been a good tool for discussion between engineering managers for calibrating. It's been a good tool for not being subjective about this person's really good at these things, but not as talented at these things. It gives us something concrete,
3:10 Scott more concrete for actually writing the review,
3:13 Scott it's concrete.
3:13 Scott But there was this conversation that came up the other day
3:16 Brad Hold on
3:16 Scott that,
3:16 Brad a second, Scott.
3:17 Scott oh,
3:17 Brad Hold on a second.
3:17 Scott yeah.
3:17 Brad Before you go too much further down this,
3:18 Brad I just want to make sure that...
3:19 Brad that i'm on the same page with you and that our
3:22 Scott Yep.
3:22 Brad our listeners are on the same page with you so first of all what i'm thinking is this sounds very similar to what i would generically call a leveling guideline document um and it's very similar to what we talked about with ted neward when we were doing that conversation around hiring and things like that he made the point that like you have to like
3:41 Brad Before you can hire,
3:42 Brad you need to know what skills you're hiring for and and
3:45 Scott Yes
3:45 Brad knowing what skills you're hiring for is something that really applies well to performance reviews later.
3:50 Brad So it's like there's this like really important, like before we hire you and then after we hire you, are you doing the job? So one,
3:57 Brad we're talking about the same thing, right?
3:59 Scott Yes, we are.
4:00 Brad Okay,
4:01 Brad and then you started to say that you guys do this thing where you're essentially doing a calibration and that all the engineering managers essentially calibrate all the engineers and then this I assume the reason for this is then you have the ability to go,
4:14 Brad oh,
4:15 Brad it looks like maybe you might get information out of that like, oh, it looks like, you know.
4:22 Brad Janet,
4:23 Brad engineering manager Janet,
4:24 Brad consistently is a harder grader than engineering manager Rahul or something like that.
4:31 Brad Is that or at least then you have a conversation, you have a conversation with the engineering manager to say,
4:37 Brad well,
4:37 Brad on the competency call,
4:38 Brad I translate ideas into code into clear code like this is what we mean by that.
4:44 Brad Is that kind
4:45 Scott Yes.
4:45 Brad of the idea behind this?
4:46 Scott Yes,
4:47 Scott that's exactly right.
4:48 Scott And what happens more often than not, it's less,
4:51 Scott you know, Janet is more rigorous than Jane,
4:54 Scott although that happens a little bit. It's more of,
4:56 Scott well,
4:57 Scott wait a second,
4:58 Scott what does ideas into code mean to you?
5:01 Brad Yeah.
5:01 Scott because you're giving everybody ones on this and this other person is giving everyone threes and you thought well what you thought was well ideas into code means they thought of the idea themselves and they actually ran through the whole process and what i thought it was was they just were good at taking a ticket and turning it into code so that's it turns out what we actually this is our every cycle what we see is we actually refine the language and the leveling guide as a result of the calibration because we find out that it's unclear
5:28 Scott clear to people you know what these words mean words are hard right so something
5:32 Brad Yup.
5:33 Scott like it turns ideas into code is a great one that's a great one to add clarity for like what exactly do you mean by that um so that's more often what happens is that we end up making some adjustments because the group comes together to to a shared understanding of what ideas into code means and then we as we do you know we do this every six months we will you
5:54 Scott revise the language just to clarify what that means.
5:58 Brad That sounds awesome.
5:59 Brad That's great.
6:00 Scott It's
6:00 Brad I will
6:00 Scott pretty good.
6:01 Brad tell you that like, you know, in the organizations I've worked in, you know.
6:08 Brad the once they get to the scale that your organization is
6:10 Scott Yeah,
6:11 Brad at you really have to have that stuff written down somewhere right and you have to have this kind of like structure to it because otherwise it's just going to be like how do you know that random engineering manager or random managers just you know they say somebody's great on their team but like what does great mean like you know and so these
6:28 Scott yeah.
6:28 Brad are these are these are great these are these are very useful tools and I fully support organizations that use those so what's the question
6:35 Scott Well, okay. The question is this. So there's five categories.
6:40 Scott I'm going to read them to you slowly.
6:42 Brad And this is for engineers?
6:43 Scott Software engineers,
6:44 Scott IC engineers.
6:45 Scott Well,
6:45 Scott actually managers,
6:46 Scott directors,
6:47 Scott everybody.
6:48 Scott Probably me.
6:49 Scott Probably my boss does this too.
6:50 Scott These are the five categories.
6:52 Scott Communication and collaboration,
6:55 Scott technical expertise,
6:57 Scott ownership and initiative,
7:00 Scott teamwork and empowerment.
7:02 Scott prioritization and execution.
7:04 Scott So let me just read those again because people listening at home might have not grocked it that fast.
7:09 Scott And these are just in the order that I wrote them down.
7:12 Scott They're not in any priority order.
7:13 Scott In fact, that's what I want to discuss with you is priority.
7:16 Scott Communication and collaboration,
7:18 Scott technical expertise,
7:20 Scott ownership and initiative,
7:23 Scott teamwork and empowerment.
7:25 Scott prioritization and execution.
7:27 Scott Those are the five categories. And within those categories, each of them has like, you know, three to five different competencies.
7:34 Scott Okay,
7:35 Scott so here's the question.
7:37 Scott We were having this conversation the other day about our engineering management team. So overall, we've got about 15 managers or so.
7:44 Scott And the question came up about
7:51 Scott How much technical expertise do we expect an engineering manager to have?
7:57 Scott Let's
7:58 Brad Yeah.
7:58 Scott set that question aside for just one quick second.
8:01 Scott That morphed into,
8:03 Scott well,
8:04 Scott should these be weighted?
8:06 Scott Right.
8:07 Scott Is there one of the are these all equal or are there some of these that are worth more than the others? Because, for instance,
8:13 Scott for an individual engineer,
8:15 Scott let's say a regular junior kind of entry level engineer,
8:20 Scott you would weight technical expertise higher and prior prioritization lower because they're not really doing the prioritization. I don't know. I'm just making that example up. But you can imagine how.
8:33 Scott different levels of the organization might have different weights on what's important certainly like you want your staff engineers and your architect staff very high technical expertise right but you also want them to be good communicators and you also want them to take ownership and and
8:49 Brad I'm having reactions.
8:50 Scott you also want them to and you want to have them play nicely with others and you want them to be good at prioritizing so like we got into this conversation about you
8:59 Scott should we wait these or not and then it became like well god they're all important and you can you can you can make a case that every single one of them is the most important one and so
9:11 Brad Yeah.
9:11 Scott that's the question that's the question
9:12 Brad Okay,
9:12 Scott I wanted to ask
9:13 Brad so,
9:13 Scott you is
9:13 Brad yeah.
9:13 Scott like well what do you think about that what do you think about waiting them do you think there should be a waiting etc etc
9:21 Brad First of all, I love this question.
9:22 Brad I love this whole topic.
9:25 Brad It is so funny because literally on LinkedIn today,
9:30 Brad I just noticed this like notification from Greg Conklin,
9:34 Brad you know, somebody who was on our pod a while back where he basically commented on an on a.
9:43 Brad posts that i'd made on linkedin where we where you and i had talked about um engineering managers and the whole notion of like engineering managers as like people managers or this notion of like you know um autonomous teams without engineering manager you remember that we talked about that uh
9:58 Scott Yeah, there's
9:59 Brad a couple
9:59 Scott an article
9:59 Brad episodes
9:59 Scott that
9:59 Brad ago yeah exactly and
10:04 Brad Anyway, so he commented that he had listened to that episode and was like,
10:08 Brad oh, man,
10:08 Brad such a great episode. I loved it.
10:10 Brad And, you know, I agree with so many things that you and Scott had to say about that.
10:14 Brad OK,
10:15 Brad so the reason I think that's interesting is.
10:20 Brad I think that was the essence of that conversation. Now, we were specifically talking about engineering managers,
10:24 Brad but if you recall,
10:25 Brad a big piece of that conversation that we had was the importance,
10:29 Brad why it's so important that you both have technical expertise and you have all those people skills of communication,
10:35 Brad collaboration,
10:36 Brad ownership and initiative,
10:37 Brad teamwork and empowerment,
10:38 Brad right?
10:39 Brad Like these are so important for.
10:41 Brad engineering matters but they're all important and if you if you take any of them away like it doesn't stand up on its own and i would make that case in
10:59 Brad general for
11:03 Brad even for engineering job for individual IC jobs where these things are very important and so you mentioned staff engineer right like I I think that a staff engineer that is incredibly uh it's incredible technical expert in some you know uh security or in LLMs or in whatever
11:28 Brad who struggles at communication and collaboration they're probably not going
11:35 Scott Mm-hmm.
11:35 Brad to excel to
11:37 Scott Mm-hmm.
11:37 Brad the staff level and so my
11:44 Brad instinct i'm going to get to your question your question is should you
11:48 Brad rank these things or
11:49 Scott Mm
11:50 Brad do you
11:50 Scott -hmm
11:50 Brad do you put weights on these things and are there some roles where there are different values that you would weight these things and my answer is i absolutely do not think you should weight these things i think that that in the in the leveling guidelines that i've seen in the organizations that i felt do the best with their leveling guidelines they they
12:15 Brad list all the leveling guidelines and they they leave ambiguity a little bit of ambiguity in these guidelines right now we just talked about calibration and things like that make sure everybody knows what the words mean that's like super important but um
12:37 Brad Your ideal employee and the employee that's essentially going to run through the ranks, go from level one to level two, level three, level four,
12:44 Brad whatever,
12:44 Brad those employees are the ones that are essentially pushing the sliders forward
12:50 Scott Mm
12:50 Brad on
12:50 Scott -hmm.
12:50 Brad all of these skills,
12:52 Brad right?
12:54 Brad And when you're mentoring and coaching employees to grow their career,
12:58 Brad you should really, I think, be looking at the areas where they have room for improvement.
13:05 Brad across that spectrum and they should and you should try to find ways for them to grow and strengthen
13:10 Scott Yep.
13:10 Brad all of those skills um and so i feel like if you do some kind of a waiting thing you kind of just open the door to more whataboutism
13:24 Brad Right.
13:25 Brad And the answer is they're all important.
13:27 Brad Like you said it, you can make a case that everything,
13:30 Brad every one of them is the most important thing. And that's because they're
13:33 Scott That's
13:33 Brad all important.
13:33 Scott right.
13:34 Brad I don't know. So that's, that's my quick hot take.
13:38 Scott Yeah,
13:38 Scott I think that's kind of where I'm at.
13:41 Scott Because as soon as I started fiddling with like,
13:44 Scott you know, I had a piece of paper, I made them all 20%. And I said, well, let's just because there's five sections. So I made them all 20%. Then I was like, well,
13:51 Scott let's just try fiddling with the numbers here and see what that feels like.
13:54 Scott And I didn't know where to take from.
13:59 Scott Right?
14:00 Brad Yeah.
14:01 Scott I didn't know where to take from.
14:03 Brad But didn't you tell me there was like a, this is again more of a hiring thing,
14:09 Brad but didn't you tell me like you'd worked at an organization before that did a, you know, you had a similar rubric
14:14 Scott Yeah,
14:14 Brad where you're scoring applicants
14:15 Scott yeah
14:15 Brad on a set of requirements and then you had like a, you know, a single point that the reviewer was able to just.
14:24 Brad throw in you know yep
14:25 Scott reviewer's
14:25 Brad right
14:25 Scott choice
14:25 Brad reviewers
14:25 Scott that
14:26 Brad choice
14:27 Scott was that
14:27 Brad i'm gonna give him a point
14:27 Scott was for resume screening um but and it worked it was you know it was like a 10-point checklist and basically we said look you know somebody who gets more than seven gets an interview and if you don't get more than seven you know seven seven or more you we take you for an interview seven or less we don't or six or less we don't and one of the points was reviewer's choice and because they just saw something about your resume
14:50 Scott They liked.
14:52 Brad And I think that that I think that that concept of what you did there now, admittedly, it's different than reviews and different than calibration.
14:59 Brad But but I feel like what you were getting at at that reviewer's choice or that reader's choice there is this fact that like as much as we want to try to make these things objective and measurable.
15:14 Brad We are still dealing with people and we
15:17 Scott Yeah.
15:18 Brad should have some tolerance for subjectivity.
15:24 Scott Yes,
15:24 Scott we should.
15:26 Scott It's an interesting part of our sort of corporate world that we want to have things be so objective.
15:38 Scott I don't mean to get political,
15:39 Scott but I think it like I think it comes from a point of litigiousness that's out there potentially.
15:46 Scott So,
15:47 Scott OK,
15:47 Scott this is raised in a totally different topic.
15:50 Scott I was having lunch today with a former co-worker who was a business guy. He's not he's not an engineer.
15:56 Scott He was he was on the business side of things.
15:58 Scott And we were chatting about this, that the other thing.
16:01 Scott And he asked me an interesting question. He said.
16:05 Scott You know, what's your framework for thinking about how to, you know, put engineering effort towards the things that are hard to quantify?
16:13 Scott Because we were talking about our company,
16:15 Scott you know, some companies just aren't good at that. If you can't put a number on it, it's like, we're not going to do it.
16:22 Scott But sometimes, you know, and there's categories and things I'm sure in every department that are really hard to measure.
16:28 Scott And I have a response to that question, but I guess I'll share it with you and I'd love to know your take on it. So I said,
16:34 Scott well,
16:35 Scott here's how I think about it. That's what I said.
16:37 Scott I said, I think it's a three prong strategy.
16:43 Scott Part number one is.
16:46 Scott And we were specifically talking about tech debt.
16:48 Scott I always talk about how do you invest in tech debt? How do you invest in the platform in ways that aren't directly attributable to some revenue, Scott?
16:56 Scott What's your thinking on that?
16:57 Scott And I said, I think about three parts. One is, well, if there's a business initiative that platform needs to change, then obviously you do it. The second is.
17:11 Scott You create a culture with your teams where if they see an opportunity that isn't going to dramatically increase the scope of a project,
17:21 Scott let's say.
17:23 Scott adds no more than 10 or 20 percent of effort to it go for it right this just happened on our team a couple of weeks ago um a team posted hey we shipped this thing and while we were doing it we also cleaned up all this duplicate code and instead of having five ways that prices are presented on our site we now have one module for presenting prices you know and i was i just think that's great you know they just they did a little bit of effort nobody asked them to um and i think that's great and i think you create a culture that
17:50 Scott allows for that and encourages it and then the third piece is i think you just have to ring fence or allocate some sort of some level of resources it could be a person it could be some amount of time to say look we're just this comes back to the subjectivity point we're going to invest in some stuff that we can't put a number on but based on all of our collective wisdom and experience we just think it's a good
18:17 Scott thing for us to be doing um
18:19 Brad Yeah.
18:19 Scott what do you think of that think i was missing any parts or would you approach it any differently
18:24 Brad I mean,
18:24 Brad I like your answer there.
18:28 Brad You know, it does kind of, it also harkens back to that conversation that we had with Greg Conklin a couple months ago where we talked about the whole issue of like, you know, when you have a retrospective or you have some incident and then you get like a backlog of stuff,
18:42 Scott Mm
18:42 Brad you know,
18:42 Scott -hmm.
18:42 Brad and there's that whole question of like how much do you invest in tech debt,
18:46 Brad you know, and he kind of made the point, which I sort of feel like you're making here,
18:52 Brad that.
18:55 Brad you kind of you you know it when you see it you know if it's if it's actually adding value when
19:02 Scott Mm
19:03 Brad when
19:03 Scott -hmm.
19:03 Brad you when you see it right like there's some there's some engineers and I am and by the way not to try to steer the conversation necessarily back to leveling guidelines but
19:13 Brad That's a great example where it would be really hard to write down in, I mean, you could definitely take a shot at like describing like the idea of, you know, as an engineer, I am good at identifying opportunities for improvement that add genuine business value,
19:35 Brad right?
19:36 Scott Yeah.
19:38 Brad You could try to describe that,
19:40 Brad right?
19:41 Brad But it's definitely going to have a very, it's going to have a kind of subjective feel to it, right?
19:49 Brad Because
19:49 Scott Yes,
19:50 Brad business value,
19:50 Scott I
19:51 Brad business value is such a broad concept,
19:54 Brad right?
19:54 Scott know.
19:54 Brad That's what your business friend was basically asking you, like, how do you get your hands on this thing?
19:59 Brad He's got a CTO at his company that's saying we should invest in fixing this tech debt.
20:03 Brad And he's like,
20:04 Brad how do I, I'm a businessman, how do I think about that?
20:07 Scott Right.
20:07 Brad They want money
20:08 Scott Right.
20:08 Brad and they say they can't tell me what I'm going to get back for it. The way I work is I give people money and then they give me back more money.
20:15 Scott I love it.
20:17 Scott Business,
20:18 Scott I give people money, they give me more money. That's the idea of business.
20:23 Scott And, you know, we've talked about that on so many occasions and okay,
20:27 Scott so now again,
20:28 Scott like, you know, not to get back to your leveling conversation,
20:30 Scott but that's a super important skill for the engineer to be able to, you know, sort of have that business acumen to understand the value of something to be able to then
20:43 Scott understand how to implement it that's technical expertise prioritization and execution right like making a really subject you know making a really uh thoughtful and uh professional assessment to say i believe this is a priority right
21:01 Brad Hmm.
21:01 Scott like
21:05 Scott And I and, you know, I would say like a great example of this is like for a junior engineer,
21:09 Scott like, yeah, I want them to be able to prioritize between.
21:14 Scott which task are they going to you know which part of the task do they take on first right they're not making decisions about priorities for the team but
21:21 Brad Mm-hmm.
21:22 Scott they're certainly making decisions about priorities for the work that they do right
21:26 Brad Yeah.
21:26 Scott and so a good example of this is like um i finished my task but i didn't implement my unit test or i or i did implement unit test but i've spent uh
21:39 Scott you know five times more time working on my unit test and I added all these these extra cases that were redundant like that's poor prioritization and that's the kind of thing that we want to be able to somehow capture that even as a junior engineer you should know how to prioritize your own work right
21:56 Brad Yeah,
21:57 Scott right
21:57 Brad and I think something we want to teach our teams,
22:00 Brad I'm going to use the phrase professional judgment.
22:04 Brad Right.
22:04 Scott Yeah, I like
22:05 Brad Somebody,
22:05 Scott that.
22:05 Brad I just told you about this team that like consolidated our pricing module,
22:09 Brad right?
22:09 Brad Because I guess there were a bunch of them and they made one.
22:13 Brad And when any of my team was listening to this, I'm not 100% sure it was like a pricing module.
22:19 Brad I can't remember what it was.
22:20 Brad So don't get upset with me if I'm remembering the wrong thing. I'm just giving that phrase for illustrative purposes.
22:27 Brad Somebody had the professional judgment to say.
22:31 Brad Yeah, it's worth it to tack on this extra time to fix this, right?
22:35 Brad And there
22:39 Brad was the engineering manager who had the professional judgment to allow it. There was the engineer who had the judgment to advocate for it.
22:48 Brad I actually was talking to that engineering manager because I said to her,
22:52 Brad how did this come about?
22:56 Brad So I'm curious to know, what is it that, I think this is a really good thing. I think we want more of this in our organization.
23:03 Brad How did this come to be?
23:05 Brad And she said, you know, I always just say to my team,
23:09 Brad they're never going to give it, there's never going to be tech debt summer.
23:12 Brad There's never going to be some point where the business says to us,
23:17 Brad you know, why don't you guys just take the summer and fix everything.
23:20 Scott Right.
23:20 Brad And even if they did.
23:23 Brad I added to what she said.
23:24 Brad Even if they did,
23:25 Brad I said, we're not going to fix it all in a summer.
23:28 Scott Right.
23:29 Brad So you have to create a culture where it's more like looking for the right opportunities. And sometimes you find those opportunities.
23:36 Brad In fact, I was just talking to another engineering manager today who someone on his team found that opportunity and we were discussing it, but it was just too big.
23:46 Brad Right.
23:48 Brad You know, the engineer thought the project they were working on was an eight-week project for three people.
23:56 Brad And they thought they could, like, do this whole refactoring in the same amount of time.
23:59 Brad And the engineering manager was like,
24:00 Brad I don't know.
24:02 Brad That just seems too
24:05 Brad optimistic to me, right?
24:07 Scott Yeah
24:08 Brad I think he's probably going to go back to that person and say, let's not do this one right now,
24:11 Brad right?
24:12 Brad Let's find a different way to fit this one in because we're going to take this eight-week project and turn it into 32 weeks and everyone's going to be upset with us.
24:19 Scott So by the way, so I have a couple of strong reactions to that.
24:23 Scott Love that story.
24:24 Scott I think that's a great example of these hard to quantify.
24:32 Scott But really important skills that we want to somehow document in our expectations for our team members.
24:40 Brad Mm-hmm.
24:44 Scott And I think that's a good example that that story is a good example where that engineering manager had to have a sense of business acumen to be able to judge the trade offs of the of the of the cost.
24:55 Scott They also had to have technical.
24:58 Scott expertise in understanding the complexity of the code,
25:02 Scott right?
25:04 Scott And so that decision that that engineering manager advocated for,
25:10 Scott and then they're going to have to go have communication and collaboration skills to sell it back to the engineer,
25:15 Scott right?
25:15 Scott So it's a great example where it's like all like that simple thing that is an easy example of an everyday occurrence that a team is going to be confronted with.
25:27 Scott plays on all of these different skills.
25:30 Scott And if you've got a big gap in any of those categories of skills,
25:34 Scott it's much harder to be a high performance team.
25:41 Brad And there's one other puzzle piece you didn't mention.
25:44 Brad I'm not sure where it fits in this framework,
25:45 Brad but it fits into that decision making,
25:47 Brad which is.
25:49 Brad As engineering leaders and engineering managers,
25:51 Brad we spend a lot of effort to build trust with our stakeholders.
25:56 Brad And what happens when you blow up the time, when you take on one of these things that you think might only take a little bit of time, but ends up really blowing up your project,
26:08 Brad you end up.
26:10 Brad just eroding so much of that trust that gives you the freedom to do those things in the first place right
26:15 Scott Yeah,
26:15 Brad and
26:16 Scott for
26:16 Brad so you want to have a high high level of confidence that you're not going to just cut your nose off to spite your face
26:24 Scott 100% agree with that.
26:26 Scott And this makes me want to mention something really important to our listeners.
26:34 Scott We're talking about leveling guidelines.
26:37 Scott Dropbox has an open source engineering career framework,
26:43 Scott and
26:43 Brad Yes.
26:44 Scott I think it's one of the better ones out there.
26:48 Scott And one of the things that I think is so interesting about it is it doesn't use the exact categories that you have. They have their own versions of it. Right.
26:55 Scott But, you know, they have like they have section like I'm just looking at it now. They've got stuff like, you know, the core responsibilities they enumerate, but they have like these sections on like talent and culture and craft.
27:10 Scott That's this word they use craft and craft is where they kind of state
27:14 Brad Mm
27:14 Scott the
27:14 Brad -hmm.
27:14 Scott job specific.
27:16 Scott things that you expect.
27:18 Scott And one of the things I think is really interesting is in the craft of an individual contributor software engineer and in the craft of an engineering manager,
27:28 Scott there is an overlap there.
27:34 Scott And you see that evolution of that overlap as you become a more senior individual contributor,
27:41 Scott your craft
27:42 Brad Yeah.
27:42 Scott expectations includes business acumen and strategy.
27:48 Scott And as an engineering manager,
27:50 Scott even in the lower levels of an engineering manager,
27:53 Scott you've got this expectation around a set of business acumen and strategy. And as you grow in these levels, you have greater and greater expectations of your level of proficiency and the fluidity of the craft of.
28:14 Scott whatever that skill set might be and that to me is the answer to the question of how do you weight these things is you got to kind of put out put them out there in this blended craft and as you advance in your career we're going to expect more of you but they're always kind of there they're all part of even the IC
28:39 Brad they're all there for sure yeah there's always a balance of them you're always trying to balance you know these these what's the technology it's like it's like juggling honestly you've got two ends and you've got five balls and you're just trying to keep them none of them you don't want any of them to fall on the ground so you're always kind of just you're just tossing
29:02 Scott Yep.
29:02 Brad them up and down balancing them so on and so forth it's never
29:06 Brad static and i don't think i mean i'm not a real good juggler i have juggled i've learned to juggle when i was like 10 years old i learned i got a book called juggling for klutzes and learned to juggle and um yeah when you're juggling you're never you're never in a stable position right you're always kind of
29:26 Brad doing it okay so let's go back to one other thing really quickly i brought this up earlier in the conversation and we should just make sure we check it off so that we're not leaving all of our listeners waiting
29:36 Scott Yeah.
29:36 Brad just supported that we did not answer the question about how technical we think engineering managers should be and the question often comes up is should engineering managers code should they be coding
29:53 Brad I have an opinion on that.
29:54 Brad You want me to go or you want to share yours first?
29:57 Scott You shoot first.
29:58 Scott I love it.
30:00 Brad My point of view is a little nuanced.
30:04 Brad I feel like an engineering manager actually needs to be able to do two things.
30:09 Brad They need to be able to design and they need to be able to validate that what their team is building is correct.
30:20 Brad Now, in order to design,
30:21 Brad you have to know the system that you're working on.
30:24 Brad And in order to know if what's being built is correct,
30:28 Brad you have to know something about software.
30:30 Brad And so I don't necessarily know or even think it's actually that all that valuable for a manager to be in there.
30:39 Brad on the frontline coding although my first manager job i was a player coach probably my first two or three i was coding all the time i loved it and the best way to understand the system and the best way to know if it's being built right is to also be in there yourself a little bit so i don't think i think coding or not coding is the wrong thing to evaluate a manager on i think to evaluate is is the design are their technical designs good and is there stuff
31:04 Brad stuff being built correctly and the easiest way for a manager to be able to accomplish that is to just you know be in the trenches a little bit
31:12 Scott So wait,
31:14 Scott so what's your answer?
31:16 Brad my answer is it's not necessary but it is an effective way to do a part of your job well
31:21 Scott Yeah.
31:23 Scott Okay,
31:24 Scott well.
31:26 Scott I, you're probably not going to get an argument from me on this,
31:29 Brad Oh, rats.
31:29 Scott but, but, but I'm willing to play a little devil's advocate here and I can tell you, let me, I mean, I'll give you my, my straight up opinion about it. So one, my first job as manager,
31:40 Scott I was a player coach,
31:41 Scott just like you,
31:42 Scott I was writing code and managing the team.
31:44 Scott I mean, right now in, you know, in my current projects that I'm working on now, I'm a player coach. I like write code, you know, I spent most of this week.
31:52 Scott week fixing some pretty gnarly bugs and all and that didn't take away and doesn't take away from my ability to lead and manage the team as well other than the time aspect of it and so i think that um
32:07 Scott And then there were other times in my career and I've worked in other organizations where the engineering managers had the technical expertise that you articulated, the idea that you're able to truly evaluate the work of your engineers, you're able to really guide them, you're able to evaluate designs,
32:22 Scott that requires a great deal of technical strength.
32:25 Scott And if you have that and you have that awareness of the system.
32:29 Scott but you're not coding you're doing code maybe you're doing code reviews maybe you're just looking at the code maybe you're you're not even doing the hands-on code review but you're you're observing the code reviews and you're observing the design document um then that's that can be enough to keep that axe sharp and be able to do the the technical thing so i so i feel pretty strongly that it's not a it shouldn't be forbidden
32:56 Scott And it shouldn't necessarily be required.
32:58 Scott I think it's situational based on the team,
33:02 Scott the enterprise,
33:02 Scott and the stage of the development of the software.
33:05 Brad Yeah, that's right.
33:06 Brad That's exactly right.
33:07 Scott Now, to play devil's advocate,
33:09 Scott one of the things that I have seen happen, and I've heard horror stories of this happening,
33:18 Scott is the...
33:21 Scott engineering manager particularly if they were like you know hot shot individual contributor who then flipped into management and we didn't give them good coaching or growth or or kind of like
33:38 Scott each opportunity to to learn how to be a to do those other parts the the collaboration and the communication and the empowerment you know all the things that we talked about in that other episode of what's so important about creating psychological safety so if if if they like just kind of went from like hot shot engineer to now i'm the boss of a bunch of engineers and they're kind of leaning into coding because that's like they can't get their team to perform so they're writing
34:05 Scott writing the code themselves right that to me is a is a very clear signal that we have somebody that's not that needs some coaching on how to be a better engineering manager and so that that when i have heard people say well we shouldn't have engineering managers coding it almost always has been a case of actual toxicity
34:29 Scott or fear of toxicity around that type of a dynamic.
34:33 Brad Yeah. And the same goes with code reviews.
34:35 Brad Actually, I'm a little bit opposed to managers doing the code reviews.
34:40 Brad I'm not strictly opposed to it, but in general,
34:43 Brad I think it should be pure code reviews.
34:45 Brad Now,
34:45 Brad if a manager is in the cycle of people doing it maybe from time to time, they review something,
34:50 Brad but if everything has to be reviewed by the manager,
34:52 Brad then you're just building a disempowered.
34:55 Scott Yeah, not only are you disempowering your team, but you're not growing them too.
35:01 Scott One of the best ways to become a better developer yourself is to read a lot of code by other developers.
35:09 Brad Well,
35:09 Brad as we've talked about, and we are now 30 minutes into this episode before AI has come up.
35:18 Brad As we've talked about,
35:20 Brad in an AI world,
35:21 Brad code review is more and more important.
35:26 Brad I think in fact, you
35:26 Scott Yep.
35:27 Brad just tagged me on LinkedIn recently about somebody saying, if you're using this AI,
35:31 Brad you've got to be able to know what it's doing.
35:32 Brad You can't just take it and stick it out there.
35:35 Brad And some people,
35:36 Brad some engineers saying,
35:37 Brad I don't like that.
35:39 Brad And what I mean by I don't like it is it's not fun to just, I like to write the code and create the thing.
35:44 Brad Just reviewing other people's work is not that fun.
35:48 Brad But then as we also talked about in some previous episode.
35:52 Brad code uh there is some evidence that ai is actually better at reviewing code than it is at writing code if
35:59 Scott Yeah.
36:00 Brad we get the robots to review our code we can just be work for the robots
36:04 Scott I think that like what I heard you say,
36:07 Scott which does resonate with me, is, well,
36:13 Scott I mean.
36:14 Scott I just going to go back to the whole concept of like should engineering managers code and my answer to that question is it
36:24 Scott totally depends and so long as it doesn't get in the way of all the other important things we think that they should be doing and if it's a supplement it's a supplement to creating that technical expertise and that and that guidance in that environment I don't see anything wrong with it
36:40 Scott If it's getting in the way of that empowerment,
36:43 Scott whatever,
36:44 Scott then of course they shouldn't.
36:48 Brad Yeah.
36:48 Brad Yes, you use the word supplement. I would use the word tool if it's a method for you to understand the system because you need to understand it,
36:57 Brad then go for it.
36:59 Scott Yeah,
37:00 Scott totally.
37:02 Scott Yeah.
37:03 Brad All right.
37:04 Brad So we've solved all the world's problems today.
37:07 Scott I
37:07 Brad We
37:07 Scott think we've
37:07 Brad solved
37:07 Scott solved
37:07 Brad all
37:08 Scott all the world's problems.
37:09 Brad decided that we're in agreement that we shouldn't wait these factors,
37:14 Brad basically. You need to have all of them in equal
37:17 Scott I
37:17 Brad proportion.
37:17 Scott feel pretty strongly that you don't. I feel strongly that you don't want to wait them.
37:20 Brad I think that's right.
37:21 Scott Waiting them only turns it into a game and gamification.
37:29 Scott And it doesn't really convey what matters about them, which is that there's robustness of this kind of whole constellation of skills and craft that we expect.
37:43 Scott That's what matters.
37:44 Brad It's a fabric.
37:45 Scott It's a fabric.
37:46 Scott Yeah, I like that.
37:49 Brad All right.
37:50 Brad Well, with that, Brad,
37:51 Brad until
37:51 Scott Another episode.
37:52 Brad next week in
37:53 Scott Until next week.
37:54 Brad the books.
37:55 Scott In the books.
37:57 Brad All right, everybody,
37:58 Brad don't forget to give us a five-star rating.
38:00 Brad We would love that.
38:02 Brad We are currently the number one ranked podcast in the category on Apple Podcasts for podcasts about CTOs.
38:12 Scott I didn't know that.
38:13 Brad Did you even know that they have?
38:15 Brad No, I made that up. They don't even have that category.
38:17 Brad But if they did have that category and we had a lot of five-star reviews,
38:21 Brad we would be number one.
38:23 Brad Thank
38:23 Scott Yeah.
38:23 Brad you very much, everybody, for giving us a review.
38:26 Brad And Brad,
38:27 Brad I'll talk to you next week.
38:28 Scott Talk to you next week, Scott.
38:29 Brad All right.
38:30 Scott This episode of How Many CTOs Does It Take podcast was edited by Saffron Epigav. Our theme song was AI Generated by Brad.
38:38 Scott Please follow us on all the social media platforms at at HowManyCTOsPod.
38:44 Scott You can find us on YouTube,
38:46 Scott LinkedIn,
38:46 Scott Instagram,
38:47 Scott Facebook,
38:47 Scott Threads, X,
38:48 Scott TikTok,
38:49 Scott and Patreon, or at our website at HowManyCTOsPod.com.
38:55 Scott And remember to rate, review,
38:57 Scott and subscribe on the podcast platform of your choice.
39:01 Scott Thanks for listening.