Soft Skills Engineering - Episode 511: Should I take a temporary management position and performance-based bonuses

Episode Date: May 4, 2026

In this episode, Dave and Jamison answer these questions: I’m approaching 15 years of experience with the last 7 years at fang. About a year ago I was promoted to staff engineer (thanks to the podcast) and switched to an adjacent team under the same director. I have never actively pursued a management role but I’ve been starting to think about it more. A colleague of mine just announced they need to take extended medical leave (1-2 months) and I was asked to fill in as a temporary manager while they are out. How do I go about managing a team if everyone knows it’s short lived? Should I just try to keep the team alive or aim higher? Is 1-2 months enough for me to get a sense of whether I’d enjoy management? I feel like I’ve dived into the deep end and it’s scary but also exciting. I love the podcast, I’ve listened to every episode! I’ll take whatever comedy or advice you have to offer. Bobby Drop Tables asks, Recently came out of a salary negotiation where HR blocked a payrise because they said I was already the highest paid non-management position dev. While I’m getting paid well for the market, I wouldn’t say it’s a ridiculous amount. HR said they wanted a fairly flat salary range across the organisation, with pay differences being dealt with via performance bonuses. On paper this sounds good for most departments (sales, engineering etc), but I’m really struggling to figure out what metrics management could use to assess the software team. It feels like any metric that could be dreamt up could/would be gamed and would likely have negative consequences. Have you ever come across any decent metrics or methods for assessing software performance when it comes to performance bonuses? Especially when the team lead might not have a say in who gets what or how much?

it takes more than smugly telling the llm it was wrong about something to be a great engineer this is soft skills engineering episode 511 i'm your host dave smith i'm your host jameson dance soft skills engineering is a weekly advice podcast for software developers who got so good at arguing with humans that they're now doing it full-time with llms do you think it's better or worse for you to argue with a robot versus a human better or worse for me i'm gonna say much much worse why i'll give you 60 minutes of answer okay i'll give you two reasons number one the robot is a lot more tolerant of horrible behavior than any human would be so you will learn bad bad etiquette and bad manners and bad techniques and number two you can much more easily convince an llm that it is

wrong than you can a human so it's actually bad practice for the art you're trying to practice which is i'm assuming the art of persuasion i wonder if there's some wrong idea benchmark out there of how easy is it to just stick to your guns and say no actually the ocean is made of crabs completely instead of water with some crabs in it instead of partial crab it's full crab yeah yeah there's probably a benchmark like that yeah there probably is yeah well that's not what this show's about all right we should uh should i thank our patrons i was hoping you would i wasn't gonna say it i was gonna wait for you to volunteer to do it because i didn't want to be pushy okay see that's an example of a skill i learned not arguing with llms well they're also not super

pushy yeah that's the thing but they but they allow humans to be put their enablers yeah what's that is that postiles law what's the law about be liberal and what you accept and conservative and what you send not in the political sense but like oh people use it for like api validation and also for communication sometimes yeah i hate that i hate that law do you yeah i really do that's put a lot of burden on you it does and it's why it's why web browsers are so complicated that we only really have two you have to accept everything they accept the yes anyway all right to the patrons yeah let's thank our patrons thank you to angel will not please stop asking thank you thank you i'm i i gotta start this over i'm out of practice i'm not gonna say thank you after

every single name that's what the thank yous at the beginning the end are for okay all right moving on 22 does not equal 22 the real name of the next guy is will angel error your willed angel name variant must contain at least one uppercase letter one number and one special character no one knows my real name is seth angel nice i thought this was a funny name but you didn't laugh now i feel self-conscious will angel if you can hear me please save us i want to put no carrier on my tombstone but if i live long enough no one will get the joke my actual name on LinkedIn is yammy debugging in the dark. Canny, the mobile development

ordinary first of his name. Jacob Shandling. Kvothe Oferkwan Turdi, or as my mother used to say, Fyeth Kileth Huznleth. The missing semicolon. Will Angel please report to HR over your strange cubicle crabs?

Help. And then there's plain old Nick Molyneux. This guy doesn't change his name, but he is hiring. Embedded engineers treat assembly the same way TypeScript engineers treat JavaScript. Javier Gonzalez.

