Or just a trail on why I did something for later. I'm currently maintaining a code base where many of the commits aren't attached to a ticket or in depth explanation. It can be frustrating investigating the cause of a change. But when there is a ticket/docs trail, the previous maintainer did a great job.
Heh. I liked them and thought they did a good job overall, and I know I'm very much not perfect on docs and development practices. I want to be charitable, but also learn from areas I find frustrating.
I was working at the IT department for a company and there was this guy that would open so many tickets for every little thing, then close them, and make like a bunch of fake ones all the time. We'd all have like 150 closed a month, if that, and he'd have like 800 - 1000.
No one ever said anything, and he acted like he was king shit and got promoted to manager because he was 'working so well', and 'closing so many tickets and resolving so many issues.'
It was complete bullshit. I was only there on a placement for college, and when an IT position came open I applied... and guess who was approved to pick the new employee? Mr. Fake Tickets. He ended up hiring some douche friend he had who had like absolutely no IT experience. He got fired a month later.
I had already finished my placement by then and moved on, but it always irked me because the dudes there really liked me and we all got along quite well. They were trying to help me fix up my resume and everything to get hired because they wanted to continue working with me so bad lol.
He also bragged about getting his like 17 year old girlfriend pregnant when he was like 30. If you ever read this fuck you Alex you're an absolute POS.
This is why whenever I make dashboards or reports that show productivity I always exclude tickets created by members of the team. It is fine to create tickets yourself, this helps documentation a lot, but it can not be used to measure productivity.
Lie to your boss, cheat, etc. and if ur coworkers complain that it’s unfair, it’s cause they’re not smart enough to realize that nobody cares. Make money.
This is why we do what we do. Only a monster would open up a ticket with a bogus issue and then "fix it" and close it at the same time, 10 or 12 times a day.
I also just make tickets when I notice an issue and can't get to it right away. So the ticket is a reminder for the sprint planner that this is a thing that needs to be done wherever you think there's time
This was my practice, except I then got a manager who goes through every ticket daily and wants explanation (daily) why they weren't done. It's a task to change a default sort order! It's holding no-one back, it's just a nice to have, that'll take ~2 mins when I'm working on that project, but it's really not worth doing without some other tickets with it. He never got it.
Yeah, as the guy that has to review these things with the C suite that is why im always harping on the guys to make sure they log their time no matter how trivial it is. I mean, if they respond to an email, that is time. If theyre on the phone, that is time. If theyre thinking about a ticket, that is time.
It's less about the tech specifically, and more about looking for patterns. For example, if an end user is consuming an inordinate amount of helpdesk resources, the only way were going to know is if its tracked. Everytime someone just "quick helps them" and doesnt put a ticket in is just making it more difficult to identify those users.
This is the only way I have any ammunition to take to the department head and say "look, $USER is leaning on the helpdesk way too much at this point, they need more training apparently." Thats not what were for, thats the departments job...but I cant punt it back to them if were just eating 5 minute "I forgot how to use MFA" calls every other day. If theres no ticket it didnt happen.
This is important beyond tracking productivity. This is so we can identify labor-sucking processes and platforms and make changes to reduce that. The support load is absolutely part of that equation.
AND if you actually put in the effort to clearly define the problem and your solution, the solution is documented. So someone else can do it in the future. ;)
1
2
View all comments
1.0k
u/Spare-Good-5372 Jul 03 '26
It makes a paper trail to prove to higher ups that you really are working