The term guardrails is a polarizing term in some camps.  When I pinged Vasco Durarte on LinkedIn he said “I prefer the term “heuristics”: guides for action that are actionable, instead of abstract principles that need to be translated to action by everybody.” Rather than debating the nuances of implementation, we can all agree that in many cases having some form of guidance allows smart people to make decisions faster and with less risk. Less risk accrues to both to the person making the decision and to the organization. I will freely admit that I don’t like to be told what to do in many circumstances however I am not above being guided in others.  To test how many guardrails or decision heuristics I leverage in a typical day, I wrote down the guardrails that I encountered on Wednesday, March 20th (a fairly typical day). I categorized the guardrails into three categories.

Physical guardrails – On the way to work there were physical barriers on the side of the road I drive to work on to keep cars out of Lake Erie. If I wasn’t tallying up the number and types of guardrails I would have missed the speed limits on the streets (including a school zone).  At work, my standing desk prominently states that it can only hold 15.88 kilograms – I will refrain from sitting on the desk to test the limit. The elevator I crammed onto with several people I didn’t know had a weight limit displayed above the control panel. Simply put almost every machine or physical entity that I encountered had a stated set of guardrails to prevent misuse.

Process guardrails – I had several meetings with Scrum Masters during the day to listen, ask a few questions, nod sagely and occasionally provide advice (most people can figure out their own questions if you can get them talking). My heuristic/guardrail in these circumstances; listen twice as much as you talk; also listening typically gets me in less trouble than talking (another guardrail). Scrum is a framework; a framework represents a set of guardrails that guide behavior.  One of the teams I talked with uses the Kanban Method, which is another process framework while others leverage TDD (test driven development) on top of Scrum and Kanban — all of the frameworks represent guardrails to help PEOPLE make decisions.

Coding standards – While observing a team wrestling with a quality problem during a retrospective, a team member indicated that their .NET coding standards had contributed to the quality problem and needed to be updated.  No one suggested that the standards were onerous and constraining but rather that they needed to be tuned to better reflect the environment. Coding standards are guardrails.

Somewhere around mid-afternoon, I stopped taking notes on the guardrails I encountered.  Guardrails are all around me. They help guide our behavior, they help make decisions faster but what they don’t do is remove the responsibility of poor decisions.  When context or the environment changes guardrails need to be re-evaluated. One of my favorite lines in Forrest Gump is “stupid is as stupid does”. Guardrails are tools that help avoid stupid until something changes in the environment.  Regardless of how tried and true a guardrail is, think before you act.