Soft Skills Engineering - Episode 450: I'm terrible at behavioral interviews and time zonessssssss

Episode Date: March 3, 2025

In this episode, Dave and Jamison answer these questions: I struggle with behavioral interviews. I’ve gotten a little bit better as I’ve done more interviews, but it’s still a major pain point for me. I have some common behavioral question answers written out in a spreadsheet in SAR format, but I feel that not all of them are good examples for a mid-level developer. The main problem is that I can’t remember in detail all the things I’ve done at work in the past few years. For example, I can think of one time I had a small conflict with a coworker, but I can’t remember the details of what happened. I have a work diary of sorts, but unfortunately, I haven’t been regularly writing things down. Also, I usually just write down accomplishments and notable things that happened. Should I start writing down experiences that match up with these types of behavioral questions?? Do you have any advice on how I can jog my memory and reflect on all the things I’ve done during my career to craft good answers to behavioral questions? I also freeze up when I’m asked a “tell me about a time when…” question that I’ve never experienced. I’ve heard advice like “come up with a hypothetical scenario and explain what you would do” or “just lie and make up a story”. I’m the type of person who has a very hard time lying and making stuff up on the fly. I am one year into being promoted to a team lead at my company. We are made up of 4 devs, 2 QA, and a product owner. One challenge for our team has been differing time zones. Our 2 QA engineers are east coast while the rest of the team is on the west coast. Currently one of them signs off at 5pm EST and the other at 4pm EST. This means that if there’s any communication that needs to happen between dev and QA it has to happen in the morning since by 1pm PST they are headed out the door. This also constrains the times that I’m able to schedule meetings that involve QA. I’ve been thinking for awhile establishing a set of core hours from 9am-2pm PST but have been afraid of the pushback from our QA. I feel like making this adjustment is reasonable and other people I’ve asked have echoed that sentiment but my desire to people please and be looked at favorably is preventing me from making a change. In all honesty we can get by with the current set up, but I find myself getting bitter about not being able to schedule meetings in the afternoon and stories getting held up because QA is off the clock so early. What do?

it takes more than ludicrous typing speed to be a great software engineer this is episode 450 of the soft skills engineering podcast where i'm your host jamison dance i'm your host dave smith soft skills engineering is the weekly advice show where we answer all of your non-technical questions about the technical field of software engineering and we just assume you already have ludicrous typing speed because you gotta have that you can't type fast there's actually a typing speed test to subscribe to the show you have to pass it's really easy to pass the speed test is can you type before google forms shuts down right so far 100 success rate yeah we haven't turned anyone away dave do you want to thank your patrons yes i do big thanks to those amazing

human beings who are contributing at the level where we shout their name out or whatever they write as their patreon profile name every single week they are noah labart unsalted meow mix is morally objectionable jayro all gone they all unsubscribe from our patreon and now we have no money dave and jameson are definitely definitely human alexander kuznetsov chris Morton. Kyle Molyneux. Molyneux. Molyneux. Sorry. Oh, I said Kyle. Oh, man. I completely botched that. Nick Molyneux. Apologies, Nick. We will send you a Ferrari in the mail as an apology for that. We'll let you download it. You can download a car that we sent you. MichaelYoung.dev. Attribute error. None typed object. Has no attribute. Two string. Javier Gonzalez. Chewy.

Ted Timbrel. I quit my job, but it's 2025. Oh, my God. What have I done? Alexa, Alexa, Alexa, Alexa. Turn off all lights. BecomeASeniorEngineer.com is a newsletter you should read. unsalted french fries are morally objectionable generating side projects with ai so jameson notices my resume dan from drone deploy chase w norton never is not just a crater on mars i like chicken i like liver myomics myomics please deliver trash panda get status kyle boss can't see dodds hold on a second i have to sneeze 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 kings and i beautiful

functional user documentation three times shout out to angelica cathore williamangel.net has cookies oogala boogala 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 then all of a sudden it and last but not least cody sale big thank you to everyone who contributed if you'd like to contribute go to softskills.audio and click support us on patreon where you can send us money and in exchange we will not only feel good but we will also say whatever safe for work thing you type into the patreon name field i love how humans can develop a shared culture out of like just from scratch right unsalted meow mix is morally objectionable if you just

