S2E9 – Do Leaders Have to Be Technical?

Show Notes

 In this episode of the TTL podcast, Andy and Mon-Chaio delve into the importance of technical skills and mindset in leadership roles, particularly as individuals transition from technical to management positions. Their discussions are anchored by research findings, such as an article hypothesizing technical competence loss in Boeing’s leadership contributing to quality issues, and an HBR article highlighting that 24 of the 100 best-performing CEOs have engineering degrees. Mon-Chaio and Andy argue that while the technical execution may become less critical at higher leadership levels, a technical mindset plays a crucial role in problem-solving and decision-making. They also look at some job postings to dissect expectations on technical leaders, suggesting that a mix of technical understanding and leadership capabilities is essential.

Please like, subscribe, and share your thoughts on how a technical background influences leadership effectiveness.

References

• The 1997 Merger That Paved the Way for the Boeing 737 Max Crisis – https://qz.com/1776080/how-the-mcdonnell-douglas-boeing-merger-led-to-the-737-max-crisis
• The Questionable Engineering of the 737 Max – https://youtu.be/hhT4M0UjJcg?si=0ldd3bN6bM2d_UPx
• Google “boeing merger with mcdonnell douglas management problems” for many different takes on whether this was a root of the problems. https://www.google.com/search?q=boeing+merger+with+mcdonnell+douglas+management+problems
• How technology-based firms become also highly innovative firms? The role of knowledge, technological and managerial capabilities, and entrepreneurs’ background – https://www.sciencedirect.com/science/article/pii/S2444569X18300726
• CIO influence behaviors: the impact of technical background – https://www.sciencedirect.com/science/article/abs/pii/S037872060200040X
• CEO background and impact on performance – https://oxford-review.com/ceo-background-and-impact-on-performance-live-resource/
• The Best-Performing CEOs in the World – https://hbr.org/2014/11/the-best-performing-ceos-in-the-world
• Why Managers Fail – https://www.jstor.org/stable/24119148

Transcript

S2E9 – Do Leaders Have to Be Technical?

Andy: All right. Welcome to another episode of the TTL podcast. Today, Mon Chaio and I are going to be talking about how much do we need to keep brushing up on those technical skills, learning the new languages, learning the new libraries, repeating the creation of that wheel again and again. The question is, how much do people, as they move into leadership and management positions, how much do they need to keep those tech skills? Relevant and kind of related, how much do they need to have come from that technical background? So we’re going to kind of talk a bit about what that means, what research we found about this. We’re going to look at a few job postings. And then in this case, there’s not really tactics.

So maybe this is more of a TL podcast episode. Maybe some tactics will come out of it as we talk about it, but really it’s more of a. How much do we think on the sliding scale, do these things contribute or matter?

Mon-Chaio: Yeah, I think on the tactics side, probably what it will eventually lead down to is, as you think about hiring your leaders, what are you going to prioritize? And I think we’ll get into that as we look at some example job postings. At least that’s what I think the tactics will be about. But as all of our listeners know, we tend to wander in our discussions.

We may end up somewhere completely different by the end.

Andy: At the end, we’ll be talking about sourdough.

Mon-Chaio: That’s right. Yep.

Andy: Alright, so one of the things that got me thinking about this Mon Chaio was all of the stuff going on with Boeing.

Mon-Chaio: Hmm. Tell me more.

Andy: So I was reading an article that I cannot remember the name of at the moment, but we’ll, I’ll find it again and we’ll list it in the show notes. If you don’t know, we list a lot of articles, links to papers and such, in our show notes. So always read the show notes and you’ll find resources. But I was reading this article and it hypothesized that a, a factor in the quality issues that Boeing has been having is that they lost technical competence and expertise as part of their leadership structure.

Mon-Chaio: Mm hmm.

Andy: Less focus on the training, the engineering excellence, and those kinds of things. And much more emphasis on the bottom line, the cost accounting the things like that. And this isn’t like a black and white thing, probably.

And the idea was, that’s possibly a big contributing factor to what’s been happening with Boeing. Is that they kind of, I think us from the technical background would say, they lost their way.

Mon-Chaio: Right. And for those people that don’t know what’s been happening with Boeing, although how could you not, right? I think the most recent thing was, what was it? A door came off mid-flight.

And prior to the door incident, there was a whole set of issues with, I think it’s the 737 MAX,

