Part 5: Write and Submit a Proposal

Part 5 of 8 in A Guide to Speaking at Technology Conferences.

A proposal is not the talk itself. It is evidence that you understand the audience, have a focused idea, and can deliver the session described.

This article expands on CFP Land’s archived “Submitting Abstracts”.

Choose a topic worth developing

You do not need finished slides before submitting, but you do need a credible plan. Test the idea against seven questions:

Does it fit the conference and one of its tracks?
Will you still care about it after months of preparation and questions?
Do you know it well enough, or have a realistic research plan?
Does your experience provide a distinct angle?
Will the lesson improve someone’s work or wider community?
Is the story genuine, including its failures and limits?
Can attendees take a concrete action afterward?

Introductory topics can be valuable when they serve the event’s audience. Novelty does not require inventing a brand-new subject; it can come from a specific context, comparison, dataset, failure, or explanation.

Begin with the audience outcome

Complete this sentence: “After this session, attendees will be able to…” Use a concrete verb. Compare approaches, diagnose a problem, design an experiment, or apply a technique is clearer than understand or learn about.

Then define the audience. A session for test automation beginners should not quietly require advanced knowledge of distributed systems. A leadership talk should explain why its lesson matters to people responsible for teams or strategy.

Narrow the idea

A useful talk usually has one central promise supported by a few points. “Everything about software testing” is too broad. “Three ways our team made flaky end-to-end tests easier to diagnose” establishes a problem, scope, and likely outcome.

Narrowing does not make an idea less impressive. It makes the proposal credible and the talk memorable.

Write a clear title

The title should help reviewers and attendees predict the subject. Personality and wordplay can help, but clarity comes first. If a clever title could describe five unrelated talks, add a subtitle or rewrite it.

Avoid claims the talk cannot support. Words such as always, never, perfect, and effortless invite skepticism and rarely reflect real engineering work.

Draft many titles, then return to the title after writing the abstract. Avoid clichés, unexplained acronyms, clickbait, and jokes that obscure the subject. Include the terms an attendee would use when searching the schedule.

Build the abstract

Unless the CFP requests a different structure, a strong public abstract answers four questions:

What problem or opportunity does this session address?
Why does it matter to this audience?
What will the speaker cover or demonstrate?
What can attendees take back to their work?

Write for a person scanning many submissions. Open with the substance, use plain language, and remove background that does not help someone choose the session.

A dependable structure is: state the problem, preview the approach, and explain what the session will enable the audience to do. Two or three compact paragraphs are often easier to evaluate than one dense block. End with a specific outcome rather than a generic invitation to attend.

Customize the framing for each conference, obey its word limits, and state the intended experience level. Use inclusive language and remove metaphors that depend on disability, violence, or stereotypes when plain language works better.

Give reviewers the detail they need

Many systems include private notes, an outline, or a field for the program committee. Use it. Describe the session’s progression, examples, evidence, demonstrations, exercises, and timing. Explain what is original about your perspective and disclose vendor relationships.

If the talk relies on a case study, include enough context to evaluate it. If it makes an empirical claim, identify the evidence. If it is interactive, describe how the interaction will work for the expected room and time.

Write an appropriate biography

Your biography should establish why you can give this particular session. Mention relevant work, community experience, or prior exploration without turning it into a complete career history. First-time speakers can demonstrate credibility through the work itself; prior conference appearances are not the only qualification.

Get feedback and revise

Ask at least one person in the intended audience and one person unfamiliar with the topic to read the proposal. Useful questions include:

What do you think this talk will teach?
Who is it for?
Which sentence is confusing?
What would make you attend—or skip—it?
Does the promised outcome fit the session length?

Read the abstract aloud, check every required field, preserve a copy, and submit before the last hour. Confirm that the system shows the proposal as received.

Choose the right submission strategy

If the CFP permits multiple proposals, submit more than one only when each is genuinely developed and appropriate. This gives organizers options but does not make unfinished ideas stronger.

Consider a workshop only when the material benefits from practice and you can design exercises, pacing, support, and contingency plans. A workshop is not a talk made longer.

Save every public and private field exactly as submitted. Note the promised format, length, and outcomes so an acceptance months later does not surprise you. Rejection is normal; improve the proposal and keep submitting to suitable events rather than measuring success by one decision.

← Part 4: Find Calls for Proposals · Part 6: Handle Acceptance, Waitlists, and Rejection →