Soft Skills Engineering - Episode 435: How to make my boss actually do something and kindly shooting down

Episode Date: November 18, 2024

In this episode, Dave and Jamison answer these questions: First! I recently listened to episode 178 (huge backlog of episodes to work through!) and Dave made the assertion (in 2019!) that 47% of all companies would be remote by 2023: wildly close, what else do you see in the future? Second: my work situation continues to confound and external insight would be helpful! My boss and I have a long working history going back to an entirely separate company. I’m a high-ownership/high-drive Principal level IC and feedback has been lackluster. Takeaway from last years performance review would be best summarized as “I agree with your self review. End message.” I’ve been working to “manage up” and mentor (reverse mentor?) him, but he always makes snap decisions and then refuses to reevaluate after presented with more info. Coupled with his myopic view of our team’s scope and general preference for speaking only (not much for action), I’m trying to figure out how to get where I want to be without burning an old and historically very useful bridge! I want to work on big technical problems, instead I’m de facto manager of a team… I managed before and did not enjoy being responsible for people. As a principal I’m responsible for their output somewhat, but if they underperform I work with their manager and them to prioritize, and do up front work to incentivize their investment in what we’re doing… help! What do I do when my teammate proposes a new architecture or framework in a new project? It might solve some existing problems but has a high chance to create technical debt and make the onboarding harder for new engineers. How can I convince them to use the existing solution while still helping them feel comfortable sharing their opinion next time? If I follow their suggestion but things don’t go well, how can I convince them to refactor the structure without them feeling like I’m blaming them?

it takes more than explaining why java has a null pointer exception when the language doesn't have pointers to be a great engineer this is soft skills engineering episode 435 i am your host dave smith i am your host jameson dance soft skills engineering is a weekly advice podcast for software developers who just need a little help explaining logically inconsistent statements in programming languages you can never escape pointers they're always there they're just lurking out of sight yep i guess you could call that a leaky language that doesn't have pointers guess what yes it does in its runtime that's written in c yeah exactly maybe there's some kind of mythical i always hear about lisp machines and i don't quite understand what that means

besides they use Lisp a lot. Maybe there's some mythical other type of architecture that doesn't use references to addresses and memory under the hood, but I don't know what it is. It doesn't use memory. It only uses register. It just doesn't use memory.

It is random. Yeah. Stateless. Totally stateless. That'd be cool. Yeah. It looks at the one or zero and decides is the next thing a one or a zero.

Right. That's all you got. And I make fun of the pure functional purists because they got nothing on this machine. I've created the perfect computer. It is a single piece of paper with a one and a zero written on it. Completely stateless. Purely functional. He always gives the same results, given the same input.

Yes. Or any input. Yes. All right, let's get out of here. I got to thank our patrons. thank you so much to 10 print lucas morton is cool go to 10 nick molyneux up to put two with little music emojis attribute error none type has no attribute to string javier gonzalez chewy ted timbrel i found some cash and i'm back on the list baby become a senior engineer.com unsalted

french fries are morally objectionable dan from drone deploy chase w norton level up your type script with type hero.dev never is not just a crater on mars flamingo emoji i like chicken i like liver miamix miamix please deliver trash panda kyle boss kenzie dodds nevar is not just a planet in the vulcan system jenny can own chardo the stochastic parrot helicon.ai best observability tool for ai red panda's best panda typescript is a microsoft conspiracy jonathan king is nigh beautiful functional user documentation it takes more than setting a funny name on patreon to make dave and jameson laugh to be a great engineer yes the creator of william angel.net lord ragnar travis braden canes john grant if you would like to join this

illustrious crew dave don't gloss over this bit maybe it's different go to soft skills.audio and and that cuts off and a special shout out to cody sale who has generously given a large sum in order to support the good work we do thank you co thank you co cody is the caboose testing the limits of the patreon name field yep you found them however many characters that is i'll let you count it up yeah jameson i want to thank our sponsor for this episode. This episode is sponsored by WorkOS, which is the best way to add single sign-on into your software product. You'll hear more about WorkOS in the middle of our show today. Dave, do you want to read our first question? I do. This comes from a listener named Smomebody.