So I think anecdotally we can see that there’s issues that happen at Boeing over the years, but we can also see that just by feeling from a lot of other companies that we know and love, right? We feel, oh, there’s certain companies that used to be technical or used to have sort of boots on the ground people running it, but now are being led by more business y people.

And perhaps we don’t feel the same. And so, I think we can take that feeling, that anecdote, and say, Yeah, well, that means something about how technical your leadership has to be, all the way up the chain. Like we often talk about, that’s not good enough, right? I think, what does the research say around it?

When people study it, when they take it out of these feelings based and small sample size based areas, what does the research say about this stuff?

Andy: Yeah. So let’s go one more step into research. And this is an HBR article, Harvard Business Review. And I say one step into research because the article is kind of research.

Mon-Chaio: Sometimes HBR is a little bit, yes.

Andy: But it’s, it’s another step. And it, I think, I actually. I don’t like the framing the article tries to give it because when you look at their numbers, it’s like, well, it’s not as clear cut. The article is titled “the best performing CEOs in the world.” They’re looking at who’s been the best CEOs and their primary thing on it is stock market performance.

Mon-Chaio: Of course.

Andy: Of course. And, and they acknowledge that, the kind of like, of course. They, they’re like, well, it’s the thing that we can measure. They recognize that there is a much harder to measure aspect around the company’s culture and how they’re viewed and the way that they operate.

But partway through this article, they get to a big headline. It says, “why engineers make great leaders.” And they say “24 of HBR’s 100 best performing CEOs have undergraduate or graduate degrees in engineering, compared with 29 who have MBAs. At technology or science based companies, it’s not a big surprise to find an engineer at the helm, but engineers thrive at the top of other kinds of firms too.

Examples include Carlos Alves de Brito of brewing giant Anheuser Busch InBev, Jeffrey Sprecher of the financial services firm Intercontinental Exchange”, and so on. So the, the point they’re making is that an engineering background helps you be a better CEO.

Mon-Chaio: Mm hmm. Mm

Andy: Now I say it kind of muddies the water because if you look at those numbers 24 have graduate degrees in engineering.

or degrees in engineering. 29 have MBAs. 8 of those CEOs have both.

Mon-Chaio: hmm.

Andy: It’s about, it’s mixed. It’s about evenly set.

Mon-Chaio: But instead of looking at the numbers, Andy, I think that it really plays into our own biases, right? We, as engineers, do believe that the engineering mindset gives us something unique That allows us to be successful or or effective in many different situations.

And I would imagine that was what the HBR article is trying to say, that there’s something about the engineering training or the engineering mindset that allows these people to helm successful organizations.

Andy: Yep. In fact, they have a quote from someone saying, “Engineering is about what works, and it breeds in you an ethos of building things that work, whether it’s a machine, or a structure, or an organization. Engineering also teaches you to try to do things efficiently and eloquently, with reliable outcomes, and with a margin of safety.

It makes you think about costs versus performance. These are principles that can be deeply important when you think about organizations.”

Mon-Chaio: Now, some of those I agree with. Maybe that last one. I don’t think that you go far in either engineering school or engineering career without really embracing that cost benefit stuff, right?

Now, the building stuff that works I think I’ve seen, I think it’s actually worse to be an engineer, perhaps, in some of those realms. Engineering sometimes can get caught up in that art, right? At least many of the really good engineers that I know have that love of that art of engineering. And sometimes that can dominate over the, what is it that works and what is it that we actually just need to do the job?

I think there’s a lot that we can glean from that article, but you’re right. It’s just a half step in. Are there more steps that we can take into something a little bit more rigorous?

Andy: So, I have one that’s not rigorous. Again, it’s fairly anecdotal. It was a paper that was talking about why managers fail. As they move higher and higher, their technical skills matter less, their interpersonal skills matter kind of a little less, not quite as much less, and their administrative and conceptual skills matter. More and more.

Mon-Chaio: Mm

Andy: And maybe, this is the thing of the engineering background that we could glean from this.

It’s not that your technical skills, but it’s that mindset back to that HBR article.

Mon-Chaio: Hmm. Mm

Mm

so if we were to take that in concert with the HBR stuff, it sounds like we’re arriving at this engineering mindset gives you certain pluses, perhaps, in how you see problems and solve problems. But as you move up the organization, it’s less about do you know the specific technical details, versus can you apply that type of mindset to larger scale problems.

