Soft Skills Engineering - Episode 469: Passed over for lead role and perhaps I'm the jerk

Episode Date: July 14, 2025

In this episode, Dave and Jamison answer these questions: I’m a long time listener to the podcast. Thanks for reading and answering my question! I have over 20+ yrs experience as a manual QA and 6+ yrs experience as a SDET. I’m in a new role as a hybrid manual QA / SDET for a company that hasn’t had QA for a few years. After a couple of months a new hire was added to support a new project in non-development or QA tasks. While waiting for the launch of the new project, senior leadership decided to have this new hire to help me with QA. They have no experience in QA or coding. I spent a considerable amount of time training them, and found it difficult. After a few months my manager told me the hire will transition to lead QA. They will NOT be my supervisor or manager. I will be answering directly to the manager as before. I feel sidelined since I didn’t get hired on as a Sr. or Lead role. I’ve already been left out of numerous meetings catered to team leads only. The new hire is very vocal in meetings. They repeat my ideas as their own, and speak for me when I don’t agree. It’s exhausting to hold back ideas from the new hire or correct them and add context to the rest of the team when I disagree. I’m worried I’m training this new QA lead to be my replacement. What are your thoughts? I feel like the company culture is chaotic for the long term. Any thoughts what I should do in the short term and long term? Hi Dave and Jamison (as a unit would you answer to Davison?). Long time listener, first time caller. I recently joined a data-engineering team at chill 90s multi-national tech company. My boss and I are based in the UK, and two more junior engineers who do the bulk of the IC work are based in India. These two engineers seem to work hard, have far more domain knowledge and technical ability than me, and generally seem to do most of the work. There’s also a senior engineer who’s kind of absent. My boss is a ‘red personality’ who’s been at the org for at least a decade, who doesn’t seem as close to the technical detail. He cares about the destination and wants to get there yesterday, but discussions about ‘ways of working’ or the specifics of achieving the output seem to bore him. He characterizes such talk as risk-aversion. I’m shocked by some of the technical details. Tooling chosen specifically to bypass version control, editing Jupyter Notebooks to deploy changes to ‘production’, dashboards that seem to have totally wrong data, etc. It seems like they will do the minimum required to make things ‘work’ and then move on. Scalability or making things interpret-able for others just doesn’t seem to weigh on their mind. It’s then me as the new-joiner navigating their hacky code who inevitably wanders into all the pitfalls and gotchas. I’ve tried to advocate for better practices and lead by example. They nod along, but ultimately seem resistant to change. I need their help and experience with the codebase, but I also have this creeping sense that their working style is too sloppy and unprofessional. They don’t report to me, and our mutual boss seems happy with the work. I feel a bit like the guy in Twilight Zone: I can see a gremlin wrecking the plane, but nobody else can see it, and my attempts to address the situation just seem a bit hysterical. What’s worse, my gentle attempts at flagging the issues with my boss haven’t gone down well. In my first performance review my boss mentioned something about a ‘us versus them attitude’ and ‘assuming good intent’. What do you make of this situation? Am I the a-hole? Have you faced this sort of thing in the past? Is it time to consider old-reliable? Is 4 months too soon to quit a job?

it takes more than backpacking with your eight pound work laptop to be a great engineer this is soft skills engineering episode 469 i'm your host dave smith i'm your host jameson dance soft skills engineering is a weekly advice podcast for software engineers about all the non-technical stuff that goes into being a great software engineer besides carrying around work laptops because you're on call but still want to be in the mountains with your satellite internet connection yeah i was gonna say is this because you're on call or is this because it's like a talisman where you feel naked without your laptop in your backpack yeah and also does this allow you to now be one of those people that plays music on a bluetooth speaker while you're walking around

except it's like playing from your laptop instead of right because cell phones can't do that these days yeah they're not powerful enough i have never for the life of me understood it's really clear to me why everyone hates it when people do that right in nature and yeah i'm not here to listen to top 40 but like what is going through their mind when they say i will do this and this is the right thing to do backpacking or hiking or whatever i don't know i gotta find one of these people that i that i love still some people are so awesome that they deserve a soundtrack that must be enjoyed by everyone in the vicinity. If that's the case,

I feel like you could have a song written about you. It's just like, here comes a special boy or something like that. Just to let everybody know. And here comes a special boy and his soundtrack. Yeah. Yeah, that would be cool. Oh, that's not what this show is about.