read that without context you sound like a crazy person but if you've been a dedicated listener you know that we're only moderately crazy yeah the context means slightly insane but less insane yeah oh y'all you're the best yeah thank you should i read our first question i wish you would okay this is from an anonymous listener who says i struggle with behavioral interviews i've gotten a bit better as i've done more interviews but it's still a major pain point for me I have some common behavioral answers written out in a spreadsheet in SAR format, but I feel that not all of them are good examples for a mid-level developer. The main problem is that I can't remember in detail all the things I've done at work in the past few years. For example, I can

think of one time I had a small conflict with a co-worker, but I can't remember the details of what happened. I have a work diary of sorts, but unfortunately I haven't been regularly writing things down. Also, I usually just write down accomplishments and notable things that happened. Should I start writing down experiences that match up to these types of behavioral questions? Do you have any advice on how I can jog my memory and reflect on all the things I've done during my career to craft good answers to behavioral questions? I also freeze up when I'm asked to tell me about a time when question that I've never experienced. I've heard advice like come up with a hypothetical scenario and explain what you would do or just lie and make up a story. I'm the type of person who has a very hard time lying and making stuff up on the fly.

I'm the kind of person that has a hard time lying. Good. Good for you. yeah although that could be a lie oh how would you know but then if it is then oh i got you brought up the sar format i've heard it described as the star method but as i was trying to remember what that's called so it's an acronym s is for situation i couldn't remember what t is for i think it's turbocharger yeah that sounds right situation turbocharger action results it's like here's the situation here's the action i took here's what it resulted in what is t in star the t stands for would you please give me an offer for this job

oh the task okay i i mean that sounds a lot like this situation yeah exactly it feels to me it feels like task and action i'm like i i think you guys were stretching to just find an english word yeah for an acronym you backronymed it yeah i like turbocharger better agree okay so yeah it sounds like you're already on top of that. That was going to be my big insight. So I'm going to smoothly transition to Dave. Oh, first and foremost, I'll say congratulations for not lying. That's great. I love that. Yeah. And also the advice you got, in my opinion, to resort to a hypothetical when you don't have an answer from your work experience. Also bad. I think that when someone asks you a behavioral question, they want a concrete example. They do not want to know the

answer to the question that you hypothetically would do because that is easy. Can we back up and just talk about what a behavioral question is? Because maybe it's unclear. Yeah. Great call, Jameson. To explain what a behavioral question is, we should start by explaining what it's not. The first thing that it's not is it's not a knowledge check. What does the following C pointer syntax do when you add three to a pointer? It's not just there's one right answer ready to go. So it's not like trivia. It's not like a monopoly. I said monopoly, but I meant jeopardy. Oops. Well, it's not like either of those. That's true. I guess they're both true statements. It is not like monopoly. It's also not where it's like, okay, what is the best thing to

do when you don't have enough requirements? It's not a hypothetical. Behavioral questions are designed to determine how you have behaved in a situation in the past in your work life for real and you know people find these to be the good interview technique or they're very popular interview technique especially at the fan companies because it's very hard to fake that you know because what'll happen is you'll say hey tell me about a time when and that that's how you know you're in a behavioral question like boom you hear those words tell me about a time when those six words you're in a behavioral question right now yeah and the reason people like them is because you can ask follow-up questions like,

oh, really? Then what did you do? Then what did you do? And it's very hard to fake your way through those. I've had a handful of people try to fake their way through them when I ask, tell me about a time when, and they're clearly kind of making up a story

or they're talking about something that they were only somewhat involved in, and they just don't have the details. But when you were a firsthand participant in a behavioral situation, you can easily answer lots of questions about it, unless it was a long time ago, and then people can still struggle.

but anyway i won't monologue any more about that but james that's my answer to your very good question of what is a behavioral interview that sounds great and now in the future when you're in an interview and someone says tell me about a time when you had to explain what a behavioral interview question was you can refer back to this i've got this i've got it yeah there was this situation yeah the situation i turned on my turbocharger and then let it loose oh man yeah so the so the widely agreed upon technique that jameson was describing for answering behavioral questions is the star method i just cut out the t unless you can work the word turbocharger in and then i'd say go for it yeah i guess we should probably define that

