3. Why do you want to present
at all?
What’s your objective?
What will people learn
from your talk?
Most people fail at the first hurdle.
4. First steps: prepare, research, plan
Be clear about your reason for wanting to present
Research what the target conference is for
Research why people go to the target conference
Research what the target audience typically wants
to hear
Find out how long you would have to present
Now decide on the style
of talk you want to give
5. Style of talk
“A vs B”
“Case Study”
“Emerging Technology”
“New Version Update”
“Introspection”
“Unrelated but Cool”
“Just for Fun”
6. “A vs B”
“Case Study”
“Emerging Technology”
“New Version Update”
“Introspection”
“Unrelated but Cool”
“Just for Fun”
I had to make a decision between using A vs B : analysis (pros & cons)
Something awesome that will inspire and remind us why we are
developers
My company did X with Y and here is how it went. Lessons learnt, traps to
avoid, insight
Here is why the latest process is good for your business and your
career (agile, develops, extreme programming, test driven
development ....
Introduction to Z technology and how its going to change your life /
development practises / technology choices
Overview / deep dive / hands-on of latest functionality in product
Let me show you how you could use your skills with new tech (that
maybe you can't afford to buy) to do something different : alexa,
robots, VR, AR, AI ...
7. Understand the submission requirements
Title and abstract
Target track(s)
Elevator pitch (300 chars)
Talk outline (reviewed by selection
committee only)
Photo and biography
Videos of previous public speaking
Your ‘talk’ is all of these
things put together
8. Your submission should be entertaining, inspirational,
informative, insightful, authentic and honest …
9. And your supporting bio, blogs etc should clearly
show you are the best person for the talk
13. Abstracts: Do’s
Avoid waffle,
Make it clear what your audience will take away
from your talk
Make sure there's a clear take away for the
audience "....By the end of this session developers
will be able to immediately start with the
DeepLearning4J library and start their ML journey..."
Triple-check spelling and grammar, get a native
English speaker to proof-read for you if English
isn't your first language
Make the title really catchy/dramatic, add loads of
technical details in the For The Panel section
Show awareness of topic but avoid overuse of buzzwords
Demonstrate clear learning outcomes or takeaways
Use numbers, if possible –
Instead of saying “Tips for Java
EE 7”, use “50 Tips in 50 Minutes
for Java EE 7
14. WIIFM (What’s In It For Me) – Prepare an abstract
that will allow the attendees to connect with you.
Is this something that they may care about?
Something that they face in their daily life? Think if
you were an attendee, would you be interested in
attending this session by reading the abstract?
Think WIIFM from attendee’s perspective.
Use all the characters – Conferences have
different limit of characters to pitch your abstract.
The reviewers may not know you or your product at
all and you get N characters to pitch your idea.
Make sure to use all of them, to the last Nth
character.
Submit to the right track
Use tags
Use positive active words –
learn, understand, see, hear
Run the title and abstract by colleagues
to check - is it attention-grabbing? does it
sound interesting? is it something people
would learn from?
Abstracts: Do’s
15. Abstracts: Don’t’s
Try to get attention by using sexual references or
inappropriate/ offensive language
Use insulting or rude language towards any group of
people.
mix technical pitch for the session with pitch for the
presenter. There are separate boxes for these
separate things.
use the "for the committee box" for the technical or
personal pitch, it's there for other stuff.
Try and pack in too much content,
sometimes less _is_ more
Use the words Rock Star, Ninja, Pirate, Elite or anything
else like that unless it's satire
ever submit a product pitch, or
make something sound like a
product or service pitch
16. Live code something too complicated. The more you will have to code, the
more you'll have to remember, the more attendees will have to read (and not
pay attention to your words anymore) and obviously the more bugs you
can potentially introduce: Try to keep the code as simple as possible
according to your topic, and in case you can't, try to break it in small and
easier steps so that you can exchange with your audience between each.
Abstracts: Don’t’s
17. Your abstract gets read by the selectors AND the
conference audience. It is your promise to the audience