Soft Skills Engineering - Episode 380: Overruled by non-technical manager and describing technical stuff to non-technical people

Starting point is 00:00:00 it takes more than staring longingly at that new programming language that you can't use in production to be a great engineer this is episode 380 of the soft skills engineering podcast i am your host jamison dance i'm your host dave smith soft skills engineering is a weekly advice about all of the non-technical things that go into the technical field of software development like how all of your problems would be solved if you just switched to other things oh haskell i will never know the you know it would be great if we had to find a new logging library for all the like basic infrastructure stuff that we already use that we already have figured out if we had to refigure all that stuff out yeah exactly oh language great all the ripple effects not so fun yeah unless you get

Starting point is 00:00:53 to write it yourself and then which of course you would yes in fact that might be how you choose the thing what thing does not have an http library perfect i would like that to be my job for a while please this is job crafting yeah dave you want to thank our patrons yes i do a big thanks to this crew they are typehero.dev full stack contractor looking for job corp to corp never is not just a crater on mars flamingo emoji i like chicken i like liver meow mix meow mix please deliver trash panda trash oh i almost did a british slash new england accent there with putting it trash panda the computer science book.com santa hopar kent c dodds jenny kim owen chartle craig motlin the stochastic parrot alice jost muskingham ohio patron.com we're hiring irish and monkey face

Starting point is 00:01:48 emoji jonathan king web tau awesome end-to-end testing will angel ragnar nick hathaway ragnar nick hathaway travis i'd still love that travis brayden canes john grant cody sale nick cantor if you would like to join this illustrious just the most illustrious of crews go to soft skills that audio and click the support us on patreon button if you put in enough numbers the right numbers whose decimal interpretation is greater than a threshold that we decide we will say whatever you can type into the patreon name field and if you contribute any decimal value greater than zero we'll send you a slack invitation to join our community of over a thousand people who chit chat with each other share comedy share job opportunities with each other and get advice

Starting point is 00:02:33 get real advice unlike the stuff you hear on the show you can actually ask people for real advice and it's good yeah and we'll send that to you at the beginning of every month and a hug just a virtual one but yeah it's more it's more of a philosophical hug i guess can we say we can just say that nfts are fake right i can just say like there's an nft for the hug and then you just have to believe me and pay me money that's how it works okay let's answer some questions but first that means i have to read the question okay i will do a listener named ashley asks i'm a mid-level developer at a small company with a non-technical manager after several months working on migrating our users from a legacy system to our new system our non-technical business analyst discovered

Starting point is 00:03:23 that our current system reuses lots of code from the legacy system they immediately escalated their quote concerns about this to our manager this quickly resulted in a group message from our manager to the ba that stands for business analyst our senior engineer me and another developer Without asking for more than a cursory explanation of how two sets of users who need the same functionality can use the same codebase without breaking things for each other, our manager made the decision to fork the project and maintain two separate codebases. The developers tried to explain why this was a bad idea, but we were immediately shot down. This has already resulted in issues in pre-production environments. They were afraid that having changes in one unified codebase would break things for both groups of users. We were given no opportunity to make further arguments.

Starting point is 00:04:07 two months later i find that my motivation at work has tanked despite being below market rate i've stayed because it allowed me to advance my skills as a developer but my trust in our ba and management is completely shattered is it worth staying in my current role is salvaging our current situation a hopeless cause that is likely to just collapse again in the future or would i be wise to get out asap before things blow up and the blame is pushed on our development team I feel like I already know the answer in my gut, but I'd like to hear your perspectives on this. Oh, boy. It kind of seems like we're in the Dilbert cartoon on this one.

Starting point is 00:04:48 It does. It does feel like that. Feels like somebody thinks they're good at being decisive without knowing what they're deciding. Honestly, it's situations like this. So James and I are both in leadership roles right now. And honestly, every time I make a decision, I have this voice in the back of my head that's like, you're this boss. I do as well.