I'm going to thank our patrons. Let's do it. All right. Thank you to Matthias Feist. My actual name on LinkedIn is Yami debugging in the dark Connie, the mobile development extraordinaire. Oh, wait, no, sorry. Ordinaire. I almost said extraordinaire. Yeah. First of his name, quote, or one equals one drop table. Meow mix. Jacob Shandling Bjorn.

Where's my stapler? Let's not get Dave and Jameson involved in this silly feud. Also your mom called. She misses you. The missing semicolon. Christy, the world's okayest programmer. noah labhart is this a pro-avian podcast in general or just geese i have some ancestral hatred of magpies passed down from my father ancestral hatred yeah he hates him oh man i don't hate them as much though so i think it's it's like the bloodline hatred is thinning out there yeah i think i'm okay with the rest of them okay alexander kuznetsov nick molyneux attribute error none type object has no attribute fetch

dad joke javier gonzalez chewy ted timbrel hey seaman thanks for the update since slack's out of budget now i agree this is the next logical step best bjorn doing my part to make dave's heart swell but he should probably get that checked dan from drone deploy unsalted password hashes are morally objectionable yes yes never is not just a crater on mars flamingo emoji i like chicken i like liver myomics myomics please deliver trash panda python summit python dash summit.ch 16th october a swiss swiss python conference kyle boss kent c dodds that guy over there jenny kim the stochastic parrot no jonathan kings nigh beautiful functional user documentation yes should williamangel.net add a cookie banner vote now nice bullish on

figma's ipo braden canes john grant britney ellick benadryl cabbage patch thank you i went to williamangel.net to look for where i could vote and i don't see it my vote is build the most obnoxious cookie banner of all time yeah not a cookie banner a cookie wall cookie barrier what oh jameson that would be the most funny ironic b2b sass company it's like a cookie banner vendor that's just prides itself on making the most obtrusive interruptive hard to use banner that absolutely stops your customers from getting to what they need to get to now okay i'm trying to think of how you could make this possibly useful it'd have to be a sabotage thing right like get your competitors to use this vendor that will tank their traffic or something oh yeah i like okay i

I haven't seen investment advice yet in these shout outs. This is the first time. So this is interesting. Oh, which one? Bullish on Figma's IPO. Figma, they filed for IPO. Oh, yeah. Yeah.

Good one. Sorry. I was so swept up by the idea of an adversarial cookie banner. I missed the last few names on the list. Oh. All right. Should we read our first question? Let's do it.

Okay. This comes from an anonymous listener who says, I'm a longtime listener to the podcast. Thanks for reading and answering my question. I have over 20 plus years of experience as a manual QA and six plus years of experience as an SDET. For those that don't know, SDET stands for software development engineering test, typically creating automated testing software. OK, I'm in a new role as a hybrid manual QA slash SDET for a company that hasn't had QA for a few years. After a couple of months, a new hire was added to support a new project in non-development or QA tasks. While waiting for the launch of the new project, senior leadership decided to have this new hire help me with QA.

They have no experience in QA or coding. I spent a considerable amount of time training them and found it difficult. After a few months, my manager told me the hire will transition to lead QA. Oh, boy. They will not be my supervisor or manager. I will be answering directly to my manager as before. I feel sidelined since I didn't get hired on as a senior or lead role. I've already been left out of numerous meetings

catered to team leads only. This new hire is very local in meetings. They repeat my ideas as their own and speak for me when I don't agree. It's exhausting to hold back ideas from the new hire or correct them and add context to the rest of the team when I disagree. I'm worried I'm training this new QA lead

to be my replacement. What are your thoughts? I feel like the company culture is chaotic for the long term. Any thoughts what I should do in the short term and long term? Yikes. Yeah, this is wild. hired someone with no experience for qa now they're leading qa there's there's got to be

something going on behind the scenes here and i think none of the things are great for you personally but on the face of it given the facts you have told us this does not make reasonable sense i i feel like either someone in leadership does not like you or thinks you're doing a bad job or too expensive or you've offended them somehow or maybe there's some like i don't know maybe they're the brother-in-law sister-in-law of like someone in executive leadership or there's some there's some like outside relationship causing them to be nudged this way yeah i don't know i feel like the the story as you presented it does not make sense so there's something else going on which is not a great place to be in part of it made a little sense to me which was this this