First, I recently listened to episode 178. Parenthetical note, huge backlog of episodes to work through and dave made the assertion in 2019 that 47 of all companies would be remote by 2023 wildly close what else do you see in the future right answer wrong reasons yeah okay now on to the real question my work i like that can someone can someone go cherry pick all the things that i've said that turn out to be right i recently looked through our backlog uh our episode list and I didn't find any. Oh, shit. Okay, never mind.

Strike that from the record. Okay, second question. My work situation continues to confound and external insight would be helpful. My boss and I have a long working history going back to an entirely separate company. I am a high ownership, high drive, principal level individual contributor

and feedback has been lackluster. Takeaway from last year's performance review would be best summarized as, I agree with your self-review. End of message. I've been working to, quote, manage up and mentor or reverse mentor my boss, but he always makes snap decisions and then refuses to reevaluate after presented with more info. Coupled with his myopic view of our team scope and general preference for speaking only and not much action, I'm trying to figure out how to get where I want to be without burning an old

and historically very useful bridge i want to work on big technical problems instead i'm de facto manager of a team i managed before and did not enjoy being responsible for people as a principal i'm responsible for their output somewhat but if they underperform i work with their manager and them to prioritize and do upfront work to incentivize their investment in what we're doing help exclamation mark oh i agree with your self-review end of message i didn't know that was an option i know right you gotta save that reviews a lot easier going forward yeah this is this is hard i feel like i've been in this situation i assume it's sort of like you're doing great keep it up and then they don't even have to read your

self-review because exactly if you're if you're high ownership a principal engineer presumably you've thought of some great feedback for yourself very insightful so really yeah do those good kpis i think whatever you came up with is probably good i'll see you next year this might actually be a symptom of the long-term relationship that this person has with their boss because the boss has grown to trust them so completely that they're like look i know you well i know you better than you know yourself i don't need to review your work i trust you they also could have arrived at that like old married couple age where they just they know nobody's gonna change you know like why bad why bother giving feedback they're still gonna put their slippers on

backwards or whatever it is i don't know exactly that could very well be listen i've known you for 10 years i gave you i stopped giving you feedback on your curly braces a long time ago yeah it didn't work the feedback didn't work so i'm done it also could be like you're so close that it's hard to give critical feedback that happens sometimes in some relationships where you're your friends and you don't want to upset the friendship by saying hey you are doing a bad job at this thing that's all right so you don't have enough feedback and you also are the manager of this team in a way that you don't want to be and you feel like your boss is kind of not doing anything and has too small of scope and vision there's lots going on here yeah and i kind of

sense that this person wants too much from their boss like you're viewing your boss as a critical success factor when in reality you could probably just be successful without your boss helping you and in fact what i have found is that the more senior you become and in this case i'm interpreting principle level to mean pretty senior the more senior you come you become the less a management structure is actually a designed to help you and be actually helpful yeah which makes sense i mean if if it's a tree most of the nodes are at the bottom of the tree so most of the management org is set up to manage where there are the most people right you can just do things i think that's the summary of your advice just go do stuff then yeah if there's something you want to do is

myopic view of our team scope and general preference for speaking only. I'm trying to figure out how to get where I want. Yeah, just go do stuff. You're trying to help manage other people say, hey, I have this other project I'm really passionate about, and I'm going to focus on that. I think that's the best way I can have impact as a principal engineer. Exactly. And don't hold yourself back because you're not getting, quote, feedback from your boss. I think that another thing that happens as you become more senior is that feedback from people, especially your manager, becomes less valuable than the signals that surround you that tell you if you're doing a good job, especially if you're a principal level

individual contributor. I'm assuming here that your work dictates where the company is going technically. And you will see the results of your work in the success of the company, not just in the business metrics, but in things like cost savings, and things like bug rates, in things like developer productivity like this is where you need to start looking for feedback to tune your work because at this point you might be the only one who actually has that visibility or even understands the work you've done to understand what the impact should be yeah yeah i like that i like your idea that you don't you don't need to depend on your boss very much and at at this level too it's sort of like a peer relationship more everyone talks about how

