Soft Skills Engineering - Episode 449: My tech lead ignored my warnings and I don't know what my leadership style is

Episode Date: February 24, 2025

In this episode, Dave and Jamison answer these questions: Hello, long time listener first time question asker. I work for a medium sized tech company and I recently moved teams. Right now my old team is attempting to refactor a bunch of code I wrote to use a library that’ll make life easier. I don’t blame them, I tried to do the same thing. It does not work. I asked the tech lead “did you run into the same framework bug I did when I tried this refactor”… “nope” he said. So out of curiosity I pulled down the branch and guess what I saw, the same bug when I tried this refactor 3 months ago. Now I am in a weird position. Do I tell the tech lead again (he was the tech lead when I tried this same refactor) that this does not work or do I ignore it because I am no longer on that team? I don’t want to overstep my bounds but I also know its a lot of work to refactor all this code, so much work they’d need to stop delivering features and add this to their roadmap. I have been interviewing for leadership roles and I keep getting asked “What is your Leadership Style”? I am honestly not quite sure how to answer this as I don’t really understand what they are asking. I have searched the internet for a clean, 5th normal form database that lists the available styles to no avail with no definitive tables. It seems this is truly a soft skill. From your experience, what is the interviewer really asking in this case, how can I better identify common styles, and what can I do to grow my skills in this area?

it takes more than your ceo viewing your linkedin profile to be a great engineer this is soft skills engineering episode 449 i'm your host dave smith i'm your host jameson dance soft skills engineering is a weekly advice podcast about all the non-technical stuff that you need to do your job like making sure that you promote yourself to your ceo on linkedin do you feel like that's a what exactly do you say you do here type moment yeah you know i was just browsing linkedin and i didn't know we had a who was that that made that annoying comment in the meeting yeah i'm gonna go look them up yes oh there's enough activity with people posting on linkedin that it must provide some utility but i i cannot bring myself to do it yes i think you're right and i agree

I just I choose to lose out on that utility I do believe that LinkedIn has morphed from being my favorite rolodex that automatically updates itself with contact information about anyone I've ever worked with to yet another distracting attention sucking thing that when I go to do one thing I end up spending 20 minutes doing something I didn't intend to do which is read some lame news feed it's the worst tumblr of all time that's what it is now oh Fred got a new job oh Fred wants to say congratulations to diane about this promotion like how can i not read this fred's been thinking deeply about leadership principles yes expound upon them yes oh my gosh what a deep thinker fred's always been a deep thinker yeah i don't know it's got to do something someday i'll

either make enough money that i can not not feel guilty for missing out on whatever it does or give in and speaking of making enough money let's give a shout out to all of the patrons that support this podcast yes to the level that we shout them out every week and and contribute to me not having to do anything on linkedin to promote myself nice um thank you too all gone they all unsubscribed from our patreon and now we have no money to start a zoo you need at least two pandas a grizzly and three polars that's the bare minimum nice that's the bare original cody sale alexander kuznetsov chris morton nick molyneux michael young.dev attribute error none type has no attribute to string javier gonzalez chewy ted timbrel i quit my job but it's 2025 oh

god what have i done alexa alexa alexa turn off all the lights that's like pseudo alexa turn off all the lights i think become a senior engineer.com is a newsletter you should read unsalted french fries are morally objectionable generating side projects with ai so jameson notices my resume nice dan from drone deploy chase w norton never is not just a crater on mars for flamingo emoji i like chicken i like liver meow mix meow mix please deliver trash panda get status kyle boss kent c dodds nevar is not just a planet in the vulcan system jenny kim the stochastic parrot helicone.ai best observability tool for ai red panda is best panda java is just discounted c sharp with worse documentation jonathan king it's not a beautiful functional user documentation

