Original URL: https://www.theregister.com/2007/07/03/institutional_idiocy_it/
Institutional idiocy in IT
High tech narcissism or old fashioned stupidity?
Posted in Software, 3rd July 2007 10:25 GMT
Every now and then, I think it's healthy to sit back and recap on industry best practice. However, I'm not going to do that here. It's much more fun to tear into worst practice.
I'm talking about the sort of institutional behaviour that transforms the simplest task into something requiring a 20 person committee. The measures put in place to offset competitive advantage. The pointless and unavoidable bureaucratic method that drags us down to the baseline level of performance (or more accurately, lack thereof).
Unfortunately, I've got no quick fixes to the hardship and stress these people cause, but if I can make fun of them for a page or two, at least we might feel better about it...
What are the signs that your company indulges in unhealthy reinforcement of idiocy from years past? Well, there's really only one. Your company probably has a purpose, a core competence from where the profits come; and once the company was innovative, streamlined, and single minded in the pursuit of this corporate goal.
Unfortunately, in this golden age some weren't happy. Those who couldn't innovate furrowed their brows in a vain effort to understand and started inventing ways to stifle that which was beyond their comprehension. Bureaucracy was introduced to slow down the ideas men and to shift the battlefield. Eventually, many organisations forgot that providing bureaucracy and a playground for narcissists does not help them to make a profit.
Does anyone know what I mean when I say "office drama queen"? Imagine a basic oversight that can be fixed quickly. For instance, a missing SQL file in a deployment package, the kind of anomaly that is fixed in a couple of minutes, after which things go smoothly thanks to the undramatic reaction to a simple mistake. But not if the drama queen is the first to notice. The severity of the problem will be magnified many times over. There's perhaps a valid underlying issue, but any impact analysis is lacking. He (or she, but we'll assume male for now) will grab a passing manager by the shoulders, shaking him as he shouts about the impending breakdown in the client relationship. As the real engineers shake their heads in disbelief, the manager is visibly affected; he mistakes the head shaking for universal appreciation of the management talent just displayed.
While we're talking about this, we could also mention the email demon. Any ill-judged mail will come back to haunt you. Remember those vague suggestions you made, in context, just to start a discussion on some subject? The email demon's reply shows a complete misunderstanding of the original email and he's seen fit to place in bold, YOU MUST NOT DO THIS. Copied in are all available managers; his only hope is that one of them won't see what a cretin he is. You, of course, have a devil's alternative. You can reply to his CC list or you can ignore it. In one case, you will be interpreted as belligerent; and in the other, you're letting yourself be walked over. If anyone has figured out a way to deal with this, please let me know. I can't say it officially, but just between us, this significant contribution to the industry should see you well placed for a Turing award.
These are two of the tactics employed in the game of politics - that productive people generally don't like playing. It's not all that we're up against though. Armed just with basic professional integrity, we must also face arcane procedures without any obvious origins; which may have made sense once but not now, when the same result can be achieved both faster and more reliably with improved techniques or tools.
Beware of pointing this out, however, because the suggestion that widely used procedures are outdated can be seen as highlighting the ineptitude of your colleagues [or, worse, your boss, who may actually have implemented them when he was at the coalface, years ago – Ed].
If the arcane procedures form part of an interface with other people, you may not even be able to do things your way quietly, you might have to accept them until you can find a way to bring people around diplomatically...Is such a case hard to imagine? An example is that many development companies have still not adopted incremental development processes; there are still "telephone directory" specifications out there, developed by the marketing department with no input from development.
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.