they're parallel tracks management and ic and it's kind of true in a way and kind of not true because there's still power dynamics but usually as you get to be a very senior ic you might have a boss still but you you're like a i don't know you're like a a co-lieutenant or something some dumb military term that i don't understand um that i will just make up on the spot less like you are a subordinate reporting directly to them and taking direction from them so if if you don't love the vision of your boss, good news. That's a big part of the role of a principal engineer is help define the technical vision of a team or org or company. So it's fine. You can just say, hey, here's what I think the vision is. Let's go do it. Yeah. I mean, I was just kind of thinking,

try to scale this thinking up and let's go up to the CTO, then go up to the CEO. Who does the CEO get feedback from? Well, I guess you could say the board of directors and the investors give the CEO feedback, but usually that feedback comes in only two forms. Either A, here's a check for the equity that we're paying you out because you've been so successful, or B, you're fired. They don't often... Yeah, it's binary. I mean, don't get me wrong. The board of directors and the investors are often very interested in mentoring and guiding the CEO, but typically they hire a CEO not because they want to mold and shape them, but because they already believe in what the CEO is doing

and they want to let them run free. And they hired they invested in that person because of who they already are. And so yeah, some mentorship and guidance is definitely valuable. Don't get me wrong. But that CEO, the main source of feedback from the CEO is going to be the business outcomes that they're striving for, you know, like basic things like revenue, like are they actually is the company actually making money. And the closer you approximate that, like as you move toward that, the less and less you're going to get feedback from others. And the more and more you're going to have to find it yourself. I feel like maybe I just repeated myself there a fair bit, but I just wanted to say the thing about the CEO having binary feedback only. What about this piece of

I'm responsible for their outputs. I work with their manager and help them prioritize and do upfront work to incentivize their investment in what we're doing. It's also like this piece of, it sounds like they don't want to do it though. Oh, I got, I kind of got the impression that even though they don't want to be responsible for managing people, they understand that as principal engineer, they are responsible somewhat for people's output by giving them good things to work on and helping managers manage their people by providing feedback on their people. I guess I didn't really read that as a major problem that they see. To me, it sounds like they're saying, I'm doing too much of this stuff. Like it's too much like, I feel like I'm the manager of this

team. Yeah. Well, to that, I would say the things that were listed here. So I am responsible for their output somewhat. If they underperform, I work with their managers and I do upfront work to incentivize their investment in what we're doing. These are very much important bullet points on the job description of a principal engineer. So if you don't want to do that job, then maybe you don't want to be a principal engineer. Yeah. It still might be taking up more of your time than you would like. And I think you can shift the proportion of time that goes towards that. I think I agree with you that increasing the output of other engineers is a big part of the job, but maybe you can time box it somehow. You can delegate some of that. You have

your army of staff engineer peons, the lowly staff engineers that all look up to you. Hopefully it's not only your responsibility to support underperforming engineers. So if you want to do less of it there are ways to do that yeah like just stopping it like yeah or just saying i don't know do you just do you just schedule it say great i have time two weeks from now or i don't know yeah i guess time box how many hours you spend on it and then you queue stuff up and then they go somewhere else or i i do kind of like the idea of delegating some of this if it's a i don't know maybe it's a very senior engineer then you're the best person to help them but you shouldn't be just in the weeds meddling with every performance issue

with every individual contributor yeah so maybe you can help coach or train or or ask other engineers that are also senior to help with this yeah so i mean i i'm when when the question says i want to work on big technical problems and instead i'm doing all this people management stuff to that i say big technical problems tend to be solved by big groups of people and the people element just can't be separated from it. So I actually kind of think we might have a little bit of an expectation problem here. The biggest technical problems I know of were solved in coordination with lots of people. And that means you got to do the people stuff. So I don't know, maybe reset expectations a little. Yeah. Well, have we answered the question?

I think maybe. There's one remaining thing, which I think is how do I manage the relationship with my boss, who I perceive as a longtime friend, but also someone who's standing in the way of me getting what I want. And to that, I would say, A, I already said, maybe what you want is not actually perfectly aligned with what you should expect for the job that you're doing. But even setting that aside, I think that there's many situations where we advise people to go talk to someone and say, here's what you should say to them. This is a situation where I don't even think a conversation is necessary. I mean, your boss seems to be standing in your way, but I'm not really sure he is. And I don't really know if there's anything you need to tell your

