Technology change can be unwelcome even if the technology being changed had many problems. But it’s even more unwelcome when the technology being changed worked perfectly fine from the impacted employees’ perspective.
I have experienced what it’s like to be told a technology I enjoyed using, and was grateful for, had to change. It’s stressful and upsetting. As a Learning professional, what can you do to make this situation more tolerable, or even prevent it from happening in the first place?
I saw an article in Harvard Business Review by Dorothy Leonard-Barton and William A. Kraus on the subject of managing technology change in organizations. The article made me think of this core challenge: Many technical developers work in a vacuum and are highly skilled in technology, but little-to-not-skilled in the human impact of technology. That means they don’t consider it their job to worry about the feelings of the employees the new technology will impact.
In many cases, the developers never meet with the employees who will be end-users. There is typically a project manager between the developer and future end-users. Is that intermediary—who relays messages—a good idea, or counterproductive? I’m often reminded of the old childhood telephone game in which one person whispers a message to another and then another and another. By the time the message has reached the end of the line of people, it is often unrecognizable from what it started as. This phenomenon happens in organizations. It could be happening during the new technology development process.
It might be worth experimenting with having developers meet directly with future end-users. The project manager could sit in, but only to facilitate discussion and take notes. It should be a meeting powered by information imparted by the developers, with the developers asking the employees questions on their feelings about the information they have shared. The first question should be: “How do you feel about the technology as it currently exists?” If the group the developers are meeting with is small, they could even go from person to person, asking each individual if there is anything they would like to change about the technology. And if so, what those things are. If not, whether they would like to leave the technology as it is. If the overwhelming majority of future end-users like the technology exactly as it is, the developers will have to explain why the technology may need to change anyway (to integrate with another technology the company has added, because the current technology won’t be operable much longer if it is not updated, etc.). The developers then should make plans to use the technology in its current state as if they were an end-user to see how it works, and figure out why employees are so happy with it.
After assuring employees they will familiarize themselves with what it’s like to be a user of the current technology, the developers should ask the employees to tell them what they love about the current system.
Once the new technology is developed, the end-user employees should be asked to demo it before it’s finalized. While there’s still time and ability to make changes, employees should be able to complain in a meaningful way—a way that may result in the things they’re complaining about getting fixed.
There also should be discussion among executives about valid reasons for changing technologies. For example, is the need to have all employees in one department using the same technology a good enough reason? What if one technology suits one business unit within the department fine, while another business unit finds that different technology would be better? Should a business unit be forced to stop using a system its employees are thoroughly happy with? Is changing for the sake of having the newest and best a good enough reason? What if the older version of the technology is working well, and the employees who have experienced the newer version did not like it? Should the change managers dismiss these employees’ dissatisfaction as nothing more than the need for time to adjust?
“If it ain’t broke, don’t fix it” is a great mantra. It may conflict with the new wisdom of pushing for constant improvement, but when it comes to technology, “improved” can mean needlessly complex and cumbersome processes for end-users who are not information technology technicians. You may be doing a “favor” for employees who never asked for one.
How do you assess the need for technology change in your organization, and then how do you ensure it is rolled out so future end-users will be happy, rather than aggravated, by the change?
