|Perl: the Markov chain saw|
Re^2: Why Perl is a Valid Choiceby jhourcle (Prior)
|on Feb 01, 2006 at 16:52 UTC||Need Help??|
I've worked at a job where the problem was the exact opposite of these two statements -- the director of the department had been a consultant -- he believed that the solution to any problem was to throw bigger hardware at the problem, and that the tech folks were just an annoyance that he had to deal with.
Because he came from a semi-technical background, he thought that he was instantly knowledgable in all things technical. I don't know about you, but I don't want an ear-nose-and-throat specialist performing open heart surgery on me. Likewise, someone who designed a Citrix solution for the company might not have the necessary skills to deal with a 35k user mail system. (hell, he didn't even have the skilsl to design a replacement Citrix solution years later, when the Citrix consultants were trying to explain that the system ran best on faster dual processor machines, and he had already blown the budget on quad processor machines that he got a good deal on (and were discontinued shortly after he bought them)).
In this case, the management only cared if they were liked by other management folks -- they couldn't care less about the people who worked around the clock for 2 weeks straight to try to repair a mail system that had tanked. (but of course, it was the system w/ student's accounts that went down, not the one with faculty and staff, so it wasn't that big of a deal)
When I was appointed 'technical oversight' for a project, whenever I raised an issue with a solution that our director had proposed, I got bitched at, and told I was wrong. (the director had actually threatened multiple staff members, and I heard that there was a meeting that he tried taking a swing at one of my former managers). I was informed after I was fired that he had told one of my project managers to try to force me out.
I'll agree on some of the reasons for such occurances, but we had 12 'UNIX administrators', the most of whom sat idle, and there were two of us who did the majority of the work, because we actually delivered. (but although we were the only two focused on development, they left us doing production support, and then got pissed off whenever a schedule slipped) They spent lots of money on training -- they even sent managers to training, but didn't bother sending the people who were actually maintaining the particular systems because they couldn't risk having those people out for a week.
Money wasn't really an issue, either -- management would go to the board of trustees, explain how they needed another $1.5mil, and when the quote turned out to be lower than they thought, they'd just buy more systems than needed (to sit in a store room for more than a year) ... and of course, there'd be no budget left for disk upgrades because of it ... well, there was money spent on disks, but they went to a different project, so we didn't have the necessary disk space for our project.
In this case, the director wanted to micro-manage -- he specifically kept overriding what my managers (yes, I reported to more than one ... I asked for clarification once, and he told me I took orders from any manager who had an emergency, and he refused to elaborate on what qualified as an emergency, and who made the judgement)
So yes, I'll agree on the management incompetance, but there are a few, possibly outlying cases where managers try to rule by fear, and/or spend the time sucking up to their superiors (when they're not playing Jedi Academy at their desk), and couldn't care less about being liked by their underlings or even trying to do a semi-competant job -- just the appeareance of doing one to their superiors. And they're perfectly willing to piss off the tech guys, if it means they'll go away, so they aren't around to expose their lack of knowledge.