boss. I think you are the owner of your own destiny here. And especially at such a senior level, go do what you want to do. I don't know. I mean, it's almost like this person's holding on to some of the mentality of how things were when you were in a more junior role and you were expected to come to work and kind of do what your boss said every day. But I really don't think that's how your boss thinks you need to work now, especially the I agree with yourself review end message bit. Like your boss is not really interested in managing you. So great. Take that as a signal that you are free to do what you want. I like it. You've answered the question. I decree. Oh, brilliant. Jameson, I just want to randomly tell you this important fact that I have

worked for three companies that have built their own SSO implementation. And these were some of the biggest mistakes I've made as an engineer. That's foreshadowing. We want to tell you how to avoid this mistake. Yeah, it does seem straightforward at first, but then you remember there's OAuth, OIDC, SAML, SCIM, RBAC, a bunch of other acronyms that you only find out about when you get paged. Some of these acronyms, you don't even know what they stand for, but you are responsible for them. Okay. This is where WorkOS comes in. WorkOS makes it easy for developers to add SSO and other enterprise features to their app rather than building it from scratch yourself. We actually use WorkOS where I work right now. And they have amazing docs. Their kind of developer

facing stuff is great. They've got example apps in a bunch of different languages, Node.js, Python, PHP, Go. It's nice. Yeah. And sometimes people worry, well, do I actually get to maintain control over my UI? And yes, WorkOS provides a login UI toolkit called AuthKit, which uses Radix themes, which are open source. And so you actually have tons of customizability over the look and feel. Yep. It's a drop-in replacement for Auth0, and it gives you really great pricing. One million monthly active users for free. One million monthly active users. I feel like I should twiddle my mustache as I say that. Recently, WorkOS acquired a company called Warrant that provides fine-grained authorization

and role-based access control, or RBAC. FGA and RBAC for those in the know. So this means that WorkOS can grow with your needs over time. Do not punish your future self by building a homegrown SSO system. Join many companies that are using WorkOS today, like Vercel, Webflow, Perplexity, and Loom. You can check it out at WorkOS.com. That's WorkOS.com. Would you like to read our next one? Yeah, I would. This is from an anonymous listener who says, what do I do when my teammate proposes a new architecture or framework in a new project? It might solve some existing problems, but has a high chance to create technical debt and make onboarding harder for new engineers how can i convince them to use the existing solution while

still helping them feel comfortable sharing their opinion next time if i follow their suggestion and things don't go well how can i convince them to refactor the structure without them feeling like i'm blaming them hmm yeah this is interesting this feels like right on the edge i don't know this is right in the wheelhouse of this show it feels right on the edge of technical and non-technical and soft skills and proposes a new architecture framework in a new project the main question i see here is how do i shoot an idea down without cutting off the idea factory for future ideas yeah i think you can say that this i feel like this is a theme that i've been harping on for the past few months you can just say the thing that you're trying to do directly

explicitly instead of implicitly do it you can say hey i don't think we should do this hopefully you have some reasons that you can articulate. But you can also say explicitly, I want you to still feel comfortable sharing your opinion next time. Just because I disagree with this doesn't mean that you shouldn't speak up. And I feel like we come to better decisions when we talk through different alternatives and disagree and then work things out. Yeah, I agree. Confront it head on. I disagree with this idea and I wish you would never speak again. yeah that is i mean that can be the the subtext that some people take away communication is just so hard and the more explicit you can make it the easier it is because

you can interpret that someone is offended by you saying stuff they might interpret that you're mad and you disagree with it and think they're dumb for proposing it or yeah the more explicit you can make it the better um i am assuming that you're in this a position to to actually kind of put your foot down hopefully hopefully you have discussed why they want this and have you feel like you understand their reasoning and could explain it to them in a way that makes sense to them hopefully you're not just kind of like knee-jerk shooting it down because it is scary and new i'm going to assume by the fact that they took the time to write this question into our podcast that they're not having a knee jerk reaction to this it's just a very slow knee

jerk they have the slowest reflexes in the world it's like a gentle they've been hit with a little hammer on the knee and then several weeks or months later i think this one is from 2022 actually so this is several years later oh man then they're neat it just kicks out of nowhere while they're like walking down the stairs two years later boom oh yeah this is a common problem though and i i I got to say, I applaud you for thinking about the other person's feelings when you shoot down an idea. That's great. I mean, you have reasons for believing what you believe about this. And you could just say those and leave the other person subject to just interpreting that as maybe a personal affront. And I got to tell you, I hear about this probably once a month.