Chewy, the first, landed first engineering role. thanks soft skills heart nice ted timbrel chewy ted timbrel chewy to ted timbrel chewy ted timbrel chewy ted timbrel chewy ted timbrel wow huh a single opening parenthesis dan from drone to play never is not just a creator on mars flamingo emoji i like chicken i like liver meox meox please deliver swiss python summit the one on 22nd and 23rd of october 2026 kyle boss kent c dodds slowing down jenny kim the stochastic parrot will angel is the crab of patreon names ira chan jonathan king it's not a beautiful functional user documentation if i were angel i wouldn't

vote.williamangel.net ignore the crabs dave's serial killer name dave smiles adding inside jokes to your agents.md in your personal repo is technically still a team building exercise braden canes john grant britney alec slash new newcastle's best dev conference may 27 28th and close parenthesis followed by a single closing parenthesis thank you that's awesome thank you thank you i'm sitting here in my chair thinking about people who want to change their profile name on patreon and then forget by the time they finish their commute or whatever it is they're doing washing dishes or going on a walk while they listen to the podcast and i'm like i'm sure that's happened to a bunch of people and i feel that so much but we believe in you we believe in

your ability to change it to something silly i think the world could be more silly you could do it thank you patrons and everyone else for uh for listening if you want to join the patrons you can go to softskills.audio click support us on patreon any amount gets you an invite to our slack team enough of an amount gets you to join this list of great high taste individuals who increase the silliness level in the world, which is awesome. And thank you. Dave, I expect you to read our first question. I will fulfill your expectation. I will not disappoint you. Okay, perfect. Excellent. Okay, this comes from an anonymous listener who says, I'm approaching 15 years of experience with the last seven years at FANG. For those that don't

know, FANG stands for Facebook, no longer called Facebook. Amazon, Apple, Netflix, Google, no longer called google what else has any of these companies changed names none of them i don't know okay continuing about a year ago i was promoted to staff engineer thanks to the podcast all right and switched to an adjacent team under the same director i've never actively pursued a management role but i've been starting to think about it more a colleague of mine just announced they need to take extended medical leave of one to two months and i was asked to fill in as a temporary manager while they are out? How do I go about managing a team if everyone knows it's short lived? Should I just try to keep the team alive or aim higher? Is one to two months enough for

me to get a sense of whether I'd enjoy management? I feel like I've dived into the deep end and it's scary, but also exciting. I love the podcast. I've listened to every episode. Wow. I'll take whatever comedy or advice you have to offer should we treat that like an xor or a logical or oh man this is this is great good on you for getting promoted you said thanks to the podcast i assume that you also did something besides said hey i listened to the podcast stand back one promotion please but i appreciate all the credit nice what do you think i think that look your co-worker your colleague has a really unfortunate thing happened one to two months of medical leave that's probably a serious medical issue yeah i think that you should take

advantage of your colleague and force them out of this role by the time they get back by doing such an amazing job that they will be fired after their extended medical leave have you been replaced by bizarro dave smith evil evil mode engaged yeah it's like mario and wario i guess d if you flip it upside down does it really look still a d like much difference very hard to tell them apart the the evil one yeah good one i mean i think if you want to lean into this you could just make their medical condition worse and then it might be longer than one to two months that'll give you more time for your evil plan oh wow double down that's really bad yeah yeah you might need to you might need time yeah like i'm really liking this gig please don't come back yeah blast

some 5g into their hospital room fry the brain or something i think this is a great opportunity to dip your toe into management which is one of the hardest parts about making the move to management it's it's similar to getting your first software job how do you get someone to take a chance on you in a, uh, a potentially tricky position that has a lot of responsibility when you don't have any prior experience. How do you get prior experience? If no one will take a chance on you, you've answered the question. So whether you should do it or not, I, I think it's very clear. You should absolutely try it. You will learn a bunch. You will be a better IC. You will be more easily able to switch into management later if you are interested in that for real,

or maybe you'll find out you hate it and that's really useful to know. So I think the downsides are low. Yeah. Downsides are low. Upsides are really high. And I just want to put a little footnote on this whole conversation that if the message our listeners are taking away from this is that if you want to dip your toes into management, all you have to do is find a manager and get them really sick. So they have to take extended medical leave. This is not what we recommend. Yeah. Do the opposite of that. Yeah. You've, you've misheard our show. What about this other question? Should I just try to keep the team alive or aim higher? Yeah.

I intuit that to mean, I guess interpret, not intuit. Maybe both. Should I try to make some big changes, right? I see some problems, some things that I think should be different. Should I kind of reshuffle stuff and change our processes? What do you think about that? Yeah, like let's make the team unrecognizable when your colleague returns. What have you done with my team?