Starting point is 00:05:14 It's so easy for me to look at everything I decide and list all the downsides and say, here's all the ways that this is wrong and dumb. And like enough of them might be true that this could be bad. wouldn't it be great to have a team that was just like no great job Jameson good decision yeah I need some yes men I mean in some ways

Starting point is 00:05:44 it would be temporarily great but worse overall certainly yeah I don't think anybody should be trusted to only employ yes men i know just amplify all my already bad decisions what you need are some maybe men maybe yeah is this a good idea everyone people who maybe you're right let's not do this bring a strong sense of ambivalence not only do i not know i also don't care

Starting point is 00:06:16 oh that is way worse than having someone who thinks your ideas are horrible you can at least engage with that if you just put out an idea and you are met with shrugs i don't know it just sucks the the joy out of me exactly give me some passion anyway this is tough i i think having a non-technical manager or even a manager who's technical in a different domain or whatever the case just doesn't have enough context or knowledge or skills to be properly informed and opinionated on your day-to-day work is really challenging it's yeah it is challenging i don't think most bosses have enough context and experience to be more informed than the folks they work with on everything but hopefully they have experience

Starting point is 00:07:10 on on a lot of useful things and that seems like kind of the difference here where if they were a technical manager they might i don't know they might they might trust the engineers more even if they don't really have a firm opinion on this specific decision it's not like they would they would just know better and thus agree with you it's more like they kind of have they have the same vibes as you yeah like they might be more willing to explore the trade-offs with you rather than just saying oh i see the problem fork the code bases forks are good i've heard that fork everything yeah oh and you know and i'll take the devil's advocate on this one just a little bit and say maybe the manager's right and there's a couple reasons why the manager might be right here

Starting point is 00:07:56 not not to get into too much technical detail and maybe the manager's only right by luck but you know if this legacy system is scheduled to be shut down in like three months and no new feature enhancements are going into it and bug fix rates have been low maybe it's fine maybe just leave it alone and let it keep just huffing and puffing while you work on the new system unencumbered by how any of your code changes might affect the legacy system i mean the the question asker mentioned that trust my trust in management is completely shattered it seems like they did not exhibit a lot of trust for you for the engineers in the way they made the decision because it feels like you weren't heard yeah your your manager is not their job is not to do the things that you

Starting point is 00:08:41 think they should do all the time or make the decisions you think they should make so it's it's normal for them to decide sometimes in in a way you disagree with but i think you should be able to expect that even if you disagree you understand why they're doing it and why they think it's the right decision and that old amazon like disagree and commit thing is a thing that you you you should be able to do because you you kind of trust each other enough that you can get over some disagreements by saying like broadly we're we're moving together on things yeah it seems like you don't have that here yeah i i uh i try really hard to do this and it is challenging as a manager actually it's challenging for anyone to fully understand the rationale that went into your

Starting point is 00:09:34 decision making when you make a choice at least when i make a choice i sometimes it's just like well i feel like it you know like that's what i want i can't explain why i want it and so as a leader i try to force myself to explain like the underlying tenets that guided my decision making and then try to explain like look i understand there are pros and cons to this decision. Here are some of the cons. And I'm aware of those. And I choose these cons because I think they're better than the pros of the other options. And that's my favorite thing when managers do, when they do that. And so if a manager did this to me, I would be frustrated because it's like, look, it doesn't even seem like you considered. Not only did you not share with us

Starting point is 00:10:20 the decision-making process or the pros and cons, I don't even think you considered half the pros and cons because i don't even think you know what they are so yeah it like totally shatters trust for me it feels like feels like they got a lot of trust for the business analyst which might make sense if they are non-technical they they yeah i mean it's possible they're kind of intimidated by the engineers on the team like yeah all these smart people that know stuff i don't and have all these concerns that i don't understand and and i just want to go back to the comforting realm of business analysis i mean they might be intimidated by the smartness or it could just be their fashion sense is extremely intimidating ah i look great just so on point every time i walk