Andy: So I found, when I was looking for research in CEOs, and do they need the technical background? Or CTOs, do they need the technical background?

The CEO, basically, I found this HBR article. Almost everyone just references it. Which I, I’m a little troubled by, since it wasn’t very open about its procedures or data or anything. Almost nothing about CTOs. It doesn’t seem like the question gets asked about CTOs. Do they need to have that technical background?

But, the one I found where the question does get asked is CIOs. Chief Information Officers. And The thing on Chief Information Officer is I found one article that asked the question , will CIOs, because if they come from a technical background, be too introverted, be too low on interpersonal skills, that they will be ineffective in influencing others.

Would they be able to influence an organization? So say it turns out that they actually hear through the application support teams saying, our services keep failing because one in a thousand DNS lookups comes back with the wrong answer.

And the C, the CIO say that they’re the one involved in this case. Let’s not, let’s not fathom the reason that they would be the one involved. This is kind of asking the question of, well, if they don’t have that influencing behavior to get the infrastructure group to now look into this, then they wouldn’t be effective, even though They fully understand what’s going on.

So they had this hypothesis that CIOs from, from a technical background, will have less ability to do these influencing behaviors than a CIO, from a non-technical background, from like an MBA background or a business school background, political science background.

Communications. And they had all this great reasoning for it. And I was nodding along as I was reading the paper. I was like, Oh yeah, this makes a lot of sense. This makes a lot of sense. And then they couldn’t support a single one of their hypotheses.

Mon-Chaio: Did they at least acknowledge that they weren’t able to support their hypothesis?

Andy: yes, yeah, yeah. Yeah, yeah, they said, yeah, none of our data supports any of these hypotheses. The null hypothesis holds in all cases.

Mon-Chaio: Mm hmm.

Andy: And the null hypothesis for anyone who doesn’t know, the null hypothesis is, there is no difference.

Mon-Chaio: hmm.

Andy: So their hypothesis is, there will be a difference. The null hypothesis is, there won’t be a difference.

And basically, if you don’t have anything to say that the null hypothesis is wrong, You have to accept the null hypothesis, and that’s what they found. There was nothing that showed any meaningful difference between people from a tech background and a non tech background.

So they were in this stereotype of technical people are introverted and can’t communicate. That’s, that’s the stereotype. But they said, but that doesn’t really make much sense if you think about it. These people got to these leadership positions because they can influence others. And through getting up to those positions, even if they weren’t immediately trained on those skills from their technical background, they will have to learn them as they go through these different positions.

Mon-Chaio: And that makes a lot of sense. That’s what leadership training is all about. And

Andy: Yeah.

Mon-Chaio: development is all about, right? I mean, how many of your leaders come in fully developed in all of those skills? And I think in both of our careers, we’ve seen the people that don’t have those skills, or at least possess them in minimal quantities, are not going to be the ones that are going to reach CIO status, for example.

Andy: Now, the interesting thing, as I was saying that, that this brings up, and back to our kind of topic of how much does that technical background matter, Leadership training is all about those non technical skills, the, the influencing behaviors, the management, the, that kind of thing. But for someone from a non technical background, do they get technical training?

Mon-Chaio: Mm hmm.

Andy: they get the training of the discipline that they’re kind of heading up? Should that CIO be told? Hey, yeah, you’re from an MBA background? You need to go to an MIS course.

Mon-Chaio: hmm.

I think that there’s two things around being technical that I think are important as we move into leadership. One is definitely that mindset that we were taught, that we continue to talk about. How do you think about a problem? Things around how do you experiment on a problem? How do you detect failure?

How do you read things like P 99 and understand is it a P 50 problem, a P 99 problem? How do you do cost benefit analysis? Things around scale, right? Understanding this bottlenecks that can happen. in certain areas. Are they critical bottlenecks? Do they bottleneck the whole process? Things around flow.

That’s not to say that you can’t understand those things coming from other backgrounds, but for whatever reason, it feels to me in my experience, like that type of stuff comes out more from an engineering background. So how do you acquire that knowledge if you’re not an engineer? I would say that, yeah, you could probably acquire a lot of that knowledge through education.

Andy: Do you, do you think that taking those courses would get you So, I had a professor in Germany, who always talked about having Fingerfertigkeit. Kind of like you’re trained enough that it’s just at your fingertips. I think in English we call it muscle