two-time shout out to angelica cathore oh way to hack the system yeah williamangel.net has cookies and just the word and good brayden canes john grant britney ellick joe grossberg every monday when i hear soft skills engineering i think i'm going to change my username for next week and then all of a sudden it cody sale oh man really is the best part of my week thank you thank you we appreciate you you keep us going and you bring glory to yourselves really all the listeners are now entertained by your funny jokes and don't know who you are because you had to change your name right it's it's the most altruistic form of glory yes we call this effective patreonism yes highest value per dollar anyways dave do you want to read our first

question i do this comes from a listener named mutumbo who says hello long time listener first time question asker i work for a medium-sized tech company and i recently moved teams right now my old team is attempting to refactor a bunch of code i wrote to use a library that will make life easier i don't blame them i tried to do the same thing but it does not work i asked the tech lead did you run into the same framework bug i did when i tried this refactor nope he said so out of curiosity i pulled down the branch and guess what i saw the same bug when i tried this refactor three months ago now i'm in a weird position do i tell the tech lead again who was the tech lead when i tried the same refactor that this does not work or do i ignore it because i am

no longer on that team i don't want to overstep my bounds but i also know it's a lot of work to refactor all this code so so much work that they would need to stop delivering features and add this to their roadmap this is like the trolley problem uh literally right before this conversation i was talking about the trolley problem with someone and yeah i guess it is kind of you told them so you you you just verified i pulled down the branch and guess what i saw the same bug Yeah. I'm assuming that means pull down the branch of the refactor, right? Not like their old branch. Yeah. I'm guessing the in-progress refactor is my guess. It's kind of an interesting factor here that the tech lead was the tech lead the last time this was attempted and failed. So it kind

of makes me wonder, like, is that tech lead not paying attention? I have like three blog posts or papers that I cite. Sometimes they rotate, but there's always three and like a new one gets added and then that has to push another one out. But one of them that is in my head right now is programming is theory building by peter nor which is how i learned how to pronounce australian no is by saying his last name how you actually say it nice one of the inventors of bnf that like grammar syntax for specifying back as an hour form that's the that's the nar the australian no in uh bnf and he wrote a paper titled the title i already said which describes a lot of the work in programming is in creating a theory of how the world works and a theory of how your program

relates to the world and maintaining that and modifying the theory as you learn new things about the world and new things about the program. And to me, what this sounds like is your tech lead's theory of the program doesn't match yours, where there's this bug you know about because you know about these specific circumstances. And it's very possible your tech lead heard you say it before and thought that's not true because of these other conditions and and just like didn't understand deeply enough the conditions that are true that the theory of the program in order to really grasp why the bug matters so just telling them hey there's this bug might not work the same way that writing a bunch of documentation and handing off a bunch of code with documentation

to a different team doesn't work because the documentation is not enough to give them a theory of the program they have to like build that knowledge up in their head interesting not just read the docs and reading the docs is a necessary but not sufficient way to build up that theory i hope it's not necessary because there's never any docs but um it certainly helps yeah maybe potentially helpful but but never sufficient yeah the the paper talks about couple cases one case where there's a lot of continuity on a team maintaining a program and because they have this strong theory they can make these changes more easily. The other one where there's that big handoff and the team writes a bunch of docs and makes themselves available to the other team

that's taking over the software and still come in and find outrageously horrible decisions that would have been so much easier if they had understood the affordances in the code to support those changes already. And they didn't because they had not built up that theory the same way that the original team had it and so here we are reliving that paper yeah as we will forever yeah and this listener gets to write another paper because they also didn't incorporate the theory of that paper and so now they ah they can write a paper after they watch this disaster unfold yes what would the paper be called it'd probably be the same title as the original paper boy programming is theory building sure would have helped here that's the title of the paper

exactly yeah i mean i guess i'm ignoring a bunch of things that could be going on it could be that you're wrong but you listen to the show you're not wrong yeah clearly you have a track record of good decisions yeah could be that the tech lead is like lying to protect their project right they pushed really hard for this refactor and then if there's this killer bug that stops it then that kind of puts them at risk it could be that they i mean the bug is there it's just not that big of a deal or they think it's not that big of a deal they think there's some way to work around it i don't think there's a downside in bringing it up again though as long as you are tactful about it yeah i'm just sitting here resisting the urge to go on