All these processes. Again, leaning into the, yes, sabotage them and brainwash them all to hate their old manager. Yeah. Look where I took you from. Yeah. You could try to make your old manager look really great by being a ruthless tyrant. Yeah, we can't wait for old manager to come back to save us from, yeah, Gorlog the Skull Smasher, whatever your manager name becomes.

But only for one to two months. Yeah, step one, request that they address you by your new name. I've enjoyed being your colleague. It's time for me to step into a different role, the role of Gorlog Skull Smasher. And there'll be some changes you might notice. I'll give you a guess what the first one is. I have a strong opinion about this,

which comes from my strong opinion about just stepping into a management role, even as an experienced manager, a new role, which is I don't think you should try to come in and make wild changes unless there's something actively on fire you are very likely to not have the right context to make a big change to process or people or priorities yeah especially if it's a temporary thing if if this was a new role i would also say like probably take a month if it's a really small startup if you're in the some specific context that doesn't always apply

But I think in general, you don't want to just roll in and say, good news, I know nothing about the job or the team, but I've got a lot of ideas about how things need to be different. That doesn't often work well. Yeah, I agree. I think one to two months is actually about the amount of time I like to take in a new management position just to get the lay of the land anyway. So you're just barely going to have enough context to know what's going on by the time you're done. And that's about the time when you could be making some changes anyway. So I think there's some intuition here that says I probably don't want to come in here and make a bunch of changes or take the team to some new level. Now, having said that, while yes, it is probably the case that you will not have enough information or context to make big sweeping changes,

I think you definitely should look for opportunities to improve things. This is a great opportunity. You've got new eyes on the processes, new eyes on the team members. you've got a bunch of experience 15 years of software development experience that you could bring to bear to help this team and things that you're already really great at so i think there's a really good opportunity to make it a little better but i probably would not be aiming for revolution yeah you probably have more context because you are i don't know if it's a team you're already working on but it seems like a team you at least know something about so it's not quite

coming in from nowhere but that's also made up by the fact that are balanced out by the fact that this will be a first kind of management experience thing. Also, the fact that it's a temporary role means you are, I mean, there's a possibility that something changes. Maybe the co-worker needs to take a longer leave or they have a kind of a life realization they would like to do something else or whatever. But there is an end date here in a way that there isn't in a kind of full-time management role. So you do still have a bit of a kind of have their shadow hanging over your decisions a little bit i feel like i've overemphasized this now too like you shouldn't do nothing you should do stuff you think will make things better but there's probably a ceiling on

how disruptive of a change you want to make if it requires a lot of change on the part of the manager when they come back to like deal with the new reality if you add i don't know we're now kanban instead of scrum and all our processes are totally different i think this is better but it's going to be a big ramp up for someone else to deal with it probably not worth yeah if It's like, hey, you know those alerts we haven't prioritized? I really think we should prioritize them and clean it up and we'll get more time back. That feels like a reasonable change.

Yeah, so in other words, you're looking for optimizations or efficiency wins, maybe not total disruption. Yeah, yeah. And I think I'm going to say this idea out loud and feel whether I agree with it or not. Nice. I think it'd be useful if you treated it like it was going to be permanent in your future plans where you're there one to two months.

again, that's about the time where you should start saying, here's my strategy or vision for what this team will be like. And here's my, I don't know, 30, 60, 90 day plan for things that we will do on this team to do better, do more, solve these problems I've addressed. So I think it's probably useful for you to plan around this and think about these problems. Maybe you can share them with the manager when they come back. Here's what I've observed and some stuff you maybe want to think about. But that's also a very valuable experience for you because you'll have practice thinking that way what will help make this team what what are this team's current problems and opportunities and what will i do about them assuming i'm able to yeah i love it let's see

what are some of the kind of i mean you're you're gonna get a sense for sure in one to two months what are the things you really can do like should what should you do i was trying to think of like specific things that you could actually do but i think it's going to be so situation dependent that i think you just go in and frankly you're going to probably feel so deep in the water that you're going to be happy just to kind of like feel like you've kept the team from imploding after two months that you might that might be enough that might be as high as you need to aim yeah that's maybe a useful thing to talk about i think if i or a manager i was working with had to leave for a month or two if someone else stepped in and the team just kind of kept on

