Soft Skills Engineering - Episode 465: Talking to your report's previous manager and how to replace a 30-year-old ticketing system

Episode Date: June 16, 2025

In this episode, Dave and Jamison answer these questions: A listener named Mike says, To what degree do you think it’s appropriate to talk with your peer managers about people that have moved from their team to yours? How much weight do you give their criticisms of an IC that they used to manage that is working out just fine under your leadership? How do you know if it was mostly due to a conflict in their relationship, or if there’s a nugget of truth you need to look out for? Hi, thanks for a great show. I’ve listened to 400 episodes in a year - thanks for making my commute fun! I’ve been at my current job as a software developer for a year. It’s a great company overall, but we rely on a 30-year-old in-house ticket system that also doubles as a time reporting tool. It lacks many basic features, and project managers often resort to SQL and Excel just to get an overview. As you can imagine, things get forgotten and lost easily. Everyone dislikes it, but the old-timers are used to it. They want any replacement to be cheap and also handle time reporting, which really limits our options. I suggested to keep using the old system for time reporting only for now, but the reaction made me feel like I’d suggested going back to pen and paper. While the company is old and set in its ways in some areas, it has made big changes in others, so I’m not ready to give up hope just yet. How can I at least nudge the company toward adopting a more modern ticket system to improve visibility and planning? I’ve shown examples that save time and offer better overviews, but it hasn’t made much impact. Where should I focus my efforts—or do I just have to learn to live with it? Some more context: This is in Europe and the culture at the company is generally open to feedback and discussions from anyone. I have 10+ years experience and a relatively good influence. My manager is driving change successfully to make the company more modern but I suspect he might have given up on this one.

it takes more than passive aggressively approving changes by commenting lgty to be a great engineer this is soft skills engineering episode 465 i'm your host dave smith i'm your host jameson dance soft skills engineering is a weekly advice podcast for software developers who just don't want to take responsibility for saying it looks good to me you know this could be a commentary on how much self-confidence you think they have you look like the kind of person who gets up in the morning and says i look good yeah and my code looks good yeah that's an admirable trait i missed the y at the end and i was trying to figure out what this stood for and what i got was looks looks gross to me lgtm you'll never know what my g stands for looks gouty to me it's overly rich just too complicated

yeah fancy code for its own sake that doesn't do anything you know when you next time you get like a a 5 000 line code review just say looks gigantic to me looks gigantic to me yeah i like that because i feel like that's the case where you do say lgtm the most is when it's gigantic and you're like surely someone who wrote this many characters wouldn't have messed up yeah i trust him yeah who could type that much and still make a mistake no one yeah no one no one who could be so confident to submit a code review that big and make a mistake me the other day when i left a bunch of lines of equal signs in console.logs in the debugging code i left in the pr all right should i thank our patrons i hope you will

thank you to the folks that contribute so much that we shout them out or their named concept out every week thank you to jacob shandling hey bjorn just letting you know that this is now our official communication channel kind regards your boss croissant connoisseur christy the world's okayest programmer noah labhart unsalted french fries are safe to eat just cut a quarter inch around the crust mix unsalted oh unsalted meow mix should be discarded when do you check the names you keep missing how funny i am okay alexander kuznetsov nick molyneux attribute error none type attribute object has no attribute fetch dad joke javier gonzalez chewy ted dim timbrel doing my part makes dave's heart swell but he should probably get that checked

dan from drone deploy never is not just a crater on mars flamingo emoji i like chicken i like liver miamix miamix please deliver trash panda python-summit.ch 16th of october a swiss python conference kyle boss ken c dodds that guy over there jenny kim the stochastic parrot no jonathan king i always like the no because it really disrupts the rhythm i get oh yeah it's not a beautiful functional user documentation i've spent over 230 hours playing balatro i just need a few more hours to unlock the last joker i've heard about this game it's good when i play my wife asked hey is that real money and i said no and then she said oh okay good okay never mind it looked concerning to her williamangel.net is now trapping i mean hiring humans in the

loop to monitor the data selling ai shut up and take my money brayden canes john grant Brittany Alec, this is a pro-goose podcast. Hey, Bjorn, I just want to let you know that your boss is really happy with your work this week. Good job. Nice job, Bjorn. Dave, do you want to read some listener feedback? Yeah. Okay. So here comes a follow-up comment from four years ago, episode 263. For reference, we're on 465 today. So this is going back four years this comes from a listener very verbose who says i'm listener very verbose from episode 263 in july 2021 sorry is this a meta commentary on them being very verbose and how you said all this stuff already oh boy that was unintentionally awesome yes and repetitive my bad okay i'm the person

