Sometime you need something to keep cars off of the sidewalk!

Guardrails are a tool to ensure alignment with the organization’s goals and objectives and to keep people on the right path. Guardrails are an everyday fact of life. Several years ago, I was on vacation in Lima, Peru. During the vacation, we ventured into the heart of the city to see the sights, at the end of the day four of us piled into a cab on a very crowded street to go back to the hotel. Mass was just ending at the cathedral and there were throngs of people taking to the street. The driver inched along for a few minutes then pulled the car up on the sidewalk and began rocketing forward (the rocketing part is my recollection). I still wake up occasionally picturing people diving into doorways. Jason Bourne had nothing on this guy. In most societies, there are laws, standards or just social norms about driving on the sidewalk.  I was in India for the past two weeks. When we in touring Mysuru, several coroners had physical barriers (concrete and metal poles) to keep cars from cutting corners and driving on the sidewalk.  Both of these examples represent types of guardrails. Guardrails channel behavior for the benefit of the greater society by abridging, formally or informally, the range of action individuals can take. Breaking through a guardrail requires a conscious decision. Software development, in all of its forms, requires guardrails unless every decision made by a team is scrutinized and approved before it is made. Without guardrails words and phrased like self-directed and empowered teams are hollow.  In order for guardrails to be effective, there need to be a few simple’ish guardrails for the guardrails:

  1. Guardrails need to make sense to those being asked to follow them.  Ill-conceived or misunderstood guardrails will cause the guardrails to be ignored or to be followed in a passive-aggressive fashion. Neither behavior is good for an organization or its customers.  In general, guardrails that make sense either are established too far away from the work and therefore are not relevant or are not explained.
  2. Transparency. People that need to be guided by guardrails need to know the guardrails exist.  All standards and policies governing how teams should behave need to be explicitly stated. Guardrails that are not known will only be followed by accident and will not be effective. I recently had a discussion with Jeppe Hedaa, CEO of 7N and author of NUCLEON (podcast interview coming soon).  In one of his examples, he talked about how he required (a guardrail) that his agents and salespeople put the personal cell phone of their clients in the CRM system so that he could personally call them if there was any significant issue with their project or personnel he was providing without having to wade through layers of bureaucracy.  Until the agents and salespeople in 7N understood the expectation and why the number was needed compliance was at best spotty.
  3. Guardrails need to be challengeable. Guardrails make sense within the context they were established. When context changes the teams using the guardrails need to be able to challenge the validity/need to the guardrail.  Returning to my harrowing experience in Lima, if my driver had sensed that my family and I were about to kidnapped by counter-revolutionaries (there was a fight between the Shining Path and the central government of Peru at the time) then challenging the guideline of driving on the sidewalk would make sense.  FYI – I do not believe that was the case. 
  4. Breaking or ignoring guardrails needs to have consequences. a Guardrails exist to keep teams aligned to the goals of the organization and channel behavior in the right direction. In Scrum, product owners prioritize the backlog establishing the priority for a Scrum team.  The team established how the work will be done and the pace of the work. Teams that just do the work they want to rather than what the product owner (representing the business need) reduces the value the team delivers. Rouge teams need help to get back to a path of acceptable behavior (unless there is a REALLY good reason – see the guardrail 3 above).  In worst case scenarios, I have only heard of this happening in the real world, rouge teams need to be broken up.
  5. Leaders need to respect the void between the guardrails. Guardrails provide a safe place for teams to make decisions without being micromanaged. Once guardrails are established leaders need to respect the “void” and let the team make decisions and self-organize to solve the problem they are addressing. In Mysuru, the traffic barriers were installed so that no one had to stand on the corner and enforce the rule no running over pedestrian rule (PS – thank you to whoever made that decision).

The idea of guardrails is simple.  Guardrails exist in everyone’s life. However, like all simple and powerful tools, the devil is in the detail. Asking people what they think about guardrails tends to generate two very different reactions.  The reactions range from: “guardrails establish boundaries that allow me to operate without having to continually ask for permission for every decision” to “how dare anyone to constrain my/our creativity”. The five guardrails for guardrails provide a framework to mitigate the worst reactions.

Next: How Guards Affect Decision Making