going successfully without any major disasters i feel like that would be that'd be great good outcome good outcome that's what i'm hoping for if things get much better magical bonus if they implode sounds bad but i am kind of hoping that there's not a ton of disruption and things just sort of continue in in a useful way in the current direction one one thing that i think would be very good to do is before your colleague leaves get a context transfer like tell me everything you know about this team who are the people you're worried about what do i need to know about interpersonal dynamics what projects do you have in flight like get everything you possibly can out of that manager before they leave and that's actually a really nice benefit that you have in

this situation is not only are you going to get a low stakes way to get a sense for how much you like management but also you still have the manager yeah i'm presuming they haven't started the uh medical leave yet and so yeah a lot of times you're backfilling someone who's already left and so it's like all that context is out the door yeah that is great you can get some of that from the person this manager reports to it's a different perspective though it's useful you should still do that talk to the yeah the manager's manager but getting it directly from the person that worked with them is also great yeah cool have we answered the question i think so good luck this is uh this is a great opportunity i would not hesitate to take this and the only downside i

could think of is that something bad happens to your previous position while you're in this new manage this temporary management position that you can't go back to and now you've you've actually walked through a one-way door that you thought was a two-way door and especially if that manager comes back after two months and they're like okay ready for my old job back and you're like yeah but my old job is gone so now what that's like probably the worst case scenario that i could imagine happening so you might want to get some assurance from the broader organization yeah that you'll be able to return to your old position which i think makes sense i mean i'm assuming you've been at the same company for seven years you promoted the staff engineer and you have all the skills you

need thanks to this podcast to do everything to make all your wildest dreams come true yep at work and everywhere else too everywhere else especially in your endeavors to become an astronaut which we've provided extensive extensive information about yes my son was having a really rough time going to bed last night he's three almost four he was he was sobbing inconsolably because i was with him and not my wife which i understand that reaction i've seen it before and the only way i could distract him is he has this little light that shines and projects like stars and the moon and stuff and i told him hey did you know that we sent some people to the moon a couple weeks ago and then instantly stopped crying was very interested in space so wow the people yearn

for space that's was my takeaway of course they do space parenting yes son did you know that in space there are space lawyers then he really calmed down he was like yes i think he was mostly trying to figure out what we meant and i tried to explain oh the the country and i think he meant like he assumed it was me as personally and some other people and then was planning his own trip to space which oh nice sounds good go for it we we went to space wait you and mom yeah yeah shall i read our next question yes answering your question yes you you should read our next question that's what i was hoping you would do and i will i'll state it as an explicit expectation to avoid any ambiguity great i'll do it this is from a listener named bobby drop tables who asks

i recently came out of a salary negotiation where hr blocked a pay raise because they said i was already the highest paid non-management position dev while i'm getting paid well for the market i wouldn't say it's a ridiculous amount. HR said they wanted a fairly flat salary range across the organization, with pay differences being dealt with via performance bonuses. On paper, this sounds good for most departments, sales, engineering, etc. But I'm really struggling to figure out what metrics management could use to assess the software team. It feels like any metric that could be dreamt up could, would be gamed, and would likely have negative consequences. Have you ever come across any decent metrics or methods for assessing software performance when

it comes to performance bonuses, especially when the team lead might not have a say in who gets what or how much? Ooh, HR blocked it. Painful. What a slick move. No, no, no. We can't give you a raise, but we've solved your problem by just saying, don't worry, perform well and you'll get a bonus. Yeah, don't worry. You'll get a bonus that is totally variable up to our discretion and will almost definitely depend on factors way beyond your control, just like this pay raise. Yeah. This is such a tricky problem. I work closer with salespeople than I have in other jobs. And it's such a vastly different world measuring performance and impact with sales versus engineering. There's a lot of soft skills and a lot of kind of helping each other out. But

at the end of the day there is just a number you look at and say how what what is number number good have some money yeah we're not good have less money right and it's so different in software and design and product where the the impact on revenue is so indirect and it's susceptible to narrative and vibes and personality clashes. And I don't think anyone has solved this well ever. So preface, no, I have not come across any decent metrics. Yes. I remember craving a nice concrete metric

or set of metrics that I could use to demonstrate my performance to my very first employer. I even sat down with the department manager and just said, hey, how do we do this? And I was naive enough to think back then that this person sitting across the table from me would have any idea how to measure engineering performance

and be able to like objectively assess a team of engineers and say, you get big number, you get small number, more money to you, less money to you. And that was 25 years ago, 20, let's see, 23 years ago. And now I sit on that same side of the table as that department manager.