Mon-Chaio: Mm hmm.

Andy: And his point was that you need to get to the point of practicing this enough that it’s kind of second nature. You don’t think about applying it. Would those courses give you something close enough to Fingerfertigkeit to, to be able to do that? Or would you now be kind of like the dangerous white belt?

Mon-Chaio: Mm hmm. I don’t know. I, I want to say they, they would not. But I also, I’m also aware of a very deep bias within myself as an engineer. And understanding that that bias comes into play. I think it is reasonable to say that they possibly could. I don’t think that’s an unreasonable statement. But I think getting back to the second part, I mentioned there’s two things that I think about with regard to technical background.

The first is this ability to think technically. But the second is this ability to understand how technical people work. Understand, for example, why it’s so important if a single unit test fails. Or why fast compilers are critical to engineering workflow. Or, why branching is just universally terrible and there’s no use for it, I’m being facetious here. There’s very, very few uses for it, but there are still some uses for it. And I think in that realm, which I also think is important for leaders of a software and technical organization, I don’t think those are things that you can course through. I think those are things that you kind of have to work through.

Andy: Hmm. Mm

Mon-Chaio: And so I think from a non technical leader, I don’t know if this is clearly possible or if it’s possible within the sphere of working in a company, but I think you develop that by doing frontline work.

Andy: I asked the question of a group of fractional CTOs, if a CEO for a startup where he doesn’t have a technical founder, whether he should go on a bootstrap programming course.

One of these sorry, not Bootstrap Bootcamp programming course, one of these things where it’s like, in six weeks or twelve weeks, we will turn you into a programmer.

Mon-Chaio: Right.

Andy: And their take was, it might be interesting, but it’s kind of a waste of his time.

Mon-Chaio: I agree with that.

Andy: His specialty as the CEO should be focusing on where’s the company going?

How to get those new customers? What kind of product are they really putting together? And too much focus on the technical people would be drawing his attention away from that. And it would be actually at the detriment for the company as a whole. What’s your thought on that?

Mon-Chaio: I don’t think that’s strictly a problem with technical. I mean, let’s assume that the CEO didn’t come from a sales background, and they were a company that had to sell to large enterprises. Would we say it’s reasonable for him to take a course on selling to large enterprises? Or would we say the same thing that, oh well his focus shouldn’t be on like how the sales people are running and too much focus on that can take his attention away from x y or z? I don’t think it’s that. I just think that the technical course doesn’t give him the value that he thinks it gives him her. Right? Because you cannot achieve a technical mindset in a nine week bootcamp. What you can achieve is understanding how do you do What you can understanding Python keywords and how to write a loop, right?

Andy: And, and what you won’t get is the thing that is important, which is, what is the thinking involved in figuring out what loop to write, or whether or not to write that loop, or the impact of having test coverage versus not having test coverage?

Mon-Chaio: hmm.

Andy: Yeah.

Mon-Chaio: I agree. And I think the bigger part of that question, which is why I don’t like to divide it between technical and non technical, I think often people think non technical knowledge is easier to acquire, which may be true. I, I happen to think that that’s probably true. And so leaders will come in with a bunch of non technical knowledge.

Oh, I generally understand how sales cycles works. I generally understand how to do a financial model. I generally understand X, Y, or Z, where people have this bias that deep technical knowledge is very difficult to come by. And I think that’s, for the most part, pretty true. But that doesn’t make it less important to acquire parts of it, right?

For a CEO, it’s important, even if you don’t understand financial models through and through, you need to understand a minimal set to be able to run your company. Similarly, I think if you’re at a technical company, you need to understand a minimal set of technical stuff in order to be able to run a technical company.

Now, what is that minimal set might be an interesting thing to talk through.

Andy: And so from this discussion of the CEO, the CIO, a bit of these other things, I I’m going to propose that I think what we’re getting to is that if you can have, like as the CEO or as one of these, that, that technical background, as well as that non technical background, if you can combine them, that is excellent.

But if as a single individual you don’t have it, this is now about, like, what, who do you put together as your team? Can you put together a team that has those different aspects and can bring them together and work together? And that fits, that fits a paper that I found about what are the requisite properties of what they called a technically based innovative firm.

Mon-Chaio: Mm hmm.

