The Only Thing Firefighters Hate More Than the Way Things Are is Change

1

I am in need of some advice from the community in how to get people on board with new technology.

I was recently promoted to the EMS Training Officer position for my department and have worked hard to build a nice SharePoint website for trainings but no one is using it, even though its literally just sign in and and click one link to get to where they need to. It’s too much because it’s not an email. I’ve built trainings to show everyone how easy it is but no-one has viewed the training.

And then I’m told that Apple can’t cast to LG TVs, only Windows and Android can. :man_facepalming:

No one wants to listen to me either when I suggest that everyone on the department should have Microsoft accounts if they want things to run smoothly, but they are sill hung up on the onsite server we have for all of our documents and don’t feel like they should have to pay for the extra accounts.

Since everything I do is through Microsoft 365, I have been lucky enough to be able to use my Mac mini instead of the 5+ year old Dell POSs. But I feel like this could change “just because”.

I used Craft to make an awesome PDF and weblink for all of the medications we use and was told it was “too weird” and to make it a Word document.

Any advice or shared experience would be helpful as I am trying to regroup and find another approach to get everyone onboard with the new way of doing things.

2

This stuff is hard because people and organisations are complicated. (I spent decades trying to introduce technology and improve work practice)

I’d guess that there is a high level of risk in any change for the people you are working with. They’ve had to train hard just to do their jobs; they have to follow clear protocols and procedures in difficult situations and every second counts. They can’t risk not knowing how to do something or having to look something up. If what they have done up till now works most of the time, it’s going to be very hard to convince them to do things differently, unless there is clear, immediate pay-off. They are also people who have to make life-changing decisions in moments. That tends to build self-reliance. That’s good, but they are unlikely to do something just because someone tells them it’s a good idea.

One possible strategy would be to use change to make something easier for them. I guess there is regular mandatory training, things to viewed and read and be signed off on etc… Focus on using simple systems to make that process as quick and simple as possible: asking people to open new accounts and especially asking them to pay for them is not a good start. Build on what is there and that they are already doing and work for small improvements first. Once people like something, you can lead them further into change.

Last thought: it has to integrate with organisational leadership and strategy. How does your role fit into other roles and how things work? Maybe scheduling time, or linking training to performance reviews or even just getting people they really respect to make some changes first would help.

Good luck. The technology is rarely the real issue: people are.

6 Likes
3

I feel like creating the SharePoint site was making it simple. I’m doing all the backend work, making trainings, resources, and the calendar only one click away when they are on the home page.

The Microsoft accounts were already in use and it’s what the full time employees use for their work email. So the infrastructure has been there.

:point_up_2: So true.

Thank you for your insight.

1 Like
4

Is it? Now I have to set up and remember another account username/password. I have to remember to sign in and check for updates. On the other hand, if you send out an email with a link directly to the training video, then you remind me and I only have to view the video, nothin else. No accounts to deal with and be frustrated about. And no need to manage my own reminder system.

My point is that sometimes making it “simple” actually makes it worse. Often, the only way others would be willing to adopt a new system is if they perceive that it is better for them. But they may very well perceive the new system as worse for them.

You could ask for feedback to better understand their objections, but many will simply go with the ‘if it ain’t broke don’t fix it’ mentality. If they don’t perceive a problem with the old system, then nothing you propose will be acceptable to them. So maybe start by establishing problems with the old system. Once there is acknowledgement that the old system is inadequate, then solutions which address those inadequacies are more likely to be welcome.

4 Likes
5

It’s hard, but worthwhile. Something like the Sharepoint you should expect to have to communicate maybe 20 times, and a lot of them need to be at decision points.

If you can get something to one-click email contents from the SharePoint page, that also points back to it as the source of truth, that will help people get used to it. Don’t just copy-paste from it yourself.

As far as people, I second that you need to figure out what you can successfully mandate or have someone else mandate, and what you need to bring about via consensus.

It also helps to estimate how much time you have to make an effective change in each area. E.g. some things you can push through with some initial energy in your role, that will be really hard later. Others you can build towards over 3-12 months without giving too much power to the status quo. If you have a lot of different projects in this area I’d actually list these out and put a number on them, to help you decide how to proceed or who to ask to help.

Build consensus by bringing people into what you’re doing from most to least excited/sympathetic. Refine your document/processes based on their feedback and it’ll be more palatable to the lazier or more hostile users later on.

Commit to spending personal time with anyone who seems like they are resisting it because they’re genuinely too busy, stressed or confused. Nobody gets left behind in the change. That attitude will be noticed by others and benefit the whole organization overall.

1 Like
6

Everyone already has the Microsoft 365 account through the city so there is no additional account for them to set up.

Much of the videos are through Microsoft Stream so they have to log in to their account anyway.

I hope was to keep everything within Microsoft 365 so we didn’t have different versions of trainings/documents floating around and could collaborate on them, which we can’t do through the on-site server.

This is the big challenge. I know it’s better for the department but everyone is so set in their ways that they don’t even want to look at something else.

1 Like
7

Also, if this is in-person work, pairing free food with information about changes really helps, haha.

7 Likes
8

I’ll offer an Oreo buffet for the next training. That should bring in people. :joy:

2 Likes
9