that struggled to cut down their written messages especially when it comes to code review feedback And I re-listened today. Oh, that's cool. This is, sorry, side note from Dave, the verbose commentary now. Listen to our advice four years later, re-listen to it, see if it was actually good, and then write it and tell us about it. This is a pattern I'd like to see more of. Okay. Yeah. Continuing. Guess what? I sometimes still struggle with writing too much, but I'm a lot busier, and the added pressure helps me to keep things short, which is one thing you suggested. Thanks. Having a heavy workload really helps to prioritize what is important.

Something else I – that's actually awesome. I think we probably joked about how you could be too busy to actually write too much. It's a forcing function. I seem to recall it was more of a silly comment, but maybe it worked. That should be the theme of our podcast. That was a silly comment, but it worked. Okay, continuing. Something else I've started doing is to skim over sections of a code review

and instead focus more of my attention on the areas that carry greater risk. Being hypervigilant on every single modified line was a waste. Focusing my attention where it matters most adds value. Oh, and we didn't have automated linting or code analysis, and now we do. I can let the computer do the nitpicking for me. Thanks for the excellent podcast, and that episode in particular, I appreciated the discussion and the answers. still working on my time machine it's not quite perfect yet need some revision i could try vibe

coding to get it done but it seems lms have an even bigger problem with verbosity than i do that's true oh it's how you know that you can't be replaced by one yet yeah because only you can type a little yeah should i read our first question yeah go for it this is from a listener named mike who says to what degree do you think it's appropriate to talk with your peer managers about people that have moved from their team to yours how much weight do you give their criticisms of an ic that they used to manage that is working out just fine under your leadership how do you know if it was mostly due to a conflict in their relationship or if there's a nugget of truth you need to look out for oh hmm okay so just to maybe restate what's in the question but

to make it obvious mike is a manager someone from a different team moved to mike's team they it sounds like they moved under not the best of circumstances or maybe the previous manager just has some some dirt call it critical feedback about them constructive how much what's a positive way to say that uh some opportunities for improvement yeah yeah yeah to what degree do you think it's appropriate to talk i so i would rather collect as much information as possible knowing that some of it could be biased by poor relationships or or just i don't know it just didn't work out with them but i would rather know i'd rather hear about it i guess you could be worried about biasing and now you look at things that they do that would have seemed innocuous

before that you say ah there's the instance of them doing the right thing 15 times only for the 16th time to really screw it up that pattern that their previous manager said they had yeah that's number 14 oh crap we're almost they're just about to really screw it up yeah i would i would rather know go ahead i think i'm going to take the opposite side of this one and say unless it's a really egregious and serious i'd rather not know i'd rather allow this person to reinvent themselves in a new team in a new environment and see how they thrive now i will say i'll change my opinion if they drove their car through the front of the building okay now i want to know because i might want to that's a tough yeah that's a tough transfer yeah you drove your car from your old

office to your new office through the cubicle farms yeah you just rather not know at all well like i said there's there's probably a line above which i want to know like for example if this person's previous employment or previous team assignment was the driver of the killdozer like i'd want to know that yeah yeah and pretty much everything short of that maybe not i think what would i want to know i would want to know how what what they do well how they how to help them be effective yeah i could see that kind of pivoting into well here's all the stuff that they struggled with and here's the problems they had but like isn't it i don't know you think you think you'd rather just figure all that out on your own or just ask the person themselves i don't

know it's it's such a hard dance because on the one hand during the like let's say i'm i'm interviewing someone who's coming from another company entirely for some reason i want to know everything about their previous job good bad ugly everything yeah if you could talk to their former manager oh i'd be all over you would absolutely do it yeah and yet here you can and yet i'm saying don't and i think it's weird because on the one hand it's like in a hiring decision you're choosing whether or not to bring them into the company so you're looking for red flags. On the other hand here, they're already in the company. They've been transferred onto your team. The decision, let's just say the decision wasn't yours. I don't know. Maybe that's the

situation here. And I'm like, let them, let them blossom. You know, one of the things that sucks about staying at a company for a very long time is that you do sometimes get into a rut or, or repeat patterns that are unhelpful. And sometimes changing jobs is exactly what you need to completely reset your outlook and change your patterns. And so I'm like, I kind of don't want to know about the former you yeah it can be tough especially if you come in really junior it can be tough to be recognized as more senior even if you develop those skills and abilities or or be tough to be to have those opportunities given to you so you're saying this is just a way to reset maybe there is one of the most like hit you in the feels quotes of all of television that came from the

