Soft Skills Engineering - Episode 287: Informal favoritism and post-hoc finger pointing

Episode Date: January 17, 2022

In this episode, Dave and Jamison answer these questions: Listener Sara asks, How can I deal with favoritism towards informal leaders in a group? The group is losing group intelligence because the informal leader’s reasoning and direction is favored. Example: when member A propose an argument is dismissed, but when the informal leader proposes the same argument it is cherished. How do I react to the question “why didn’t you do it this way” for features already in production? I am frustrated by being asked that. I got scolded for an idea that turned out to be bad after I implemented it (in production), although I asked the Lead for his opinion ahead of time. As soon as trouble came up a.k.a performance issue in production, he pointed the finger at me. Lost all kinds of respect for him.

it takes more than analysis paralysis over picking the right linux distribution to be a great engineer this is soft skills engineering episode 287 i'm your host dave smith i'm your host jamison dance soft skills engineering is a weekly advice podcast for software developers about all the non-technical stuff that goes into being a really great software developer isn't the right linux distribution always the one you haven't tried yet the next one that you will pick yeah i think the answer is that the right linux distribution is the one that will consume all of your free time you've tried one that consumes most of your free time but have you tried one that consumes all of it i haven't customized the ssl setup enough in the i'm gonna say words that will make me sound

dumber than i already do if you haven't if you haven't actually applied a patch to a kernel module and built that module and loaded it into your kernel you haven't wasted enough time to say that you've tried the right one in order to get your mouse working right that's the caveat there exactly oh you got one of those new usb mice oh man that's that requires some extra work on this distribution yeah i'm on inverse shadow realm ubuntu and we don't have those we don't pander to users like that they're newfangled hardware yeah no we we cater to the power users in upside down fedora all right you want to thank our patrons i do thank you so much to the people or organizations

or entities who are contributing to our patreon such that we shout them out every week thank you to andrew pollock the yeet your job podcast avery sturtzel ian walter arunduna kashaktan ohio cameron hall ira chan monkey face emoji jonathan king testing is documenting.org fizzbuzz influencer oladapo fadie karen sveinsen will angel ragnar harrison nick hathaway travis sanders dennis bogdanov brayden canes john grant ibot winrar nick cantar and philip john basile thank you to this group thank you to all of you who who support us if you want to you can go to softskills.audio and click support us on patreon and then follow their optimized onboarding flow and if you do that not only will you get these fabulous benefits like your name being read by

a person you will also get invited to our slack community and i've said it's great so many times i'm just going to assume you know it's great you do for all our new listeners you might want to know it's great they'll catch up do you want to read our first question okay our first question comes from a listener named sarah who says how can i deal with favoritism towards informal leaders in a group the group is losing group intelligence because the informal leader's reasoning and direction is favored example when member a proposes an argument it is dismissed but when the informal leader proposes the same argument it is cherished i like cherished i didn't notice that before it's a good one you snuggle up with the argument yeah you really really cherish it

give it a warm hug you savor it polish its little noggin i don't know my ideas are always cherished so yeah get get better ideas yeah some some sometimes i uh i share my ideas and then i make really intense eyes and say cherish that idea and they say people say yes sir right away sir it has nothing to do with your position of authority that's right organization looming over you that is an interesting wrinkle here that it is in an informal leader because i think this is unavoidable to some degree with a formal leadership role and you you can try and account for it and work around it but informal that's trickier i mean this this feels like a classic bring down the popular kid in a like high school movie or oh yeah there's there's there's hijinks you can do

it's kind of adjacent to sports sports movies yeah adjacent to sports movies yeah you have to you have to skewer them in front of the group embarrass them or you have some magic creature that is a secret and you reveal the secret and now you're the popular kid yeah yeah the secret to popularity magical creatures right that's how all the popular kids did it they just didn't show their magical creature yet yeah maybe that's kind of like pokemon then you battle with your magical creatures against each other right to resolve the the popularity contest to resolve the angular versus react decision yeah i choose you angular chew the group is losing group intelligence okay i had an interesting discussion with someone once

