When Best Practices Became I Have No Fucking Clue.

When you’re implementing an IT system there’s usually a couple well known paths that you can follow that will ensure it operates pretty much as expected. In the past this was what a good IT administrator would have been hired for as they would have been down these paths before and would know what should and shouldn’t be done. Over time companies began producing their own sets of guidelines which they would refer to as best practices, serving as the baseline from which administrators could create their own. With systems ever increasing in complexity these evolved from simple articles that would fit in a blog post to massive how-to manuals that detail nearly every step required to make sure you don’t bollocks up a system. This was the point where the excellent notion of best practices turned into a manual for those who had no fucking clue what they were doing and it shows with the level of competence I’ve seen in the various IT departments I’ve been privy to over the years.

Nearly every good system administrator I’ve met has been, for the most part, self trained. It usually starts out with a general interest in computers at home where they tinker away with their machines and usually end up breaking them in the most catastrophic fashion. This natural curiosity is what drives them to figure out the root cause of problems and is essential when they get involved in larger systems. Whilst training courses are all well and good they are unfortunately narrow in their focus and are, for the most part, designed to give a set of rules to use when first approaching the problem. After that the skills required (critical thinking, logical deduction, et al.) can’t really be taught and those seeking a career in this space lacking such skills typically didn’t make it past second level support.

However the distillation of industry knowledge into best practice documents has blurred the line somewhat between those who have the necessary skills to work at the third level and those below. The documents themselves aren’t to blame for this, indeed they are actually responsible for the industry as a whole becoming more reliable in delivering repeatable results. More it is the use of these documents by those who would not otherwise have the knowledge required in order to perform the tasks that these best practices outline. This is because whilst best practices give you a good idea of which direction to head in when you’re implementing or troubleshooting an IT system they do not cover the issues specific to your organisation. They can’t simply because they are unable to account for the almost infinite number of possible configurations and that’s were those key skills become a necessity.

A classic example of this that’s rife within the IT industry is the implementation of ITIL. Serving as the best practice to underpin all best practices within IT departments the ITIL framework has found its way into nearly every organisation I’ve had the pleasure of working for. As a basis for IT processes it works great, serving as a reference point that anyone who’s been trained in it can relate to. However by its very nature ITIL is just a framework, a skeleton of a what an IT department or organisation should look like. However too many times I have seen ITIL taken literally and business processes shoehorned into the bare bones framework with little thought to how much sense it makes to do so. Realistically whilst it is desirable to be ITIL complaint it’s more desirable to have business processes that work for your organisation. That is the difference between using best practices as a gospel and using them as a basis for a functional baseline on which to improve on.

The blame can’t be wholly aimed at those administrators either as it is the business’ responsibility to hold them accountable when the system doesn’t deliver as expected. Unfortunately too often best practices are used as a convenient scapegoat which wrongly puts the blame back on the business (“It doesn’t work like you expected? But it’s built to industry best practices! Change your process.”). In reality tighter specifications and rigorous testing is required to ensure that a best practice charlatan doesn’t get away with such behaviour but that unfortunately adds cost which doesn’t pass muster with the higher ups.

In the end those best practice sticklers are both a boon and a curse to people like me. Because of them I’m able to find employment anywhere and at a very considerable rate. However when I’m working with them they can make doing the right thing by the customer/business next to impossible, instead insisting that best practices be followed or the house of cards will come tumbling down. Thankfully due to my chosen specialisation being quite new there’s not a whole lot of best practices ninjas floating around and actual experience with such technology still reigns king. However with time that will change and I’ll be forced to deal with them, but that’s long enough into the future that I’m not worrying about it yet.

By then I’ll be working for myself, hopefully 🙂