As an Educational Consultant I get to interact with a lot of different nonprofits on a variety of topics. One of my favorite assignments, though, is what we call “Train the Trainer” (T3), where I will work with a group of folks who will later put on a different hat and train their colleagues on new software. These assignments call upon product knowledge of course, but also a great deal of facilitation training, including many practice teachbacks in front of the group. As Bo Crader talked about in a recent blog post, new software isn’t worth much unless users actually USE it, so ramping folks up on software is an exceptionally important element of the adoption process.
Not just for training
In my previous career as a professor of communication, I’ve taught public speaking for over 15 years to countless students. So, yes, I’ve seen the gambit of highs and lows in those situations: nervous tics, stammering, complete freezes, near physical sickness, and even had someone literally pass out while delivering a presentation (!). Those are great cocktail party stories as everyone can relate to feeling the butterflies in front of an audience, but the real reward is seeing those same folks grow and triumph with excellent presentations that wowed audiences. The glow of pride in these presenters would make my day every time.
Teaching public speaking and T3 underscores the fact that even if we aren’t in careers where we are expected to deliver presentations regularly, we ALL do it more than we think, especially in the nonprofit world. How often are you asked to speak to others about donating to your organization? How about pitching a new idea to a colleague or superior? Speaking at a booth at a convention? Or even standing up for something you believe in at your children’s school? Quite often we are doing public speaking and not even recognizing it. And you’re probably better than you think!
Back to the basics
In any public speaking class, one is almost certain to talk about Aristotle and his well known rhetorical appeals of Ethos, Logos, and Pathos. Put simply, Ethos is proof of ethics or credibility of the speaker, Logos is the logical proof of the argument, and Pathos is the emotional connection of the speaker and her audience. All three are important of course, but in the nonprofit world one should never leave out the emotional proof. Time and again in persuasive appeals we will have established credibility and put together a perfectly logical argument that doesn’t deliver results and ask ourselves what happened. Often the answer is that we didn’t appeal to the emotions of the audience, which many believe is the most powerful proof when asking others to take action. If done with context, the photo of the malnourished puppy or hungry child is usually what audiences remember rather than the perfect logic.
How is software emotional?
So is implementing software a persuasive appeal? You bet it is. Any change brings anxiety, so part of your job is to ease that tension and help audiences to see the value of the change. When conducting training, you have to make the case to the audience that you are a knowledgeable speaker who understands the audience and their concerns (Ethos) and that the software can help the organization get from Point A to Point B in terms of generating revenue, conducting marketing campaigns, or tracking constituents (Logos), for example.
But don’t ever forget to emphasize that this very un-emotional software can help the organization reach and help others (Pathos)! Because in the end, that’s what nonprofits are trying to do—and if the audience sees that in your delivery, they are much more likely to make the investment to learn the product. Consider talking about the central cause of your organization, the folks that you are helping, or the difference you are making in people’s lives. Yes—software itself does not stir those emotional strings in audiences—but it should allow your organization to focus more and be more effective in its mission. And if your staff sees that connection, they will be much more likely to put that software to use.
Do you have any success (or not-so successful) stories of implementing new software? As you reflect upon the experience, what were the keys that you would repeat (or avoid)? Share them in the comments below!