Starting point is 00:11:04 in a room and as a team of engineers i feel underdressed yeah the sea of fifth avenue brand names yes can't even sit down at a table without tripping over somebody's gucci loafers so intimidating i don't even i mean i know they're expensive are they they're probably not even fashionable i don't know well aren't they by definition maybe if you care a lot about fashion you might like look down on your nose at them at the gucci's i don't know i don't think i've ever even seen any in real life so yeah you probably haven't not noticed it next time we meet up for lunch dave i'm just gonna show up in

Starting point is 00:11:51 balenciaga i don't even know what that word is so i think you're probably ahead of me i have heard the word gucci though okay well so yeah like this this is hard so so i well hang on hang on i think this means we're qualified to decide what fashion is and what is fashionable and we're qualified by not knowing anything about it is that the qualification i mean like i don't know we're we're mirroring the manager in this question like oh yeah i've heard a gucci but it's bad and you should instead wear prada another day another dollar is better another decision made man i am so decisive uh hmm well yeah what do you what do you do about it well i i don't know because you can't you can't just wave a magic wand and have your manager turn into someone who

Starting point is 00:12:48 has the skills and knowledge necessary to truly assess important technical decisions and what's worse is that over time let's just assume this is a really bad technical decision over time this bad decision is going to have little babies that come out of it that are also bad things that are happening. Little gremlins. Yes. Gremlins will be birthed from this bad decision. And the manager will not have the technical knowledge to know that this bad decision actually is the cause of those downstream problems. And so that manager might chalk it up to bad engineering, bad staff. So there's a lot of ways this goes really wrong. And I think that if you actually want to address this problem, you need a strong technical leader on the team who has simultaneously earned the trust of the manager and also can make really convincing, strong arguments that are good, good engineering decisions. and I just sense there's a little bit of a gap here

Starting point is 00:13:52 because if this business analyst and non-technical manager felt not only empowered but also felt justified in making a highly technical decision without consulting the team, I sense there's a gap on this team because where's that person? You know, if I were a non-technical manager

Starting point is 00:14:07 and there was a technical leader on the team who I trusted, I would just take the feedback from the business analyst and I would just aim my eyeballs over at the technical leader and be like, okay, what are we gonna do about it, you know? Yeah. We always talk about how as you become more senior as an individual contributor, often the demand on your soft skills or you're asked to do more kind of coordination and cross-org stuff and people things, even if you're not managing them. this feels squarely this feels like it falls squarely in that in that realm of like a very senior engineer would have the technical skill to know what the right thing to do is and the

Starting point is 00:14:52 organizational skill to navigate this dynamic of like getting the engineering managers trust and helping them guiding them to the right decision instead of just being steamrolled by them exactly and i'm just saying where's that person yeah i mean if you feel like you can develop into that or you the senior engineer on your team can develop into that it feels like you kind of need a united front you need to like organize a cabal of the engineers on this team and kind of get together and and if you if you want to improve this i guess you're saying in the absence of a strong technical leader you need essentially a union yeah i guess yeah i mean yeah demand your your benefits and one of the benefits is like please ask us and take our advice on technical

Starting point is 00:15:42 decisions yes please don't fire us and also don't decide what source control tool we're going to use there is another option here which is that listen you got a non-technical ba you got a non-technical manager are they really gonna know if you forked the code like do they even really know about that yeah just be like what are they gonna do it's forked yeah we we pressed the fork button yeah yeah i mean that that road ends in in a bad place but as as a person who does the thing you are ultimately in charge of what thing gets done yeah at some point someone's gonna notice and say wait i thought we were doing other thing but you can you can do the thing and then when the thing goes wrong you can explain it away oh we actually darn it we clicked the spork button

Starting point is 00:16:41 i'm sorry we'll get that fixed right away wow we really shouldn't have sporked this code base yeah oh boy that's why it's good to get decisions in writing because we all thought we clearly heard spork yeah there's a possibility that you can make this work and it can be kind of a crucible that will forge you into a stronger more powerful engineer but i think i would be kind of looking for the door here maybe but it's so hard to go find a new job right now so so hard yeah that's that's why good meta advice is always to have have compelling alternatives because if you can't get another job then your options are pretty limited to make it work here yeah and

