How to Write Good Proposals: Part II

DZone 's Guide to

How to Write Good Proposals: Part II

In Part II of this series, Ted Neward talks about the writing itself. Be sure to look out for Part III, coming soon!

· Agile Zone ·
Free Resource

Be sure to check out Part I where we cover the initial processes that come before the writing.

Writing a Good Proposal

Writing a good proposal is a relatively simple premise: You are describing what you are going to talk about. It really shouldn’t be all that hard, right?

Except… well… Here’s a little secret that most speakers don’t want anybody else to know: Much of the time, we haven’t written the talk when we write the proposal. Thus, in some cases, we’re trying to describe what the talk is going to say when we don’t really know yet what the talk is going to say.

That would seem like a drawback. Except it’s not, really.

Fundamentally, the point of the abstract is not to go into gory detail about the talk. In many cases, the more detail provided in the abstract, the less the attendee is going to get out of it. (And, spoiler alert, most attendees don’t read abstracts, anyway, they go for the title; more on that in a bit.)

Thus, writing a good abstract doesn’t require the talk to be written yet. You should have a good idea of what you want to say, granted, so having at least some kind of outline or rough “topic sentence” for the talk is always a good idea.

(Sidebar: At DevelopMentor, where I first learned how to give great technical presentations, we had a concept called the “two sentence story”: every class or class module had to be something you could distill down into two sentences. If you couldn’t do that, then it was a pretty clear flag that you didn’t really know what it was about. This is a good place to start.)

For me, most proposals have three components to them:


Don’t go for catchy, don’t go for cute, and don’t go for something that is culturally-bound. Years ago, I suggested the title of “Functional Eye for the Object Guy” to one of my peers, and they ran with it. It wasn’t until I was at a conference (where that peer was using that title for a talk given there) and I overheard some attendees remarking, “That is a weird title” that I realized, we were at a show in Europe, and “Queer Eye for the Straight Guy” simply hadn’t been “a thing” over there. All of the cultural reference weight that was supposed to go along with the title—the idea that here was a bunch of experts familiar with a number of topics (fashion, cooking, wine, etc) that “mainstream” people (straight guys) wouldn’t understand but that these experts (the experts were predominantly gay, although some were actually straight) could act as guides…. All of that context was lost the moment the talk moved outside of US borders.

Boring titles seem so boring. But, in many cases, they help convey to the audience what the talk is about far better than catchy titles do.

Personally, I have been using the same title structure for all of my talks (with the exception of my keynotes) for the last ten years, and frankly, while it’s earned me some mockery from my peers, I’m quite willing to accept the mockery. “The Busy Developer’s Guide to …” is now a core part of my speaking brand, and it’s a better-than-even chance that if you see that title somewhere on the conference schedule, it’s me giving the talk.

And that’s what branding is for, right?

More to the point, the title structure is pretty self-evident, and pretty intuitive:

  • “Busy”: What developer isn’t busy? More to the point, the idea here is that attendees don’t have a ton of time, and this talk recognizes that, and is going to distill the idea down so that you’re not wasting your time.
  • “Developer’s”: This is a talk for developers. (I also have a few “Architect’s” and “Manager’s” talks.) If this talk is for a specific type of developer, then I will throw that in as an adjective here. So a talk on MongoDB that’s geared for people who run on the JVM will be “Java Developers” or “JVM Developers”, as opposed to those running on the CLR.
  • “Guide”: It’s not comprehensive, it’s a guide. (Again, I have a few talks labeled “Intro”, but frankly most attendees hate going to “introductory” or “basics” talks, so I tend to avoid those terms.)
  • “to {topic}”: The most self-explanatory part of the whole thing: I’m going to talk about {topic}.

You don’t need to use this same kind of structure, but the talk titles should be straightforward, to the point, and describe in as few words as possible what this talk is going to cover. In my case, I also wanted to provide a hint as to the audience that I was expecting, to allow potential attendees to opt-out if they weren’t my target audience.


Let’s be clear: a talk has to have a purpose. There needs to be some kind of problem that the developer is having that your talk can solve. Otherwise, why would they come to your talk?

This first part of the abstract is what I call the “pain”. Sometimes that pain is immediate and obvious: how to debug microservices running the Heroku cloud, how to performance-monitor databases running in SQL Server, how to determine if your system will scale to a hundred-thousand requests a day, whatever. The point is, some kind of problem is plaguing the developer.

