You want to present a talk, workshop, experience report at a conference. (Or, a lightning talk, Pecha Kucha, or more.) You have something important to share. How can you create a proposal that the program committee will accept?
I'm writing this series to explain how to do just that. The series parts are:
- Understand who and what purpose the proposal serves.
- Understand the four parts of the proposal: title, abstract, description, and learning objectives.
- Why you should iterate on the proposal parts and strengthen your writing as you iterate.
- Decide which conference(s) to propose your content.
- Obtain the most feedback from your submission.
I got the idea for this series from Chris Murman's talk at Agile 2019 and from all my shepherding for the Agile 20xx and XPxx conferences.
(If you're wondering, yes, I plan to create a short book and online class from this material.)
About Conference Proposals
A conference proposal serves these purposes:
- Help the conference program committee select your proposal.
- Help the people at the conference select your session.
That means you want people to connect with your proposal so that you can share your information.
When I think about this kind of connection, I think about these ideas:
- Who do I want to connect with?
- What problems do they have?
- Is there a specific context I want to address?
Your talk has solutions that are not right for everyone. Your experience has a context, and that context matters. The context often helps me select who I want to connect with.
Who Do You Want in Your Audience?
When you choose your audience, you start to clarify what you might want to say and how to frame your work.
Your proposal is the first way you connect with your audience.
For example, I only offer talks for people using agile approaches or trying to. Why? Because I restrict my consulting work to people who want to use agile approaches. (I also work in an agile way.)
I respect people who don't want to use agile approaches. However, I am not interested in consulting in their context. I'm happy to discuss their issues over a coffee. Not for work.
What if you're not a consultant? It's the same problem. Who do you want to connect with?
Beware of a large class of people, such as “Scrum Masters,” “agile coaches,” or even “managers.” Yes, there are many of those people. And, because each person has his or her own context, you will not be able to satisfy all of those people.
Because there are many of those people, they have many problems. And, they often need different answers depending on their context.
It's okay to start with a large class of people. Make sure you narrow your focus when you identify the problems those people have. (I'll talk more about this later.)
Identify the Problems Those People Have
In Chris Murman's session, I sat next to a lovely guy who said he wanted to give a talk about helping teams be happy.
I asked why he wanted teams to be happy. (I find that happiness is an outcome of being satisfied with the work, not a direct goal itself.) He looked at me with astonishment. He said, “Don't all teams need to be happy?”
I said, “No, not at all. Team members need to be satisfied with and proud of their work. You can't control a person's happiness, especially not at work.”
“Ooooh.”
I'm not sure what he thought after that.
I am sure that his thesis—that teams need to be happy—is a response to problems he saw at work. That happiness response might have worked for him. But what matters to the conference (and the audience) is the problems he saw.
Think back to the people you identified as the people you want in your audience. Use their problems to connect with them.
What problems do the people you want to connect with have?
Beware of Making People Feel Stupid or Wrong
People work in a particular context. You might think they have their problems for stupid reasons. You might even think they are wrong.
And, their context almost always drives their decision-making.
I have a great talk about “Learn to Say No and Manage Your Multitasking!” I love giving that talk. And, when I propose it, I don't tell people they are wrong for either multitasking or requesting multitasking.
I first bring people along on a story, and then I explain how people are mistaken in their beliefs.
I know multitasking is wrong. I also know that well-meaning people might not know what I know. That's why I propose the talk.
And, I stay empathetic to the problems:
- These people multitask.
- They might or might not know multitasking is “wrong.”
- Their real problem is they have no idea how to stop multitasking.
I meet people where they are, starting in the proposal. That's part of the connection.
Define the Context
I already said I only speak to people who are on their agile journey or experimenting with that journey. That's my context for my talks.
You will choose your context.
You might choose a product domain, such as financial products. You might select a specific function, such as testers. You might select a company size.
Those are just three possibilities. You have many options for the context.
Your suggestions are not right for all possible people. If you don't know when your solutions don't work, you might not realize what the problem is or what the answers are. When you tell people when your solutions don't work, you actually build your authority. (Brian Marick taught me that trick many years ago when he was a technical editor for a magazine.
Don't be afraid of narrowing your context. People are smart. Even when I specifically say “project or program managers” in my abstract, some developers and testers come to my talks. Why? Because they have the same problems I wrote about in my proposal. And, they are willing to look past the context I set to explore their problems.
Now Try This
Write this down:
- Who do you want to come to your talk? (I'll talk more about the difference between the kinds of presentations later.)
- What problems do they have? List them in some way. If you can't write down at least three problems, you might not understand this particular topic enough. That's okay—you might select one type of presentation over another. (For example, you might decide to facilitate an exploratory workshop.)
- What is the context? I will ask you to define when your solutions don't work, so setting the context for your proposal is key.
The entire series:
- Part 1: Frame the Problem
- Part 2: Start with Outcomes
- Part 3: Write the Abstract
- Part 4: Complete the Proposal
- Part 5: Write Your Bio
- Part 6: Hook the Reader with a Great Title
(Update: I wrote a book, Write a Conference Proposal the Conference Wants and Accepts that incorporates this and all the other conference proposal posts.)