Andy: And basically, and they did support their hypotheses. They, they said, yes, these do seem to be what’s around. And they said it’s that, ” technically based innovative firms depend as much on the knowledge and technologies that enable the development of innovative projects as on the managerial capabilities that allow an invention to become a marketable product and an attractive managerial project through the business or economics training of the administrator.”

So you need both that technical skill and knowledge as well as that managerial and administrative skill and knowledge. And they basically, the firm as a whole has to have that stuff and bring it together effectively.

Mon-Chaio: But as the head of the group, I think there is a minimum amount of knowledge you have to have in specific areas to be able to helm it correctly.

Andy: Yeah.

Mon-Chaio: You know, otherwise, maybe they’re co CEOs or the CTO is a co CEO of some sort where they take all technical decisions in hand or whatnot.

But that makes sense. I mean, like everything else, your group, it’s the group, not the individual, right? It’s the group and the group dynamics and the knowledge of the group that ends up making or breaking the success of an organization.

Andy: So with that, with having clarified our thoughts and backed it up with a little bit of research, let’s take a look at a few job postings. Let’s, let’s see. What do people actually seem to ask for?

Mon-Chaio: Absolutely. And I think this actually brings it back because we’re talking about a non technical CEO . But I think what these job postings really bring it back to is now that CTO, not the CIO, not the CEO, but back to that CTO that we haven’t spent a lot of time talking about. How technical does that person have to be? And I think these job postings will be really interesting. Is there a place that you want to start or I’m happy to pull one up that I think is interesting.

Andy: I think pull up the one that you think is interesting because in our research for this, I spent more time reading the articles and you found all of these job postings, so I’m not as familiar with them.

Mon-Chaio: All right. So, I’m going to try to not shame companies here. We, we try very hard on this podcast to maintain pretty level views except when it comes to branching and

Andy: Yeah, the, just like, just don’t,

Mon-Chaio: which are just

wrong.

Andy: Yeah.

Mon-Chaio: So this is this job posting is for a 200 to 500 person company. It’s difficult to tell how large their engineering organization is, but it seems like they have a fairly sizable engineering organization.

And the job posting is for a vice president of engineering role. What it’s asking for is that it’s asking for this person, this vice president. To, amongst other things, “oversee technical strategy and architecture across data integration, data lake, data warehousing, data access layers, and data reporting.” It’s asking this person to “architect an ownership of disparate data environments, bringing them all into one comprehensive strategy,

product, offering.” It’s also asking them to “establish and evangelize best practices and frameworks for things like source code management, quality controls, inspire and create a motivating environment through coaching, mentoring, and enablement.” And to “foster a data driven culture, create a culture of career development, performance, and performance management for engineers and architects.”

Andy: Mm hmm.

Mon-Chaio: 200 to 500 person company, vice president of engineering, those are some of the example responsibilities that they’re asking for. What do we think about that?

Andy: So my first thought is that VP of engineering is not necessarily the highest level, right? So this person is somewhere in the middle. They’re, they’re not a team lead. They’re not a C suite. They’re, they’re somewhere in the middle. Right?

Mon-Chaio: Right, they may report to a senior vice president, or they may report directly to the CTO.

Andy: Right. So, what they’re being asked for is to oversee, to lead, to drive. Now, I think that all makes sense. Now, they’re also being asked to build efficient and scalable data pipelines, to architect and take ownership of our data environments. I would say that makes sense if we’re allowed to read it as they’re kind of like where the buck stops, but they’re not, they’re not doing it.

They’re, they’re, they’re making sure it’s happening. They’re, they’re supposed to be making sure it’s all going on. But they’re also asked to have some background in all of this. And so they’re informed, they’re, they’re, they’re capable of doing these kinds of things, but they, I would hope, are not doing them themselves directly, day to day. Is, is that the way you would read it?

Mon-Chaio: I don’t know that I necessarily would read it this way, given that I have seen and participated in interview processes of places that interview for these types of things, which that is not their expectation.

Andy: They expect that you’re writing that code every day.

Mon-Chaio: not necessarily writing the code every day. So when I see something like architect, I have seen companies which expect these types of roles to own that architecture. Now, you know, buck stops here. I think that makes sense. But as you go through the interview process, oftentimes they ask people interviewing for these roles.

So how would you architect this thing? And they’re having staff level or senior staff level engineers asking these questions and often these companies will say that the bar is is for that VP to meet a staff or senior staff level bar for engineering architecture.

