Operation Bootstrap

Web Operations, Culture, Security & Startups.

Building a Pirate Ship - Policy Creation

| Comments

A day or two ago I was building one of the Pirateology wooden pirate ships with my Son and thinking a bit about some of the policy creation tasks I have on my plate I found some similarities I thought would be interesting to share.

These construction kits were new to me in their method of construction. You would get a sheet of mostly pre-cut pieces that you had to first number according to a paper that comes with the set. The numbers are placed where the pieces interlock and you then construct the ship in numerical order. This provides you with some guidance but really, all you have to go on is the following:

  • A single view of the ship on the front of the package

  • A pile of shaped pieces of wood which you can associate with parts of that picture

  • The numbers on the wood to tell you what pieces intersect with each other and the order of assembly

To me, this left quite a bit to the imagination; maybe that was the point. Regardless, I was able to assemble the ship with a bit of analysis and experimentation. That got me thinking – if I felt like this didn’t provide me with much guidance then why am I so comfortable creating process and policy where there was none before? It’s not really a mystery – the answer is that there’s more of a framework already in place than we realize, which is where the similarities started to appear for me.

See, you can take some comfort in knowing that for the most part, every piece of that ship is on the table in front of you with a number on it ready to be assembled. You can also take comfort in the fact that someone, somewhere, has assembled this ship a few times before you and probably worked out most of the kinks. Therefore, you should be able to just follow the directions and put it together. However, even with that level of completeness, even with all the pieces designed and tested for you, assembling them requires some willingness to experiment & get it wrong.

In policy creation the pieces aren’t there, they aren’t cut out and you can be pretty sure that nobody has assembled them before you unless you are updating an existing policy. Yet, we feel compelled to build the perfect policy or process from the start. I think the reason for this is simply because we want to do a good job and we know that the policy & process we define impacts many other people. This is a good reason to put a lot of thought into it. It’s also a good reason to talk to lots of people before you make a final decision on how to do something. But it is not a good reason to expect things to go together perfectly the first time.

Think of software development as another example. Software is never really “done”. Often software is introduced as alpha or beta code to allow exposure to everyones use habits. While the term “beta” today is starting to mean “software with minimal commitment by the developer” it’s still a way to get something out there and let folks kick the tires.

A number of years ago I followed the snort mailing lists closely and I will always recall something Martin Roesch said. I do not recall the exact nature of the discussion but it was basically around some feature which wasn’t exactly as the poster would like it to be. Martin’s post used the line “Perfection is the enemy of good enough”. He’s likely not the first person to say this, but he’s the one who said it and imprinted it in my memory forever.

Think about what it would take if you were given only the pre-cut pieces and the picture with no numbers? What about if the pieces were not pre-cut? You would be doing a bit more experimentation wouldn’t you? You would probably need more wood.

In creating policy & process though, all is not lost. The pre-cut pieces and numbers are there in many places, we just don’t realize it. Look at how work gets done today, how are changes made and with what urgency? Often times it’s urgent changes that are most at odds with policy adherence – so understand what leads to those situations. Where do users already do things they know they probably should not (passwords on post-it’s?). What is the driver behind that behavior?

You have the advantage of analysis. You also have the advantage of directly speaking to those who will use the process. I had no such advantage building my pirate ship – I couldn’t ask why they put a slot in the wood in that spot. Maybe there was no reason at all!

Most importantly though – move forward and tread lightly. Sure, sometimes you have to get tough and drive change but make sure you have a significant majority of folks on the bus when you do this.

Comments