sherlock series when did you ever watch that series jameson was that the benadryl cabbage patch one you got me you got me so good yes it was there's a whole genre of internet jokes about i've heard about this genre and i was thinking oh i gotta think of one of those to say right now and then you just had it ready to go in the chamber and pull the trigger bend and drill cabbage patch oh my gosh that one's stuck in my head the most oh my gosh that's so good yes that series did you ever see that series jameson i did i did yeah no i think it's okay to spoil this because this show ended like 10 years ago but um there's a there's a scene when john watson finds out that his wife was a secret agent in the past and had a really dark past full of a lot of problems and

he has to decide like am i going to stay married to her now that i've uncovered this dark past and he says this line that just hit me in the feels and i feel like it applies to the situation where you're a manager and this person's coming to your team with some baggage john said to his wife the problems of your past are your business and the problems of your future are my privilege and i'm like oh i loved it hmm i think i still disagree despite how eloquent that line is because you're not marrying this person and your job is to get a good performance out of them i think it could be useful to know things that were rough in the past i guess if if you say i don't want to know you're you're sort of saying i trust that they've gotten better and maybe i'll maybe maybe

the manager would tell me some stuff that would bias me in some way or i'd be on the lookout and and it just wouldn't happen i guess i'm just looking more at the downside of like yeah what if there's this tendency that you can see early and and take care of earlier if you know about it or something yeah but guess what we don't always have to agree let's just agree to disagree on this one you get to pick which advice you follow yeah that's true that's all that's actually always true now you just have to pick between us and choose a side and we'll know and it will make us devastated if you choose the other one yes all right have we answered this one i think so dave do you want to read our next question yes i do here we go okay this comes from an anonymous

listener who says hi thanks for a great show i've listened to 400 episodes in a year thanks for making my commute fun wow that is so many thank you for listening it can be sorry about your commute that's a long it's a lot of commuting that sucks that's true okay anonymous listener continues i've been at my current job as a software developer for a year it's a great company overall but we rely on a 30 year old in-house ticket system that also doubles as a time reporting tool it lacks many basic features and project managers often resort to sql and excel just to get an overview as you can imagine things get forgotten and lost easily everyone dislikes it but the old timers are used to it they want any replacement to be cheap and also handle time

reporting which really limits our options yeah i can imagine i suggested to keep using the old system for time reporting only for now but the reaction made me feel like i'd suggested going back to pen and paper while the company is old and set in its ways in some areas it has made big changes in others so i'm not ready to give up hope just yet how can i at least nudge the company toward adopting a more modern ticket system to improve visibility and planning i've seen i've shown examples that save time and offer better overviews but it hasn't made much impact where should i focus my efforts or do i just have to learn to live with it some more context this is in europe and the culture at the company is generally open to feedback and discussions from

anyone i have 10 plus years experience and relatively good influence my manager is driving change successfully to make the company more modern but i suspect he might have given up on this one do you think 30 year old in-house do you think that means that this company is more than 30 years old and they built this way back yes i think they built this thing in 1995 and they're still using it it's probably not even a web interface is my guess i mean maybe it's like a mainframe kind of pure text it's a bunch of flat files with a bunch of yeah a bunch of little ascii boxes drawn on it it's probably running on a solaris server somewhere if you know that ui really well it can actually be super fast to do stuff yeah maybe yeah we'll have to take your word for it

that it's hard to work with yeah i okay i'm just imagining 30 years of integrations and dependencies and like oof the infrastructure that has built up around this where this is this is like a load-bearing piece of software and yeah saying well we'll just use project management tool x instead is not going to solve the problem of what about all these reports written in cobalt that run nightly on this machine under someone's desk and yeah huh i am actually super surprised at the level of uniformity that this company has i'm going to assume this is not a tiny company and the fact that no team has gone rogue on this and already adopted something else is very surprising just just use just use a different thing on your team yeah and frankly

that's probably the best evidence of a good product choice is where you say oh yeah well team xyz down the hall they've been using whatever you know insert ticket tracker here for the last 12 months and it's working great for them no problems at all and you probably didn't even notice yeah cheap is relative to i feel like all the sass ones are like i don't know the 10 to 20 dollar a month range per seat so i don't know if that fits in your budget or not and if you have to still use this homegrown thing there could be some overhead in you building some code or spending some time just kind of pushing stuff from one system into the other but if it's that bad it might still be worth it this is not a it's not a very top-down approach where you develop

