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).
On the other end of the directiveness spectrum is ‘Generate options.’ In this mode several possible options are considered, there is a deliberate expansion of the field of play. Whereas guidance says ‘follow this path’, Generate Options says “lets take a look at other, different paths”
How directive should a guild / practice be?
Before we try to answer this question, let’s just do a quick recap on the definition of a guild or a practice. Increasingly we work in matrix organizations. The verticals in this model typically follow a line of business or product, the horizontals follow expertise and are sometimes called guilds or practices. Examples are an Agile guild, a Software Engineering guild, a Quality Assurance guild and so on.
Guild leaders will move between a few levels as the situation demands and indeed there is of course no ‘best’ level here. Over-use of the ‘generate options’ or ‘challenge’ stances can result in confusion and low energy. And in terms of enforcement, yes the Bezos email undoubtedly helped Amazon become the hugely profitable company it is now. All I would say on that score is that, as Simon Sinek reminds us, we are in an infinite game and the long term results of rules enforcement in the technical domain is arguably not yet proven.
Increasingly I am finding that the ‘guidance’ stance is under-rated in many cases. Some clear, well thought through guidelines, be they technical or in the ways of working domain can be a real asset to teams as they navigate their way through complexity towards a business outcome. The key is not to over-use guidance and it helps if the members of the guild or practice are at least somewhat in alignment over the guidance the guild is issuing.
Clarity is key
As usual, clarity is key. If you are a guild leader and giving guidance, my challenge to you is “what is your reaction when a team doesn’t follow your guidance?”. Are there negative consequences? In this case you are more likely issuing mandates than giving guidance. True guidance is clear, based on research and experience, but leaves room to be pleasantly surprised when a team doesn’t follow your guidance and still gets a great outcome.
