14 Jan, 2019

Policies: What They Are and How They Function Within A Software-Defined Ops Framework

Blog Image

The definition of a policy from Wikipedia states: A policy is a deliberate system of principles to guide decisions and achieve rational outcomes. A policy is a statement of intent and is implemented as a procedure or protocol.

What do all of the below have in common?

  • No smoking within 20 feet of this building
  • RCW 46.61.050 – Obedience to and required traffic control devices
  • A dress code
  • Password must contain numbers
  • An email address is required to create a contact
  • A “No Parking” sign

These are all examples of policies. We are surrounded by policies in our daily lives and most of us (reluctantly) follow them without knowing they are policies. We use them to guide our decisions in daily life. Policies help produce predictable outcomes as well. In the business world, policies help us avoid risks and/or increase the predictability of a process.

Take a minute to think about several policies you use or follow in the workplace. A good example of a workplace policy is a dress code. Focus on one policy and now think about how it shapes the decisions you make. If the policy didn’t exist, what would you do? How does that differ from the outcome the policy intends to achieve? If you ask your neighbor what before and after decision they made, it would be a fairly good bet to say that the outcome of the decision made without a policy in place is different from your outcome. Yet it’s also a safe bet that you and your colleague are both wearing closed-toed shoes to work on a hot summer day.

It’s important to understand that policies do not just stand on their own. If we zoom out to look at the larger picture we will notice that policies are components of a capability or the ability to do something. Let’s take the example of driving. We want the capability to drive. That’s easy enough, give us a car and we are good to go right? Well, what do we do with the car? If we want to get from point A to point B, then we need a process, and if we want to get from point A to point B safely, efficiently, and effectively, then we need policies. The process itself is the act of driving. Turning on the car, stepping on the gas, turning the vehicle, etc. The policies are the rules of the road that keep everyone from colliding into each other.

Take a moment and think about the worst intersection of traffic in the world. The middle of this intersection is packed with vehicles all trying to go in different directions. Inch by inch each vehicle creeps forward, progress is slow. Why is the traffic like this? How did it get this way? It’s not unreasonable to think if everyone just followed the rules, they wouldn’t be in this traffic nightmare.

Now imagine a pristine intersection with stop lights and all vehicles are stopped at a line before the intersection. When the light turns green, the vehicles get to zoom off to their destination since the intersection is free of other cars trying to go in other directions. What differences do you notice between the two scenes?

  • The second scene is more efficient than the other
  • Cars are able to get to their destination quicker
  • The drivers and passengers are more likely to arrive at the destination without a ding in the car
  • There is less frustration and confusion

How does any of this relate to Sales Operations? A Sales Operations organization without policies or stop lights, will operate much like bad traffic. Sales reps will fight against the system or if there is no system, then they may just do whatever they want. They will look for the loopholes, like driving on an open sidewalk. It will take longer to arrive at the destination, and sometimes the destination just becomes so unattainable a rep will give up. Policies in the driving world keep the intersection clear, thus increasing the efficiency of getting to the destination, which would increase the chance of arriving at the destination. Policies in the business world grease the wheels of the process and help guide us to a predictable outcome like the attainment of a revenue goal.

In Sales Ops, a considerable amount of time is spent putting together a go to market plan. Back in our Strategy and Planning post we learned that our GTM strategy is how an organization plans on getting to its revenue goal. The plan is the process of getting to the goal. Policies are implemented to help maintain focus on the goal and make the “how” of how to hit the goal easier by taking the guesswork out of some decisions. We’re not saying no policies no goal. Policies just increase the predictability of hitting the goal. Every VP of Sales would tell a Sales Ops org to implement policies if it increased the likelihood of them hitting their goal by 5%.

In the short-term, missing a revenue goal may seem like not a big deal because the thought is that you can always double down on the efforts to make up the revenue in later months. However, as we will discover in the next couple of paragraphs, quickly adopting a plan to make up for the miss may not be as easy we might think and we can now kiss that revenue goal goodbye. Try telling your VP of Sales that. The likely scenario is the organization spending the rest of the year trying to catch up. Everyone knows the long term implications of missing a revenue goal, but something that often gets overlooked is that the faster you move, the less policy gets enforced. Policy drives focus in decisions, and therefore a lack of policy can lead to a chaotic feeling. Decisions take longer and they are less predictable. The more chaos in the culture of an org the more employee churn.

As we alluded to in the previous paragraph, this problem of policies goes a step further. Coming back to our driving example, there is a difference between a policy that is hardcoded into the process and a policy that is extracted from the process and is able to adapt to the changing conditions. The best example here is speed limit signs. We see these signs everywhere. They are permanent and don’t change. They are hard-coded into the driving process. Getting a speed limit sign changed requires a lot of time and energy. It starts with a request, a traffic study is performed, then an agreement on the new limit is made, new signs made, and a crew will then change the signs. By the time all that gets completed, the original conditions may have changed. In business, they definitely changed.

The solution to this problem is extracting the speed policy from the process and giving it the ability to adapt to the changes in driving conditions. In major cities around the world, we are beginning to see electronic speed limit signs. As the density of traffic increases or the weather worsens, the speed limit is changed on the fly. This allows the traffic to quickly adapt to the change in policy, keeping vehicles and people safe, while keeping the traffic moving. Any business interested in building a well organized intersection that allows for efficient and rapid progress towards a goal, then policies should be a part of every process and capability established. These policies need to be dynamic and adaptable to changing business conditions. This means we need to think about how to extract our policies from the processes we currently have in place. This concept gives rise to defining policies using software. Software-defined policy is the equivalent of the electronic speed limit sign. They give you the ability to quickly turn a new strategy into execution in the CRM.

Policies are an important aspect of a capability, as they help define the rules of the process. They help with decision making. They create reliable outcomes, establish predictability, and allow your organization to scale and adapt to the changing business environment.