And I think to myself, yep, we figure out engineering performance through qualitative assessment and subjective narrative subjective narrative based evaluation yep that's the state of the art unfortunately there yeah i've i've looked into this and i've been around a couple attempts at it and there are some products that attempt to measure sort of engineering health i think there's this wide distrust among individual contributors of being measured on some kind of dashboard because they feel like it will be used to crank the crank the the screws tighter and exactly what you described of motivating non-optimal behavior in

order to make the numbers go up so these products are all very they use coded or or slightly disguised language to to describe it but they're often dashboards of lines of code or number of pull requests or like various things measuring concrete activity even then that's not really tied directly to output of revenue you could make a bunch of crappy prs you could ship a bunch of code especially with lms now there's some places making kind of token leaderboards or or how many tokens do you use yes i was just thinking like that is the the 2026 engineering measure and and listen don't don't underestimate manage some managers deep deep desire to rank their team members along a quote objective metric and uh do not be surprised if that objective metric for this

year is token consumption yeah i i've heard that metric used as a i haven't seen it used as a performance measure of but more of a how how much are you adopting ai coding for places that are trying to push it on large orgs and it makes sense as a very blunt instrument if you have 10 000 engineers you give inspirational speeches at all hands but like yeah you can't have nuanced discussions with all of them and some they're going to be some detractors who just hate it enough and you smash it all with the put token number on a dashboard hammer and hopefully that smashes your team slightly closer to the outcomes you want despite all the negative things it encourages but there are the uh the the dora metrics there's the devops research what does

the a stand for awesome agency assessment it stands for anything you need to make this number go up devops research and assessment wait it actually stands for assessment it does yeah it's like a survey that um it again is somewhat qualitative but they try to do the stats thing where they say, what if we count the number of stories that people tell about each other and then turn those into numbers? But they have lots of PhDs working on it that are smarter than I am.

So they've come up with some metrics that they say correlate with high-performing software teams, but they're all at the team level. It's like frequency of deploy and change failure rate. Oh, yeah. And that's where measurement, I think, works really great. I love some of those metrics at the team level. Like, what is our team median cycle time

for like from start of development to production deploy you know it's like these are great numbers to keep track of but at an individual level there's so much variation yeah that if you make a leaderboard of that like i don't i don't know maybe with enough samples i don't know what is dave's deployment frequency like what does that even mean only once so far you've been deployed to earth one time exactly it's trending poorly the number is getting lower yeah and you know we're kind of harping on these numbers but you know what this is this is the dilemma you find yourself in you work for a company where hr has the ultimate say over what your pay will be and hr does not understand enough about engineering to assess engineering performance talent and so

what do they do? Well, they typically will depend on what managers say. And Jameson, I know, has been in meetings where a bunch of managers are sitting around, probably governed by an HR or finance person, and they're basically trying to rank their team members against each other to get more of the pie for their team. That's very common. Yeah. And so just imagine an HR person who's just kind of listening and is essentially persuaded by whoever makes the best case in that room for their team members yeah and that's going to come down to storytelling yeah i'm thinking back to those meetings i don't miss them yeah they're tough it's just it's hard to allocate scarce resources with a group of people and and yeah surprise surprise it's yeah it's painful

sometimes there are cases where it's very clear and there's even consensus among the group like oh yeah this person is obviously great and it is related to their work if you just do awesome work that's well that's that's visible then uh that has impacts on the company but also it it creates stories and those stories are shared so i think your best bet is kind of the same as if you're going for a promotion or going for a raise like if you are visibly awesome and lots of people agree the story numbers will look good i think it is interesting that hr is saying no we'll do performance bonuses but they don't have targets i i didn't see that in the question yeah that is pretty vague and it just sounds like no with extra steps yeah that's exactly what it sounds like

no extra steps oh man it's a no but they don't have to tell you no until later and later is someone else's problem yep um i have seen performance bonuses but it's tied to like the company's performance or the department's performance. And that kind of feels like you sort of throw up your hands and say, man, I don't know how we attribute. We'll vaguely count on leveling because often it's a percentage of your base salary or the percentage goes up as you get promoted. So we'll count on that to sort of allocate the funds. But beyond that, it's so hard to decide individually. I wish it weren't. I wish there were an answer here. i have used metrics about individuals when i have very specific concerns if i have seen what feels