misunderstanding of the QA job function where you say, oh, we hired someone, but their regular job isn't quite ready yet. So let's just have them do QA while we wait. Yeah. You're saying that this kind of indicates they don't really get what being good at QA is. Yeah, for sure. And then, I mean, look, I don't know. I'm not sure what happened here, but one possible explanation is that they got this person in the role. They really like this person's personality. I mean, it sounds like they're good at talking, right? They talk a lot in meetings and I don't know, they they come across well in groups oh yeah and did i say very local in meetings i may have when i read that i think i was supposed to say very vocal in meetings my eyes like misread that

word anyway so yeah vocal in meetings gives up my ideas and everyone's like yeah great idea so i think that's probably what happened here i i am less inclined to ascribe this these reported sequence of events as some kind of conspiracy to remove you or replace you because of how it came to be this person got hired clearly to do something else not qa stumbled into qa just because of an opportunity there and then everyone fell in love with them yeah i mean i think it's a fair question to ask hey why am i not leading qa i don't know that you will get a direct answer because yeah because direct answers are painful painful to give yeah it's like well because you are abrasive or i mean i i'm not i'm not saying these are the actual reasons but it's

generally it it's probably something about your character or personality or some something that feels immutable about you that makes it not a good fit in someone's eyes like you just don't have the leadership gumption of i don't know a great looking headshot and cool jewelry or whatever their criteria are yeah it's mostly just the jewelry yeah if you could get one of those giant diamond encrusted necklaces but it says qa on it that'd be pretty cool maybe that would sway some minds i mean look if you're worried that you're being you're training your replacement all you have to do is train them to fail so you're giving them like really convincing but wrong training information so for example you could say like hey listen as a qa person our job is to make sure that

all of the bugs are present in the software that we ship to production so that people can see it and it goes in sunlight which is the best disinfectant that almost sounds plausible so yeah we're trying to expose bugs so that we get the bandwidth and resources to really fix them yeah the only way to do that is if they if they really are in people's faces when they use it exactly short-term pain for long-term benefit yeah yes don't worry it's the long play yeah yeah and and that's what you got to do and as the qa lead you got to think about the long term that's part of your role right if you're just doing this short-term stuff where you're like fixing bugs and stuff look i i hate to break it to you that'll be a short-term win but long-term

problematic yeah training this new qa lead to be my replacement so i think there's i think it's tough to directly address this problem in terms of changing how people view the QA lead. I think it's probably easier and more in your control to manage your own reputation and perception of output and value than it is to tell people like, look, they don't know what they're doing. They shouldn't be in this role. They just repeat my ideas. I think that's a little bit harder and gets into it can escalate and i don't know so i think if i were you i would try to put in deliberate effort to make sure that my value was clear to the people i worked with and people that they work with so if the development team really loves you if they say oh i'm so glad you found these bugs and

you test so so in depth tell them hey i would appreciate it if you if you shouted me out i'm i'm i don't know yeah trying to make more people aware of the value of qa at this organization and if you find it useful then then help me spread that yeah this is actually tricky because sometimes qa kind of can be and sort of needs to be in some ways a little bit adversarial with dev so i don't know it depends on the relationship you have adversarial is also probably too strong of a word but you kind of have different incentives but hopefully you work well with them still and have a good relationship so if you are worried about being replaced clearly communicating your value yeah so that it bubbles up to the people who decide resource allocation

is is important because you want them to think well we can't possibly replace this person they're so valuable they're so effective yeah all the stuff that they do look at the reputation with the team i'll add one thing as a like a protective defensive layer of your own career which is that look you've got over 20 years of experience in quality assurance you've seen quality assurance done great you've seen it done badly and you have the ability to influence this organization like they did not hire someone with that little that much experience just to come in and do what they're told and you know punch tickets through the backlog so i would i would recommend that you become opinionated and tactfully communicate and articulate ways that this organization can do a

better job with qa and i also read in the question that this organization didn't have qa for what to say for a few years. I've not had QA, which means there's a nice vacuum here for you to just settle into and really make your opinions known. I think there's a lot of good you could do to bring some structure, bring some informed, valuable opinions to an organization that probably doesn't have that right now, that doesn't have that muscle. And it could very well be that this person who has literally zero QA experience, doesn't know anything, is so gregarious and kind of charismatic that they are accidentally setting QA policy in your absence, in the absence of your voice. And so I take this as an opportunity to jump in and make your voice heard and really