more clearly to the situation you describe the context because usually you can't just say well i got the project going like you have to say who was involved and what your responsibility was and I don't know. You need some details. Yep. The action you took and then what the outcome was, because often people are looking for not just did you do something that seemed reasonable, but was it successful? Yep. And you want to be able to say yes to both of those. The best R in the star is usually like the most concrete, easy to explain one is when a number goes up. And you can say that. Yeah, it's hard. It's hard to get those. But those are the ones that people really seem to like. It is the most rare. Yeah, my experience too. I feel like with

software engineering unless you're doing like performance or yeah optimization of some kind yeah you're trying to drive some metric like we had this you know we had this user ingress funnel and we had a really lousy conversion rate on one of the steps and i was able to make some changes and move it from 20 to 35 you know something like that yeah the the closer the line is between your work and dollars whether incoming or outgoing yeah so marketing funnels are sort of like incoming dollars and optimization is kind of like outgoing dollars then i think the easier it is to point to a number. But a lot of it is going to be kind of fuzzy. It's like, oh, yeah, people liked it, it launched or the team worked better after that there was less conflict or

in the absence of a concrete number. It's great to share feedback that you got like, oh, the product manager said that was the best delivered feature they had seen in years, you know, like third party accounts of your work. Yeah, I feel like I experienced the same struggle where if I were to show up to an interview today with no prep and someone said, tell me about a time when. I would just think, well, what if I didn't? What if that happened? I never did that. Do I have to have done that to get this job? Because I've never done that. I will stay silent and outweigh the question. That is my plan. So you just move on to the next one. I do have a hard time, not just in interviews, but in general, recalling clearly past experiences

and like everything in interviewing i've found practice makes this so much easier and practice can be mock interviews practice can be talking to your friends practice can be actual literal job interviews which is unfortunate if you really really want the job and it's the first interview you've done in your your attempt at getting a job and kind of this round because you might not be on your on your a-game but i found it gets easier with practice because i then deliberately have to spend time going back over my past experience and kind of mining it for details and blowing the dust off the crufty attic in my brain, which is where I keep all the things in the past beyond like yesterday. Yeah. That's not directly helpful. I know it's harder to get hired now. I guess I

don't actually know if it's that much harder to get started in interviewing. It's pretty hard, I think. Yeah. Then this is harder advice to apply than it was five years ago, like most of our advice. But I guess mock interviews, that should still be easier. You should still have a friend you can talk to about it, hopefully. I got some great advice from a mentor at Amazon many years ago now who said, at the end of every year, write down your accomplishments. Just write them down in a file somewhere and do this every year. And focus on the things that you felt were the most impactful, best things you did during that year at work. And I hate this process. It is so painful for me to review a year, but after I do it, I love the results.

It's so great to look at a year and go, oh, man, there's some really great stuff in there, things I should be proud of. But it takes real mental pain for me to dig through all of the artifacts that are necessary in order to do that. And what I found was, like I said before, producing that thing, I love the results. It's so great. But how do you actually do that? Because my mind remembers things from maybe this week and a little bit of last week. That's about it off the top of my head. And so what I do is I'll go through JIRA tickets. I'll go through all of the Confluence docs that I've touched over the last year. I'll go through pull requests that I wrote or reviewed. Any work artifact that you can assemble that has a timestamp on it from when you

touched it. And just read through those one by one. Just kind of read all the summaries. And that will jog your memory, at least in my case. And you'll be like, oh yeah, that huge project that occupied the first six months of the year that i haven't thought about in the last six months yeah yeah it is kind of wild for me certainly how fast i move on to what's next from what is done but yeah i like that before you go into any behavioral interview now you've got this year over year document where you can look over just the last few years and have a fresh look at things and then those experiences will be top of mind then i'm risking monologuing here but then what you do is pick the top three to five contributions that you made over the last three to five years

and every behavioral question that comes up, you find a way to bend it to tell one of those stories. Oh, absolutely. Yeah. It's like a presidential debate. The key is you smush the question into a question you have a good answer for. Right.

