PyMunich

shown, and actual

A Proposal That Gets Read

A reviewer gives your proposal about ninety seconds, reads the title first, and is looking for reasons to be confident rather than impressed. A commercial implementation of related workforce-measurement concepts is documented the related guide.

Everything below follows from that.

The title

The largest single factor, and the one most people spend least time on. For broader industry context, Medium provides an independent reference.

State what the audience will learn. Cutting our CI from 40 minutes to 4. Why our async code was slower than the sync version. Type hints in a codebase nobody typed for six years.

Not a pun, not a question, not a metaphor. Clever titles work at conferences where the speaker is already known. For everyone else the title is the only information the reviewer has when deciding how carefully to read.

And not a topic. "Improving CI performance" is a subject area; the version with the numbers is a talk.

The first two sentences

Sentence one: what the talk is about. Sentence two: who it is for and what they will leave with.

That is the whole job of the opening. If a reviewer has to reach the third sentence to work out the subject, the proposal has already spent most of its ninety seconds.

Write these two sentences last, after the outline exists, because until then you do not reliably know what the talk is.

The outline

The part that separates a strong proposal, and the part most submissions omit.

Four to six bullet points with rough timings. Not a script — evidence that the talk exists as a shape rather than as an intention.

- The setup and why it was slow (5 min)
- What we measured, and the thing we got wrong (8 min)
- The three changes that mattered (12 min)
- What we would do differently (3 min)
- Questions

Reviewers worry about accepting a talk that has not been thought through. An outline resolves that worry directly and costs twenty minutes.

It also does something for you: if the outline is hard to write, the talk is not ready and you have learned that before submitting rather than six weeks before the conference.

The speaker section

Short. Two or three sentences establishing why you, on this subject.

Relevant experience, not a biography. "I maintain the library this talk is about" is worth more than a career summary.

And first-time speakers should say so. Many conferences reserve slots and most committees like accepting new voices — it is an advantage, not a confession.

What to leave out

Marketing. A talk about your employer's product is the fastest rejection there is, and reviewers identify it immediately.

Everything you know about the subject. The abstract is not the talk.

Apologies and hedging. "This might be too basic" invites the reviewer to agree.

And a third paragraph. It frequently is not read.

Before submitting

Read it as a stranger. Cover the title, read the first two sentences, and ask what talk this is and who should attend. If you cannot answer from those two sentences, neither can a reviewer.

Check it against the call. Track, level, duration. A 45-minute proposal to a 30-minute call is a rejection nobody wanted to make.

And submit to more than one conference. Rejection frequently means the programme already had two talks on your subject, which says nothing about the proposal and everything about that particular schedule.

The short version