a monologue about why is programming so hard why is it that probably 50 times a year i think this should be easy and then it never is there's always something i mean even if it's like even if it's something as simple as like oh i'm going to use this cloud-based api that does exactly what i want and then it's like surprise that has tens of thousands of paying customers yeah like surely yeah nope it almost does what you want all the time it never does what you want nothing ever does what you want exactly it's always there's always something weird every week sorry maybe that's what the tech lead is saying when they say no it's it's fine is they're saying of course there's going to be something we're refactoring this giant chunk of code like

yep but the way they're saying yes is actually by saying nope no it's not a problem or they're saying yes but then you know i mean i guess there's a couple of assumptions baked into the question asker's concern here. Assumption one, you already stated, Jameson, which is you are correct that this bug actually exists and can't be resolved in a reasonable way. And assumption number two is this bug matters to the use case. Sure, it's almost always the case that there's some bug somewhere or some unsupported user experience that just doesn't quite work the way we intended. Those don't always matter. In other words, sometimes they are trade-offs that we're willing to make. And so I think maybe that's how you approach this question with the tech

lead, rather than coming in with absolute terms and saying your refactor is doomed. Instead, you say, you know, three months ago, I attempted this refactor, and we stumbled upon some information that I wanted to share with you. So you can make a decision about the feasibility of this refactor or about the value and the trade offs this refactor. And the reason I would speak in those terms, is because I recently heard a great negotiating technique. Actually, it was more of an argumentation technique, which is, it's one thing to defeat your enemy. And in this case, I'm kind of putting these two people in like enemy, let's just say argument opponents territory. It's one thing to defeat your opponent in an argument. It's another thing to defeat them

and give them a way to admit defeat without losing face. And so I think that applies here. not that I think this is a fight or an argument and you're not opponents, but rather give them information that allows them to go, oh, aha, I'm so glad that I received this information, which I can now make a decision about. And you're like, yeah, I know I'm saying all of this so you can make the decision that I know you should already make without telling you here's the decision you should make. And then I think they're more likely just emotionally to accept the information and make a good decision with it yeah yeah like it doesn't matter if you're right if they're going to be humiliated by admitting that you are right exactly and and they're less

likely to do it like when faced with the with the option of option one take the humiliation and stop the refactor but it feels humiliating or option two let the refactor continue but you never had to face the humiliation of a junior engineer telling you that you botched the decision-making process. I'm like, I don't know. The choice between those two options is not super clear. I'm thinking about how you deliver the message. And I agree with you, Dave, that there are, you shouldn't come to them like you're an investigative journalist that's uncovered a scoop about them. You know, like I discovered something nefarious about you. You should present them some information and you should take the time to check your facts and assumptions too, to say, hey, have

you tried it in these circumstances is this a thing that you think is going to occur in user behavior i do think you have a decision when you present that information though you can say you can kind of throw it over the wall and say hey i just want to make sure you're aware of this maybe you have an answer for it maybe it doesn't matter but here's what i saw and i really think it's important that you consider it and then the other option is to say like and what are you going to do about it in a less aggressive way but you know like take a little bit more ownership of it and and sort of like ask for the follow-up that one is probably a little bit more likely to ruffle feathers if you don't have a great relationship with this tech lead already if you i mean they

were your tech leads maybe you work together well but you could kind of say and i'm really concerned about it like can you tell me what you find out about it but you're kind of demanding them to do work that they might not want to do. So that one is a bit riskier and has more potential blowback in your direction. Although it is also more likely to result in them actually doing something about it. It's going to be very easy for them to just say, thanks for the feedback, back to work as usual. Yeah. Yeah. So, I mean, long story short, like summarizing, yeah, I would go talk to them. Just make sure they have all the information. There's a really good chance that this just fell off their radar and they forgot about this important detail. I

