With IBM Think now accepting abstracts from people wishing to share their stories at IBM’s premiere conference, I thought I would share some “tips” & “tricks” on how best to get your story accepted. Following these ideas is not a guarantee that your submission will be accepted but it will certainly increase your chances.
Submitting a well-crafted abstract
Call for papers submission applications typically have char/word counters on several fields where you are expected to share your idea. Don’t waste that valuable space using meaningless words or phrases. Opening an abstract proposal with “Attend this session to …” just used up 22 characters or 4 words! My advice is to be concise, be clear, be clean, be complete – avoid repetition, extraneous jargon, and excessive buzz words. If you use an acronym, spell it out the first time. Don’t leave people playing the “alphabet soup” game trying to figure out what the acronym means. And finally, please please please…. proof read your submission. Bad grammar and misspellings make an abstract hard to read and creates additional editing work for the selection committee. Don’t make rejecting your submission easy for them.
Structuring your abstract submission
Having read many thousands of “Call for Paper” submissions, people often spend too much time writing what I will term as “the fluff”. This “fluff” often leaves the selection committee wondering when the abstract writer will be getting to the point or if there is a point to be made. In my opinion, a well-structured abstract should clearly speak to these 3 questions (at a high level):
- What was the specific problem/challenge you faced?
- How did you solve it?
- What measured “actual” business results did you achieve?
As some examples:
- Increased deployment frequency by 40% or even better, improved release capabilities from 3 months to 1 month
- Increased deployment success by 80%
- Reduce mean time to recovery by 25%
- Reduced testing cycle from 2 months to 1 week
Lastly, the abstract should close with a commitment on the 2 or 3 things you promise to deliver during your session and what the attendee will leave with.
Be prepared to deliver on commitments made in your abstract
Too often, there is disconnect between the submitted abstract and presentation delivered. The result is often a dissatisfied audience leading to poor session rating, poor Speaker rating or both. In some situations, the selection committee may look at past results and previous Speaker ratings to provide insight on who will deliver the best content. My best advice is to follow Stephen Covey’s guidance and “begin with the end in mind”. The details of your abstract are your commitment to the audience. The more concise your abstract is, the easier it is to build the presentation and meet the expectations of the attendees. Happy attendees translate into higher sessions ratings and Speaker ratings.
So, let’s think positive for a moment. You have just received your acceptance notification. Next step is to build that demo asset, workshop curriculum, or presentation. What details will you include in the session material?
My suggestion; quickly build the session outline as a straw-man using bullet points:
- Present the problem and explain the solution – in detail! I have walked out of many sessions where the problem was clearly stated, the Speaker said they fixed it sharing how smart they were but offered no insight on how the problem was resolved. I wanted details!
- Share assets that helped solve the problem. If you write a utility or code snippet that could add value to others, share how you went about developing the utility or share the code with the audience.
- Proudly display your tool chain no matter how simple or complex. In fact, tool chain slides often get the most photos taken. HINT: Be sure to stand close to the screen, be part of the picture and enjoy new found social media fame! For some reason, people love to tweet pictures of others’ tool chains!
- Talk about what worked, what didn’t, experiments performed, and lessons learned. DevOps is about continuously learning, experimentation, and failing safely. Be fearless in sharing. Your experience and expertise can save others time and garner respect for yourself with peers.
- Introduce what you may do next to become even more effective. DevOps is a journey. Having that longer-term vision and sharing that vision with others may spark a new collaborative relationship with someone who has a common interest in finding the solution.
- Present concrete measured (qualified and quantitative) results – tied to the business. DevOps is about delivering results to the business. Sharing your results can help others see the possible and the potential outcomes.
Now that you can envision what the end looks like, work backwards and write the beginning – the abstract you are going to submit.
Remember people are coming to learn from your experiences – you are the teacher. And like Teachers, Speakers have a responsibility to connect with each attendee and work to share a piece of knowledge with everyone in the room. This is your chance to shine and share your expertise with others.
IBM Think 2019 DevOps stories we are looking for but are not limited to…
- Continuous delivery and continuous testing on the mainframe
- Increasing DevOps maturity: Value Stream Management
- Deploying containerized applications with UrbanCode Deploy
- Solving the DevOps “Day two” problem
- Cultural transformation to achieve desired business outcomes
- Deploying hybrid applications in hybrid environments
- Virtualizing containers and other software dependencies for the purpose of testing
And be creative! Session delivery doesn’t need to be “death by slide ware”. I encourage those submitting abstracts to think about how they might get “outside of the box” delivering their story in a new and fresh innovative way.
IBM Think 2019 Call for Papers closes July 16, 2018.
Why wait? Submit your ideas today. And good luck!
Thanks for reading