who was making kind of the a related but not exactly the same argument they were new to a group and they were presenting ideas and they felt like their ideas were not being given the credit or the the the consideration that they deserved and they were pretty upset by that and my point to them was that it kind of matters it shouldn't in an ideal world we have a numeric scale we can just put every idea on at that scale and then pick the biggest number and and there's objective truth and reality in the fuzzy real world that we live in the person proposing the idea carries some context based on their past success and so my point to this person was you have not proven that that your ideas are great so you're getting like the cautious early exploration reception of

the idea that's a good way to put it where presumably someone else who had been uh had been there a while and demonstrated a track record of success would would merit a little bit more investment so it it's possible that you are seeing this play out where this this informal leader has proved themselves to be right a lot and so them proposing an idea carries this comma and i'm right a lot at the end of of all the ideas they propose and maybe that's why people consider it which again isn't necessarily awesome it isn't necessarily horrible either though yeah it's kind of like It's interesting. Yeah, you really made me think about that one.

There is signal we have to use because it is so difficult to objectively evaluate the goodness of different technical ideas, you know? Sometimes it's easier to evaluate the outcomes. And then if you have a track record of outcomes that stacks up in your favor for the same brain that produced those ideas, we'll probably produce good ideas in the future.

Yeah. I wonder if that's true. We have no way of knowing. We'll never know. I think sometimes there's other signals, too, that carry along with it. It's like, if I choose this person's idea, I know that if that idea proves wrong, they will work nights and weekends to fix it. Whereas this person's idea, they won't. It might be a better idea, but the risk level, the mitigation vector is less reliable.

Yeah. there's sort of an identified solution here in the example where some other member proposed the same idea and it was dismissed and then later that same argument was accepted you could try and address that by saying hey thanks for proposing that it's great to see you re-raise person a's argument in this in this context i'm glad glad we decided on person a's argument or accepted person a's solution yeah the goal the goal is say person a as many times as possible yeah yeah to try and help get some of the credit that won't help if if you never come back to this person's idea through the informal leader proposing the same thing right yeah that's a good idea by the

way i don't know if you know this but i named one of my children person a so this is a very personal story to me we've talked about alice and bob the they're the security people right yeah alice bob and eve yeah i need to have several more children to cover the to be able to staff a security research paper. So your idea is just pump up person A, try to give the credit, and dilute the popular informal leader's credit? Yeah. I guess I see this all the time. I don't know. You probably do too, right, Jameson? We see this often. And I think it's very common to have people who bring reputations with them, whether deserved or not. And what's interesting to me here is the comment in this question, the group is losing intelligence. And that is really

unfortunate. I mean, I wonder if you could help establish a culture of measuring the goodness of technical decisions by the outcomes they produce, instead of just by what everyone thinks will happen. You mean, so once you implement them, use some metric from that to say this was or was not a good idea? Yeah, exactly. And I think the way that I've seen that done at other companies is, well, just one company, one really, really big company, was any time there was a technical decision on the table to be made, let's say you're weighing option A versus option B, there was almost always a column for these two options on a table that would say, how will we know it's working? How will we measure the success of this choice?

And if you didn't have an answer to that, that could kill the whole decision-making process. and you know i've like i said i worked at a company where this was the culture and it was like come back to me like we're not going to make a decision now because you don't have enough information so come back to me when you're ready with that information and that was that was really valuable because then you could actually say i don't really care who came up with the idea i just care about how good the outcome is going to be and how we'll measure it yeah you mentioned a group intelligence thing. And I agree, that seems like the bigger problem here. It's probably okay that informal leaders idea gets more attention put on it. But it shouldn't lower the

standard for deciding if it's a good idea or not. If the informal leader can say, hey, I have this idea, let's talk about it. And you're more likely to spend more time talking about it. That seems good. If you're more likely to rubber stamp it, because informal leader approved it, then that seems bad. Ideally, you'd be as rigorous in trying to figure out if an idea is good or not ahead of time, no matter who it came from. And that could be a value that you try to propagate through the team. It could be a thing you explicitly talk about even. Yeah. Person A, you. I assume there are other people on this team who feel like they would love to have more input. And I feel like it'd go over well with the team to say, hey, I want to make sure we hear from everyone and

