Announce Before You Implement

Actions to take: Notify people about any significant change with a time buffer before it takes effect. A good rule of thumb is 4 weeks in advance of the launch date. Do this even if the change is an obvious improvement that needs to happen. Follow the week-by-week process described below for maximum effectiveness.

In one of my past jobs, central planning pushed out a change to our closing announcements. I managed a branch of a large library district at the time. Upper management let branch managers know and gave us the scripts with a launch date the next evening. The fallout from such a simple change was fascinating to watch. The fact that I even use the word "fallout" to describe staff reaction should tell you something. It was a mess. Staff were annoyed at just about every aspect of the change. The timing for when we did announcements didn't work as well. The announcements were full of marketing language about our services instead of a clear closing message. The wording was hard to say. It read fine, but when you tried to say the words out loud, they didn't flow well. One of the closing announcements was too long. The PA system would cut you off unless you spoke at top speed. The complaints went on and on. It wasn't just my branch. I checked in with a few other managers. Their staff were equally annoyed about it.

I choose this example because it is mundane. Mundane enough that I felt a little silly describing the problem to my own boss. Nobody really cares that much about closing announcements. Yet, somehow, this was all the talk for weeks after the rollout. Regardless of how mundane or silly an issue is, people react badly when they are caught off guard by change.

We all hate it when our boss suddenly announces that we're doing things differently. They always miss about ten obvious problems. They don’t think about the impact to other aspects of the job. They don’t realize that the change is going to mess up something else. Even when it is probably a good idea, the boss rolls it out when it is still just and idea, not a plan, and it goes terribly.

You are that boss. We are all that boss. We all fall into this trap due to perspective blindness. You are at a certain level of the organization, with access to certain information and a certain understanding of various situations. Your employees are at a different level with different access and different perspectives. It takes intentional, repeated effort to keep that in mind. You are not maintaining that awareness as well as you think you are. You are not modifying your behavior and communication to account for it as well as you think you are.

To you, your decisions are not a big deal. To you, the change make obvious sense. To you, the plan is all worked out. From your perspective, it is reasonable to make a positive change as soon as possible. It is going to improve things, so why wait to do it!

• For your staff, the decision is a big deal. Keep this in mind: most managerial decisions do not change the boss's work, they change somebody else's work. It matters more to them because it directly impacts them in a way that it does not directly impact you. They have more emotional stake than you. They need more time than you do to accept the change.
• For your staff, the change does not make sense. They have been doing it this way for years. The current way make sense. If the current way didn't make sense, we would have already changed. Furthermore, you have been living with this idea in your head for at least some time. You've worked out why it needs to change. They have not lived with the idea like you have. You need to spend time showing them that the change makes sense.
• For your staff, the plan is not all worked out. They will have "what if's" and "what about's." Stop assuming you’ve got the details figured out. You missed at least one important question that needs to be answered. You missed at least one consequence of this change. In the extremely unlikely event that you have planned a perfect change, you still need to give your staff time to examine it and come to that same conclusion.

There is a straight forward solution to all of this. You must announce before you implement any change. When you announce a change for the first time, stop saying “starting today” or “this week” or “effective immediately” or worst of all, leaving out the timeline altogether. 

You should virtually never provide the first announcement about a change less than a week before implementing it. It is possible that, for some very simple changes, you staff could acclimate to the change that quickly. For anything even moderately important, I recommend a 4-week announce-before-you-implement process:

• Week 1: Announce the change to your team and to anyone else impacted by the change. A future blog entry will go in detail on effectively announcing change. In brief, your announcement should explain why the change is necessary, describe exactly what is changing, and describe the change process. Bosses often don't appreciate the difference between "the change" and "the change process." The change is what it looks like when all is said and done. The process portion is about the transition, including information on who will be affected, how they'll be affected, how we will overcome those effects, and on what timeline this will all happen.
• Week 2: Follow up on the announcement. Discuss it individually with each of your staff (this is a great candidate for a topic in your weekly one-on-one meetings). Find out their opinion of the change. Learn who is for it, who is against it, and why. Listen seriously for issues you may have overlooked.
• Week 3: Respond to information from week 2. Your staff may very well have pointed out issues or aspects of the change that need to be addressed. You may end up tweaking your plan. It is important to respond to staff comments even if your plan is exactly the same. Explain to them directly why their feedback has not changed your mind.
• Week 4: Begin rollout. After the previous 3 weeks, your staff should now be fully prepared for the change. If you have done your job right, the vibe you get from them will be along the lines of "let's get on with it already." Since you know from week 2 who is on board and who is resistant, you will be able to monitor for problems much more easily. You will also be able to judiciously select who should do what during implementation (for instance, not pairing two resistant staff with each other).

This is not complicated stuff. The difficulty isn't in whether or not you can do it. The difficulty is in whether or not you will. As the anecdote at the top of this post demonstrates, you do not know which changes need this level of care. We are perspective-blind. Stop trusting your gut. Instead, just assume that someone below you will have problems with any change you roll out. For that reason and all the reasons listed above, provide your team the heads-up that you wish your boss afforded you.

The average boss works to give their team the relevant details about a change and considers that a job well done. Better bosses announce before they implement.