consensus and plan a project and stuff i think this is more focused on bottom up and and leading a rebellion against the crappy tool and if the team sees that you're using it and sees how much you love it maybe they'll switch to it and then suddenly half the teams are using this new thing yeah totally and and then the load that it is carried that the old thing is carrying is a lot smaller and then if there is some like centralized dependencies on reporting and stuff where it's like well the executive team uses some of these cobalt reports to make decisions about the business at some point they're going to realize like oh crap these reports are actually useless because half the company is not even working in this system and then they'll just be like okay abandon

it you know i've shown examples that save time and offer better overviews so i think one thing you could do everyone hates ticket tracking software at big companies everybody because Because they usually get, it's hard to have them be flexible enough to have everyone who uses them satisfied with the workflow that it creates. And usually the person designing the workflow, in this case, it was like you in 1995. But if you use something like Jira, tons of knobs on it, a million ways to configure it. Usually the person who's designing the workflow is not thinking, how can I make it easiest for the engineers to do stuff? they're thinking how do i like get all the data clean and roll it up correctly and stuff so this always kind of sucks but if you can show not just this saves time in reporting but like look how

much faster our engineers can go because of this i feel like that's a pretty powerful argument it sounds like the reporting is already a pain and so that's kind of a known issue but if you can also surface the pain of like look they can't even find what to work on and yeah now they can with this thing it's another argument one time i saw a very effective technique for migrating a team away from an old technology and on to a new what was perceived as cutting edge technology at the time and this is going back 15 years and this was the great migration from subversion to get at a company i worked on we had a team of like 18 or 20 engineers working on a shared code base all in subversion and we knew that it was going to be a hard sell to convince them all to do a

big bang cutover to get at once and we also knew that git was kind of new at this time like this was before github existed i think but i was convinced and another one of my team members was convinced that it was better for what we were trying to do and i think now pretty much the world agrees with that as evidence i present who do you know that uses subversion that's exhibit a it's an empty exhibit anyway but the the guy who was the main proponent of moving to git did something very creative which was he found a product like an open source project that would actually let you work in both in the same repository so it was like it was like i think it was called git svn git git yeah git svn yeah yeah and it was like you could have a git interface

to a Subversion repo under the hood. I don't know what dark arts were invoked to make that work. As I think about that now, in hindsight, I'm like, holy crap, it's very interesting. But this allowed us to incrementally adopt it. And so what ended up happening is those of us who picked it up early were able to demonstrate wins.

Like I could say, oh, look, I have Git stash. And I remember people being like, oh, that's useful. Like, wow, that's really cool. Like they just, that's not something that Subversion had. And it was just really great. And then I also remember saying things like, look how fast this is. Like, look at my diff. And it was just like, boom, instantaneous diff, you know, subversion.

It was like, you know, start your diff, go get a drink, come back, and it's ready. And so people naturally started adopting it. So what I'm proposing here in this situation is maybe you could find a way to use your skills as a software engineer to create a kind of integration layer between this legacy system, which apparently has some kind of SQL interface, and a modern ticketing system. so that every time a ticket is created, you automatically create a corresponding ticket and pick some new ticketing system and then find some way to keep things updated and just have it work with your workflow.

And then your team can start working in the new system and they can start singing its praises. Meanwhile, you haven't actually left the old system. Yeah, I think that's the dream. There's some kind of adapter that pipes stuff back and forth. Usually for Jira, I'm sure it doesn't exist for this thing, but some of these project management tools have a jira adapter where you can use your thing and they'll push and pull changes exactly to

support the play we were talking about earlier of like we'll just get one team on it and then it'll kind of spider out as people like it better yeah there there might not be an adapter for a 30 year old in-house i'm sure there's not yeah so this is your privilege to create it yeah you might write one if it's impossible maybe the data models are just completely different we don't have projects we have images that are pixel art that encode the status the gantt chart is is the ticket fun fun side project yeah for sure also i think this is a good if it's worth time to invest in building this adapter i think that's a strong argument for how sucky the current state is in no way. It feels like sort of a circular argument. But if you say, great, I have to roll my sleeves

and build this adapter, and I'm still going to do it, it must be pretty painful. Totally. And furthermore, reading between the lines in this question, they have a time tracker. And so what that means is that it's going to be really hard for you to carve out time to work on this shadow ticket tracking system, because probably you're tracking your time for the work you do at the company. And so if you actually want this to happen and it's off the books, you're going to have to do it on your own time. Yeah. I wonder why they have a time tracker. It doesn't really feel like a consulting shop. Maybe it is. I don't know. Maybe it's some regulatory requirement they have. Yeah, it could be. But I've seen, I think it's pretty common that ticket tracking systems