I mean, if I had a nickel for every time, one little detail that I just forgot about completely destroys an approach in software development. It's a lot of nickels. Yeah, agreed. All right, have we answered the question? I think so. Good luck. Shall I read our next question?

That's exactly what I was hoping you would ask so that I would have the privilege of saying yes. Okay. This is from a listener whose name I will pronounce wrong. Goyu? Is it pronounced like the Australian Goyu? oh nar it's peter no hang on i'm gonna look this up i already tried i think it's just a screen name g-o-y-u-i-x go ux all right go you is how i am i don't know french at all but this is how i imagine

pretend french in my in my head is pronounced yeah it looks kind of french right you just don't say Yeah, or many other letters. Yes. All right. Here is the question I've been interviewing for leadership roles. And I keep getting asked, what is your leadership style? I am honestly not quite sure how to answer this, as I don't really understand what they are asking. I have searched the Internet for a clean fifth normal form database that lists all the available styles to no avail with no definitive tables.

It seems this is truly a soft skill. From your experience, what is the interviewer really asking in this case? how can i better identify common styles and what can i do to grow my skills in this area oh this is a really good question is there a list of leadership styles somewhere i'm sure there is this is also one where i don't have like a one word answer to this question myself that's why i picked this question today it seems like it seems like a very short answer question the way that it's written what is your leadership style it kind of feels like oh there should be a one word answer like uh scrum you know like i don't know yeah that's a bad answer if someone asks

what your leadership style is and you say scrum that is wrong yeah that is incorrect the question incorrectly my leadership style is i would describe it as good i immediately start thinking of like martial arts styles like oh like my monkey style is your praying mantis style it's like well to answer that question i need to know the style of the problems i need to solve on this job to defeat yes need to know what styles will be effective exactly and i can rip out my reference chart and then tell you ah monkey style so i have a dumb answer which is you could say oh servant leadership which is like uh the default answer everybody gives that is meaningless and the worst human you've ever met that's like

a horrible leader and will just coldly psychopathically sabotage other people's careers politically will kindly and smoothly say oh i believe in servant leadership in an interview i guess you could turn this into a joke and just say if i'm hired as the engineering manager of this team i will rule this team with an iron fist that's my style i brook no backtalk no second guessing what is this question really trying to ask because i think you are correct that there's not a canonical list of styles where there's like the west coast offense in football and then there are other ones that i don't know that's the only one i've heard of but there's like different kinds i don't think it's quite the same in leadership at least in in interviews like this

i think what this question is trying to get at is have you thought about it enough to be able to articulate a strategy for how you will lead a group of people it's not looking for a name of a style it's looking for can you explain like what you will try to do in broad high level terms exactly what's what you value and what you don't do you already have a corpus of experience to draw upon to say what you would do in different kinds of situations yeah it's kind of like if you ask someone like let's let's say we've made this more like a programming question like what programming style do you like the most yeah what is your programming style i mean that question depending on kind of the the subtle contextual clues you could say things like well i prefer

functional programming right and that would be like a reasonable answer to that question you know or i prefer object-oriented programming i don't know like those are actually like programming styles that you could answer this question with but if you have never written a line of code in your life you will just fumble over that answer you know like you would say exactly like what you said like the good kind like i'm the good kind of style agile programming extreme programming extreme programming that's my style is extreme which is can you imagine a less extreme thing than a group of like 30 something software engineers in a room pair programming together and the thing that makes it extreme is they don't write documentation wow that's radical

yes i can remember getting asked this question when i was an early manager in fact the the my my timeline before i arrived at this question was i had i had worked as in engineering management formally for about two years and then i took three or four years and worked as an individual contributor again and then i decided to get back into engineering management so i started interviewing for some jobs. And I distinctly remember a company I was interviewing for asked me this question, what's your style? And it completely caught me off guard because my day to day had just been out of the people management and the formal leadership mode. And so I just wasn't really ready. And I remember really stumbling over this question.