consider ideas on kind of a level playing field. Yeah. Well, I have another idea for how to achieve that level playing field, which is stop coupling ideas with the person who came up with the idea. Instead, encourage the group. And the way that I've seen this done best is to encourage the group to do this in written form. When there's a big decision to be made, have someone create a document that outlines all the options and get input from the group on what all the options could be but then when the options are described on the paper don't write the names of the people who threw their hat in the ring for each option just put them on paper anonymously which is really the normal way you would do it i know it's kind of weird when you write something down it's weird

to be like and this was jameson's idea put that in the pro column put that in the pro column but over here we have dave's idea i'm putting that in the con column for this idea so yeah and so it's it's really natural once you get to like a writing culture to anonymize things like that and i think it could help have we answered the question yeah i don't i don't really have much else to say here besides trying to launch a smear campaign on the popular informal leader and by smear you mean smear them with honey so that they fall down and stick to the ground they just look so silly like how could we trust the technical decisions of that guy he's covered in honey and then all the yeah all the dogs come over and lick them and they're oh get off of me and then you find out

they don't like dogs and that's very unacceptable culturally these days and scene that's the end of the movie it's beautiful all right should i read the next question let's do it this is from an anonymous listener who asks how do i react to the question why didn't you do it this way for features already in production i am frustrated by being asked that i got scolded for an idea that turned out to be bad after i implemented it in production although i asked the lead for his opinion ahead of time as soon as trouble came up aka performance issues in production he pointed the finger at me i lost all kinds of respect for him there's kind of a two-parter here uh the first question is what do you do when people ask you why didn't you do it this way which of course the

answer is always well because i didn't know everything you know now yeah back then but then the second part is what do you do when someone throws you under the bus or is this would this be an appropriate time to use the phrase burns your film burns yeah i think so could be yeah so what do you do like when your lead goes i don't i don't know it wasn't my idea i couldn't possibly have had anything to do with this it was a rogue engineer on the team that i'm the lead of classic political posturing right somehow doesn't give me any responsibility for this that's right Yeah, you mentioned, because I didn't know what you know, there's a concept in human factors or safety or reliability research called local rationality, which is basically that people generally behave in what seems to them to be the right way in a situation. If someone breaks something, they are very unlikely to be trying to break something.

They're probably trying to do what they think the right thing is, and their knowledge is incorrect about what the right thing is. And so there's this whole, this kind of gets into blameless postmortems, this whole culture of figuring out why did they think this was the right thing to do? What about the system led them to think this was okay? Instead of how could you not have known this, you dumb dummy, which is sort of like the outcome of getting scolded for doing it in production. Yeah. I mean, this is like the opposite of blameless postmortem, right? Yeah. Blameful postmortem.

Blameful. Yeah. That's coming. That's like 2022. Blameful postmortems are going to become popular now. We believe in an unjust culture. That's right. Oh, man.

And what do you do? I mean, I think it's really hard to be in this position because you could just burn the film of your team lead and say, oh, really, team lead? You approved this. I remember asking you if this was okay to do, and you said yes. So, neener, neener.

Yeah. Looks like we're both in the doghouse. Yeah, you dumb dummy. That's what you get for approving stuff. And then the end of that road is long, interconnected approval processes. His job is to make sure no one ever does anything wrong. And the easiest way to do that is make sure people don't do things. But more importantly, make sure that no one can be blamed when it does go wrong.

Or at least not me. yeah that's a tough one that is a tough one so what what what i would do in this situation is i i feel like i'd be fine well i don't know not everyone is me i'd be okay admitting a mistake and saying i don't know i did it wrong because i thought that was the right thing to do but in this case a performance issue in production right how could we have known this ahead of time that this would cause a performance issue. Do we need to have some kind of performance testing? Do we need better data in our staging environment that more closely resembles production scale? There are tons of technical solutions to this specific problem of we saw this performance problem in production

