I’ll bet that you’ve seen this happen.
An executive made a good-news announcement: “We are changing our work processes. The new system will make us more effective at reaching our productivity goals. The training rollout for the new system begins in two weeks.”
The move was the result of a decision made by one or more executives. Perhaps, the decision-makers listened to a sales pitch for a proprietary training program and bought into it; or, perhaps, they created their own training program while at an executive retreat.
You were either a worker receiving the surprise announcement or you were the executive making the announcement.
The rollout commenced. Team members’ enthusiasm was low. During the training for the new system, some team members thought: This is worse than the system we’ve been using. Others raised their hands and said, “This is worse than the system we’ve been using.”
The team’s morale, which had been mediocre, became lower.
Why did morale drop? People like to have input for the decisions that affect them. Some people don’t expect to be asked for their input, but all people like to be asked for it. Excluding a body of team members guarantees low morale and makes them less likely to cheerfully buy into the new system, even when the new system would have been a good fit to their work duties and their work environment.
When the new system is not a good fit, it is likely because the decision-makers were not the team members who would actually be using the system on a regular basis, so they were making an uneducated guess as to its fit.
To truly improve work processes, bring the users into the discussions. A survey is not sufficient; the users need to be at the table. If the workforce is too large to bring in every team member, bring in some of them who can represent the rest. At the meeting(s), actively solicit input from team members. If you’ve taken part in our APL seminar, you recall the unit about groupthink and how to avoid it; use those techniques to ensure that you don’t leave anyone’s ideas unspoken.
This is not to say that you should agree to every request that end-users have; some requests might be too impractical. The referent power leader delivers such denials in ways that communicate to the team members that they are valued, even though some of their requests can’t be approved.
After your team has implemented the new system, bring together the decision-makers and the users again so that they can assess the effectiveness of the changes.
As a core way-of-working, the referent power leader constantly elicits and welcomes input about processes in order to make educated decisions all along the way. This way-of-working tends to get tremendous buy-in from team members, who will follow the leader to wherever the leader believes that the team needs to be.