Institutional idiocy in IT

High tech narcissism or old fashioned stupidity?


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.

Sponsored: 5 critical considerations for enterprise cloud backup