One of the things I love about test driven development is that you define what something should do, what purpose it should have, before you implement it. So before you write any feature code, you’ve understood what needs to be achieved by a user. This is often a better way of exploring user needs, and the potential grey areas in particular, than detailed written requirements might be.

A couple of years back I took to using this same approach for writing talks. Rather than starting with what I had to say, I started with what questions the audience might have. What do they want to learn? Who will be at this particular conference? What will they likely know? What knowledge, experiences & skills do I have that would best add to what they already know and can do?

This approach has paid off in a multitude of ways. Rather than trying to shoehorn an existing talk into a conference proposal, I think more about what the attendees will want to learn. I genuinely think I deliver better talks as a result. And often big chunks of existing talks I’ve done fit in with that new set of needs; so I think more of the chunks of narrative, tools & info than in terms of whole talks.

It also has the advantage that I can write the proposal long before I ever write the talk. Usually when I submit to a conference, or am discussing with an organiser who’s approached me, I end up with a good summary of what the talk will be and what people will take away at the end. The written description serves as my own test that I refer back to: am I achieving what this description promises? Does this talk answer those questions? Will people walk away with the understanding we committed they would?

And lastly, it’s pushed me to tailor talks much more to the specific conferences and associated audiences. To be braver in proposing talks that will be more useful (but may be less comfortable for me personally).

In short: thinking of conference proposals & talk descriptions like we do tests in TDD helps a speaker focus on what the audience needs to learn, rather than just what one has to say.

This post was inspired by those fine folk who run the Technically Speaking newsletter, which I’d heartily recommend you subscribe to.