Or the problem is more abstract: the developer doesn’t know about some particular tool or language, and they may or may not realize that they don’t know it. For a lot of developers, things like agile development processes fit into this category a decade ago, and DevOps tools and practices similarly up until a few years ago. Today, it’s probably things like machine learning, data visualizations and/or artificial intelligence.

Point is, the developer has a problem, and your talk is going to talk about that problem. Make the pain apparent. Make it clear. Be obvious about it.

For example, in the abstract for my “Busy Developer’s Guide to Go” (about the programming language, not the board game), I write:

In the mid-2010’s, Google announced a new programming language, Go, and the collective reaction of most of the programming world was a giant yawn. Yet another language, and even though it came from some serious industry veterans–Brian Kernighan and Rob Pike–it didn’t really seem to be bringing all that much that was new or interesting to the table. By 2015, that tune had changed. Go is now one of the “up-and-comers” in the programming language world, and it owes its success to a variety of factors.

The pain here is pretty obvious: Go has some interesting things to it, as evidenced by the fact that there’s a lot of people who are talking about it and using it and aren’t you concerned if you’re not one of them? What do they know? What’s so interesting there that suddenly everybody wants some?


And the point of the pain is simple: If an attendee, reading this abstract, doesn’t feel that pain (perhaps because they’ve already looked into Go, or because they are simply somebody who doesn’t care about what other programming languages there are in the world until their boss tells them to go learn it), then they can opt-out of the talk quickly and move on to the next abstract in the list.

To the organizers, it serves the same purpose.

But a life of only pain is only of interest to existentialist philosophers, nihilists, and a certain percentage of teenagers with too much time and money on their hands. Pain is nothing without….


Dude, you have to make the pain go away. That’s the promise of your talk, that if the attendee who has the pain that your proposal is describing comes to your talk, you can make the pain go away. That’s the reward they get in return for sacrificing an hour (or half-hour, or 90 minutes, or whatever) of their lives to sit in an uncomfortable chair and listen to you.

Again, from the same Go presentation abstract:

In this presentation, we’re going to take a hard look at the language, go over what it has (and what it lacks!), what makes it interesting, and get comfortable with some of the syntax basics, as a “first steps” towards building non-trivial Go programs in the future. It’s probably not the last programming language you’ll ever learn, but it is definitely on of the few that you should learn.

In other words, this talk won’t make you a Go guru, but it will get you on the road to understanding what makes Go tick. You’ll have enough syntax and semantics under your belt to decide what to do next.

(Yeah, it’s a basics talk, an introduction, without using the words “intro” or “basics” in the title.)


By the way, the talk proposal is called an “abstract” for a reason: It is not intended to be a point-by-point, blow-by-blow outline of your talk. It’s intended to be high-level and succinct. Again, look at the Go presentation abstract. I don’t mention exactly what features of Go we’re going to cover, and I don’t say exactly what the attendee will have coing out of it, except in pretty high-level terms.

The reason for this is simple:

  • The talk is not yet written. That’s the obvious reason, but there are a few other reasons less obvious.
  • Your “story arc” through the subject matter will probably change once or twice. As you give the talk and/or as you get to know the material better, you’ll start to realize that topic “F” is just not all that important, while topic “G” is something that really should be brought to their attention.
  • Your audience is different than what you thought they’d be when you wrote the abstract. Yeah, the organizers assured you that this would be all senior-level developers, but suddenly you get to the event, and lo and behold, it’s mostly made up of total newbie programmers. Time to make some adjustments!
  • Anything you say in the abstract, your audience will hold you to, even if you’re trying to do right by them. If your abstract specifically mentions “F”, then you’re obligated to talk about it. If you don’t mention “F” or “G” by name, then you have a degree of control over the talk all the way up until you give it.

Again, in the Go presentation abstract, I happen to think that Goroutines are a significant part of the reason why Go is an interesting part of the language. But if I find out that the audience is not really all that familiar with concurrent programming concepts, trying to show them goroutines is probably going to create more confusion than clarity. So I can quickly elide those slides out of the talk if I need or want to, without violating the contract that the abstract is setting up between myself and the audience.

Because at the end of the day, if your proposal is accepted, that same abstract is what they’re going to publish on the website and in the conference program, and that becomes your contract with the audience: in exchange for your time, attendee, I will make this pain go away.

Writing a good abstract/proposal is hard. Which brings me to my next tip; be sure to check it out in Part III!

conference, conference speaker, presentation, writing

Published at DZone with permission of Ted Neward , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}