Create a Conference Proposal the Conference Wants and Accepts, Part 4: Complete the Proposal -

You know who your audience is because you framed the proposal. You started with outcomes, and you refined those outcomes when you wrote the abstract.

Now it's time to complete the rest of the proposal, excluding your bio and the title. Bios and titles are different from the rest of the proposal. (Those will be separate posts.)

Every conference proposal seems to be a little different. The one part every conference requests is the type of session.

Define Your Session Type

Here are the session types I know about.

Talk or presentation. You might lead interactions, but it's not a workshop. The audience expects you to wow them with your ideas and insights.
Workshop. When people see the word, “workshop,” they expect to work, not just listen to you talk. (Well, with any luck, they expect that.) The audience expects to work through some problem or other, and gain their own insights.
Experience report. You tell the story of some change, often in an organization. The audience expects a story, where they can learn from your insights.
Lightning talk. A reduced-time presentation, such as 5 or 10 minutes. No one expects you to lead any interactions. The audience expects one important idea—that yes, offers them insights.
Pecha Kucha. A specific form of a presentation: 20 slides, each in 20 seconds. A total of 6:40 minutes. The slides are supposed to be pictures. The audience might not know what to expect if they have never seen a Pecha Kucha before. Your job is to entertain, often with a little inspiration. You don't interact in the session.

(If you know of any session types I missed, please let me know in the comments and I will add them.)

Each session type offers you and the potential audience something a little different.

Choose Your Session Type

Not all conferences want all possible session types. You can often choose between a talk, workshop, and an experience report. In my experience, many conferences offer the opportunity for lightning talks and Pecha Kuchas once they accept your main presentation.

Most of the time, you'll select a session type of: talk, workshop, or experience report.

I ask myself these questions, to decide which session type I want to offer:

Is this one specific experience at one specific organization where I can discuss a change? I'll choose the experience report.
Do I have several experiences that I can mine for common, useful ideas? I'll choose a presentation or talk.
Do I have enough time to mine those common ideas and create a workshop so people can practice? I'll choose a workshop.

Your choice for session type might also depend on the time for each session.

Here's my problem. When I create a workshop, people learn as they try something new. And, just the trying isn't sufficient. I need to lead a debrief of their experience to help them see what they learned.

I have had reasonable results in a 60-minute workshop with one interaction and one debrief. I often feel as if I “should” have been able to do more.

I prefer to offer a presentation with some short interactions I don't have to fully debrief if I only have one hour.

With 75 or 90 minutes, I prefer to offer a workshop. That duration allows me the opportunity to craft two or three interactions and debrief them.

Note: Some conferences create an expectation that attendees only have to open their eyes and ears and us speakers can pour great information into their heads. That's why the conference calls the people who attend “attendees.” The program committee doesn't call those people “participants.”

Too often, in the really big conferences, these attendees expect a recipe. That's because the people have so many interconnected problems, they find it difficult to unlink the various problems from each other. When people expect a recipe, they don't consider how to adapt your ideas to their circumstances.

I don't know what to suggest. I urge you to recognize this phenomenon and to build as many interactions as possible into your session. The more interactions, the more people realize they will need to adapt what you say to their circumstances.

You're not quite done yet.

Complete the Other Parts of the Proposal

Many conferences now ask speakers to offer an outline of what they will say. In the Agile 20xx conferences, that section is called “Information for the Program Committee” or some wording like that.

“More information” offers you a chance to show the program committee you know your stuff. The audience will be in your capable hands. If there is a place for more information, fill this in. Otherwise, the program committee can't easily say yes to your proposal. Your job is to help these people say yes.

This extra information is a little different for a talk/workshop than it is for an experience report.

One formatting note: Make sure you explain this information in relatively short paragraphs. Check the grade level and readability of this text, also. Don't make people work hard to read your information.

Information for a Talk or Workshop

I fill in the Information box with an outline of what I think I'm going to say, in five-minute increments.

I start with the context, often in the form of a short story. This shows the program committee who the session is for, and the problem they have.

For the multitasking talk, I often start with this:

0:00-0:05 mins: Tell the story of when I was a young engineer and my boss wanted me to work on 3 projects.

This is why I like to start with the proposal frame. I know who I want in my audience. I know their problems. I'll still have to help the program committee see my solutions, but they can see I'm inviting people into the material and connecting with these people right away.

