Ruby Hoedown how conferences get made, and attended
pinned under “Speaking”

The abstract: one paragraph, two readers, four sentences

The part of a proposal that actually gets read, by a committee first and an attendee later.

The abstract is the part of a proposal that gets read. It is read twice by two different audiences with different questions: first by a committee deciding whether the talk belongs on a programme, and later by an attendee deciding whether to walk into the room, and the useful discipline is writing one paragraph that answers both.

The four sentences of an abstract A working abstract runs in four sentences: the problem stated concretely, why the obvious answer is not enough, what the talk shows, and what the listener leaves with, inside a budget of 120 to 180 words. 120–180 words, in this order 1 The problem, concretely “a test suite that takes forty minutes”, not “testing performance” 2 Why the obvious answer is not enough the sentence most often missing, it is what separates a talk from a tutorial 3 What the talk shows in the order it shows it, a proposal is not a trailer 4 What the listener leaves with one thing they can do or decide differently
Both readers of an abstract, the committee and the attendee in the corridor, are served by the same four sentences.

What the two readers want

The committee is asking whether this talk is clear, real, appropriately scoped and not the fourth submission on the same subject. It reads the abstract cold, often at the end of a long evening, alongside dozens of others: see the review process.

The attendee is standing in a corridor with four minutes before the next session, asking one question: will this be worth my next forty-five minutes. They do not care about method, and they will not read a second paragraph.

Both are served by the same structure, which is why an abstract written for the committee alone tends to read as a syllabus, and one written for the attendee alone tends to promise more than the talk delivers.

A structure that holds

Four sentences, in this order, does most of the work.

  1. The problem, concretely. Not the field, the situation. “A test suite that takes forty minutes” beats “testing performance”.
  2. Why the obvious answer is not enough. This is the sentence that separates a talk from a tutorial, and the one most often missing.
  3. What the talk shows. The actual content, in the actual order, without suspense. A proposal is not a trailer.
  4. What the listener leaves with. One thing they can do or decide differently, stated plainly.

No suspense. A proposal is not a trailer.

That is roughly 120 to 180 words, which is what most calls for papers ask for and what an attendee will read. Anything longer is a second document, and if the event provides a separate “notes for the committee” field, that is where the extra belongs: outline, timings, dependencies, prior deliveries.

Specifics are the whole game

Two abstracts can describe the same talk and only one is credible, and the difference is almost always concrete detail: a number, a named tool, a real constraint. “We improved our deployment process” says nothing that any of the other seventy proposals do not. “Deploys went from twenty-five minutes to four, and the last nine of them broke in a way we did not expect” describes a talk with content in it.

The same applies to scope. A proposal that promises a survey of an entire subject in forty-five minutes is read as a proposal from someone who has not planned the talk yet; one that promises a single case, followed properly, is read as one that has.

What weakens an abstract

  • Rhetorical questions as an opening. “Have you ever wondered why builds are slow?” costs a sentence and says nothing. So does “In today’s fast-moving industry”.
  • Withheld content. “I will share a surprising technique” tells a committee nothing it can evaluate, and a committee cannot accept what it cannot see.
  • Audience lists in place of content. “This talk is for developers, architects and managers” is a claim about everyone, which reads as a claim about no one.
  • Tense drift. Write it in the present, describing what the talk does. Future tense throughout (“I will explain, then I will show”) reads as a plan rather than a talk.
  • A title doing the abstract’s work. If the abstract only makes sense after reading the title twice, one of the two needs rewriting; see the title.

Before sending it

Read it aloud, the sentence that cannot be said in one breath is the one to split. Give it to someone outside the subject and ask them to say what the talk is about; if they cannot, the committee will not either. Check it against the call for papers for length and for the fields it actually asks for. And if the review is blind, remove the sentence that identifies who wrote it.

The remaining fields of a submission (title, biography, and whatever the event asks for) are covered on their own pages, and the proposal builder puts the whole thing together in one place.

Questions

How long should an abstract be?

120 to 180 words unless the call for papers says otherwise, which is about four sentences done properly. Longer abstracts are not read more carefully; they are read less carefully.

Should the abstract say what the talk concludes?

Yes. Withholding the point to create interest works against a proposal, because a committee can only accept what it can see. Say what the talk shows and what the listener leaves with.

First person or third?

Either, consistently. First person suits an experience report; third suits a technical subject. What reads badly is switching between them inside one paragraph.

Can the same abstract go to several conferences?

Yes, and it is normal practice, but adjust the scope sentence to the event’s audience and slot length. An abstract written for a forty-five-minute regional slot rarely fits a thirty-minute one without a real change to what the talk covers.