Unfuck-it Essential Reading: The Visible Ops Handbook

I am an unapologetic ITIL believer.  ITIL, for those of you who haven't ever encountered the acronym, stands for Information Technology Information Library.  ITIL is framework for IT service  management created by the British Government, sometime around 1989.  We'll discuss ITIL in pretty specific detail down the road, especially as we evaluate ITIL's compatibility with the Unfucking mindset.

Given the layers of structure and process included in the IT Service Management (ITSM) framework, ITIL can be really unwieldy to implement in smaller organizations.  Knowing how to separate the signal (impactful, action-oriented process and methodology) from the noise (committees, bureaucratic overhead) can be really daunting, especially in your first few attempts.

The folks at the IT Process Institute, a collection of really smart people who have spent a lot of time thinking about IT other process frameworks, have compiled a tight, direct overview of implementing ITIL in organizations called The Visible Ops Handbook.  Around my circle we refer to it as Visible Ops, which I will do for brevity.

Visible Ops is broken down in to four parts:

1. 'Stablize the Patient' and 'Modify First Response'
2. 'Catch and Release' and 'Find Fragile Artifacts'
3. Create a Repeatable Build Library
4. Continuous Improvement

More than any other book I've read on the subject of ITIL, The Visible Ops Handbook provides a concise, easy to digest blueprint for getting the basics of ITIL implemented to help out a stop to uncontrolled, unplanned and unmanaged changes.  

This book is such a fundamental tool in the Unfuck It tool box that I'll spend the next four or five posts going through the sections in deeper detail.

If you're at all interested in ITIL or technical process improvement, I highly suggest you get over to the ITPI website and purchase the PDF.

IT, Technical Operations and the Cult of Done

Sometime in the last couple of years I became aware of The Cult of Done Manifesto.  It's targeted at artists, writers and other creative types and is a call to action, a reminder that getting to the end of something is the point, not being perfect.  I read it over a couple of times and felt a stirring in my brain that somehow this wasn't so different from the world I lived in, albeit with some differences.  

I decided to take a stab at creating a version of the Cult of Done manifesto for IT and Technical Operations. It's a work in progress, but I've shopped it around to some people in the know* and I think it's pretty damn close.  With full credit to Bre Pettis and Kio Stark, I present the IT/Ops Cult of Done Manifesto.

• There are three states of being:  Not knowing, action and completion
• Accept that everything is a work in-progress.  It helps to get it done.
• Don't make big decisions.  The fear of screwing them up paralyzes you and keeps you from being done.
• Make hundreds of small, calculated decisions.  Being done one hundred times is better than sex.
• Don’t be afraid to make a mistake. Mistakes are a way of identifying what ELSE needs to be done.
• Pretending you know what you're doing will get you up to your eyeballs in screaming bosses and pissed off co-workers.  But if you know 75% of what you need to know to get the job done, do it.  The other 25% will get hashed out before it goes live.
• STOP FUCKING PROCRASTINATING
• If you have an idea that can't be fleshed out and implemented in a day it's too big for you and needs to be dropped, kicked up the chain, or cut into smaller steps so that you have things that can be accomplished in a day.
• The point of being done is not to finish but to get  other things done.
• Once you're done you can throw it away, shit-can it, or never look at it again
• Perfection is the pursuit of those too afraid to get things done.  It's boring and keeps you from being done.
• People without any dirt under their nails are wrong; doing something makes you right
• Failure counts as done.  So do mistakes.
• Throwing the whole thing out and walking away counts as done.
• If you can outline your idea in a paragraph, do it.  Documenting an idea is like foreplay for done. It’s also the afterglow.
• Write down your plan.  Plans are maps to the land of done.
• Follow the process.  Processes make sure you get it done over and over without having to reinvent the wheel.
• Done means documented, regardless of outcome.  Documentation is the key to making sure everyone gets it done.
• Make lists, checking things off is being Done! If you do not have it on a list, it will never get done.
• Automate all the things! Automation is the ultimate list and removes the possibility of human error when getting stuff done.
• Use whatever tool is best to get the job done, not the one that is most shiny.
• Broken things are fucked.  Your job is to unfuck things.
• When you encounter something broken make sure that it gets identified and documented.  Unidentified, undocumented things never get fixed and suck away resources and time.

What do you think? What's missing? What doesn't belong?

(*Thanks to Ralph, Bryan, Josh, Dave and Andy for the input.)

Welcome!

My name is Gary. I've been involved in IT and Technical Operations for a little over two decades, in big companies and small. From ISPs to Healthcare to Online Games, I've seen a lot of weird, fascinating and (all too frequently) totally fucked situations. Some of these were technology problems, some were people problems and some of them were just organizational problems too big to solve. Along the way I've come up with a few strategies and tactics for what I call 'Unfucking' problems.

Through this blog I hope to share my accumulated knowledge to help others get past some of the things in their organizations that are in real need of Unfucking. I also hope to hear from others on their experiences and strategies for maneuvering into success in the IT and Technical Operations world.

The posts, anecdotes and other bits and pieces will mostly be focused at IT and Technical Operations engineers and the people who manage them. I'll try to work in other perspectives and maybe some guest posts, but the bulk of what I've got to say is targeted at those in my industry.

Here's a little snippet I recently posted on my Facebook:

A few years back I had a person working for me who had just taken over as CS manager. I decided to put together this helpful presentation to give some insight into one of my core management philosophies - Don't just sit there - Unfuck it.

It sounds a little silly, but I have seen/heard an enormous amount of bitching about how a process/server/software/group is fucked up but very little in the way of personal responsibility when it comes to wading in to turn things around. I started challenging people to un-fuck those situations and have some some pretty amazing results.

Enjoy and please share.

Helpful Management Tip #1