Are your field service engineers resisting new technology? Here are 3 ways of getting them on side

Are your field service engineers resisting new technology? Here are 3 ways of getting them on side

Are your field service engineers resisting new technology? Here are 3 ways of getting them on side

Field service organisations understand that because of rapid technological change and increasing demand for better service they need to keep up — or else get buried by their competitors. As a result they are racing to implement new technologies and business models that aim to maximise productivity, improve business-wide sharing of knowledge, and deepen customer relationships.

However, as you’re evaluating how field service management software, mobility tools and the Internet of Things (IoT) can help you accomplish your goals, it’s important to remember one thing. Whatever technology you implement will only be effective if it is fully embraced by your frontline employees — your field service engineers.

Many field service engineers will tell you to get lost if you talk to them about software, automation, mobility and the IoT. They’re not interested. They’ve been doing the job the same way for years and it works — why change it? As the old saying goes, if it ain’t broke, don’t fix it.

What many engineers don’t realise is that the saying doesn’t apply anymore. Our economy has changed. Industry is service-driven. Customers demand more transparency, more speed and more value for money. Competition has ramped up. Change is fast. The way your engineers are doing things may not be ‘broke’ as such, but it still needs fixing.

The problem is many companies deploy a new system with the intention of improving performance in a certain area without dedicating enough time and resources to engineer adoption. Six months later they’re wondering why their engineers are frustrated by or refusing to use the new system. It wasn’t that their vision for field service optimisation was wrong. It was how they chose to execute it.

So, here are 3 ways of getting your engineers on side and improving your chances of a successful implementation.

1. Find out what they think, want and need

Don’t invest in new technology without first consulting the people who are going to be using it. Many companies deploy new systems without ever asking the opinion of the engineers and then wonder why those implementations grind to a halt. It’s natural for people to resist change out of fear of the unknown. That resistance will be exacerbated if your engineers view it as a top-down change that’s being forced on them. That’s why it’s important to engage your employees in a conversation.

Find out what they want or need. Talk to them about any problems they might be having, any aspects of their job that could be simplified, any processes that are slowing them down. Use this conversation as a springboard to discuss your proposals and ask them what they think. If they don’t like what they’re hearing, find out why. And don’t assume that your engineers are wrong, either. The solution you’re proposing might not be as effective in reality as you and your developers think, and your engineers will be able to tell you why. The dialogue will reveal whether your engineers just need gently persuading with some more explanation and demonstration as to the value of the solution. Equally it could reveal that the solution isn’t actually going to streamline or improve their work or their service to customers in the way you assumed it would.

2. Demonstrate how the technology will improve the way they work

If your dialogue reveals that your engineers’ resistance is down to fear of change, you need to show them how the solution is going to make things better for them and for customers.

In many cases the underlying fear is that the new technology is trying to replace them. All this talk of robots replacing workers and the IoT making reactive service visits unnecessary probably doesn’t help matters. Indeed, we wrote an article ourselves called “Is the IoT killing the fixer?” However, the conclusion of that article was that IoT capabilities are set to change jobs, not necessarily take them away. Engineers who are prepared to reskill and work with technology are the ones who will stay relevant.

However, telling your engineers that they need to move with the times is not going to get you very far. Instead, hold meetings with them, demo the system and describe its purpose and benefits fully. If it’s a way of completing and submitting a service report online instead of filling in a form and posting it, explain why it’s easier for them, faster for your invoicing team and better for your customer. If it’s a way of scheduling their jobs without whiteboards, spreadsheets, emails and phone calls, explain why it’s quicker, more efficient and more profitable. If it’s a way of getting spare parts to the right place at the right time, explain how it’s going to improve first-time fix rates and customer satisfaction.

3. Support them during AND after deployment

Another reason engineers resist technology is that companies have a habit of dropping new solutions in their laps and just expecting them to get on with it. The development of a solution isn’t complete the moment it’s rolled out. You have to engage and support your engineers during and after the implementation process to ensure that they are both able and keen to use the solution to its full advantage.

Make sure they are properly trained and put a post-deployment support plan in place. Listen to their concerns and suggestions as they use the solution and make sure they have an outlet to get answers and provide feedback. Continue to seek their views on how the solution is working for them in order to maximise their engagement and productivity and uncover additional needs that could lead to further improvements.

Right now there is a push across all industries to focus less on technology and more on the people using it. The key to a successful deployment of a new field service solution will be remembering this, and putting engineers at the centre of the process.