Yeah. Exactly. Oh, I'm so glad you brought that up. Yeah. And I mean, there's always, I feel like there's, I don't know, there's probably like five different behavioral questions for software engineers.

And then there's just a million little variants on them. One is always like, how do you deal with conflict? Another one is, how do you, like, can you lead a project? How do you ship something hard? Maybe there's only two. Maybe those are the two. How do you deal with conflict and how do you ship something hard? Maybe the other one is like, how do you influence or persuade a group?

Yeah, we should do this. We should, like, boil all of the behavioral questions down. Those are like the archetypes. Yeah, down to the platonic form of the behavioral question. Yeah, we need the hero's journey type of analysis. And I'll tell you, having sat on the other side of the interviewer table hundreds and hundreds of times, what I am looking for are shining examples of great contributions that you've made to your team. And if I ask you one question and you describe a star situation where you did a really amazing thing and it doesn't exactly answer my question, I'm going to be really happy with that answer, actually. So don't feel bad.

Yeah. You don't have to be a dirty politician to do this. Yeah. I agree with your earlier advice to not lie. And the hypothetical sounds rough, too. Are you saying just say, well, I haven't experienced this directly? Or are you saying this is where you need to then bend the question to your will? Yes. Yeah, you need to give an answer. But a hypothetical answer is just wasting time. You're just burning interview time. That's it. And that's time you could be spent sharing something awesome. But instead, you're just wasting the interviewer's

time because they're just waiting for you to stop talking so they can ask you the same question again and hope to get an answer this time. Yeah. I know I'm repeating myself, but it does get easier with practice. And I think all the techniques you described, Dave, are things that help you practice. Because I assume if you just write things down, I mean, that'll help you recall things. Your brain remembers stuff more if you record it. But also the idea is you probably want to review those before the interview. Yes, definitely. In fact, I kind of had this idea I'll share a technology solution that might help with this problem that I haven't tried, but I suspect will be very good, which is if you've been keeping these annual docs and

you have a list of all your JIRA ticket summaries and all of your GitHub PR summaries, you could dump all this information into a large language model prompt and then say, hey, please write five star style answers to behavioral interview questions and just have it give you a script and then just memorize that script, which won't be too hard because it is your life it's talking about, right? And yeah, it might get some details wrong and it might embellish some things.

And that's okay because you can, of course, correct. But basically, I think a large language model is really good at doing this prep for you. Yeah. I mean, you know what isn't good? Googling most common software engineering behavioral interview questions and then clicking on the very first result.

And? Because it's not behavioral. I mean, there's like maybe a third of them are behavioral interview questions. But maybe you can glean some from this, at least. I feel like that is another kind of thing that a technical artifact that has digested the entire internet would be able to produce pretty well for you. It's like, give me a bunch of examples of software engineering behavioral interview questions so I can practice. It's a little bit more divorced from your specific experience, but it could at least help you. And if you don't have a mock interview, you could probably prompt your way into like an okay mock interview. The problem is current LLMs are pretty obsequious and reluctant to tell you you are wrong and dumb. And I don't know.

They don't give any feedback besides like, great job. Yeah, you're the best. What a good point. Yes, you're right. I was wrong when I said that true thing. I see. Yeah, I see now. I messed up.

Let me try again. It's Kirsch's most commonly output thing. I know, right? I'll give one more piece of advice. and then i think i'm tapped out on this one which is if you have an answer to the question they asked but it's a bad answer do not give it instead that's really good advice give a different answer to a give a true but different answer like for example if it's like tell me about a time you had a conflict with a co-worker and it's like yeah i got so mad because my co-worker used tabs

and i wanted to use spaces that i walked over to their desk and punched him in the face it's like yeah do not share that story it will not help you now so that's an example of a like an an actively bad answer but even if you have just a weak answer like for example if the question is tell me about the most impactful process change you've made for your team and your answer is i added one lint rule once you know it's like that's that's a bad answer because it's in the right direction but the magnitude is really weak you know it's not showing big impact it's not showing big contribution and so find something better to answer it and frankly it would be better to give no and almost better to give no answer than to give a weak answer like because think about the

