How To Write Exciting Conference Proposals

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:

They point to significant changes or important circumstances, to create
context for the talk.

They mention specific challenges that arise in these circumstances.

They refer to the urgency of learning what the speaker will share.

They pose questions, but don’t answer them, as a way of showing what the
audience will learn from the talk.

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:

The first several sentences of most proposals focus on obvious,
well-established facts that don’t need to be stated. The speaker is trying to
frame the topic and its importance, but it ends up being equivalent to humans
need oxygen to live or something similarly banal.

The speaker tries to indicate that the subject matter will be widely
applicable and everyone will find it relevant, but it ends up coming across as
regurgitation of best practices.

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.

What’s different?

One is about the topic and the other is about the speaker’s experience.

One starts with context and the other starts with a challenge.

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.

See Also

I'm Baron Schwartz, the founder and CEO of VividCortex. I am the author of High
Performance MySQL and lots of open-source software for performance analysis, monitoring, and system administration.
I contribute to various database communities such as Oracle, PostgreSQL, Redis and MongoDB. More about me.