The Call for Papers Nobody Tells You How to Write

I've spent a fair number of evenings reading call-for-papers submissions for network operator events, first just as someone who submitted a few myself, and later from the tooling side, building the review and scoring workflows for NOGnet, the event-support platform I work on. Neither role puts a gavel in my hand on a program committee. Both put a hundred abstracts in front of me at once, and after enough of those evenings a pattern gets impossible to ignore.

The talks that turn out best in the room almost never read like it beforehand. A good share of the abstracts that sound impressive on paper fall apart the second the speaker actually gets up there. There's a real gap between what makes a good forty-minute talk and what makes a good two-hundred-word pitch for one, and nobody sits first-time submitters down to explain it. So here's my attempt, for whatever a few hundred evenings of reading these things is worth.

The vendor pitch in disguise

The easiest failure to spot is the abstract that promises operational insight and turns out to be a product announcement with a conference badge on. You can usually tell within two sentences, and it has nothing to do with where the speaker works. Plenty of strong NOG talks come from vendor engineers. What gives it away is that the abstract describes a capability instead of a decision. "Our platform now supports X" is marketing copy. "We had to choose between X and Y under a deadline, and here's what it cost us" is a talk. A reviewer skimming a hundred submissions in one sitting learns to read for that difference fast, because it decides whether a room full of engineers leans in or checks their phones.

Vague enough to mean nothing

The second failure is quieter, and honestly more forgivable, because it usually belongs to someone with real experience who just doesn't trust the format to carry it. These abstracts stay so general that a reviewer can't tell whether the person has actually operated the thing they're proposing to talk about, or just read a good article on it last month. "This talk explores the challenges of route leak prevention" could be written by either person. Nothing in the sentence tells them apart, and when a reviewer can't tell, the safer assumption skews toward the less generous read.

What works, almost every time, is specificity that would cost something to fake. A number. A timestamp. A configuration detail that only shows up if you were the one holding the pager. An abstract that opens with a route leak taking down peering for forty minutes at two in the morning, caused by a filter everyone had trusted for six years, gets read differently than one that opens with a category name. The number doesn't need to be dramatic. It just needs to be specific enough that a tired reviewer believes you were in the room when it happened.

A few things I'd tell someone submitting for the first time, from the reading side of this:

• Lead with the incident, not the topic. The topic can be your second sentence.
• Say what went wrong before you say what you fixed. Reviewers trust postmortems more than highlight reels.
• Cut anything that would still be true if you swapped in a random competitor's network. If a sentence doesn't need your specific experience to be written, it isn't earning its place.
• Describe the takeaway in concrete terms. "You'll leave knowing which BGP communities mattered for this failure mode" beats "attendees will gain valuable insights."

I don't mean any of this as advice on how to polish an abstract until it sounds important. The best ones do the opposite: they stop trying to sound impressive and just describe what happened, in order, with the boring parts left in. A reviewer on their fortieth submission of the night isn't hunting for eloquence. They're checking for proof that you were there when the thing broke. That proof is usually one honest, specific sentence. Polish rarely counts for much next to that.