Andy: And you think that’s unreasonable? I’m guessing.

Mon-Chaio: I think it’s tricky. I think for a 200 to 500 person company, I think it starts to become a little unreasonable. What I often advise companies is I often advise them, look, a lot of these folks and for this particular role, let me see, hold on one second. If I scroll down here, prior experience. Yeah, for this, so for this particular role, they didn’t specifically state like have to have previous VP experience or whatnot. But often when you’re a VP of Engineering, you’re talking about somebody that’s 15, 25, 30 years into their career. It’s very rare for those people, especially if they’ve been in an executive or leadership for a good amount of time, 5, 10 years, to have really kept up on what are the APIs that Amazon is now developing.

How many different data stores do they have now? I think it’s less reasonable for companies to expect that these people have kept up to that and have deep understanding to be able to talk about the trade offs between MongoDB.

And an S3RDS pair, or something like that.

Andy: Yeah. In that case, it sounds like they are conflating the technical and non technical career ladders.

Mon-Chaio: Mm

hmm.

Andy: And as we were just talking about, it’s the thinking. That seems to be important, not necessarily the, the execution once you’re, once you’re going up those things. And in fact, I would say probably if, if your primary thing is that you can execute, your identity is probably still that you do execute, which means that you’ll probably be reaching into your teams a little too often and not letting them who have, where they have much more knowledge about what’s going on, get on with it.

And so you will, you’ll be doing that kind of like reach in all the time, and you won’t be asking like the interesting questions for that, that being able to be accountable and responsible for what’s happening.

Mon-Chaio: Right. So, another one along this line is, and I think these are actually pretty representative. I wouldn’t say that these are outliers in the job posting that I’ve seen. So, this one is for a global organization. So, an organization which is quite large and has offices everywhere around the world. So, not small at all. They’re looking for a senior director of engineering. To provide strategic leadership, drive innovation, ensure best practices.

They’re asking them to do team management, build and lead a team of engineers, architects, and developers. They’re asking them to have technical expertise, serve as the subject matter expert for things like API gateway architecture, design patterns and implementation, stay current on industry trends and emerging technologies related to things like React Native. They’re asking them to do solution design, to collaborate with architects to design scalable, secure, robust API gateway solutions. And they’re asking them to have had experience, proven experience in leadership roles, preferably at the director level or higher.

Andy: So this one, I think, is, basically, I would say they’re looking for a lead developer. They’re looking for a very experienced lead developer. And this one I think is where, from the outside, it’s really hard to take titles. And understand how the company is actually structured. Because I know that in a lot of banks, the most senior developers are called directors.

Mon-Chaio: hmm. Mm

Andy: At least in London banks. They’re all called directors. They’re something something director. They’re senior directors and all these things. That is simply the way that their pay scales work.

Mon-Chaio: Yeah, I think that makes sense. I think that makes sense. And I agree that it sounds like this is more of a lead developer. It is a very large organization, so how, who knows how many senior directors they have within their company probably. And so then the last one I want to talk about is a head of engineering role at a company that seems like it has between two and ten employees. They ask for this person to lead and grow cross functional teams. They ask them to develop and execute engineering strategy and roadmaps. They ask them to maintain a hands on engineering and leadership approach to provide technical guidance, review, and mentorship to the team. So what do we think about that?

Andy: sounds like a great position to me.

Mon-Chaio: And it seems very reasonable, right? When you think about a two to 10 person organization, their engineering team is probably maybe half of that if we’re being charitable.

Andy: Yeah.

Mon-Chaio: And so this really is, again, a title situation where you are just a lead developer. They’re not asking you to do a ton of management. And they’re really just asking you to keep the trains running, right? Keep the software coming and make sure that you assume all software risk as part of your role. Which I think is very reasonable. I think that’s very reasonable.

Andy: In a position like this one, I would expect that what they’re looking for is someone who has that highly technical capability, has that management and leadership experience, and can grow away from the technical capability as the teams grow.

Mon-Chaio: I would certainly hope so. Although, we never really know how companies think about how they should grow.

Andy: Yeah,

