Institutional idiocy in IT
High tech narcissism or old fashioned stupidity?
In other cases, inefficiencies are more malicious in origin. Imagine a middle manager. As an engineer, he developed some tool or maybe a framework - and at the time, he even managed to persuade some of his friends to use it, despite how bad it was. Based on this embryonic user base and reported cost savings [probably without the benefit of a pre-implementation cost baseline – Ed], he managed to get himself a promotion to team leader. Now, not only can he coerce his own underlings to use his tool (so he can claim a growing user base), but he also has a network with other team leaders doing the same thing. They can each coerce their teams to use each other's lousy software, giving them all an exponentially growing user base.
This is the stuff technical directors and (later) mass resignations are made of. A warning sign that your company has this sort of culture is when more resources are committed to producing software for internal use than for customers. The irony is that all of this internal software contains copyright notices - "company confidential, unauthorised use prohibited". But the developers on the sharp end know that if any competitor was dumb enough to steal such software it would be set back years.
Sometimes I wonder if such devious fiends could not be defeated by some critical thinking (feel free to search Wikipedia on "critical thinking", and there's even a critical thinking foundation to help you think critically here - no endorsements implied). When someone comes up with an idea for a new tool or framework, it's possible to compare the expected benefits against the cost but in my experience, this step is often skipped in a rush of "new toy" enthusiasm. And what's worse, afterwards the results are not confirmed against a baseline – and if you didn't take a pre-implementation baseline first, you can't easily recreate one after implementation. Enthusiasm is good, but with a bit of healthy scepticism at the outset (and application of some theory) we'd have a lot less middleware to navigate.
Don't get me wrong; I can accept that most organisations will have some institutional baggage. In one company, I wanted a memory upgrade because my top of the range processor was being wasted while the OS thrashed about in virtual memory. To justify an investment that would have paid for itself in days I had to wait 10 weeks and get a director involved. Finally, some kid on a training scheme came around and reluctantly installed the chip, complaining that it was his job to upgrade laptops and that the desktops were the new guy's job.
Another time I was going to a conference and I needed authorisation for business cards, the HR manager brought it up in a meeting attended by several directors and some external consultants. Certainly, the decision, and potential cost savings, merited some such expensive brainstorming, but my modesty suggests there were perhaps more strategic questions that could have been addressed. Although later on, as said company went through its dying throes, I wondered if it was still using board meetings to authorise business cards.
In conclusion, I've painted the idiocies of the workplace as coming from two sources. Firstly, there are those who want to contribute productively but are unable to and therefore amuse themselves by escalating every error to management. Once the manager is convinced that this person is needed to watch over you, he'll become your boss and that's where the fun really starts.
Secondly, there are the office politicians who like to amuse themselves by reinventing the wheel in a different style. These people were probably once in the first category, but through sheer determination to maximise other people's problems, they've moved up the corporate ladder. Next time, provided someone leaves a comment to this article explaining how to do it, I might write another article about handling such people!
Patrick Murphy is the pseudonym of an experienced developer and consultant – who feels that his real thoughts, if attributed to his real name, could impact his future career in a world where being a "team player" often counts for more than an ability to deliver.
Sponsored: Hyper-scale data management