story that forms in the interview's mind when you say the most impactful thing i've ever done to help my team is i wrote one lynch rule you know it's like okay this person works on teams and doesn't contribute like that that's a narrative that will start to form you got to beat that narrative with something else like i'm at stand-up every week and i smile and and help the team feel motivated and I've gotten several feedback from multiple people that this helps the team function better. You know, it's like, great. Anyone can say that, you know, that's a lot easier than I wrote one Lint rule once. Yeah. Not the disparaged Lint rules, but you know, some of them can be really good. It's also sometimes interviewers are trying to find out

where your strengths lie and they're not necessarily trying to find out, are you strong at every single thing here? But are you a really product focused software engineer? Are you very focused on technical excellence or technical abstractions? Are you really focused on just talking to people in the business or the team culture or cohesion or all of them or none of them? And so it's not an automatic just red, well, red flag. It could be an automatic red flag. It's not an automatic no if you don't have a great answer for one of them or you give an answer that's pretty disconnected. As long as you feel like you can show accurately what you are strong at and what you uniquely are going to bring to the team and the company, you don't have to be

perfect. And no engineer is just incredible at everything and universally the best at every behavioral activity that they could possibly ask about. That's right. The way that I tend to evaluate these things, I said I was tapped out, but I got one more thing up here, is, you know, if you get five behavioral questions in an interview, and if you give just outstanding answers to three of them and then two just kind of weak answers, you're probably going to be fine if I'm on the other side of that interviewing table. Especially for a mid-level developer role. Yeah, exactly. We're not expecting you to be perfect at everything. And so the question that we tend to ask when I'm evaluating candidates is, okay, what are their strengths? Okay, got it.

Great. We'll set those aside. What are the concerns we have about this candidate? Okay, got it. And of those concerns, which ones are coachable? And if the answer is we have a major concern here and and we don't think it's coachable, that's usually a disqualifier. But if it's like, oh, you got three great strengths, I have two concerns, both coachable, and they're both coachable with the team members that we have, you know, I've got the right number of senior people to help and my manager is well prepared to do that coaching, then like that's going to be a yes. You know, so don't worry if it's like, oh man, I only got 60% of the questions really good and 40% of them I didn't have great answers for. That could be a good outcome still.

I really like that. What are their concerns and do we think they're coachable? I like that. All right. I think we've answered the question. Okay. Dave, do you want to read our next question? I shall give it my best shot. Okay. This comes from an anonymous listener who says, I am one year into being promoted to a team lead at my company. We are made up of four developers, two QA, and a product owner.

One challenge for our team has been differing time zones. Our two QA engineers are East Coast, while the rest of the team is on the West Coast. Currently, one of them signs off at 5 p.m. Eastern time and the other at 4 p.m. Eastern time. this means that if there's any communication that needs to happen between dev and qa it has to happen in the morning since by 1 p.m pacific time they are headed out the door this also constrains the times that i'm able to schedule meetings that involve qa i've been thinking for a while it's establishing a set of core hours from 9 a.m to 2 p.m pacific time but have been afraid of the pushback from our qa i feel like making this adjustment is reasonable and other people

i've asked have echoed that sentiment but my desire to people please people please yes sorry I didn't interpret it as a verb correctly. My desire to people, please, and be looked at favorably is preventing me from making a change. In all honesty, we can get by with the current setup, but I find myself getting bitter about not being able to schedule meetings in the afternoon and stories getting held up because QA is off the clock so early. What do time zones? They're not just bad in your code. they're bad in real life too yeah yeah i have been dealing with time zone code recently and i can reiterate they are indeed bad in your code yeah you can tell how recently a developer has

had to touch times unrelated code by how strongly they feel like the entire world should just move to utc yeah screw it california wakes up at 3 a.m or i don't know what the time would be but something like that yeah so i feel like there's an obvious answer here which is yep i think you're right and you have to tell them these are the core working hours but i think you kind of know that already you've hinted at that in the way you've structured the question it seems like you even checked with other people like hey does this seem reasonable and other people have said yes it makes me wonder are these qa engineers like are they particularly grumpy or intimidating in some way that makes you worried about it or or when you're into a team lead role maybe it's just

