Mel: [00:00:00] Hello, friend, and welcome to another 10 in 10 episode on all Things People Change. I'm your host, Mel Loy, and I'm recording this episode on the Lands of the Yuggera and Turrbal people, here in Meanjin, Brisbane. And today's episode is the fourth in our five part series.

So we are 75% of the way there if I did my math right. And these episodes are where I share my comms tips and tricks for different kinds of people related changes that we typically encounter in most organisations. And today we'll be talking about policy and benefits changes. So when the organisation has made a decision to update a policy, bring in a new one, or change employee benefits, what's the best way to communicate?

Now, the problem I often see is organisations not putting in enough effort into these types of changes. Sometimes they're literally just an automated message from a central HR system, and you just have to tick to say, I've read and understood. I've seen systems that don't even let you read it [00:01:00] before you tick that box.

You've gotta tick the box to read it, which is ridiculous. Uh, other times it might be that you need to sign a piece of paper to say that you've read and understood this document. Or you might just get some kind of arbitrary, vague comms saying something has been updated. Go look at it. Now, honestly, it's really lazy.

It is lazy communication, and it's also not helping your audience, especially if there are new rules or procedures that they should be abiding by. It is setting them up to fail, and therefore it's also setting up the broader business for increased risk. So instead of a tick and flick approach, I'm going to share a few ways that you can actually make sure that not only do people read what's changed, but they understand it and they act on it.

So let's get into it. Tip number one, be clear on what's changing and what's not. This is really important. If a policy or procedure has changed, or benefits have changed, be very clear on what's different and what is staying the [00:02:00] same. So it could literally just be you have a table with two columns, and the first column is previous policy.

Second column is updated policy. And it might be that in the previous policy. Column. For example, you know, AI could not be used at all in the updated policy. You can use these tools, X, Y, Z. When it comes to employee benefits, this is also super important. Nobody wants to feel like they are losing benefits.

So not only do you need to talk about what's changing, but also why it's better than the previous version, and talk about what's not changing as well. So if there is something that is really important to people, that people really like, mention that it's staying. Now importantly, make sure that this kind of information, that what's changing what's not - is right up the front of your communication.

People will not read long emails or long policy documents. We know that. So make this comparison front and center. So that's tip number one. Be clear on what's [00:03:00] changing and what's not. Which brings us to tip number two, keeping it simple. Now, this means a couple of things. Firstly, the language you use in policy documents and related communications needs to be simple and easy to understand.

Now, all too often we see these documents and comms written in very technical HR language full of jargon. And we know that we need to be communicating at the level of a 14-year-old in order to effectively reach 83% of our audience. When you start to communicate at a higher level than that, the understanding drops off pretty significantly and fast.

So as you are developing these documents and the comms check to make sure the language is clear and simple and test it with your intended audience, they will be able to tell you pretty quickly if something is confusing or it doesn't make sense. Also don't think that you can just get away with throwing the glossary in there to explain away the [00:04:00] jargon.

The research tells us that actually adding a glossary of terms doesn't help understanding at all. Now, keeping it simple also relates to the layout of the documents themselves. And like I said, people very rarely read long emails or... Let alone documents. So what I like to do when I help clients develop policy suites is to put a key points box right at the top of the document, and that is three to five maximum, maximum three to five dot points with the main things people need to know.

And I'm talking one sentence dot points, not paragraphs. If you're not sure what to put there, think about the things that people ask about all the time or where they often get tripped up. So where they make mistakes, they don't realise they're not abiding with policy. If they read nothing else, at least they will read those three to five key points and get the main idea.

And those three to five key points can be used in all your comms. They can be used on an intranet site, whatever it might be. Avoid big blocks of [00:05:00] text and instead use really short, sharp dot points or even simple diagrams like flow charts to help people navigate and understand the content. So that's tip number two.

Keep it simple. Tip number three, apart from using simple language, also use tangible examples of the policy or procedure in practice. So you want to make this policy meaningful for your audience. They need to understand what does this mean for me? So when you are describing a key policy point or even a benefit, ask yourself, what does this actually mean to my audience?

So let's use an AI policy again as an example, because there's a lot of those happening right now. You might have something in there that talks about, let's say an employee persona called Jane. And Jane wants to use chat GPT to help draft an email. She decides to copy and paste the inner email she'd written previously.

This is a bad idea because blah, blah, blah. And then you have Sam, who also wants to use chat GPT to help draft an [00:06:00] email. So he provides general information in the prompt without using any names or identifying features. This is okay because blah, blah, blah. So you'll have a, you know, an example of what to do, an example of what not to do, and brings that policy to life.

Now you don't need to have these examples in the policy document yourself. In fact, probably doesn't, you know, really fit in there a lot of the time. But what I've done is put these in a guideline document that goes with the policy or in the comms, or both, but think about what the policy means for different audience groups as well.

So for example, a policy about delegations of authority, so you know who's allowed to spend how much money, will mean different things to a frontline team member versus a senior leader. So you might need to have a few different scenarios in there. If you've got any FAQs to go along with the changes, I'd also recommend copy and pasting these scenarios in there too.

And the more repetitions the better. And the final tip, [00:07:00] check understanding not just the, I've read and understood tick and flick. So the tick and flick method isn't gonna cut it like I've said, but instead what you could do is maybe have a short quiz on the policy or the changes. So for example: Five multiple choice questions, and that's linked to employee's profile so you can monitor who has and who hasn't properly read the documents.

Another idea, uh, in team meetings or toolbox talks, a couple of people, uh, on the team are assigned to explain the new policy or procedure or benefits to the rest of the team. So it means they have to learn about it. It also means they are going to put it in language that their team members, their colleagues understand, but also they're more likely to be listened to because they are a trusted peer, not just some, you know, random guy or woman who's come in from head office to talk about it.

Now when we reading the policy online, if your system allows this, you could have a question or something that people need to respond to [00:08:00] before they're allowed to say that they've read and understood the policy. So for example, it could be a question like, what does this policy mean for you and your role?

Now, hopefully you can build in some smarts around the system so people can't just write, not applicable or whatever. But again, you will not only be able to see who has read the document, but how will they understand it too? And then you can target any follow up that's required. Okay, that's our episode.

Told you it was short, sharp, and sweet, which means it is time for our wrap up. And today I shared four tips to make sure new policies or procedures or changes to existing documents or benefits, for example, are not just read, but really understood. So they will actually put into practice. Step number one, or tip number one was be clear on what's changing, how it compares to any previous versions and what's not changing.

Explain the why and the benefits where appropriate. Tip number two, keep it simple. This means the language you use and also the [00:09:00] way you lay out these documents. So consider having a key points box right at the top and using diagrams where possible to replace a lot of lengthy step-by-step text. Tip number three: use scenarios or avatars to make the words meaningful. So for example, using a persona like Jane, the manager, who now has to follow an updated finance policy and talk about what's good practice and what's not. And tip number four, check people's understanding properly, not just a tick and flick or sign a piece of paper.

So consider using things like quizzes, asking team members to explain it to their peers, et cetera, et cetera. Alright, team, that's your episode for today. That was our fourth of our fifth in our series of people changes. So we've got one more to go and the next one is a change that's happening everywhere.

It's all about new technology. So stay tuned for that next week. In the meantime, keep doing amazing things and bye for now.