This is also, in my personal experience, I've gotten better at answering this question by interviewing. Because- You can see what's on the menu. yeah but also it's at times i lack introspection about what i am doing and why i just do the thing that seems like the right thing to do and so being forced to try to explain why i think that is the right thing to do is a useful exercise for me because i rarely start from first principles to think like what is the correct way to lead here then okay i'll do that thing i just fly by the seat of my pants a little bit more are come work for me it's great i swear yeah it's really

really like good i swear i'm an excellent leader i'm an excellent servant leader yeah servant yeah i'll i'll serve you your box full of your possessions escorted out of the office oh no yeah so for me interviewing was helpful as a non-cringy way to practice explaining to myself what it was that I actually did and why. You can do this not interviewing also. You can try and write about it or journal about it or something. But I needed that practice

to be able to articulate what I did and to recognize what was different enough to be worth articulating. I'm going to suggest an exercise, which is imagine you have the job already. Imagine you are meeting your team. What are you going to do in the first, I don't know, 30 days?

How are you going to meet with them? How are you going to get to know the lay of the land? What priorities are you going to establish? How are you going to identify different skill sets on the team? I feel like it can be easier to pull a broad thing like leadership style out of like some specific actions you might take. So you might say, well, I'm very collaborative. I like to lean heavily on my direct reports and trust them a lot.

Or I'm very visionary. I don't know how you would ever say that with a straight face, actually. Presumably someone could. I have a strong idea of what I think is the right direction, and I help get everyone moving in that direction. And those are different, I think, different styles. You could kind of pull those out of what you would imagine doing in the first while on the job.

I've actually gotten the opportunity recently to help a company evaluate some candidates for the head of their engineering department. And so this question has been on my mind, like, what are the competencies and what are kind of the attributes that people can take different tracks on and that are valid and could be argued for in different situations? And what I mean by that is, if you just say, like, what's your style? And like you said, it's like, well, I'm going to be a good manager. I'm going to be a good leader. I'll just always do the right thing. Yeah, like no one would argue that the opposite is also a good idea, right?

Like, I'm going to be a bad leader. Like, no. So what that means is that you need to answer this question in ways that are true to you. And also, someone could take the opposite side. Because you want to find a company where your style is actually going to be well, that's going to fit in well, you know, and be be useful. So as I've been preparing for this, I've been writing down a few things I've written down, I think it looks like I've written down six, six areas. And there's probably a lot more, but this is the six that occurred to me. six areas in leadership, engineering management specifically, where I think you should take a stand and they can describe your style. And in most of these areas, there's like two directions you could take, like a left and a right direction, not politically, just, you know, that's left and right as a metaphor. It actually refers to the hands on your body. Anyway, I'll just run through these six real quick. How does that sound? Excellent. Okay. So like the first one is

performance management. Like what kind of performance manager are you? Are you the kind of person who holds people accountable? Are you the kind of person that just trusts that all performance management happens at the hiring? And then everything else is just, well, this is who we got and we're going to stick with them no matter what. The other one is processes versus results. Are you a process person or are you an outcomes person? Are you good at setting up meetings and reviews and handoffs and processes? Or are you someone who says, team, here's the direction we're going. This is the number we're trying to move. Number go up. Let's work together to get that number to go up. I don't care how you do it. That's number two. Number three, are you kind of

a hands-on inspector of a leader or a hands-off leader? Meaning, do you, are you going to review the code of your team members? Or are you just going to say, nope, I trust your code will be great. I do not want to look over your shoulder. Like these are both reasonable positions to take depending on your style. The fourth one is, are you going to be a protectionist manager? Like someone who it's like, look, I will protect my team from the rest of the company first. Like I'll bias toward protectionism. Or are you the kind of person who will see your team as, as like a resource to be managed for the company. You know, like, yeah, right now we have four engineers, but we should have two. And I can see from the business standpoint that we should have half.