i discover that someone told themselves a story about something that someone else said or did which was just not at all true and it kind of makes me sad it it it makes me worry that i'm not actually able to say anything to any other human being without something being filled in that i didn't intend you know yeah and i hear it i don't i don't know if i do this i try and i really try not to do this where i'm like look just take the facts as presented i really don't want to fill in the story gaps with things about how you feel about me or uh what your true motives are any any of that stuff i'm just like look i'll just go with the facts and i gotta tell you it's a much more stress-free way to live i lean into the opposite direction where i i build up this rich

fantasy world that i live in it's so exciting full of intrigue and drama huge shifts of alliance yeah it's great battles really entertaining to live in yeah battles being waged on the stage of your mind yeah did you see how they slightly hesitated before they opened the door for me the knife in the back is coming soon i can tell you've joined the other side unless a double agent you're trying to portray yourself as the other side trying to signal to the opposition that okay yes that's why i just winked at them that's why i gotta talk to hr after this podcast oh no that yeah that makes a lot of sense i i don't think i do that very well the the don't

interpret things wrongly yeah yeah that's because you're very creative i think that's part of it like i'm not actually that creative to think of a backstory i'm just like all i know is what they did i don't have any other ideas about this i feel like i am somewhat empathetic which also is like leaning into this of like interpreting signals from people and telling telling yourself a story about why they're doing things or how they might feel i think that does make it harder in some way oh i had another idea now it's gone well while you're thinking of that i have an idea so when i feel compelled to shoot someone's idea down i one thing that i found that works really well is as you're describing the idea or you're making your case to the person um try to show

that you have objectively considered it by listing all the good things about the idea and not just the bad things this will signal to them that you've done your research and you're not just shooting it down for some other dumb reason, like I didn't have the idea, for example. You can say, look, I like this new framework that you've proposed. It has the following advantages. It looks like it will increase developer velocity in the long term. It looks like it'll be easier to hire people that work in it. It looks like it'll reduce our deployment speed or whatever it is. And then you can say, but there are also two cons that I think outweigh all of the pros. And they are, A, I think it'll make it harder to onboard new engineers and it will create some

technical debt. So in the aggregate, when I compare this list of pros and cons, I think the cons outweigh the pros. And if you show someone that you were really thoughtful about it, then they actually have a chance to say, okay, I agree with that because maybe they didn't consider the cons that you had thought of. Maybe they only thought of pros. And it also gives them a chance to say, oh, well, as long as we're listing all the pros and cons, here's a couple of pros you didn't think about. And that might give you a chance to reconsider your position with now more complete information and see if the scales tip back to a more affirmative answer than a negative. Yeah. What about the second part? If I follow their suggestion, but things don't go well,

how can I convince them to refactor the structure without them feeling like I'm blaming them? I was reading a Wikipedia article the other day about some British statesman who had some witty sayings or something. I don't know. And he wrote a book about some historical event that got disputed by people. And then he joked for a while that he was going to write a second edition after some new evidence that came out that was, I told you so, you fools. That's the title of the second edition of the book. That sounds about right. With more expletives in there. And so I think that's what you could do. You could make like, we've talked about architectural decision records before, or I don't know, writing to communicate technical decisions. You write a memo that's

titled i told you you fool yes exactly what's this wiki page here in the company corporate wiki called i told you you fools why are there like 14 of them part one yes my list of grievances yeah i mean maybe that won't go so well i you know it is so hard actually once a decision like this has been made especially when it comes to bringing in new frameworks and stuff like this or architectural changes in your code base it is so hard to get them out so i would say this is actually a situation you're never going to face where you'll need to actually convince them to refactor or restructure it without feeling like you're because you'll never you'll never be given the opportunity yes you will never have to do this good news you will never get clearance from

your product managers to spend time on it okay that's yeah you're saying it doesn't matter if you convince them you have to convince the business and you won't so don't even try right that's that's what i'm so you can still write the i told you so fools article but it's not going to matter no one will read it yep yeah and that's why it's so important to make good architectural and framework decisions up front i think that's also why especially in an established place folks tend to be kind of conservative about architectural decisions and i mean that in the sense that kind of slow to introduce new things slow to change the way things are done slow to add new variants of like we do it this these five ways let's add a sixth way