Mon-Chaio: And, I think this gets into a central point that I see often. Which is the bias that leadership skills just come. When companies say as a leader, you need to be up to date on technical capabilities. I think what they’re really saying is they don’t value the leadership capabilities. Because it takes a lot of time and energy to become a good leader. We’ve talked a lot about the tactics that you need. You need practice time, for example. Andy, something you bring up a lot, practicing conversations. How do you have conversations? We advocate having structured engineering leadership development sessions, and we advocate things like reflection and community building around leadership. If a company really values that, do they really say, well, that’s a 10 hour job. And then for the other 30 hours, you’re going to keep up to date on all of the stuff that your team is doing and be an expert at writing code and so I’m not sure how companies think about that unless they are saying, well, you can spend 30 hours in engineering or in leadership, but then it only takes you 10 hours to stay up to date just as a senior engineer stays up to date.

Andy: Yeah, I agree that, that a lot of these job postings have a very, to me, skewed balance of the leadership versus the technical, and that as, as you spend more time in that leadership to become effective at that, have that higher leverage, higher impact skill set, that knowledge of the exact technical details to be able to be in that individual contributor position are going to have to fall away.

It doesn’t mean that you wouldn’t ever be able to pick them back up. I believe that most technical people could pick them back up if they put their mind to it fairly quickly. But it’s not going to be your day to day thing. And in fact, , if you’re asking them to spend 90 percent of their time they’re probably going to be an impediment to their team rather than a help,

Mon-Chaio: And you mentioned that earlier, that white belt, right? That just being dangerous enough to be an impediment.

Andy: I think what you end up with is you have to figure out like, what does the team need right now? And work from there. So some of these roles, I think they’re hiring lead developers. Other roles. I think it’s a little less clear. Are they hiring a lead and, and manager? Or are they hiring an experienced developer?

And I think that lack of clarity during the interview, during the hiring process is a point that should be discussed.

Mon-Chaio: Think that is true to some extent, probably to a large extent, that companies don’t really know what they want. They kind of spew out, they vomit out everything they can think of of what they consider might be a perfect candidate. But this, this thinking process isn’t confined just to those types of companies. So I know at Google, for example, it wasn’t that long ago, five years, maybe six years ago. That they still required their managers of managers to go through a coding interview Before they could join the company. I think it was google Maybe it was a different big tech company, but it was one of the big tech companies And I don’t think that was unique back in the day I think still manager of managers and probably director levels and above Are now still required to do architecture interviews during their interview process And I think the question in my mind is I don’t think it’s That the companies don’t know what they want out of the roles.

In fact, the roles are so Regimented that they do know exactly what they want out of those roles. But I think the question is why do they think that’s important? And what is the signal that they’re getting there?

Andy: I think it goes back to what we were talking about, which is that that technical background, that technical knowledge can be very important in understanding what’s going on, which then brings us back to our discussion we had about hiring in whichever episode, which is those questions should probably be geared a little bit more towards that ability rather than, “can you write this in C++?” It’s more along the lines of “how can you leverage your technical background to understand the implications of what’s happening in, in this kind of a system that your team is building.”

Mon-Chaio: Right. Interview the way they would do the job. But one way would be, hey, here’s two proposals for two architectures that people have come to you with, and they’re saying, help us pick. And, you know, have your candidates show how, what questions do they ask?

You know, do they understand the technical keywords that are in there? Are they picking up on the unimportant parts of the proposals or are they picking up on the important parts? That sort of thing.

Andy: Yeah, I like that.

We should probably wrap this up. We had a, a few tactics around thinking about what it is you need out of these positions. I think that we agree that technical knowledge is important, but it’s, it’s a team thing for those groups that the exact coding ability of your leaders and technical people, if their role is not day to day coding, Their technical ability to code is probably not what you’re actually looking for.

And that then feeds into the kind of hiring or training, and also treat leadership training just as you would treat dev training. Hey, yes, spend time practicing, not just only doing your coding dojos and, and those kinds of things, but also for your leaders, spend time practicing communication, spend time practicing feedback techniques, spend time practicing all of those things.

So we covered a wide range of things, Mon Chaio.

Mon-Chaio: We did, and I think you had a great summary so I don’t have really anything to add from there.

Andy: Well, with that as always, we would love to hear from anyone out there. We would love feedback. Subscribe wherever you listen to us. Give us a thumbs up or a like or a star rating or whatever it is on your platform. Get our word out. Share us with anyone you think could benefit from hearing our rambling words of wisdom. And send us anything you want at hosts at the TTLpodcast. com. Until next time, Mon Chao, be kind and stay curious.