lean into that experience. Be like, look, I've seen this done seven ways. Five of them fail, two of them work. I'd like to recommend we do the one that works. Really good. That carries a lot of weight in a company when you've seen things done a lot. Yeah. Yeah. I'll add one more thing onto that which is i i think i've seen especially in orgs where there's not a lot of experience with the role that you have a lot of experience with there can be this tendency to if the org disagrees with your recommendation for some reason or another they can start to develop this opinion of you as like the curmudgeon that oh they're just stuck in their old ways and change with our circumstances and times so i think it's you you should be opinionated you should be recommending

things you also will need to do some amount of the old disagree and commit stuff from amazon of like if you just have this chip on your shoulder of well i recommended this thing and they didn't take it and i'm gonna bring it up a bunch and and remind them oh you did this wrong like i think that that can be bad for your reputation as someone who who is going to help lead and shape this organization and can make it harder to lead and harder to have your advice taken yeah but i think you can do it you got so much experience yeah you got a lot to draw on here you know how to do this yeah well have we answered it i think so good luck best of luck all right should i read our next question let's do it this is from an anonymous listener who says hi dave and jameson

as a unit would you answer to davison uh you know i think i would yeah why not sure a long-time listener first time caller i recently joined a data engineering team at a chill 90s multinational tech company my boss and i are based in the uk and two more junior engineers who do the bulk of the ic work are based in india these two engineers seem to work hard have far more domain knowledge and technical ability than me and generally seem to do most of the work there's also a senior engineer who's kind of absent my boss is a quote red personality who's been at the org for at least a decade who doesn't seem as close to the technical detail i actually had to look up what red personality was and there's this like personality color test thing yeah have you heard i this was

news to me have you heard of this yeah i'm familiar with this one yeah red is like the uh leader take charge yeah kind of like decisive yeah maybe not as into like the details very outcome focused and and maybe hurts feelings along the way yeah kind of like yeah maybe aggressive would be a way to say yeah aggressive aggressive yeah or assertive for sure aggressive sometimes yeah okay anyways he cares about the destination and wants to get there yesterday but discussions about quote ways of working or the specifics of achieving the output seem to bore him he characterizes such talk as risk aversion i'm shocked by some of the technical details tooling chosen specifically to bypass version control editing jupiter notebooks to deploy

changes to quote production dashboards that seem to have totally wrong data etc it seems like they will do the minimum required work to make things work and then move on. Scalability or making things interpretable to others just doesn't seem to weigh on their mind. It's then on me as the new joiner navigating their hacky code who inevitably wanders into all the pitfalls and gotchas. I've tried to advocate for better practices and lead by example. They nod along but ultimately seem resistant to change. I need their help and experience with the code base but also have this creeping sense that their working style is too sloppy and unprofessional. They don't report to me and our mutual boss seems happy with the work i feel a bit like the guy in the

twilight zone i can see the gremlin wrecking the plane but nobody else can see it my attempts to address the situation just seem a bit hysterical that episode gave me nightmares i don't know how but i somehow somehow watched it as a kid and it was like a recurring nightmare wow the gremlin munching on the plane i think it was just this fear of like oh no it's going wrong and no one else can see it that's like classic engineer fear yeah yeah what's worse my gentle attempts at flagging the issues with my boss haven't gone down well in my first performance review my boss mentioned something about an us versus them attitude and assuming good intent what do you make of this situation am i the a-hole have you faced this sort of thing in the past is it time

to consider old reliable is four months too soon to quit a job oh oh wow oh you're four months into a new job and figuring out all these personalities and learning how to navigate it it's such an awkward time that's when everything kind of comes out you know it's like the first couple months of the honeymoon phase you're like oh that was weird but that might be okay yeah by four months you've seen them all and you've seen the patterns repeat yeah yeah okay so this is interesting i'm assuming they're an ic yeah kind of like a more senior ic yeah i think joining the team yeah and if i'm summarizing the problem it's you have these two they seem like sort of the cowboy coder archetype like productive to the business at long-term costs to engineering quality and productivity

and so that that stuff is the business loves cowboy coders because they they love the quick output and it's hard for them to understand the longer term costs especially if you keep covering those costs yeah yeah hmm i mean you've got here i gotta tell you this this question asker i think is going to be swimming upstream maybe for your whole career because data engineering at its heart i have often found to be let's just say like pretty hacky and i i don't mean to say that data engineers are hacks or are not professional what i mean to say is that the industry seems from what i've seen it seems to be permeated by this less of a desire to have all these automated systems and like perfect quality checks before everything goes out