Starting point is 00:17:38 there are times where that will be the better option and there are times where you think it will be worse and it actually ends up being better but it's nice to have the flexibility where if you if you cannot afford to go look for a job or can't afford the potential downtime or loss of income while you're looking or or i don't know whatever yeah i guess the question's answered you stick around and make it work and so let me just offer one idea for how to stick around and make it work. So if you have a compelling argument that sporking the code was not the right idea, then you should be able to write three or four bullet points about why. And you should also be able to write three or four bullet points about why it's a good idea. And I would write those

Starting point is 00:18:20 down for myself, take a good hard look at them and say, is this the right call or not? And if it's not and you feel convinced i would go and prepare a presentation to my boss you know when you actually take the time to put effort into that sort of thing it it communicates meta information along with the actual information that you're sending and that meta information says this is a big deal to your boss you need to get their attention it's you know forking the code is not just the kind of thing you do casually it's like well it's wednesday time to fork the code you know that's not your boss might not know that they might think oh this is just no big deal it makes a lot of sense. We want two code bases. But they might not understand that now you've doubled your

Starting point is 00:18:59 work in a lot of cases. And you've created really complex situations for engineers to have to navigate when they got to fix bugs in those two places or when the bug fixes have to be different because the code has drifted. Anyway, it's really complicated. And so I would go in and sit down and say, listen, I would like to make a case that we reunify this code. I understand the risks that you are concerned about, but none of those risks have materialized. Here they are, one, two, three. Because remember, as I read the question, this all came because a business analyst thinks it might be a problem in the future, but none of your engineers think it's going to be a problem in the future, and it has never been a problem in the past. And if you can make that kind of

Starting point is 00:19:40 clear-cut case, your manager might change their mind, and they might say, unspork that code. Knife the code. A fork divides. A knife is one thing. reunify the code with the spackle and spatula of reunification yeah we really have to knife this team and become unified ignore the implied violence behind that okay have we answered the question i think so good luck tricky situation good luck dave will you read i was gonna say answer but of course you'll answer it will you read our next question yes and i'll answer it as well thank you and we'll see if you will join me in answering but that's up to you this comes from a listener named damison chance oh you damison asks i sometimes find myself struggling to describe

Starting point is 00:20:30 how software issues will affect product designs to non-software engineers it is hard for me to explain quote this seemingly tiny change in user experience that you've asked for is actually driven by this back-end functionality that is totally transparent to users and really no one besides back-end engineers has any reason to know about it but yeah anyway that small change is going to require six months of work and changes to multiple services. So true. I have found this approach quite ineffective, and I think it comes off as me sounding like, quote, my way or the highway. I'm wondering if you guys have any tips for explaining how systems work to people who aren't software engineers and don't necessarily have all the context you do. Oh, this is a great

Starting point is 00:21:09 question. And I have to link a YouTube video in the show notes. And you can find this YouTube video if you search for Omega Star. Jameson, do you know this one? Is this the microservices one? Yes. Yeah. This is like three minutes straight of an engineer trying to explain to a product manager why they can't add, what, like a birthday field to a profile page. And it's like 50 microservices oh man it's so good i'm putting this in the show notes i love that video because it's both like uh it pokes at both sides it's sort of like yeah you look how complex this thing is that you thought was simple and it's also like look how horrible you made it to add a birthday field engineers exactly look at this monstrosity you've built but yeah there's this weird i don't

Starting point is 00:22:00 know we i don't think we need to focus too much on this but there's this weird power that comes with understanding this super complex system. I get these brain tickles. It feels good. And so much so that sometimes I worry that I made the system complex so that my brain would tickle. I'd feel good about it and I'd understand it.

Starting point is 00:22:17 Oh, no. Well. I'm just thinking, I was just kind of getting contemplative there. Have I intentionally designed complex systems just so that I can have the brain tickle? I don't know if it's intentional even. It's like subconsciously.

