A lot more people have some degree of social anxiety than one might think, especially in IT.
Lightning talks originate—and work well in—the sort of tech-bro workplaces where there’s an Xbox, foosball table, and bar in the breakroom. Half the “culture fit” criterion of hiring for those places is just an attempt to filter out potential hires with any amount of social anxiety; so the average level of it in such places is low.
But other than in that little ecological niche, you’re not likely to see many engineers who are fond of public speaking, even when they have something they know and would love everyone else to learn about.
On the other hand, though, many of these same more anxious people are fond of writing. Unlike public speaking, which is a live performance, a written piece can be composed—worked out slowly, checked for errors, re-drafted, thrown out with no repercussions, etc.
Many engineers who aren’t at-all interested in giving a lightning talk, might instead quite like to blog about what they’re doing in some official capacity. And they would like it even more, I expect, if they didn’t have to have final responsibility for what was presented (because there’s always still the anxiety that someone might spot a flaw in your argument that you didn’t); but rather if their prose was handed off to a managing editor for the blog, to work up into a final article.
Which means that a lot of these same engineers would be fine composing a lightning talk, as long as they didn’t have to be the presenter, and also weren’t put on the spot to answer questions afterward†. Find someone in your org who just loves talking—maybe a salesperson, maybe your CEO!—and have the engineer in question work with them to transfer the knowledge necessary to give the presentation. As a bonus, the presenter gets to be educated in this stuff from the source, one-on-one; which can very much help improve the depth of their knowledge, when that same person is communicating with your customers!
† Q&A is a very valuable part of a talk, and the knowledge required to answer arbitrary questions really has to come from the engineer themselves, rather than a presenter. I’d suggest still doing Q&A with the engineer, but asynchronously, so you’re not putting the engineer in question “on the spot” in front of an audience. Maybe set up a mailing list or group-chat channel, that everyone attending the talks can subscribe to, to ask questions relevant to the latest talk. Then there’s no time-pressure on the engineer’s part to respond, but everyone still gets to ask questions, and to hear the answers to others’ questions.