to production and even the definition of production is like what is that well it's it's an etl or some workflow that populates a database that is consumed by dashboards that gets used by the business and the cost of an error is is usually very low because the error looks something like oh an executive looked at this dashboard and got mad when the data was wrong and we fix it the next day you know and it's like one person affected it's not like and we lost a million dollars in revenue while the system was down because of a glitch that got shipped to production yeah i mean i think the real cost is like this data was totally wrong we made these big business decisions on it that that feels much scarier but that's also harder to point out i guess

yeah and i mean depending on what data is being engineered like you're definitely right like it could be that the business was operating for months or years on incorrect information and making bad decisions for sure the other the other kind of data engineering i often see is like data that is powering like model training data and stuff like that you know so that could be what's going on here in which case yeah like actually you probably should have some really aggressive quality controls in place because presuming these models are like customer facing or in production like business critical flows so but nevertheless this field is permeated by band-aids duct tape and uh cowboy coating so it's kind of like i don't know man you might be up you

might be having some headwinds here i think i have the same vibes not having been deep in the field but i think it's not like lack of skill or or care yeah on the engineer's part usually i think it's this field is more uniquely exposed to business pressures and needs it's perhaps yeah some executive needs a report tomorrow right and you gotta go like sprint to cobble a bunch of stuff together i don't know it feels like it's it's often pretty ad hoc it's less like you're building up a product with a roadmap although i'm sure that exists in some places but i think a lot of it is like responding to specific needs totally and a lot of firefighting like oh i remember i've seen so many times where the product itself gets updated and it like completely invalidates some

data engineering flow for like a bi workflow yeah and of course nobody tells the data engineering team like oh by the way exactly the change has been in the works for three months yeah the scheme is going to change and yeah no one told the data engineers they just wake up one morning to a like a five alarm uh fire drill and uh it's like well what do you do like it's got to be fixed in hours not weeks or months so what do you do the expedient thing it sounds like you're arguing for jupyter notebooks as a way to deploy to production because yeah it's like a pretty easy yeah it's great yeah you just type and then hit enter i mean yeah i guess i'll just harp on this point for just another minute and then i promise i'll i'll actually give a hopefully useful answer but

there there certainly is an like an impedance mismatch situation here where if you are a highly orderly person and you want long-term highly automated good quality scalable workflows and whatever data engineering unit economics are you might be just suffering a lot i don't know but i kind of want to set that aside and just say like all right let's say you actually do want to influence this team and it is the right thing to do for the business and all the stuff i just talked about with the headwinds and the and the swimming upstream and any other metaphor that makes your job harder are just off the table well in that case now you've got to try to exert some influence on these people who don't seem to care and not only that but you're being managed by a manager

who doesn't seem to care and for sure your engineer co-workers are latching on to that and they are going to respond to that incentive so i don't aside from i don't think you're going to convince your manager to start caring so what do you do well the good news is your manager doesn't care that's also the bad news the good news is you can kind of just take this over you don't need to go get permission from your manager from what i'm reading here your boss has basically given you a blank check to do whatever you want because he simply doesn't care about the things you care about and so what that means is you can put in place programs and practices and processes and help your other team members abide by them and kind of just assume that you're the leader here

I'm trying to look up so they're in India you're in the UK four and a half hours ish is London to Bangalore I worked with folks in in India and it was like 11 and a half to 12 and a half hours which was rough but in the UK it's going to be a lot closer yeah this is enough of an overlap that it definitely makes it harder I think this would be an easier problem to deal with if you were in the same time zone but there's enough overlap there that you could spend a significant amount of time in real-time collaboration for sure you mentioned your boss called out this us versus them attitude i could see this coming up if if you're kind of complaining to your boss a lot about like oh they they do things the wrong way there's all these problems that they're causing and you've

tried to advocate for better practices they nod along but ultimately seem resistant to change you could just pair with them a lot and say hey let me help you implement git in this workflow one of the challenges you will have is i assume that your boss cares i mean i guess you kind of said it he just cares about the outcome and the output and not about how you do it which is great and i think some of the practices you'll put into place will at least in the short term result in lower output because you're going to do less tweaking in jupiter notebook and more some other workflow presumably that is maybe a bit slower so i think one of the challenges you have is decide on what good looks like and then the other challenge is how do you how do you move

