Change Management: Talk to the People Who Do The Work

By Tom Swanson, Engagement Manager at Heinz Marketing

Most change efforts fail to achieve established goals.

This makes sense to me.  Changing is difficult enough to do on your own (like my diet for reference, I really love ice cream).  Now try change in a massive organization with cross-functional teams (and all the other business buzzwords).  How do you “harness synergy” when you are coordinating a new process or implementing a new tool?

It is a question with no easy answer.

There are books and blogs, videos and classes, all geared towards being better at making change.  And there are far more things to dig into than one blog post can contain.

Good blog posts pick a topic and explore it, so here is mine:

If you want to be better at making changes, you need to incorporate feedback from the people doing the work.

In keeping with business buzzwords: these are usually “individual contributors” (ICs for short).

We will use this language but it can be applied to whoever is most impacted by the change.

This seems simple enough, but in practice it can get real tough.

Let’s break it down into three simple sections:

1. Why you seek out IC feedback in change management
2. Why IC feedback can fail
3. How to gather IC feedback (spoiler: it depends on the change and the team)

Onward!

Why you seek out IC feedback in change management

The value of gathering feedback from the people who will be doing the work in the new system should seem pretty straightforward.  In order to get the benefit, though, it is crucial you don’t see this as just a box to check.

We need to know what the potential benefits are of this effort in order to really gain them.

So, gathering IC feedback has a number of distinct benefits.

First, who would be better to speak to if a change is viable and useful than the people who will be doing the work?

It is easier to think through processes and systems in abstraction, but another thing entirely to really consider what it means to enact them.

Talking to ICs will get you much closer to the implementation, even at early stages.

Second, it is a great way to increase the success rate of the training needed.  How much training is needed in the first place largely depends on the size and type of the change, but earlier exposure to the change helps ease this process.  Being a part of the development requires ICs to think through how it will actually work.  This means the process will be easier to adopt as they will have helped shape it to their own needs.

Finally, it increases your ability to get buy-in.  Having been consulted on the change, often, helps people approve it.  This can be a real sticking point for teams trying to manage big changes.  Often they get rejected or worked-around in favor of past processes.  Improving your inclusivity while designing and implementing the change really helps ensure ICs are on-board and willing to make the shift.

How to fail at including ICs

There a number of ways to fail in this part of the process.  Most often this happens because IC feedback is viewed more as a box to check, rather than a crucial part of the process requiring careful thought and empathy.

As a quick aside, in any change effort there is a risk of just “going through the motions” of change management.  This must be fastidiously avoided, as that mentality undermines the empathetic nature of good change management.  None of this should be checking boxes and going through motions, as in many cases the positive outcomes of the change will impact people’s daily lives.  Take the time and think it all through.

There are other pitfalls to watch out for, though.  Here are a few listed out:

1. Shifting meeting times around frequently is frustrating undermines credibility. IC meetings should be considered top priority.
2. Don’t give enough time for feedback. It is easy to try to contain it to a meeting, but thinking things through takes time.  Give a few extra days and a clear channel to provide updates or feedback.
3. Not closing the loop after feedback is gained. If you make the choice to not include a piece of feedback, communicate back to the team that gave it as to why.  You don’t need to explain the choice over-much, but you do want ICs to know they were heard.
4. Providing too much (or too little) for pre-read. This can be a real needle to thread, but too much pre-read is a chore, and too little means the time spent in the meeting is all on questions, rather than feedback.  If you have a lot to review, provide a short video or guide to go through the contextual pieces and keep the meeting very focused on a single main topic.
5. Give people the choice to be there. We typically recommend going opt-out, rather than opt-in as that assumes inclusion, but you could go either way depending on how comfortable you are with over-communication.  Opt-in requires more communication as there is a greater cost to missing an email.

Tips to do well at gathering IC feedback

As spoiled before, the tips I am about to list really depend on the specifics of your situation.

In fact, the first tip is to think through your specific situation.  There are plenty of angles to go here, but these are three of the most important:

1. Team size. Larger teams tend to have a harder time communicating.  Smaller teams are scrappier and more agile.
2. The situation. Change fatigue is a real hindrance.  If you have made changes recently, and especially if they have not gone as well as you would like, you need to take a slower, more consistent approach.
3. The change itself. Bigger process changes require more rounds of feedback, more time, and deeper analysis to “do it right”.

There are other things to make sure you are looking at such as your team composition, the individual personalities, cross-functional needs, tools, etc…  However, for gathering IC feedback, these should all be considered.

Another tip for improving your IC feedback is to offer multiple options for how to give it.  Most people default to meetings and email, but there are other options.

 

You could consider a survey.  These are particularly helpful in a few settings.  They work well for early stage requirement gathering as well as when you have something to show.  You can provide a walkthrough and then a survey to ask questions.

If you do go the survey route, make sure to add plenty of free-response questions.  These take longer to review, but give you a fuller picture of the feedback.  Not including free-response risks people not giving their true feelings and thus a failed effort.

Another way to gather IC feedback is via focus groups.  This is a much more “marketing-y” way to do it, but it is excellent for cross-functional teams.  Get representatives of each team together and talk them through the change.  That way, feedback that comes up from one team might illuminate issues from another team.  The cross-functional aspect is key here, as you want to see how these groups intersect.

Finally, employee-support groups provide an interesting angle for gathering IC feedback at the implementation-stage of a change.  If you are activating a new process, having groups available to ICs where they can talk through issues or voice concerns provides a clear avenue for giving feedback.  It also allows for other ICs to step-in and help, improving communication and collaboration across the board.

Conclusion

Gathering IC feedback is crucial to effective change management.  There are varying ways to do it at every stage of the process, and plenty of ways to screw it up too.  Be thoughtful in your approach, give plenty of options for how to give feedback, adapt to your situation, and focus on consistency and empathy.  If you can follow those basic principles, then this part of change management should be a breeze.

As always, reach out to me with any questions.  tom@heinzmarketing.com