Starting point is 00:22:33 Yeah, whether or not it's intentional, it's like did i create this problem i don't think the brain tickles from simplicity to retrain my brain it's like art it's beautiful yeah how can the software do so much with so little and so clear of code to develop a fine taste a small change can require so unfortunately this is a boy who cried wolf situation i think because guaranteed these people you've talked to have heard this from other engineers in the past and some of the time it's been true and some of the time they have been explaining things making assumptions about what needs to happen to the system and and kind of deciding that instead of more explicitly presenting the trade-offs

Starting point is 00:23:20 because often there's some kind of trade-off of like yeah we can hack it in and it'll be small and simple and it'll make our lives worse in this way or we can clean up this past mistake and touch all the microservices and it'll take six months and yeah it's people have been burned on both sides like engineers get burnt all the time by by quick hacks that last longer than their career they have to maintain forever and and folks talking to engineers get burnt by surely it can't be this hard to add a birthday field so i feel like there's there's lots of baggage to this there totally is i mean as an engineer you've been burned so many times that you just can't help but be super cautious when telling anyone how long anything will take

Starting point is 00:24:05 i don't even know how long it takes me to open my editor anymore yeah i don't think i can give a estimate without saying several times this is an estimate not a deadline i don't i think those words just come out of my mouth that's a version of this of like i'm trying to prevent future pain that I've felt in the past. Yeah. All your scar tissue is like tingling. Yeah, but then it makes it take longer for me to say stuff.

Starting point is 00:24:30 It does. And I, you know, I have, how do I do this? I feel like I've gotten to a really good place with this, but it really depends on the environment. If you have a place or an environment of trust

Starting point is 00:24:44 where everyone who's asking this question and everyone who's answering it knows that we're all working together to deliver a valuable product as fast as possible, then you have a little bit more leeway with this. But if you've got adversarial people on the other side of this question, or if you've got a history of poor shoddy workmanship, or you have really crazily demanding customers who are just like, what? I need to know exactly what day and time this is going to ship. Then it's just, there's almost no technique that just fixes this problem and so i would actually say you kind of

Starting point is 00:25:23 have to go back to the roots and try to create an environment of trust first and then you can navigate a little bit more confidently in the in this whole world i worked with somebody once who was in the product org who was good at taking the answers from engineers and not just saying well can that number be smaller? Like, no, give me, tell me a smaller amount of time instead. But like kind of pushing on assumptions and saying like, well, what can we change to make this less work? Can we change something about the solution? Can we change something about the requirements? And that back and forth, like, I think it is healthy and reasonable to get pushback from people that you deliver estimates to. You're not infallible. Your estimates aren't always

Starting point is 00:26:15 right also you you might not have thought of of every way to solve the problem you might not be aware of some of the business constraints so you hear this complaint of like when i give an estimate people just tell me to make the number smaller and and yeah you don't want to do that but you kind of need to be able to work with each other to say here's how long it would take to do this way if we change these requirements, there's a way to do it in half the time. And here's the thing we get from it. And maybe it's half as good, but that's the right trade-off to make now. You can offer trade-offs in response to questions instead of just say, there is one way that will take six months. I 100% agree. And I think what you're describing

Starting point is 00:27:06 is a phenomenon that I've observed happening over the last 10 to 12 years, where engineers have kind of relegated themselves to this position of, look, product managers tell me what to build, I tell them how long it's going to take, and then I build it. But actually, that's not a good pattern for getting the best outcomes. And I'll give an example. We had an epiphany recently, where my product team came to the engineering team and said, we want to build this feature. And they laid out a whole bunch of cool Figma designs. And the engineering team went back to work and figured out how they were going to build this, designed a comprehensive system to meet all the requirements, started implementing

Starting point is 00:27:44 it. And then halfway through, we discovered some new scope and we discovered some more new scope. And then suddenly it was going to take a lot longer than we expected. And the product team in the middle of this was like, hey, we love this feature, but I'm not sure we love it at this cost, you know? Yeah. And I thought, oh, that is so true, because so often when I'm purchasing something, just,

