Improving the efficiency of systems (versus filling timesheets)
EagerDinosaur
Member Posts: 114
in Off-Topic
I work in an office where staff are responsible for both developing systems for external customers, and then doing 3rd line (and sometimes 1st/2nd line) support on them. Everyone in the office is effectively a "support-developer".
This sometimes means that code-changes to improve the systems will reduce the number of support incidents raised. This can reduce the amount of work for staff to do, and cause problems filling in the closely-monitored time-sheets at the end of the week. My employer operates in a competitive market place, so being inefficient can result in loss of contracts eventually, but it can take several years for this to happen.
I'm fairly keen make code changes (following change-control procedures of course) to improve the systems I work on, but I'm aware that some of my colleagues would prefer that the systems just keep on generating the same mundane support incidents, so that they have something to put on their timesheet.
How do other people deal with this tension?
This sometimes means that code-changes to improve the systems will reduce the number of support incidents raised. This can reduce the amount of work for staff to do, and cause problems filling in the closely-monitored time-sheets at the end of the week. My employer operates in a competitive market place, so being inefficient can result in loss of contracts eventually, but it can take several years for this to happen.
I'm fairly keen make code changes (following change-control procedures of course) to improve the systems I work on, but I'm aware that some of my colleagues would prefer that the systems just keep on generating the same mundane support incidents, so that they have something to put on their timesheet.
How do other people deal with this tension?
Comments
-
Priston Member Posts: 999 ■■■■□□□□□□Find a job with better management. If the reward for developing awesome software is losing your job, it doesn't seem like a good place to work.
or
Create graphs of the case metrics before and after the code changes are implemented. Show your boss you reduced the number of a certain incident by ##% which saves them ## hours in labor which equals $$$$ a year. Then ask for a raise.A.A.S. in Networking Technologies
A+, Network+, CCNA -
OctalDump Member Posts: 1,722Have a conversation with the people who do the measuring. If you have data that shows "my way is better", then that will help. Either they will get what you are saying, convince you otherwise, or you feel like nothing has been achieved. In which case, consider moving jobs and make sure to mention that is why you are looking for another job in your interviews. Being clear about what you want in a new job can help prevent you landing in a different place with the same problem.
Sometimes there is a reason for the madness, since some of the rules governing business are themselves a bit mad.2017 Goals - Something Cisco, Something Linux, Agile PM -
powerfool Member Posts: 1,666 ■■■■■■■■□□Sounds like a problem with the business model. You need for the company sell more work for you to do instead of just having you sit on your hands and maintain what you have already done. In addition, what about new features? These should be billable in one way or another... either by charging the customer or just as a value-add for the customer that keeps them paying the bills (same as normal support does).2024 Renew: [ ] AZ-204 [ ] AZ-305 [ ] AZ-400 [ ] AZ-500 [ ] Vault Assoc.
2024 New: [X] AWS SAP [ ] CKA [ ] Terraform Auth/Ops Pro