towards that incrementally without tanking your velocity because i don't think the blank check covers we're going to just go off and build this framework or i don't know make this infrastructure overhauls and we're not going to deal with the the business needs for a little while like you'll still have to deliver on those but you need to be improving the architecture while you do it yeah if the team members nod along but are resistant to change i think you can make the commitment a little bit stronger by putting in stuff like i don't know automated tooling to gate changes right like cool you say you want to do it this way and you agree but then maybe habits or incentives take over and then you do it in this other way some kind of linting things some kind of i don't know

system that only deploys if changes are checked into version control like if you can get verbal agreement about why this is good and then put in a system to enforce it i think that that'll that'll make it easier to stick to it absolutely yes totally in fact i would say any any kind of agreement you come to there without a mechanism for enforcement is doomed to revert back to the prior mean yeah yeah i mean their incentives are strong habits are strong yeah and it's really easy to say yeah i would love to do this it sounds like a great idea and then you get into work and the fire is going on and you're like cool i can do this the fast way that i know that my boss will like or do this new thing that i am that this random guy who i don't report to says he wants

yeah yeah you do kind of have to sell up and down yeah for sure for sure now and and in this case the beauty is you don't have to sell up as much you know if you had a micromanager in the seat then it would be a lot more challenging to accomplish what you're trying to do i guess when i say sell up i'm i'm i'm assuming that you'll need to get some kind of permission or cover to do this change to account for the lower velocity right unless you can sweep the lower velocity under the rug a little bit like it's almost like tackle changes that will have the lowest impact on velocity as possible at first and then show the benefits and show the no cost you know our low cost or if any cost to your manager and then kind of get your manager to

buy in and realize that you're actually on the same page not knowing the specifics here i feel like this would be a good time to just sit down and write out a plan you kind of have your list of problems lists of pain points or things that are the most egregious or or hardest to deal with and maybe rank them by pain come up with some solutions kind of rank those solutions by effort if you end up with some sort of like list of stuff to do and how long it would take and then and then order that by rough like impact effort combination that might give you a way to make these changes to gradually improve it could feel overwhelming if you just step into a code base and say oh this is all wrong oh no yeah everything here is wrong totally we have to change everything but

you can't change everything all at once so isn't it amazing how much of how many of businesses problems can be solved by making a list and putting it in the right order yeah it's kind of incredible interestingly i have found that's a thing that lms are very good at ah they're very good at helping with planning if you provide them detailed input of the state of things and the such like the the the outcomes that you want and they're helpful rubber ducks for for kind of like organizing that information as long as your input is good i was just gonna say it sounds like a rubber duck it's like really the organization is actually happening in you as you communicate to an llm that you know is listening very intently yeah i think so they're much better than a rubber

duck in that sense yeah rubber well i don't know what's better than a duck a rubber nvidia h100 a rubber shoggoth isn't that the lovecraft thing i don't think i've ever said that word out loud or heard it said out loud how do you even spell that s-h-o-g-g-o-t-h i don't know it's uh have you seen those memes of there's this like tentacle monster thing with the little happy smiley face stuck at the end i don't know if i have oh okay this is a thing that was going around in the earlier days of llms a few years ago okay to get people to think about safety and oh yes how they have this friendly face but you really just don't know what's going on yeah i see the memes now online i'm looking so everything we're talking about here is culminating

i think in starting with a written plan and can i just propose that one of the things that i've seen that drives agreement the best on a team is by writing down a your intentions like number one thing is what do i intend to do because your boss has already told you please assume good intentions with me you're like okay well why don't we just state our intentions explicitly so we can get alignment on that and you may or may not want to share this with your boss but at the very least it's for you to become clear about what you want to do. And I would write them down, maybe there's like three, five intentions that you write down, then I would write down a list of tenets. Because I think what's happening here is you're having priorities that are coming in tension with each

other. One of the priorities is speed of delivery. But another priority is like quality of results. And those two things can often be intention and they very much are right now. And so if I were you, I would review technical decisions that have been made over the past few months that you've been working at this company and identify what is the underlying tenet where someone chose x over y and in this case x might be speed and y might be quality but go more specific than that because if you just say speed over quality it's just too ambiguous like you can't really make any decisions based on that kind of a tenet but you have to say things like we favor version control and and a a complete record of changes over speed of results you know it's like it's more important for us to