only. Do we need, I don't know, feature flags or something like that? You just inspired me with your answer to come up with the correct response here in this situation. If someone is pointing the finger at you you say oh well it's strange that it's not working in production because it definitely passed our load tests and then and then the lead goes we don't have load tests and you go oh there's your problem it went through our rigorous qa process didn't it yeah clearly our qa team would have caught this performance regression and in their testing right oh they don't test for performance oh there's another problem and look before you know it you just backed your way into a blameless post-mortem yeah i think i think you're

right about not the the cost of turning it back on the lead is that you are further away from making the team safe and this is really the the biggest problem here is is if you get blamed for making a mistake, you won't make fewer mistakes. You'll just tell fewer people about it. That's right. That's exactly right. That's right. Or you will take less risk, or you will be less ambitious, or you will take longer. I mean, the end of the road for blameful postmortems is not good. So doubling down on blameful is not where you want to go. And you can say that. There's quite a bit of material out there around blameless postmortems and how you deal with broken stuff the old etsy blog post on just culture and blameless post

mortems is kind of i think it might be the source of this if if not it was kind of a canonicalization of it but the google sre book has a chapter on post mortems that talks about blameless post mortems it feels like a standard practice on the yeah order of like source control i'm very unsurprised that it's not uniformly implemented though because it's a lot easier to just use git than it is to roll back a culture of blame. But you have a lot of evidence you can point to saying, hey, it's a better way to, like, yeah, I messed up. We will get better outcomes if we think about it in this way

instead of you saying you did it wrong. Be more careful. Now, I think this might be a good opportunity to talk about some of the nuance with blameless postmortems. I think if you take blameless postmortems all the way to their extreme, one of the bad outcomes you'll get in doing that is that you'll start saying things like,

look, we should let an unskilled person off the street come in and type whatever they want into their editor and our systems should prevent that from causing any trouble in production. Or even a nefarious actor could come in and submit code and nothing bad would happen to our product or our customers. And that's just not true. And so, I mean, I think there's a threshold

where your systems, your blameless systems that you develop, they can tolerate a certain level of mistakes being made by people, but not all. And it could be, and I'm going to play devil's advocate a little here with the question asker, it could be that there was a mistake made here that was so obvious and egregious that no systems could compensate for it. It's probably not the case here, but it could be, right? And so I think you have to be just a little bit aware of that angle on the whole blameless postmortem thing, because you still want to have talented skilled team members you just don't want to take it so extreme you know yeah i mean there's still consequences and there could still be

accountability if someone repeatedly messes up in really obvious ways then that's a sign that they don't have the right skill sets or attitude yeah but everyone will mess up sometime and someone's going to be unlucky enough to mess up in the way that results in like they're messing up where the slip of the finger can bring prod down instead of like make a bug that gets caught by the test framework or something you know yeah i forgot what my point was uh yeah i think you need to push blameless postmortems and and a blameless culture and kind of improving systems as as a way for resolving these issues and that's my answer and i'm sticking to it blameless nothing is my fault ever it's all jameson's fault blame jameson post-mortems oh that's a good oh yes you need

a fall guy a patsy wait yeah maybe you are the patsy in this case the sacrificial goat yes oh yeah oh yeah it's even better it doesn't even have to be a human you can just blame the goat yep why do you have a pet goat in your office well that's how we do blameless in case prod goes down to sacrifice to aws yeah aws demands more goat blood yeah or to our sass vendors broadly yeah all right well that is a last minute buzzer beater of the solution. Got it in just before time expired. And with that, I think we've answered the question. I think so too. What should people do if they want their own questions answered?

Go to softskills.audio and click the ask a question button. You can fill out our form there. Thank you so much to everyone who does that. Your questions are the lifeblood of the show. We love them. We love you. And we look forward to many more questions in the future. Indeed. We'll catch you next week.