because they kind of know and and it's here forever once we add it that's a little more pessimistic than the truth and you can make a business case for it you can kind of chip away at stuff over time but it is generally a lot harder to remove or change stuff than it is to at it yeah which i think is why i don't know you could bring that up in part of your cons at the beginning listen if this goes wrong we will never ever fix it right right it's a one-way door right i mean that's a common amazon decision making framework it's like one-way doors deserve more scrutiny i'm not scrutinizing you but this is an important decision that we will not be able to go back on yeah man it feels like such a bummer to say this that feels like it's a larger problem

if technical decisions are in general a one-way door because they're not there's nothing inherent in the code that makes it a one-way door it's more like the the priorities of the business make this a one-way door right so reality yeah economics yeah i actually had a yeah i had a customer who was a kind of a high dollar value customer that paid for a lot of custom software development back in the day and he used to make a joke where he'd say the difference between hardware and software is that you can't change the software my father-in-law works in hardware and he does iterate a lot on these little boards that he's well little i don't mean that in a dismissive sense they're very tiny uh these boards that

he's building it's a lot of changes yeah um that's because you can change hardware yeah well have we answered the question i i think so combination of make sure you fully explore the pros and the cons and show them that you've done so and then understand that certain decisions are actually very hard to revisit so it's important that you make them right up front and i was i was laughing when i said you'll never actually be able to restructure or refactor this but it's kind of like 80 true and so when the time comes and you actually are able to do it hopefully it's crystal clear to that person why we're doing this like your arguments against this framework they will either prove to be true or false and it'll be demonstrable you'll know based on things you

can actually observe and so hopefully they're observable by the other person as well and hopefully they're a rational human being who hasn't completely tied their ego to the to this particular web framework that you chose and if so you'll they'll be like okay let's go ahead and kill it. But I've actually been there before. So let me just tell one brief story. A little over 10 years ago, I joined a company. It was a startup. We had a bunch of code and an early engineer in the startup had chosen to use a particular framework to do permissions enforcement in our web application. And it was probably a little overkill for what we needed. And no one really understood it well, because it was kind of a magic thing that just kind of happened in

the background and exceptions would just be thrown here and there when someone stumbled upon a permission thing that they weren't allowed to do. And this, we wanted to tear it out. So when I say we, I mean pretty much the rest of the development team, which is like four or five people. And so I did not handle this well. I think I just assumed that everyone agreed with me. And that was true for everyone except the person who brought it in. And we never really had a sit down conversation where we said, hey, we'd like to debate the merits of this framework. Can we remove it? But we eventually did tear it out and more or less without this person's knowledge. And so I think that there may have been hurt feelings that were completely avoidable if

we had sat down and had a person-to-person conversation and been able to actually explore the whole situation together. So that was an example of when it goes bad. And that person eventually left the company and I felt bad about the way the whole thing went down. And I wish that I had just sat down with them and said, listen, I don't like this. And I want to explain to you the good and the bad as I understand it and see if you have a different opinion on it.

Yeah, it is. It's really hard not to get tied up in your own technical contributions in code. And especially if you work somewhere for a while, you will work there long enough to see it become a monster. And then everyone kind of complains about the current state of things. And oh, it's so bad. It's so horrible. And teams can be better and or worse at noticing the author's presence or kind of being careful in their language to try not to hurt feelings. but it in general if you work somewhere for a while you will build something cursed by everyone else including yourself sort of and and it's i don't know it's tricky to navigate i agree but necessary that's what the money's for yes to make you feel better wipe our yeah wipe our tears away with these piles of cash all right all right we've answered it i think so what can people do i forgot to wish them good luck yes you know what dave's good luck is sufficient okay it's powerful enough to count for both of us

what can people do if they want their own questions answered go to soft skills audio and click the ask a question button we want to say thank you to everyone who does that each week we love love reading your questions they fill our heart with joy and luck luck yeah that's why i I think they put a little spring in my step. I could tell. I could tell from the Zoom call. Sounds springier. Thank you so much for listening.

Thank you for asking questions. We will catch you next week.