Morey's Law #12 - Unless the Rules Aren't Working

Earlier in the history of the blog I shared a post titled: Don't (Suddenly) Change The Rules On The Player which became Morey's Law #11 (Don't Change the Rules of the Game). The gist of Law 11 is that you shouldn't change the rules on your team. They build expectations based on their experiences and the standards you set. If you change the rules (suddenly) then your team will start having trust issues. In fact most of the time, as a leader you find yourself playing referee:

The counter-point of this is that sometimes the rules are wrong, holding you back, or potentially causing significant harm. Hence Morey's Law 12:

Unless the Rules Aren't Working

There are many examples of the when the rules change. Perhaps a new system needs to be implemented, liked an ERP; or a new process is required due to client expectations or a changing industrial environment (like the development of a new HSE notification system). What if there is a new standard for welding, steel forming, rolling, or for that matter, a better coding system, or more efficient program. These are all changes that will impact the rules. Times move so quickly today that the rules from yesterday can become outdated before the ink dries, and systems that were supposed to last decades instead last only a couple of years.



However, that is not the crux of this Law. Each one of those are typically a project, with a planned method of change. What I am referring to are changes to the way you or your team operates. One of the things we talk about a lot in my Parachute Project Management program is the need to implement new systems and standards in order to regain control of a broken project. Or perhaps there is a need to change a reporting criteria in order to meet new regulations (think what happened for Sarbanes-Oxley).

Sadly, in many cases, these changes are dropped on the team like a bomb, and are often not thought thru. Knee-jerk reactions to bad situations typically fall into this category. Instead the changing of the rules almost needs to be treated like farming:

1. Prepare the field first by letting the team know why the change will be occurring. Describe what it was that is bringing about the change so that they can understand why it is necessary. If you skip this step, the team will often come up with the worst possible reason for you to make the change: "Because (s)he can."

2. Plant the seeds by explaining what the most likely solution will look like. The team can start to understand how the new "normal" will look. In many cases, I've found that the team may even have suggestions that could improve the solution.

3. Have a growing season. Let your team know when the implementation will take place. Give them a timeline and (depending on the size of the change) you may want to have review, training, and education sessions before the actual go live. This will help manage the expectations of the team, and allow for a smoother acceptance of the change.

4. Harvest. Now that the team has had an opportunity to grow into the idea, implement the process and hold people accountable to it. Don't hammer them if there is a mistake, but consistently point out the errors and make sure the team members are the ones who correct them. If mistakes are too frequent, then increase the severity of the consequences. You have to be CONSISTENT here, because if you let it slide once, then others will think that the new rule is no longer important.

5. Process the Harvest. In this case, perform an evaluation of the process and change. Did it accomplish the goal? Where could things have gone smoother? What went well?

6. Store for next season. Most farmers will keep a portion of their production as seeds for the next season. Consolidate the lessons learned from the evaluation and keep them somewhere you can use them the next time an adjustment is required.

The real goal here isn't to change a bad situation. The goal is to change a bad situation AND have your team buy into why it even needs to happen.

Going back to the Law #11. If you clicked the link then you read how a team's bonus paychecks structure was changed as the checks were handed out, and impacted the very checks that were being handed over. This made most of the team feel cheated and in fact many felt unappreciated and used.

Instead, if the VP had gone through these steps, letting the team know that due to budget constraints the bonus check structure would need to change, and that it would happen with the next check, rather than the most immediate one, then the team may have been more accepting (provided the budget constraint could be explained). If there had been a way to swap another perk for the bonus check (i.e. additional comp time for the weekends and holidays worked) that may have done something to rebuild the trust of the team.

Throughout all these steps, take the time to assess impacts and determine alternatives. Look for ways to make the job easier on the team, to remove obstacles. In many cases, the team may even embrace the rule changes!