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. And when you're mentoring and coaching employees to grow their career, 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! Don't mess with the ocean, it tales in the compass song. stories untold. Welcome back.
0:41 Brad All right, let's get this thing going, Scott. Come on.
0:44 Scott Oh, man, 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. 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. 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. All right. Anyway, Scott, welcome to another episode of the How Many CTOs Does It Take podcast. 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. 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. 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. So you can imagine this, it's a spreadsheet that has down the left side and each row is a competency that an engineer. 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 for every single engineer gives them a grade on every single competency. 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. I think it's zero through three and zero is not applicable. 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. And it's been a really good tool for calibrating so that people are, 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, more concrete for actually writing the review, it's concrete. 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, I just want to make sure that... 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 Before you can hire, 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. 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, we're talking about the same thing, right?
3:59 Scott Yes, we are.
4:00 Brad Okay, 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, oh, it looks like maybe you might get information out of that like, oh, it looks like, you know. Janet, engineering manager Janet, consistently is a harder grader than engineering manager Rahul or something like that. Is that or at least then you have a conversation, you have a conversation with the engineering manager to say, well, on the competency call, I translate ideas into code into clear code like this is what we mean by that. Is that kind
4:45 Scott Yes.
4:45 Brad of the idea behind this?
4:46 Scott Yes, that's exactly right. And what happens more often than not, it's less, you know, Janet is more rigorous than Jane, although that happens a little bit. It's more of, well, wait a second, 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 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 revise the language just to clarify what that means.
5:58 Brad That sounds awesome. 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. 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. I'm going to read them to you slowly.
6:42 Brad And this is for engineers?
6:43 Scott Software engineers, IC engineers. Well, actually managers, directors, everybody. Probably me. Probably my boss does this too. These are the five categories. Communication and collaboration, technical expertise, ownership and initiative, teamwork and empowerment. prioritization and execution. So let me just read those again because people listening at home might have not grocked it that fast. And these are just in the order that I wrote them down. They're not in any priority order. In fact, that's what I want to discuss with you is priority. Communication and collaboration, technical expertise, ownership and initiative, teamwork and empowerment. prioritization and execution. 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, so here's the question. We were having this conversation the other day about our engineering management team. So overall, we've got about 15 managers or so. And the question came up about How much technical expertise do we expect an engineering manager to have? Let's
7:58 Brad Yeah.
7:58 Scott set that question aside for just one quick second. That morphed into, well, should these be weighted? Right. 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, for an individual engineer, let's say a regular junior kind of entry level engineer, 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. 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 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. I love this whole topic. It is so funny because literally on LinkedIn today, I just noticed this like notification from Greg Conklin, you know, somebody who was on our pod a while back where he basically commented on an on a. 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 Anyway, so he commented that he had listened to that episode and was like, oh, man, such a great episode. I loved it. And, you know, I agree with so many things that you and Scott had to say about that. OK, so the reason I think that's interesting is. I think that was the essence of that conversation. Now, we were specifically talking about engineering managers, but if you recall, a big piece of that conversation that we had was the importance, why it's so important that you both have technical expertise and you have all those people skills of communication, collaboration, ownership and initiative, teamwork and empowerment, right? Like these are so important for. 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 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 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 instinct i'm going to get to your question your question is should you 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 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, whatever, 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, right? And when you're mentoring and coaching employees to grow their career, you should really, I think, be looking at the areas where they have room for improvement. 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 Right. And the answer is they're all important. Like you said it, you can make a case that everything, 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, I think that's kind of where I'm at. Because as soon as I started fiddling with like, 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, let's just try fiddling with the numbers here and see what that feels like. And I didn't know where to take from. 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, 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. 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 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. 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. 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, we should. It's an interesting part of our sort of corporate world that we want to have things be so objective. I don't mean to get political, but I think it like I think it comes from a point of litigiousness that's out there potentially. So, OK, this is raised in a totally different topic. I was having lunch today with a former co-worker who was a business guy. He's not he's not an engineer. He was he was on the business side of things. And we were chatting about this, that the other thing. And he asked me an interesting question. He said. 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, 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. But sometimes, you know, and there's categories and things I'm sure in every department that are really hard to measure. 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, well, here's how I think about it. That's what I said. I said, I think it's a three prong strategy. Part number one is. And we were specifically talking about tech debt. 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? What's your thinking on that? 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, let's say. 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 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, I like your answer there. 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, you know, and he kind of made the point, which I sort of feel like you're making here, that. 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 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, right?
19:36 Scott Yeah.
19:38 Brad You could try to describe that, right? But it's definitely going to have a very, it's going to have a kind of subjective feel to it, right? Because
19:49 Scott Yes,
19:50 Brad business value,
19:50 Scott I
19:51 Brad business value is such a broad concept, 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? He's got a CTO at his company that's saying we should invest in fixing this tech debt. And he's like, 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. Business, I give people money, they give me more money. That's the idea of business. And, you know, we've talked about that on so many occasions and okay, so now again, like, you know, not to get back to your leveling conversation, 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 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 And I and, you know, I would say like a great example of this is like for a junior engineer, like, yeah, I want them to be able to prioritize between. 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 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, I'm going to use the phrase professional judgment. 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, right? Because I guess there were a bunch of them and they made one. And when any of my team was listening to this, I'm not 100% sure it was like a pricing module. I can't remember what it was. So don't get upset with me if I'm remembering the wrong thing. I'm just giving that phrase for illustrative purposes. Somebody had the professional judgment to say. Yeah, it's worth it to tack on this extra time to fix this, right? And there was the engineering manager who had the professional judgment to allow it. There was the engineer who had the judgment to advocate for it. I actually was talking to that engineering manager because I said to her,
22:52 Brad how did this come about? 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. How did this come to be? And she said, you know, I always just say to my team, they're never going to give it, there's never going to be tech debt summer. There's never going to be some point where the business says to us, 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. I added to what she said. Even if they did, 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. 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. Right. You know, the engineer thought the project they were working on was an eight-week project for three people. And they thought they could, like, do this whole refactoring in the same amount of time. And the engineering manager was like, I don't know. That just seems too 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, right? 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. Love that story. I think that's a great example of these hard to quantify. 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. They also had to have technical. expertise in understanding the complexity of the code, right? And so that decision that that engineering manager advocated for, and then they're going to have to go have communication and collaboration skills to sell it back to the engineer, right? 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. 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, it's much harder to be a high performance team.
25:41 Brad And there's one other puzzle piece you didn't mention. I'm not sure where it fits in this framework, but it fits into that decision making, which is. As engineering leaders and engineering managers, we spend a lot of effort to build trust with our stakeholders. 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, you end up. 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. And this makes me want to mention something really important to our listeners. We're talking about leveling guidelines. Dropbox has an open source engineering career framework, and
26:43 Brad Yes.
26:44 Scott I think it's one of the better ones out there. 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. 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. 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. things that you expect. 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, there is an overlap there. And you see that evolution of that overlap as you become a more senior individual contributor, your craft
27:42 Brad Yeah.
27:42 Scott expectations includes business acumen and strategy. And as an engineering manager, even in the lower levels of an engineering manager, 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. 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 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 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 I have an opinion on that. You want me to go or you want to share yours first?
29:57 Scott You shoot first. I love it.
30:00 Brad My point of view is a little nuanced. I feel like an engineering manager actually needs to be able to do two things. They need to be able to design and they need to be able to validate that what their team is building is correct. Now, in order to design, you have to know the system that you're working on. And in order to know if what's being built is correct, you have to know something about software. And so I don't necessarily know or even think it's actually that all that valuable for a manager to be in there. 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, 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. Okay, well. 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, I was a player coach, just like you, I was writing code and managing the team. 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. 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 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. And if you have that and you have that awareness of the system. 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 And it shouldn't necessarily be required. I think it's situational based on the team, the enterprise, and the stage of the development of the software.
33:05 Brad Yeah, that's right. That's exactly right.
33:07 Scott Now, to play devil's advocate, one of the things that I have seen happen, and I've heard horror stories of this happening, is the... 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 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 or fear of toxicity around that type of a dynamic.
34:33 Brad Yeah. And the same goes with code reviews. Actually, I'm a little bit opposed to managers doing the code reviews. I'm not strictly opposed to it, but in general, I think it should be pure code reviews. Now, if a manager is in the cycle of people doing it maybe from time to time, they review something, but if everything has to be reviewed by the manager, 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. 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, as we've talked about, and we are now 30 minutes into this episode before AI has come up. As we've talked about, in an AI world, code review is more and more important. 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, you've got to be able to know what it's doing. You can't just take it and stick it out there. And some people, some engineers saying, I don't like that. 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. Just reviewing other people's work is not that fun. But then as we also talked about in some previous episode. 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, which does resonate with me, is, well, I mean. I just going to go back to the whole concept of like should engineering managers code and my answer to that question is it 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 If it's getting in the way of that empowerment, whatever, then of course they shouldn't.
36:48 Brad Yeah. 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, then go for it.
36:59 Scott Yeah, totally. Yeah.
37:03 Brad All right. 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, 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. 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. That's what matters.
37:44 Brad It's a fabric.
37:45 Scott It's a fabric. Yeah, I like that.
37:49 Brad All right. Well, with that, 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, don't forget to give us a five-star rating. We would love that. 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? No, I made that up. They don't even have that category. But if they did have that category and we had a lot of five-star reviews, we would be number one. Thank
38:23 Scott Yeah.
38:23 Brad you very much, everybody, for giving us a review. And 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. Please follow us on all the social media platforms at at HowManyCTOsPod. You can find us on YouTube, LinkedIn, Instagram, Facebook, Threads, X, TikTok, and Patreon, or at our website at HowManyCTOsPod.com. And remember to rate, review, and subscribe on the podcast platform of your choice. Thanks for listening.
