Guidelines or rules?
Like the pirates code, the difference between guidelines and rules in software companies is not always clear
--
There’s a brilliant moment in “Pirates of the Caribbean: The Curse of the Black Pearl” where the young Elizabeth Turner, beginning to find her feet in the chaotic pirate world she has fallen into, attempts to appeal to the ‘Pirates Code’.
Wait! You have to take me to shore. According to the Code of the Order of the Brethren-
The pirate Barbossa comes back with one of the classic movie quotes of all time:
First, your return to shore was not part of our negotiations nor our agreement so I must do nothing. And secondly, you must be a pirate for the pirate’s code to apply and you’re not. And thirdly, the code is more what you’d call guidelines than actual rules. Welcome aboard the Black Pearl, Miss Turner!
This movie moment has always struck a chord with me. In the world of self-organizing teams is there a place for ‘rules’? Or at least ‘guidelines’?
Levels of guidance
Lets take a look at levels of guidance, below I’ve knocked up a handy little graphic as a way of illustrating the spectrum that runs from very directive to not directive.
At the most directive end of the spectrum we have ‘enforce’. Of course you need to have something to enforce, so this level implies there is an underlying mandate being enforced. One of the most well-known examples of enforcement of a rule in software is the Jeff Bezos email sent in 2002, sometimes called the ‘Bezos Mandate’ or the ‘API Mandate’. For brevity I will quote only the first and last points
1. All teams will henceforth expose their data and functionality through service interfaces.
6. Anyone who doesn’t do this will be fired.
Point number 1 is the mandate (“expose service interfaces”), point number 6 the enforcement part (being fired is the negative consequence of not complying with the mandate).