Starting point is 00:28:06 you know, as a consumer, I think, oh, I definitely want that product, but I don't want it at that price, you know, or I want a lesser version of the product at a lower price, and that'll meet my needs just fine. But as engineers, if we just take this and make it a one-way street where product gives us requirements, and we just take that and produce estimates and then final work, then there's no opportunity to have that discussion of, do I want it at that price? and so this was this was kind of a slap in the face for all of us on the team because we were like oh my goodness we marched way too far down this road because product came back and said actually if it's going to take six months we don't want it it's not worth it to our customers

Starting point is 00:28:43 because the opportunity costs are so high we have a lot of other stuff we would like to build in that time instead so no no thank you we just won't build it and we were like oh man that's interesting and so i've adopted a different pattern recently where instead of just saying okay product give us requirements we'll give you estimates instead product gives us requirements and then they say also we're willing to pay this much for it and the pay for it currency is in terms of engineering time which we have a point system for but that doesn't matter it all turns into time in the end and we go okay cool now we have something we can actually work with like we can come back and we can say well we could do it we could do this set of requirements for this

Starting point is 00:29:24 price or we could do this reduced set for this other price and then and then we go back and forth so the the estimation process is actually iterative it's not one and done and we have found so much more value in getting to the right product for the right with the right economic balance by actually having estimation be iterative instead of just this one big bang estimation i love that yeah but it takes tons of trust it does yeah it does take a lot of trust it feels better when you do it though too i mean everybody's happier when you can come to a thing everybody wants and and kind of at a price while you're building it how it's going and yeah yeah it's way nicer there's there's also maybe an opportunity here to pitch some some cross-cutting improvements

Starting point is 00:30:14 where if it takes six months to do a lot of things is there is there something you can do that would take one or two months that would make other things take much less time in the future this is kind of a common situation caused by some technical debt or some architecture choices then that's also a way to justify investing in fixing those so you can say it'll take six months but if we spend four months on this other project things like this will take three months instead I don't know, whatever the numbers are. Yeah. So we've talked a lot about estimation techniques, which I think is kind of a really common use case that triggers this kind of situation.

Starting point is 00:30:55 But there's a more general question here, which is, how do I just explain anything that's technical to people who aren't technical when there's all these intricacies? And I've seen a couple of techniques that help with this a lot. First of all, metaphors. Now, as an engineer, I hate metaphors. I'm like I don't I don't want you to give me an approximation of what the thing is just tell me what the thing actually is this database is not like a mailbox at all I cannot drive down the street and hit it with a baseball bat as a teenager I mean it's like look I don't need a metaphor I know what a database is tell me just tell me it's a database like you know I don't

Starting point is 00:31:33 anyway oh it's a relational database I know what that is too oh it's got foreign keys I know what that is too. There's no need for a metaphor here. Anyway, but non-engineers hate that stuff. They love metaphors. And I have found that metaphors get purchased in people's minds and they stick way better for people who are not engineers. And so I can't think of a great metaphor at the moment, but invest some time to explain things in metaphors because people will remember that if you can do it. Yeah. It's sometimes tricky to... All good metaphors are abstractions and fail at some level and it can be hard as an engineer who's who's used to thinking about exactness and correctness and completeness to say it's kind of like this thing it's really not in

Starting point is 00:32:18 all these ways but to help you understand it is broadly like this thing yeah even though it breaks down if you really dig into it they're not going to really dig into it or they're never going to dig into it great now they now they understand it more and you can say what it's actually like under the hood so i've i've found that a thing that some people have to get over is like but it isn't actually it isn't that metaphor but close enough is what you are aiming for and then make you have to be very careful that you don't create a metaphor that also communicates falsehoods about the thing because people pick up different aspects of the metaphor that like jameson said don't apply so it's risky but um if you say what was written in this question you know like oh we've got this

