How To Write Exciting Conference Proposals
Posted in Conferences on May 28, 2017
Most conference proposals are too boring, even when the speakers and topics are great. This is a pity. I think something about the process of submitting to a CfP sets a trap for most speakers. This post is my advice for avoiding that trap.
TL;DR: Your proposal should focus on your story about what you’ve done personally and what you’ve learned. Your story, not the topic. And, don’t tell us anything about the importance of the topic or how high the stakes are.
I’ve written twice before (1, 2) about how to write better conference proposals. But while recently reviewing another thousand or so proposals, I suddenly understood something simple that separates the boring ones from the exciting ones. And I realized that I make the same mistake myself when I submit proposals!
Because I only see this pattern myself when I’m reviewing, not when I’m writing proposals, this time I’ll try to help you experience what it’s like to review conference proposals. Remember, your first audience is the review committee, who are reading hundreds of proposals.
What follows are real conference proposal abstracts. I have lightly edited where necessary to avoid identifying people explicitly. If you see one of your proposals below, please don’t take offense or jump to any conclusions about implied quality of your talk or expertise. Your proposal is hopefully serving a valuable purpose as part of this blog post.
Read through the following, spending no more than 8-10 seconds on each:
The rate of business change is accelerating. Organisations must build the right things better and faster to survive. Agile, Continuous Delivery and Lean help, but we need practices to ensure the “right things” flow into these processes. This talk explores design sprints in the enterprise to: Bridge the business-IT divide; Build the right thing; Increase organisational agility.
Databases require capacity planning (and to those coming from traditional RDBMS solutions, this can be thought of as a sizing guide). Capacity planning prevents resource exhaustion. Capacity planning can be hard. This talk has a heavier leaning on MySQL, but the concepts and addendum will help with any other data store.
The popularity of containers has driven the need for distributed systems that can provide a secure substrate for container deployments. In this talk, we will go over how Acme has been working on multiple components to secure every part of the container platform - from the newly announced LinuxKit all the way up to SwarmKit - and how all of these blocks fit together!
The Continuous Delivery (CD) movement has been around for more than a decade, and its lessons are even more relevant when embracing container technology. The talk will provide guidance and specific technical solutions on how to implement CD best practices on a reference implementation based on Git, Docker, Kubernetes and Terraform.
With ever increasing demands for fast business change how can we ensure our digital channels have the increasingly exacting standards of performance our customers (and business owners) expect? What does this look like in an age of DevOps and Continuous Delivery? We’ll take you through our experiences as we build a strategy for shifting left and automating performance analysis.
End-to-end engineering ownership - or DevOps - is the only way to scale operations in a micro-services world. Achieving this in large engineering organizations requires the right mindset, architecture and processes. The Acme Small Business Group (SBG) is on the journey to turning it’s 1000 engineers into full lifecycle engineers who own their services from cradle to grave.
Creating a fast & reliable pipeline poses numerous hurdles that cause most dev teams to fall back to slow release cycles, low levels of test & platform coverage & straight up buggy apps in production. To keep re-work & technical debt down to a minimum, defects must be identified & addressed as early as possible & frequently across multiple environments & under realistic conditions.
Do you see any similarities in these proposals? I selected only 7, but already the pattern emerges, and most of them feel very alike in some ways:
On reflection, all of these are very natural things to do, and seem like good things to do for that matter. And I think conferences usually ask speakers to make sure proposals include this information! Unfortunately, though, the result is mind-numbing when you’re reading through proposals and trying to decide which to vote for (or which to attend, if you’re the audience).
What’s going wrong? Although well-intentioned, the effort to illustrate the context and importance of the topic ends up having a very different effect:
As soon as I realized this, I was able to pinpoint two specific things about clear, brisk proposals that make them more fresh and exciting. To illustrate this, here are two proposals on a similar topic, hiring:
Today hiring the best people for the job is getting difficult and keeping them is another struggle. Not forgetting that people and plants are similar in that in order to become their best they need to have the right environment. This talk is about how to build a workplace (culture) that attracts talent and enables them to give their best.
Eric Schmidt’s quote, “Hiring is the most important thing you do,” is easy to say and very hard to implement. In this session, we’ll share the highs and lows of our journey to rebuild our recruiting program from scratch and create an approach that scales to the needs of our business and increase our annual hiring rate by 400% at the same time.
After I realized this, it became clear to me that a lively proposal is usually a personal story about learning from an experience, and a boring one is usually about a topic and best practices.
Here’s another lively one:
Our company did releases every 4 weeks by IT Ops at early hours 2 years ago. We transformed our way of working in less than 2 years to teams deploying at all hours, with the responsibility of monitoring their applications during business hours. How do you handle 400 IT-professionals with different skill sets? We created a guide for DevOps in our organization and want to share our transformation.
The general tone of this proposal is “we did something, learned something, and we want to share it with you.” I’m instantly excited to attend this session!
What’s my advice to people writing conference proposals? Tell a story about what you have actually done yourself, and don’t worry about setting the context, motivation, importance, or urgency, unless it’s non-obvious. Stories always win, and everyone knows that the pace of business change is accelerating. People want to hear your story, your mistakes, and your lessons learned.
Also, remember that busy reviewers will only give your proposals a few seconds of attention.
What am I not saying in this post? I’m not saying that writing needs to be high quality. When I realized that I didn’t really care a lot about passive voice and bad grammar while reviewing, I felt guilty that I’ve emphasized the need for “good” writing in the past. I’m not saying it doesn’t help. It does: clear, active, direct, compelling writing always helps. But it’s less important than the other points I’ve emphasized in this post. Some of the exciting proposals have pretty egregious writing mistakes, and I don’t care! A run-on sentence and passive voice is entirely forgivable as long as the speaker’s experience comes through clearly.
I know it’s hard. It’s so hard that I don’t follow this advice myself. But I’ll try harder in the future. I hope this helps.
PS: You’ll note that not all of the first seven “bad” proposals are wholly boring. Some of them do point to the speaker’s experience and story. I chose those seven almost sequentially from a conference, skipping only a couple that seemed exceptional. They’re not bad, they’re just ordinary, and many of them will be great talks even if the proposals are hard to read. My point is simply that when you read 350 ordinary proposals in a row, a non-ordinary one leaps out and screams for a high rating.