As a reviewer, when I read something like this, I relax a little. I'm pretty sure the writer knows what they're talking about.

Your opening sets the context for the audience.

Start the talk with a way to connect to the people you want in your audience and their problems.

In my experience, the larger the conference, the more detail the program committee wants. That's why I explain the outline in 5-minute increments.

When I write the talk, I often change the order of the information for better flow. I keep the story at the front, but I change how the rest of the session goes. If you also do that, make sure you deliver on the outcomes you described.

For a workshop, I describe the interaction in words similar to this:

“From the worksheet, work in triads discussing the specific points above. Debrief what people discussed and wrote down.”

I often use 10-15 minutes for this kind of interaction.

For the simulation I use in the multitasking talk, I might use these words:

“Encourage people to try the various words. Debrief. Timebox this total activity to 7 minutes.”

When the program committee sees explanations like this, they know I know what I'm planning to do.

I don't actually create or update the talk or the workshop until a couple of months in advance of the conference. That's because the call for submissions opens quite early, and often closes more than six months in advance of the conference.

However, I have a zeroth design for every interaction. And, because I offer a reasonable outline for the talk or workshop, the program committee believes I will deliver.

An experience report requires different information for the program committee.

Information for an Experience Report

If you propose an experience report, the More Information box is your chance to describe your story.

You might consider a paragraph for each of these points:

Start with the problems, the initial state before you started your experience. What kinds of problems did you see? You might have to add the number of teams or products involved.
What triggered the problem for a change?
What did you try? What succeeded?
Did what you try make the problem worse? When did you make things better? What was your experience for each of these tries and fails? How did you feel? The more emotions you uncover, the better the experience report.
What did you and the organization learn as you proceeded with the tries and fails/successes?
What is the new, updated state?

Not all experience reports can report a positive change. Sometimes, everything the writer tried failed. Everyone can learn from a failed attempt at change. Please do consider writing an experience report about things that failed.

Experience reports are not just about the company's transformation. If you are the reporter, please write about how you changed also. One of the reports I shepherded recently said that the more vulnerable he felt, the better I liked the report.

I wasn't looking for vulnerability. I was looking for the kernel of the experience. He delivered and it was a great report.

Always Explain the Story Behind the Session

In all the More Information boxes, I suggested you start with a story to set the context. I'm talking about a few minutes for a story that highlights the major problems your audience has.

An experience report is an entire story, so the starting story is the beginning context.

A short story—about 3-5 minutes—helps you set the context for the entire session. If you can add a little humor, that's great.

I use sarcasm, eye-rolling, and a little self-deprecating humor. Just enough so people realize I'm human.

Discover what works for you, first for the opening story and then throughout the rest of the session. Find the best version of your speaking self.

Explain When Your Ideas Won't Work

You have experience solving problems in a specific context. It's possible your solutions are universal. In my experience, a universal solution is almost never universal.

When you set the context and explain when your solutions might not work for the audience, you actually create more credibility than if you say your solution will work for everyone.

I often add these details in the More Information part of the proposal. I've used these approaches:

Set aside five minutes somewhere in the outline to discuss when things won't work.
Discuss anti-patterns or other problems as I proceed.
If I think I'll run out of time in the session, write a blog post or article and refer to that content in the session.

Don't be afraid to say when your ideas won't work. Every time I've done this, people argue with me. I've heard this, “You said this wouldn't work in my context, but it does. You're wrong!”

That's the kind of wrong I like. I smile and thank the person.

Complete the Other Fields

You might see keywords, room setup, and more. Complete all those fields except for the bio and the title now. If you're not sure what any field is, ask someone on the program committee. Ask as early as you can, so you can finish the proposal early.

Now Try This

Write this down in the same proposal document:

Decide if and what kinds of interactions you want to offer. Then decide what session type you want to offer.
How well will that session type work for the problems your people want to solve?
Review the abstract and the outcomes. Can you deliver with this session type?
If you can't deliver with the session type you selected, do you need to change any outcomes?

Now, it's time to write a bio and add your speaking experience.

The entire series:

(Update: I wrote a book, Write a Conference Proposal the Conference Wants and Accepts that incorporates this and all the other conference proposal posts.)

Create a Conference Proposal the Conference Wants and Accepts, Part 4: Complete the Proposal