- Different groups learn new technology in distinctly different ways
- The best technology training is aligned to performance goals
- Engaging people in how to improve the technology and its use enhances adoption
I once saw a résumé where, in the “skills” section, the applicant noted his third-degree black belt in karate, his equally high rank in Judo, his proficiency in Krav Maga, and his lengthy experience in Microsoft Word.
To borrow from Sesame Street, one of these skills is not like the other.
But it is telling that in the mind of this applicant, his knowledge of a single software program was parallel to his 22 years of martial arts practice. Contrast that long-term timeline with a digital native, who expects the user interface of most software to be so instinctive as to be invisible. Now, combine those two outlooks and everything in between into one workforce, and ask them all to start using a new technology that you just spent the past year investigating, comparing, defending for budget and implementing. Ouch.
When I see colleagues leading the technology adoption process, I always ask – only somewhat in jest – “How’s your pain level today?” because it is painful. It’s hard. But having led five major organization-wide technology platform shifts, and been a part of dozens more, I’ve learned some hard lessons that can make it easier:
Teach it differently. There are people who will sit and watch all your step-by-step how-to videos, and even read the user guide, but odds are, none of them are the key people you need to actually use the platform well. You will still need to make those help resources, but you will also have to provide some scenario-based practice sessions, ideally for people in similar roles. Above all, be adaptive to the rate of adoption: if you have a group that starts to excel, create some fast-paced sessions for them. If you have a group that needs more time, separate them out and give them a chance to ask basic questions. If you flex to the different learning needs and speeds at the beginning, you will have a lot less cleanup and re-teaching to do later on.
Explain the “So what?” Every click you teach should be aligned to a performance goal that person is responsible for meeting. Do not show people “nice to have” or “nice to know” features. Show them how to do the five or six or 10 performance-enhancing activities you bought the platform for in the first place. Again, the naturally curious or technically fluent are going to ferret out all the other features, come to you later for guidance, or actually read that 52-page user guide. You don’t need to teach them the extras. By focusing on the key performance goals, and restating the connection between the platform task and the goals over and over again, you will drive much more adoption.
Create a genuine feedback loop. Hold on! Don’t dismiss this one so fast. I really do mean that you should ask the same people who struggle with the difference between “Save” and “Save As” to give you ideas and feedback. Why? Because I am always surprised from where the good ideas, the insights that everyone misses, end up coming. Those good ideas can have a major impact on your technology; I have always believed in sharing collective (and, of course, curated) ideas for improvement from my colleagues with the service provider. It may take their engineering team 12 months to get to it, but you would be surprised at how often even large companies adjust to client suggestions. And while you’ll get a lot of obvious ideas when you make and maintain this open call for collaboration within your platform users, you will be surprised as the good ideas, goodwill, and good attitude this effort creates for you long-term. Bring your patience with you, but do give it a try.
To learn more about best practices in managing technology and people, check out some of our other posts, and tell us what you have done to bridge the adoption gaps.