kind of not super comfortable pushing unpopular things which i mean i guess nobody really gets comfortable with that but yeah it does get easier with more time true so i've i've worked remote for a long time and time zone distributed for a long time in almost all of these cases there was you there was a kind of central place i almost said central time zone and that is oh yes because it wasn't ever the central time zone in the united states but there there was like a base yeah and then the team was distributed but like enough of the team was in this one time zone that was kind of centered around that okay and it was not in any of these places a hard expectation that you would work the core working hours of the base but it was it just kind of exerted this gravity

that sort of pulled working hours a little bit more to overlap more with the central place the main time zone yes the main the primary time zone yes how about that okay so i think it is perfectly reasonable to say hey most of the team is pacific time we need to have the most overlap we can with pacific time zone and then make a change because of that also 4 p.m eastern time that's not working hours like even on even on the east coast they should not be doing that i mean if if you're working with a west coast team and you sign off early on the east coast like yeah they're they're already i don't know i think it's a fair expectation to say hey you need to maximize your overlap with this team. And nine to five is a pretty reasonable expectation for

working hours. So you need to not do that anymore. I don't know. Start your day later. I think if I was in this situation and well, first of all, you're the team lead. So it probably is your duty to solve this problem. So let's just state that up front. You're not just trying to influence someone else to solve it. And if I woke up in this situation, I would do some analysis on the work tasks that have been affected by this problem. And I would count them. I would say, okay, maybe you've had 10 instances where a task was delayed by one day because QA had already gone home for the night and the developers still had iteration to do. Because that's the problem I've seen with this. In fact, I live this life, except with a much worse time

zone gap where we had people in Eastern Europe and I was in mountain time in the US. So there was about an eight or nine hour time difference, which means we'd come in in the morning and we'd have a couple of hours of overlap and we you know developers would fix any bugs that qa had found overnight and then send those fixes over to qa hoping that they would get to them before they go but often they wouldn't so then you'd have to wait till the next day to find out if your fixes had passed qa and if they did great and if they didn't well guess what one more day so it's like it's like 48 hours minimum turnaround time on all qa reported issues it was really honestly it was really terribly painful. So now the way that I organize my development teams is I will never put

QA more than an hour or two away in time zone, unless they're willing to agree to work in the same time zone as the developers or the developers are willing to work in the same time zone as QA. Because it's just so bad. Anyway, so sorry, what I was saying was I would go and count all the tasks that have been delayed. Quantify this problem. That's the beauty of this particular problem is it's very easy to figure out, well, it takes effort, but the math is not hard, right? And it's not subjective. You can figure out the delays probably pretty straightforward. So the team is in differing time zones.

I wonder if they are working remotely, working from home, or if they're in different offices. Because if they're working from home or fully remote, then it's so much easier even to just say, start your day a little bit later, end it a little bit later. It's like, you're not worried about traffic. You're not worried about, I don't know. You already have all of the convenience of working from home that it is easier to deal with a little bit of inconvenience around shifting your schedule exactly if you have to go into an office then that's a little bit trickier but i also think the cold calculating soulless like

my model of the the sociopathic experienced fire of people ceo type is sort of like qa is generally a less valuable skill than software engineering in how much it costs to hire and like deep knowledge of the product is extremely important. So it's certainly not free to just replace QA. But I do think it is easier to replace QA than replace software engineering. I don't feel like they have a ton of leverage either to say, and no, we won't. We will not do it. Then you get to say, okay, well, it's a requirement for the job and we'll find someone who can and it'll suck, but our team will be faster overall. Jameson, you're a monster. I know. I just can't believe that you would actually say there are quotation marks around all of what i just said okay and then at the end it

says by the cold calculating sociopath yes fire of people got you i forgot i missed the open quote but i got you now yeah yeah you would never say anything like that of course i would never say anything like that i was just listening to a podcast where they they extensively quoted someone saying kill our enemies and they kept making so killer and i can't say kill our enemies but we're quoting this person who's saying kill your enemies um it's kind of like that perfect i think your team will be happier they're probably not pumped like the software engineers probably don't love the fact that they it's 2 p.m and great qa is gone my bug fix is done and oh oh they're gone because oh oh yeah one of them leaves at 4 p.m local time great great great great great yeah now