No practical experience but from my reading it sounds more like not a case of resistance to new technology more resistance to your vision of how that technology needs to be applied

Sometimes you have to admit the two sides are just not a good fit and if they are not going to bend perhaps you either need to or walk away

10

Sharepoint by itself never caught on at the corporation where I worked but Slack made inroads, especially with younger programmers and the go-getters. Then Microsoft, for their own survival, offered Teams and that did a lot better. Slack and Teams made interaction natural and even fun. Nobody cared that they were using a nice Sharepoint site. They were just talking to their friends and coworkers and following useful links.

11

I tired Teams too but no one wants to download the app. That’s why I did the SharePoint site. They don’t have to download an app and can access from any computer.

12

We have both Sharepoint and Confluence at my workplace and nobody uses either. Just a few people in your position who have invested in trying to create something beneficial but unfortunately it’s difficult for other people to see the benefit or derive value.

Did you gather the requirements of your colleagues before designing and implementing the system or did you implement a system that worked really well for you under the presumption that it would therefore work well for everyone? I have to admit that if you just came out one day and said me and my team should go and create new microsoft accounts to have an easier life because of something you implemented without consultation I wouldn’t engage with it either.

In fact this is exactly how my department’s sharepoint site was delivered, and after two years it’s still used by exactly five people out of twenty.

You’ve made a classic ‘design by engineers mistake’. You’ve built something because you can and because it satisfies your own desires, not because it’s what your users want.

This is not the case. It’s too much because it’s not better than an email from the perspective of your users. You haven’t met their needs; you’ve done something cool. It’s not the same thing. Why should they pay for extra Microsoft accounts? So that a system they didn’t ask for works better for them? That’s not just a hard sell, it’s self-sabotaging.

It isn’t.

Putting asside my personal feeling that Sharepoint is absolute, unmitigated, and truly bug-ridden garbage (I have an actual document full of bug workarounds that I’ve built over two years), you’ve offered them something unfamiliar that needs new processes and new learned interctions with no incentive to spend resources on learning it or adapting to it.

You’ve actually added complexity.

If you want to exponentially increase the resistance you’re facing then sure, take this approach. You will never earn back the good will you spend by doing this, and those people will never fully trust you again.

Honestly your best approach is to involve them in the process to redesign this solution. Start with an actual requirements gathering exercise. Involve your users in refinement of the solution, and build something they’re invested in. You may end up with basically the same solution but you’ll also build users that are invested in it by following Human Centered Design philosophies.

If your users don’t want to use your product it’s not because the humans are defective. It is always the product.

3 Likes
13

To clarify, you do this in situations where they are already doing something someone told them to do. E.g., if their boss said, “you have to check these training emails every week,” you can get their boss to say, “starting on x/x we’re going to check this website every week instead of the emails.” It’s appropriate and effective for some kinds of changes and not others.

You’re right that it’s not especially trust-building to have a management hierarchy, but it’s not ruinous either.

Also, with their managers, the consensus-building and planning is still happening, though it’s probably a shorter meeting unless they have particular concerns.

14

I recall a similar thread here a little while ago. My experience does not fit neatly with your situation, but there may be some learnings from it, or from other responses, that do.

1 Like
15

What I describd is not “having a management hierarchy”. I’m not really interested in having silly reductive arguments.

16

If only life was that simple. I’d agree that seeing people as “defective” is not going to get anyone anywhere, but people might have all kinds of reasons for not wanting to use a product. Maybe it’s because of previous bad experience, maybe they want to resist change, maybe they don’t want to co-operate with management, maybe they’ve got too much to do to have room for any more, maybe they are too stressed, maybe they don’t have the skills or training that would enable them to use a product, maybe the product is the problem. If you want to make change happen you have to deal with what the real obstacles are.

17

Life, in this case, looks a lot different if you’re management (herding cats) or a foot soldier (look at all this work I have to get done!)

1 Like
18

All of these things are product problems. A product is not just the website, or the app that you download. Your product is onboarding, use patterns, update methodology, further development, and improvement methodology, user buy-in, and emergent use patterns. A product is also it’s own design process.

You cannot engineer individual people. If people are change resistant or for some reason deliberately uncooperative those are product issues and your product has to include strategies to cope with those obstacles or better still the design process needs to incorporate those obstacles. Your product is also training to enable use and the persuasion to encourage adoption.

If you’ve delivered something that you think is finished and you’re still having these issues, you’ve delivered an incomplete product.

Nothing about it is “that simple”. Delivering software with strong adoption, especially to users that have an established system, is never simple.

2 Likes
19

No use disagreeing about semantics, but I’d say those are at least as much HR, organisational and leadership problems as they are product problems. And of course you can’t engineer people, but you can develop them, train them, organise them, motivate them, team them, lead them, and sometimes, sadly, replace them.

1 Like
20

Senior management buy-in and dictating from the top.

This is where all our training docs are going to be kept and updated from now on. Use it, if you find it hard ask for help. Do not rely on information on emails or other folders/drives as it is out of date and will be deleted in X weeks.

Then - add quick links from where they used to be accessed to the new home in SharePoint. Write a guide in using OneDrive (included with M365 and Windows 10/11).

As lots of people have said it’s not the tech, it’s delivering the change.

1 Like