like low productivity i will go check and say am i correct are they if i just look at the numbers that you don't use to judge someone regularly but like i don't know it feels my this the story i'm feeling is low productivity does that seem accurate if i just count up tickets or prs or i don't know uh pr reviews or whatever numbers we have available yeah number of characters typed into pr comments yeah yeah how many thumbs up you gave the ceo's social media post or whatever but that's more after something else has already tripped me and less as a continuous thing because people are shaped differently as well there's some people who do a lot of glue work that helps the whole team, and maybe their individual metrics are a little bit lower than someone at their level

because they're pairing a lot, they're having a lot of conversations. Or there's the cowboy who cranks out a ton of stuff and it's broken all the time. I'm struggling to have a different answer besides this is hopeless. I wish it weren't. Well, it probably is hopeless. And let me just explain why I think that's the case. I've worked for a company that had exactly this arrangement, a flat salary range with pay differences via performance bonuses. But in my case, the performance bonuses were stock. And so basically there was a cap on pay up to a certain amount. No one made more than that as a base salary. And then the stock that you were given each year varied wildly from person to person, where someone could be making two, three X what

someone else was making. And this was that company's strategy for managing this. And I would be willing to bet a nickel that your company has heard about that company and is adopting this same strategy. And so there's probably not much you can do to fight against this other than make sure your manager is armed with really great narratives about you. So that when they're in the room fighting for this bonus money, they have at the ready, cool stories they can tell that makes an HR person go, yes, that's someone we want to retain and pay well. And the more people that agree with the story or have heard the story besides your manager, the better too if if another manager of another team says oh yeah that really was awesome because

yeah it helped my team or i don't know like exactly it's not it's not at least the ones i've been aren't purely just backstabbing vicious battling like no no no no there is some disagreement in competition but we are i mean we work together and we like each other generally so there are there are a few people where it's pretty easy everyone just says oh yeah obviously person x exactly and um i think the the takeaway here is you thought you were in the software engineering business but actually you are a bard and you are in the lore business what do you mean your job is to collect and tell really great stories about yourself and then let other people do that as well oh i thought you mean like cast vicious laughter or i don't know play the

loot in a way that casts spells on people that's like a little bit more of a fantastical bard i'm not actually a really jameson's the expert on fantasy i just dabble and so i may have used some of the wrong words but i i like nowadays the gen z folks are all using the term lore about cool things that happen in their life like my uh i have a teenage nephew and he came home comes home from school sometimes and tells his mom mom new lore dropped today i just think it's a great way to look at life yeah but that's your job with your career i feel like we mentioned this a lot but we couldn't talk about this without mentioning goodhart's law where when a measure becomes a target it ceases to become an effective measure i think that's sort of the the underlying premise

behind the hopelessness we feel about effectively motivating excellent performance with performance metrics is yeah you can make a number go up and do the wrong thing very easily but it doesn't mean metrics are useless but they're much better for looking at what happened than telling people what to do yes i don't know there's probably this makes me want to go like talk to a robot about software engineering research because there is a bunch of research about it it's been a while since i've looked into new stuff but maybe we should have thought of that before we recorded this podcast probably that would have required some prep i don't do any of that the prep is my life i live my life that's right i'm always ready to do the podcast that's right and at any moment when

i say i should have done this before the podcast i'm actually wrong because i already prepared as much as is best for the podcast that's right wait what i'll bet our listeners don't know this but we don't even schedule this every week. We just randomly have an alarm that goes off and it's like, here, go, two questions, run. And you have to drop everything and record wherever you are, whatever time of day it is. Yeah, it's like the pager duty alert.

Ah, crap, podcast, now. Exactly. If you know stuff about this or if you've seen good software performance metrics, I would be interested. I think the one place I've evolved at this is from they're literally always bad and how could you be so stupid as to tell anyone

we need your number of commits to go up to it's possible it's really hard to communicate nuance to very large orgs and it's possible that it could be a good trade-off for part of the time in some cases to say make this number move this way for your individual productivity metrics better that we can afford to do it

And the impact will be positive overall, even if it's going to cause some weird stuff. But I still think it's, you can never just build a dashboard and put everyone on the dashboard and see the accurate stack ranking of people yet. All right. Have we answered the question? And the answer better be yes, because I have no more to say about it. I think the answer is yes. That's all your life prepared you to say, which means it's the best. yes what can people do if they want their own questions answered the answer to that question is go to softskills.audio and click the ask a question button and if in that form you write a question which is where should people go to answer their uh to get their questions answered

on the podcast it will self-destruct did you know you can stack overflow a google form with the right you would have thought that they would have fixed that already nope uh turns out it's all it's all recursion all right thank you for listening we will catch you next week