Conferences are a special opportunity for speakers to make meaningful connections with audiences.
A great talk challenges our preconceptions. It excites and entertains us. It conveys advice by resonating with some experience that anyone can relate to. A great talk is comfortable with exploring subtle aspects of a complex issue without suggesting that complexity itself is a malady to be cured.
Most technical talks, however, lack all of those qualities.
They tell audiences that some new tool can transform hard problems into easy ones. (A "tool" in this sense could be a language, a library, an application framework, or even a human process.) They eschew nuance or depth in favor of surface-level summaries of said tool's features. Most hour-long talks barely convey more information than what a reasonably engaged person would learn from readily-accessible documentation in the same amount of time.
A conference worth of content
I'm about to undertake the task of reviewing submissions to the JavaScript track at Codemash. Right now, that means I'm hoping to help find 18 talks that I would want to attend. Calling eighteen talks a "track" seems euphemistic at times; I'm tending to think of it as a conference-within-a-conference. My goal is to line up a series of talks that will empower attendees to skate to where the puck is going to be in front-end web development, by covering four bases:
- Timeless aspects of writing software that are always relevant, applied to the technologies we tend to find ourselves working with today
- Near-term trends and innovations that people can grapple with or adopt today in hopes of being well-positioned tomorrow
- Medium-term rumblings from ongoing conversations in communities and standards groups to address the intractable problems of today. Nuanced discussion of issues like these is an opportunity both to analyze the nature of today's hard problems and to provide informed speculation as to the sort of solutions that may soon emerge
- Long-term visions of the future that contextualize today's fashions within the broader strokes of computing history and upon which we can find inspiration to play and experiment with bold, new ideas that we otherwise wouldn't make time for
I expect that most talks will fall into the first two categories (as they're the most abundant and immediately relevant), but I'm working hard to secure a few high-quality talks in the third and fourth categories, as well.
Design and delivery are intertwined
It's tempting when discussing this topic to try to separate the approach of a talk (its "design") from its in-person execution (its "delivery"), because shortcomings in a talk's design often appear to be overcome by exceptional delivery.
The sentiment, "well sure, it's a surface-level summary talk, but it will be fantastically delivered," seems to be a common one. I'd maintain that such a talk is only marginally more successful than it would have been if presented poorly. Obvious information is no less obvious when papered over by an entertaining presentation.
Similarly, a talk with a groundbreaking, earth-shatteringly important design cannot be saved from a dry, boring, or poorly-prepared delivery. It's almost impossible to weed this out by reading an abstract, so don't be surprised if I reach out to you directly to try to gauge your commitment to deliver something that's truly worth attendees' time.
Problematic assumptions
Conference talks that fail to meet their potential often exhibit one of these tendencies:
- Assumes a broad survey of all a tool's features is the most appropriate (or digestible) format for novice attendees
- Is designed as if the talk's value is equivalent to the sum of information it contains
- Avoids the discomfort of engaging with complex topics by way of rhetorical flourishes or hand-waving. By making complex things seem simple, they might succeed to inspire an audience only to set them up for disappointment upon being reacquainted with reality
- Associates depth and nuance with "advanced" talks, as if digging into the rationale that informs a given topic is somehow not as valuable to novices
- Seeks to satiate the curiosities of attendees as opposed to equipping them with what they need to embark on a journey of their own
If you plan on submitting a talk to a technical conference, first ask yourself if your topic is at risk of one of the above problems. Feel free to contact me if you would like my feedback!
Tool obsession
Underlying the specific problems inherent to many "tool talks" is a broader issue: they far outnumber everything else! This, in spite of the fact that non-tool talks are arguably more valuable and durable, because typically they seek to address a universal aspect of the practice of understanding, writing, or maintaining software. So why are they dwarfed by talks about tools?
First, tool talks are easier to conceptualize. One could easily think, "well, I started using Angular.js lately and that's been going great so I'll submit a talk to tell people about Angular." Often a better—if less intuitive—talk might be hiding amid the very same sentiment. The same person might have more thoughtfully arrived at, "boy, we kept arriving at hard-to-test JavaScript code, but Angular's dependency injection sure helped; I should submit a talk about testability in JavaScript and why Angular worked for us!"
Second, tool talks require less gumption to execute well. After all, if a talk's purpose is to present facts about a tool, those can be both found and validated easily. If a talk promotes a new way to design code, then a great deal more experience, preparation, and confidence are necessary.
Finally, tool talks are often what attendees say they want. Imagine a survey: what's more likely, (a) that an attendee will check a box indicating interest in a talk about Ember or (b) that they'll scribble in the margin a story about how their app is struggling to weigh the convenience of view-model data binding against the performance impact it's having on their user interface? The answer is obvious.
Rather than give attendees what they expect, I'd rather give them something truly great. And a skin-deep introduction of a library or framework, particularly when stripped of the context that inspired it, almost never makes for a great talk.
Connecting with a great talk
Enough complaining about what holds so many talks back—what sets great talks apart? A great talk:
- Excites audiences by being designed carefully and delivered with energy
- Clothes information in entertainment, even at the expense of cramming in more content. Well-executed humor can effectively dissolve insecurity & doubt
- Commiserates when necessary by being open and honest about the perennially hard problems that developers might face with respect to a given topic. Sometimes it's hard to take a prescription seriously until it's clear that the person giving it has lived with your pain
- Paints a picture when words aren't enough. There have literally been books written on the merits and pitfalls of presentation slides, but there is no doubt that well-crafted visual aides make it easier to quickly understand and permanently retain the speaker's message
The common thread running through all of these things is that a great talk establishes a meaningful connection between the speaker and the attendee.
What are you doing still reading this? Go submit the next great technical talk!
caveat
One caveat to all this is that I want to mention that I develop and present talks of my own a few times each year, and that at some point or another I've been entirely guilty of literally every "bad" quality of talks that I've tried to articulate above. The reason I'm aware of these issues is due in part (but not entirely) to a critical examination of the flawed design and delivery of my own past talks. This post is as much a signpost for myself as it is for anyone else; I've exhibited each of these shortcomings in the past, so naturally I'm at risk of stumbling over them again in the future.
If this post gives you pause about how you present conference talks (as a speaker or an attendee), then great. If all it does is provide you with ammunition to call me a hypocrite at some point in the future, well, it never hurts to receive more constructive feedback.
