Lack of female speakers at technology conferences. A common topic of discussion, particularly among women who want to see more of their peers take the stage. I think that a first step to improving the current state would be to have more women responding to Call for Proposals (CFP) issued by conference organizers. Writing a proposal can feel like a prohibitive hurdle to those who are new to speaking at conferences. A proposal does require some effort to compose, while offering no guarantee that the effort will be rewarded with a speaking engagement. Having written a few proposals, I’ve come to realize that there is a common expectation in what they should contain, and that writing a proposal is not nearly as onerous as I originally imagined.
The purpose of a proposal is to pitch an idea to the organizers of the conference. You do not need to have an existing presentation prepared before proposing. Instead you imagine how you might communicate your experiences or knowledge to others, then describe this vision.
In my experience, a conference proposal usually has four key parts, which are:
● Format
● Title
● Abstract
● Learning Objectives
How I tackle these when writing a proposal differs from how they are requested when submitting a proposal. When I write a proposal I begin with the abstract, which might also be referred to as the presentation description. A simple abstract has two paragraphs, where the first states some problem or opportunity then the second describes what the presenter will talk about. With this structure in mind, I roughly note down my ideas, often in bullet point format or sentence fragments dumped into a document.
From this skeleton, I work to create polished prose. An abstract is a marketing tool, so I aim to tell a compelling story that will make people want to attend my talk. I try to keep my language simple, easy to understand and persuasive.
Usually I only know the format that I want to adopt once I have completed the abstract. The available formats will differ between conferences, but may include a short or long presentation, half or full day tutorials, or hands on workshops. Consider how much you want to communicate to your audience, and which format the material is best suited to. Most new presenters will stick to a familiar method of delivery and choose to present from a set of slides.
Next I consider the learning objectives, which may also be described as the learning outcomes or key takeaways. This is generally the point where I determine whether a proposal has merit for submission. I like to aim for five succinct bullet points that explain what I feel people may learn from my session, where each begins with a different descriptive word. Bloom’s Taxonomy is a really helpful reference for giving me the correct language to express where I imagine people will find value.
Once my idea is defined with an abstract, format and learning objectives, then I attempt to label it with a title. This is my least favorite part about writing a proposal; I find it quite difficult to summarize my message into a catchy one-liner.
When writing a proposal, I place a one hour time limit on this entire process. In my experience this is enough time to determine whether I have an idea with merit, then write a proposal that describes it to others. Remember that a minimum output is two paragraphs and five bullet points, which is not much at all!
Before submitting a proposal to organizers, I seek feedback from my peers. I am lucky to be part of a strong community of testers in Wellington who are happy to complete proposal reviews. If you can’t think of someone to ask to review your proposal, there are people with an interest in improving gender diversity in technology that will be willing to assist you:
● Speak Easy – a new initiative from Anne-Marie Charrett and Fiona Charles.
● A Line at the Ladies Room – a mentoring programme co-ordinated by Lorinda Brandon.
Proposal feedback will usually include phrasing, spelling and grammar; it’s amazing how many errors slip through the gap between what you meant and what you actually said. The reviewer should also highlight any areas of the proposal that are unclear. If your reviewer needs to ask a lot of questions to understand your proposal, then attempt to include your answers to their questions in the proposal itself. This will make it much clearer when you submit to the organizers.
Updating the proposal after feedback and submitting it can take as long as writing the proposal itself. Some conferences request a proposal via email while others enforce a standard submission format through an online form. Altogether, I usually spend about two hours pulling a proposal together.
You may be wondering, is this worth it if I don’t get accepted to a conference?
Even though my proposals are not always selected, I find the process of writing them to be valuable. A call for proposals is a worthy excuse to spend a relatively short amount of time reflecting on my work and considering which experiences and ideas I could share with others. Though I find it challenging to articulate what I want to present, writing a proposal prepares me for a number of other conversations. Having thought about how to frame my work to others, I can eloquently explain myself in meetings with senior stakeholders, client managers, and my own boss.
A Call for Proposals is an opportunity to have your voice heard by speaking at a conference. It is also a platform through which you can find your voice by practicing writing proposals. The review process may also help you create new connections with testers in the wider community, or strengthen relationships in your existing networks.
I believe the benefits of responding to a call for proposals far outweigh the investment. I hope that many of you will consider responding to the next call for proposals that interests you.
About the Author
Katrina is an active contributor to the international software testing community. She is the Editor of Testing Trapeze magazine, a co-founder and organiser of WeTest Workshops, an international speaker, frequent blogger and tweeter – @katrina_tester.
Katrina works for Assurity in Wellington, New Zealand. She is the Practice Lead for Lean Testing, the lead trainer for the Agile Testing course, and the content owner of the Assurity graduate programme.