have a way to put, and here's how long I spent on this thing. Yeah. That's true. Maybe that's what it all comes down to maybe it's not just like a time like a billing thing but rather just how much time each task took in which case almost any ticketing system will work yeah having said that it is also possibility that the time tracking system and the ticketing system just happen to be two rvs living in the same trailer park in this case and they are not actually strictly coupled to each other and if that's the case because i've worked at companies like this as well, where we had to do time tracking and it just happened. It was just because of the industry. It was like defense contracting. And so we had to record our time

spent, but it wasn't tied to tickets. And so as a result, we had a time tracking system and a ticketing system and it was for customer billing purposes. Well, I sense in here that there's a bad requirement if that's the case. And that requirement is that it must be the same tool that provides both yeah and you know like a lot of really bad plans or bad execution or bad outcomes have come because of bad requirements and so it could be that you could somehow make it clear to whoever's making this decision that coupling these two requirements to each other and insisting that one product provide both ticketing and time tracking is actually going to create a mess the question asker even said that they suggested what if we just use the old thing for time

tracking and they got a bad reaction yeah weird right you got to double down and say well what if we switch both at the same time we bring in two new systems one for time tracking and one for ticketing what if we question why we're tracking our time at all and find out we don't actually need to track our time yeah easy for us to say i assume there's a good reason and that's impossible but yeah maybe not i don't know maybe the answer is well because in 1995 the software was written to track time and do tickets exactly and all those people are retired hmm have we answered the question well i do have one more idea which is that when it comes to choosing technologies like this or choosing products for in-house usage it can feel paralyzing

to the decision makers because especially in the ticket tracking world there are so many options and that is in the ticket tracking world not only are there a lot of options but also like everybody hates the one they use you know you you either hate it out of the gate or you eventually hate it but everyone hates it and so it's a hard decision to make because you can always find a detractor for every possible product having said that one way to help overcome that decision paralysis is you you yourself could go do a market inventory of what are all the offerings out there and come up with some criteria or some let's call it heuristics to measure each one and kind of do like the green check marks and the or check mark and the red x in a matrix style where it's like

along the call the columns are all different ticket tracking systems and the rows are each like a feature that you guys think you need at the company it's like the thing that all the vendors do for you but they just they just cheat on it to make themselves look the best exactly you want to do a more objective version of that exactly and it's going to take a lot of time and the time it takes may actually be another reason that no one has done it yet but if you put that together and then find a way to present it you might actually get top-down alignment where you can say like look here are the trade-offs we have to we're choosing between this is my recommendation and then you might end up being the one who has to actually implement the darn thing which you know that

might be another reason there's just so many reasons that things don't change in an organization and one of those reasons is always we just haven't found someone who's willing to be the change champion for this thing and actually see it through all the way and so if you really want this to change you might have to volunteer as tribute depending on how big your company is too this could be the rest of your career yes my legacy yeah when i worked at a giant megacorp we used jira we used jira enterprise which meant we hosted it locally it was definitely under provision because it was crazy slow went down all the time and there was a team of many many many people whose full-time job was jira enterprise hosting and then more teams of people whose job

was like care of the workflow like the guardian the sacred guardians of the buttons in jira that let you add fields or change what happens next when you so basically their job was to tell teams no when they ask for custom fields or statuses or tell everyone yes ah and then deal with the crying that comes from 8 000 fields on your tickets yes okay which didn't help with the slowness problem no it did not it did not so those two teams probably didn't like each other the beauty of this is if you take on this challenge and you champion this change all the way through your grandchildren will have the opportunity of replacing the thing that you choose yeah 30 years imagine everyone in the company cursing you instead of this 90 1995 tool

imagine them cursing anonymous oh he made us move to this new thing just go with me for a moment it's the year 2055 soft skills engineering is recording our 10 000th episode and it's a listener calling in about this system it's the circle of life i would love to replace it again i would too i should probably change some habits if i want to still be doing soft skills engineering 2025 or 2055 need to rethink the amount of time i spend sitting in front of a computer yes well have we answered the question i think so good luck good luck good luck listener thank you for asking in and thank you for giving us a window into your world it's always fascinating love seeing seeing what kind of problems go on at different workplaces and answering them that

part two uh i swear yes also that part yeah obviously implied but yeah yeah what should people do if they want their own questions answered go to softskills.audio and click the ask a question button where you can fill out our little form thank you so much to everyone who does that we really appreciate you writing in with your questions and problems we love reading about the experiences you're having at work and we promise we will eventually answer all of them or die trying Yep. That's pretty morbid. Time to go.

We'll catch you next week.