So I'm going to cut the two. Or are you the kind of person that says, I will defend my team to the death? You know, there will be at least four team members at the end of this year, even if it means I have to quit, you know, something like that. Yeah. And the fifth one is, are you technical or not? And this is like really important to a lot of people to know. Are you the kind of manager who's going to be writing code? Are you going to be able to understand the architectural decisions that are being made? Are you going to have an opinion on the technical details

or are you going to be less technical? And the last one is, are you a fast decision maker or a slow decision maker? And like different styles make sense. Like, oh, you're working on a NASA program. Yeah, probably slow decision maker is the right one. Like we are going to consider every single possible risk. We're going to measure six times and cut once.

Or, you know, if you're at a startup that only has three months of funding, like it kind of makes sense to be a fast decision maker. That's what you would want to hire. So those are the six aspects that I think can define a style, which is why I struggle when this question is asked with such a simple thing. What is your leadership style? It's like, well, I can answer that along six dimensions. Do you have a few minutes? And they do. I guess they do. It's an interview. It's the interview. I have 60 minutes and this is my only question. So go ahead. Yeah. I like that. There's probably more axes that you

could identify here so many i'm sure there's probably an interesting blog post i'm sure that's already been written that i'll just find immediately after this or that could be written about this idea and if so you will write it yeah are you the kind of manager that writes blog posts or reads blog posts there's your style huh now i'm just thinking about this i'll bet jameson that after this once this question has been planted in your mind that you're going to go back to work and realize a lot about your own style based on how you watch yourself acting I bet I won't. I bet I won't on purpose just to prove you wrong.

Oh, that's part of your style. Are you contrarian? Contrarian or supportive? Yeah. Asking what your leadership style is, it's almost like saying, what is your personality? And it's like, oh boy, like there's entire tests about that. Yeah.

It's also, I mean, like anything in an interview, it's you're going to hear the words that they say. That doesn't mean that's their leadership style. I know, right? Those are just the words that someone says about their leadership style. So true. But hopefully it's kind of correlated. This is why I actually don't like the question, what is your leadership style?

Because you can have people say words that don't actually reflect their leadership style. Instead, I would like to figure out the list of style points, style categories that I'm interested in, and then ask you about situations you've been in. What would you do in a situation where you would have to make a trade-off between hands-off versus hands-on? Or what did you do? When was the last time you had an underperforming team member? Let's hear that story. Yeah. When was the last time you, you defined a new process? When was the last time you inspected some of your team's work and found it to be lacking? And when was the last time you were

asked to do a layoff? What did you do? You know? Yeah. What was the most important decision you made last year as a manager? And tell me about the factors you considered. You know, it's like, this is how you find out someone's leadership style in an interview. It's not like a perfect way, but it's way better than saying, what's your leadership style? And it's way, way better than saying, do you like good leadership style? Dave, I love your answer. I'm just thinking about it. I'm going to keep thinking about it. But in the meantime, I think we've answered the question. What do you think? I think it's probably as good as it's going to get. What can people do if they want their own questions answered? If you would like to know your leadership style when it comes

to filling out Google Forms, all you have to do is go to softskills.audio and click the ask a button. And my style in that situation is to thank the many, many people who have submitted their questions. In fact, I'm hesitant to say this next thing, but something magical numerically happened this last week, which I just noticed in our question backlog. What's that? We've now overflown the three digit mark on our question backlog, which means our job literally gets harder every week. Our mission to completely answer every question ever just gets a lot harder and we're not keeping up with it. But our commitment also grows every week to answer them all. It grows proportionally to the number of questions in the back. Yeah. We will get to all

of them as long as we outlast the universe. Yeah. Which I'm sure we will. There's some problems to solve first, but our commitment to getting to answer all the questions has some good side effects like the end of human aging and time travel and various other cool inventions. So look out for those, I guess. Thank you for listening. We will catch you next week.