what do i do for the rest of the day i'm just kind of stuck yeah oh being blocked like that is just so painful yeah it's like i'm in the zone i'm i'm rocking i'm ready to go and then boom nope you're not you definitely increase context switching because you have to just say okay i'll go do something else because i'm not just gonna sit and do nothing for the rest of the day and then now you've got multiple parallel things and they take longer for each of them and yeah it's it's no good so i i think you are worried about people pleasing but you can twist that into saying i will please the greatest number of people on my team if I move QA's working hours to extend later into the day. Yes. As an engineering leader who is also a people pleaser, do not be afraid to make decisive,

clear, team benefiting decisions because that is actually the greatest way to please people. No one likes an indecisive leader who is unwilling to confront the real problems your team is having. Yeah. I've definitely felt that as a similarly inclined to people please leader that if you're really waffly because you don't want to offend anybody, then it can come across as very unclear what the actual decision is. And it's a different kind of displeasure or pain that you foist upon your team to say, well, I don't know, what do you think? And just sit in this limbo for a long time. And they may never tell you about it. Yeah.

Especially if they think it's your fault. You may never hear about it. Yeah. Yeah. I had kind of this awakening some years ago when I was in this mode of people-pleasing, and I thought to myself, I just want to explain clear principles, and the team will just automatically do what I want. And it'll be so great because I won't have to tell them specifically what to do. They'll just do it, and it'll be what I want. And I had one of my team members say to me once, Dave, we want to do what you want. Could you just tell us what you want?

And I was like, oh, I am so grateful you said that. My mind was just absolutely flooded with gratitude because I thought, oh, I've been so worried that I'm going to give some clear direction that they don't want to do. And then they'll resent me and I'll be like a totalitarian boss or something. but in reality the main thing that they wanted was to make me happy by doing what i wanted and i was like oh that's so great like they're actually look like we don't actually care that much which direction we go here just tell us you know if we are my main thing is i want you to be happy dave now not not everyone is like that right like some people do have strongly held opinions and they'll you know they they might resent you if you make a decision that's opposite to those opinions okay fine it happens but a lot of people just want to make you happy because you're their lead so you know lean into that yeah and some of its power structure stuff of like well

this person who has some authority over my job i want them to be happy some of it is legitimately like it just feels good to have a clear vision and clear direction yes and it doesn't have to be from your own brain to feel good if you feel like someone has articulated something very clear and you you kind of don't disagree it seems reasonable great that that's great everybody's pulling together, I think that feels nice to be on a team like that, even if it's not your specific direction. I agree. I feel that. Well, I don't have much more to say about this. I think we've answered it. I think what to do is clear, and hopefully we've given you enough that you can overcome your reluctance and fear of bad reactions. I think your instincts are right. This is the

right decision. I agree. And I think after a little bit of quantitative analysis of this problem, if you present the problem to the team and then describe the solution that you want to impose on the team, I think that not only will that be the best possible way to deliver it, but I think most people will go like, yeah, that makes sense. For the benefit of the team, I can stretch my work schedule and I can shift my work schedule to be an hour later. And you can even tell them like, look, if some of you have a problem with this, if you have personal reasons for needing this current schedule, come talk to me. Let's discuss and see if we can find a solution together. Yeah. All right. Yeah. I love it. I love it too. Mostly because of the friends we made along the

way were we not friends before this episode i just feel like we leveled it up this time okay good okay good good good i was very briefly concerned 450 that's how long it took dave doesn't open up very quickly yeah you probably noticed that by now from listening to the show it takes time standoffish oh my gosh i'm glad i could break through your crusty exterior. Yeah, finally. You earned my trust. What can people do if they want to similarly earn our trust and ask their own questions? Go to softskills.audio and click the ask a question button. We thank you, each and every one of you, for writing in your wonderful questions. We promise we'll get to all of them. That promise becomes harder every week thanks to your

amazing questions that you write in. Thank you. Keep them coming. Thank you so much. We'll catch you next week. I'll see you next time.