Strict Rules of Golf – for IT

Years ago, an avid golfer told me about his long-time buddies who, after a few years of playing together, found themselves getting into arguments during play. Through high-school and college, they had been fairly competitive and loved a friendly wager, but they got better as they got older. The money started getting serious – and the squabbles took away from the fun. So they adopted a new Guiding Principle, and began to play strictly according to the USGA Rules of Golf (RoG).

They all carry RoG books in their golf bags, ever at the ready. The on-course opinion calls & ad hoc rulings stopped, and they found themselves able to enjoy the game more. Play went a bit faster as well; no need to theorize or guess, as practically every situation could be solved by this ready resource.

Interesting thing about the RoG – since it’s such an ancient game, the Rules cover an amazing amount of detail and plenty of odd situations (practical joker? bird’s nest? mini-earthquake?) This thoroughness was a key reason to start this policy; no longer did they suffer through multiple opinions on how to deal with situations – they went straight to the Rules for the final word. It no longer matters if you don’t agree – when its documented in the RoG, you go by the letter of the law, no excuses.

“Rules of Golf” for IT

In my IT shop, we’ve established an internal wiki for processes, defined standards, policies and procedures – anything that could benefit from structure and specificity. I like the Wiki (in a burst of innovation, we refer to it as the Wiki) as a medium because it’s quick and easy to capture the process, instantly accessible to everyone in the group, and changes / additions / deletes are faithfully logged and retained. Perfect for the daily, weekly, & monthly processes that people need to know, but are such a pain to capture and document in an accessible way.

What does this have to do with the Rules of Golf? Simply put – the Wiki has become our go-to Rules guide; our generally accepted standard is that “as it is written in the Wiki, so it shall be”. Strict adherence to the documented process in the Wiki, no exceptions.

The Second Obvious Problem

Of course, the First Obvious Problem with this approach is that typically tech folks don’t like to write documentation – their loss, until they realize that the person who writes the rules” has a surprising amount of control over what those rules actually say.

But in the first few months – after an initial capture of the key processes and standards – folks begin to realize that the “stuff” captured in the Wiki is [some combination of] wrong, incomplete, missing detail; unworkable and/or incomplete. Not an atypical situation – because, unlike the RoG, we only started building the Wiki last year, and the attack plan was to add content when the [new] topics came up (instead of “death marching” through all of our internal processes – no one has the patience or stamina for that). The RoG’s comprehensiveness is due to it’s longevity; it’s a model to aspire to, but you have to realize that we will get there over time.

The assumption (requirement!), of course, is that the Wiki is constantly being updated, added to, improved; it accretes specifics, develops depth, and slowly becomes more authoritative over time. It supports my “lazy” idea about automation – document something well, and you never have to remember it again. Added bonus – you will guarantee consistency / quality.

Strict Rules of Golf for IT – and the Third Obvious Problem

An internal documentation store pays off when the organization commits to using it exclusively. Like our golfing buddies from above – no more opinions, beliefs, legends, or “we’ve always done it that way”. When in doubt, go right to the Wiki as the authoritative definition of The Correct Way of Doing Things.

Of course, the cynical will point out that, unlike the Royal & Ancient, it is quite easy for me to change the rules by editing the wiki to agree to my point of view! Actually, I am always amazed by how long it takes people to realize this “obvious” fact – but there are simple “controls” that are in place (all edits are logged, nothing is anonymous – and past versions can be reviewed). The unwritten rule is “don’t be sneaky”; if there is a difference of opinion, have a discussion with the author (preferably not over eMail).

Wait, unwritten rule? Actually, it’s in the Wiki …