I worked in a callcenter doing software/dev stuff, and would sometimes talk to the folks handling calls. I got in trouble for this, because they were supposed to talk to their manager for requests and such, and I'd occasionally fix stuff.
it was a west coast company that moved most operations to the east coast. however, the manager was still on the west coast, and wasn't seeing the day to day issues. In one major instance, I remember seeing that the initial 'customer info' screen was taking a LONG time to load. Like...30-40 seconds. In some cases, it was only a few seconds, but for important clients, it was taking a long time. They could vamp and chat for a bit, but it was getting worse.
The agents were hitting a webserver in california, and pulling HTML back, across a private network, and... it was a LONG time for older clients. It was pulling up the entire client history. For important clients - who did a lot of business - it was pulling back megs and megs of data.
When I looked under the hood, the data was being repeated - an entire block of data was being duplicated inside HTML comment tags - someone had put those in for debugging stuff and never got rid of it. So we were pulling back, say, 35 meg when maybe only 18 was needed. I simply deleted the commented info - it had not been touched in 6 months - commented the reason in the svn commit log, requested a new push go out, and the next day things were hugely faster.
I got my ass kicked. I "went behind someone's back" (untrue) and "jeopardized production systems" (untrue). Other people had seen the code and it was pushed out via normal process. It was simply the original developer didn't like that I'd highlighted something he'd forgotten to do. :(
I then angled for actually using gzip compression but was shot down at the time (no, "there's a bug in IE6 with gzip compression and printing" or something like that), even though the gzip would have brought this down to under 1 meg, and every call would have been 'up' in under 4 seconds.
We were further shielded from ever talking to CSRs, because they "might overload us with requests". It was (and still is) a bizarre rationale. :/
I work in a similar role where we previously did have a lot of contact with call centre folks, and the whole "overload us with requests" thing is very real. You become the go-to IT guy in no time at all, because if you make stuff for computers, surely when one breaks you can fix it, right? Or you could build something else in place of it? And suddenly, you have nearly no time to actually finish projects anymore. We had to distance ourselves by a floor and implement a ticketing system to avoid exactly this. Sounds like you had the opposite extreme though, which sucks just as bad but for the floor staff instead of the devops guys. Seems to be a fine balance.
It's not bizarre if you look at it from someone elses point of view: Someone (e.b. your manager, or your managers manager, or higher up) had said there wasn't anything they could do; you made them look bad.
It's stupid behavior as far as the company is concerned, but from whoever you made look bad, well, they stopped that from happening again, didn't they?
wasn't specifically a manager above me directly, but yeah, of course someone looked bad. other people looked bad directly to the people who were paying us money - our CS team said they kept raising the issue in meetings. just really bad rules - groups of people sitting literally 100 feet from each other not being allowed to talk and fix things.
it was a west coast company that moved most operations to the east coast. however, the manager was still on the west coast, and wasn't seeing the day to day issues. In one major instance, I remember seeing that the initial 'customer info' screen was taking a LONG time to load. Like...30-40 seconds. In some cases, it was only a few seconds, but for important clients, it was taking a long time. They could vamp and chat for a bit, but it was getting worse.
The agents were hitting a webserver in california, and pulling HTML back, across a private network, and... it was a LONG time for older clients. It was pulling up the entire client history. For important clients - who did a lot of business - it was pulling back megs and megs of data.
When I looked under the hood, the data was being repeated - an entire block of data was being duplicated inside HTML comment tags - someone had put those in for debugging stuff and never got rid of it. So we were pulling back, say, 35 meg when maybe only 18 was needed. I simply deleted the commented info - it had not been touched in 6 months - commented the reason in the svn commit log, requested a new push go out, and the next day things were hugely faster.
I got my ass kicked. I "went behind someone's back" (untrue) and "jeopardized production systems" (untrue). Other people had seen the code and it was pushed out via normal process. It was simply the original developer didn't like that I'd highlighted something he'd forgotten to do. :(
I then angled for actually using gzip compression but was shot down at the time (no, "there's a bug in IE6 with gzip compression and printing" or something like that), even though the gzip would have brought this down to under 1 meg, and every call would have been 'up' in under 4 seconds.
We were further shielded from ever talking to CSRs, because they "might overload us with requests". It was (and still is) a bizarre rationale. :/