Starting point is 00:33:00 back-end functionality it's transparent to users so no one you know it's like none of that is going to stick it won't be helpful but if you can say it's kind of like an apple there's a peel and but underneath the peel there's a lot of material in there and we got a lot of material we gotta that we gotta change to make this apple peel change colors you know i don't know so we got up on the spot we gotta plant the servers and got it okay thank you and then we'll harvest the bits yes yes yeah so that helps another thing i would i would a technique that i would suggest is make sure that the people know that you're on their side when you're explaining things and it's easy for some people to make incorrect assumptions about your motives when you spam them with

Starting point is 00:33:49 technical details and some people might and hopefully incorrectly assume that you are avoiding the question by spewing mumbo-jumbo at me, like all this jargon that I don't understand. You want to avoid that. And so I like to say what I'm feeling and what's motivating me before I give the information that they asked for. So for example, if someone comes to me and says, hey Dave, what would it take to add this birthday field? Rather than explaining all the gory details, I could say, oh, I can see that that would be a really cool feature. That sounds like it'd be really valuable. I would love to help find a way to deliver that as quickly as possible without causing a lot of downstream problems. Let's talk about how that could work. And then

Starting point is 00:34:32 you can share, now that you've established kind of a common goal, now you can shift to, okay, here's why it's going to be hard. And then at the end, you can say, man, I wish it wasn't so hard. I really want to help you with this. But you can see that actually this is a little more complicated than we thought. So maybe we should go and look at the roadmap and see if we can allocate some time there and see what else needs to shuffle in order to make this happen. And I've just found that by stating up front your intentions that you're on the same team and understanding what their reasoning is for asking you, then explaining it, people are much more likely to think, yeah, this person is on my team, even though they spammed

Starting point is 00:35:07 me with all their jargon. I love that. It also avoids a failure mode, which is people being afraid to ask you stuff because they feel like you're going to get upset at them. How dare you? Don't you know how much work it will be to change this system? And you might not be meaning to communicate that, but that's a vibe that could come across if you react in horror in large numbers every time someone says, can we do this thing? Can't we just? And this is why at this very moment, you need to pause this podcast and go watch the microservices Omega Star YouTube video. It's just so perfectly describing what Jameson is saying right now.

Starting point is 00:35:45 yeah yeah like if they you you want to be on their side and the way you do that is say like we are together you're like both hands on your hips standing back looking up at a building like how are we gonna put new gutters on this you're not like inside it at the top throwing down rocks saying go away stop invading my exactly how dare you peasant and it is it is easy for engineers to convey that sentiment sometimes intentionally because engineers have been burned by people like the manager in the previous question yeah yeah it's like oh are you one of these people that's going to make my life suck for no reason for the next six months uh yeah but you you don't want to retreat into the castle you want to both be looking at the castle together yeah i like that

Starting point is 00:36:29 i like that metaphor hands on hips looking up at it boy how are we going to do this together yep well have we answered the question i think so good luck tell us how it goes yeah or you know what make up a story about how well it went if the real thing is too disappointing exactly oh your advice is always so helpful jameson and dave yes men you know i feel a spring in my step i didn't before yeah me too what can people do if they want the same spring in their step go over to soft skills.audio and click the ask a question button where you can fill out our form and tell us what questions you have. And two things.

Starting point is 00:37:10 Number one, thank you to everyone who does that every week. We love reading your questions. We answer some of them and we promise to answer all of them eventually. Number two, if you would like to tell us how we did, we would love to hear it, especially if we did bad. Oh, that's just, that's the best. Send us your bad outcomes from all the advice you followed

Starting point is 00:37:30 and we will go and we will read it on the show and we'll have a good laugh at Jameson's terrible advice. i you know what i'm happy to take all the blame perfect because i am not it'll be my fault good well there is no blame assignable to dave perfect my ego is too weak to handle it thank you for listening we'll catch you next week bye

Soft Skills Engineering - Episode 380: Overruled by non-technical manager and describing technical stuff to non-technical people

There aren't comments yet for this episode. Click on any sentence in the transcript to leave a comment.