know all the changes that were made than to get changes done quickly you know it's like okay great and it's like under the hood you know or not under the hood but you you know that change uh tracking and git is actually a low cost way to do uh development work anyway so you know it's not going to be a high cost to speed it'll be a low cost of speed and a very high high improvement to quality so anyway the point i'm trying to make is write some tenets and and the reason i'm saying this is I want you to put these tenants in front of your co workers, and get them to agree, not just nod their head, but to be like, Oh, yeah, I have a disagreement with that tenant, I think we should choose y over x. It's like, great, that's a discussion you can have, then you can write all

these down in a line, then in here's my point. So earlier, Jameson was mentioning, like automated mechanisms that can enforce some of the decisions that you make. Well, one kind of mechanism is where you can actually in a conversation, you can refer to a tenant, where you can say, Hey, remember tenant number three that we agreed on where we said we would favor having a comprehensive revision history over having speed of delivery well this is one of those moments and that's when your engineer can go ah yes i agreed to that i saw that i see that it's in writing i remember wanting that let's let's do it this way as opposed to just being like i forgot what i agreed to verbally in that meeting yeah i could also see there being disagreement that is not verbalized

and then just comes out in action. So they say yes, and you even mentioned this, they nod along but seem resistant to change. And there's certainly going to be some cultural differences here in how you handle disagreement. But I think if you want to get past the problem of them saying, oh, sure, and then just not doing it, I think this could help because it gives you something to point back to,

to say, well, yeah, we said we were going to do this. Help me understand the reason why you didn't do it. You want to really understand if they actually do agree or if they disagree and why. And to get that true disagreement, which by the way, there's a little cross-cultural stuff going on here with India and the United Kingdom,

which these two countries have different ways of coming to consensus. And so putting it in writing and allowing them time to think about it and offline, not with you staring at them over a Zoom call, might actually be a really good way to get true opinions out in the open. There is one other thing here

that's less related to technical quality and more about your own onboarding. I mean, I guess that's related to technical quality. I think you mentioned something about struggling to figure out what's going on and that it feels like it's because it's such a spaghetti mess. I think the motivation for change should be more about this will help the business achieve its outcomes and less about like, this is confusing to me or this is hard to understand. Yes, exactly. You're the more senior person, I think. I guess I'm, yeah, two more junior engineers.

you don't say directly i'm more senior but you mentioned these other engineers are more junior presumably you've been around the industry longer like that's the job hopefully your background and experience helps you deal with the spaghetti mess enough to make a sense of it and it sucks and it's hard and it's a cost you have to pay but saying like this is confusing to me is not a compelling reason totally something differently totally maybe if your team was like hyper scaling then you could say this is confusing will hurt onboarding but this doesn't feel like that situation yeah you're i totally agree with you jameson this is another good reason to write your intentions down so that your boss can see that it's not just all about you you really do

have the intention of helping the business yeah i mean the the least confusing thing to you is probably something you just do all yourself um yeah probably why it's less confusing to these other engineers is because they've built a bunch of it but that's that's not i mean saying well i'll just redo it all in a way that makes sense to me is not an option or won't really pay dividends I mean, maybe it will. I don't know. Not the right solution. I'll put it that way.

Yeah. All right. That's all I got. Yeah, I think we've answered it. I'm fresh out. I hit the bottom of the well. It's dry as a bone down there. But everyone knows the water at the very bottom,

right before you run out, is the best, I think. The darkest, smudgiest. If I know anything about wells, which is nothing, I know all the best stuff's at the bottom. Oh, yeah. For sure. So you got all the good stuff. As measured by thickness and diversity of content.

Yeah. Viscosity. The high viscosity stuff. Percentage of tree of life covered by your water. Biological diversity of water. Yes. Yeah. It has the most different types of things in it.

All right. What can people do if they want their own questions answered? If you want your own question answered, go to softskills.audio and click the ask a question button on that website. Then you can fill out our form and you can enter as much or as little information as you like. When we read your words, if we like the shape visually of the question, we will answer that question for you. That's the main criteria. You really just lay out those words. Are you talking about like the line endings?

Exactly. Like they form a pleasing pattern? Right, exactly. Yep, something beautiful, some kind of laminar flow or, I don't know, whatever. Anyway, do your best. And we promise you we will get to all of these questions eventually. But they will be sorted by visual aesthetics first. Yes, which is tricky because we use different column widths when we look at these spreadsheets.

but that's why you're so smart because you can figure it out yeah you'll figure it out don't worry all right thank you for listening we will catch you next week