Rehearse as much as you can, with your slides and without (e.g. in front of a mirror - it really helps to examine and refine your own nonverbal cues). It will help you manage time, leave time for Q&A/commentary, and just create a better overall impression of your authority on the subject.
Be genuine. Anecdotes and personalization are endearing and add retention that reciting stats and other dry facts alone cannot. Even better if you're not afraid to go against the "grain"/conventional wisdom.
RELAX. Even if everything possible goes wrong, you're presenting because it's something you know (at least you should).
As an example of points 2 and 3: I gave a talk last October that was completely abysmal in all technical/preparation aspects, but was so well received that I was asked about it all night in the post-con pub crawl.
I went through a chaotic series of events (including a breakup, this will be relevant below) leading up to my talk in a different city I didn't get to drive to until the day of my talk. To make matters worse, my slides (on my desktop) didn't sync up to Google Drive, so I had to rewrite them from scratch on a basic black-on-white slide deck from my phone at a rest stop and on my laptop right after I came screeching into the conf just an hour before my talk. I missed two major points on my deck (remembered one during the talk, discussed the last one during the pub crawl), and even had a typo in my company name. To make matters worserer, there were lots of sound issues with the mic.
Aside from one guy closing his laptop and leaving after I said, "If you came for code samples, you're in the wrong talk; this is an architectural/philosophical discussion," the audience responded well and even discussed it with others who didn't attend but wanted to know more over drinks afterward.
My talk was on simplifying software architecture by avoiding/removing unnecessary complications, and not developing tunnel vision based on a given language/framework/library. While universal in principles, it was presented to a Drupal-centric audience (I haven't used it at all in months, but it put a ton of food on my table in the decade leading up to the talk). I went so far as telling a room of Drupal developers "You may not even need Drupal" (in a conf sponsored by the three largest Drupal hosts - the biggest one also the biggest contributor to the Drupal core and module ecosystem and co-founded by the creator of Drupal - and most of the largest Drupal agencies in Texas), and began the talk explaining that my philosophy had largely been informed by my experience in what, despite ending earlier that week, had been by far the easiest relationship I'd ever had (we handled it like adults and we're still friends).
I also made sure my title and synopsis had impact and some humor to grab attention:
STOP BUILDING MODULES!!! 'How Drupal can coexist in a microservices world' or 'How to progressively decouple your backend'
OK, so the title starts off a little extreme. Don't scrap your module development just yet (if ever). At the same time, think outside the Drop, and not just on the front end.
Drupal's oft-overlooked killer feature, and how it can work wonders for getting a startup to MVP or beyond (hint: it has little or nothing to do with content or even Views)
Don't reinvent the wheel
But what if you need wings and wheels? - Or maybe some other vehicular metaphor?
Who's the gatekeeper? (sorry, needed another metaphor)
Is Drupal appropriate for this project at all? {"everyone else at the Drupal event" unsettled Tom meme}
Mike is a software architect and has been a Drupal developer for a decade, a JavaScript developer for nearly two, with prior backgrounds in IT and design. He founded Dominant Design & Development in 2018, and co-founded idealFunction() in 2019.
He has worked with clients ranging from small businesses and tiny, cash-strapped startups to global nonprofits, corporations, and state and federal government. In addition to building its own SaaS products, idealFunction() helps entrepreneurs who have great product ideas but lack the technical chops or staff to refine and/or architect/develop them.
I really appreciate the time you took to write such an elaborate answer. Delivering an awesome talk even when all else is going wrong, is definitely something I'm aiming for and I hope I reach this benchmark someday soon.
Thank you so much for sharing your experience!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
As an example of points 2 and 3: I gave a talk last October that was completely abysmal in all technical/preparation aspects, but was so well received that I was asked about it all night in the post-con pub crawl.
I went through a chaotic series of events (including a breakup, this will be relevant below) leading up to my talk in a different city I didn't get to drive to until the day of my talk. To make matters worse, my slides (on my desktop) didn't sync up to Google Drive, so I had to rewrite them from scratch on a basic black-on-white slide deck from my phone at a rest stop and on my laptop right after I came screeching into the conf just an hour before my talk. I missed two major points on my deck (remembered one during the talk, discussed the last one during the pub crawl), and even had a typo in my company name. To make matters worserer, there were lots of sound issues with the mic.
Aside from one guy closing his laptop and leaving after I said, "If you came for code samples, you're in the wrong talk; this is an architectural/philosophical discussion," the audience responded well and even discussed it with others who didn't attend but wanted to know more over drinks afterward.
My talk was on simplifying software architecture by avoiding/removing unnecessary complications, and not developing tunnel vision based on a given language/framework/library. While universal in principles, it was presented to a Drupal-centric audience (I haven't used it at all in months, but it put a ton of food on my table in the decade leading up to the talk). I went so far as telling a room of Drupal developers "You may not even need Drupal" (in a conf sponsored by the three largest Drupal hosts - the biggest one also the biggest contributor to the Drupal core and module ecosystem and co-founded by the creator of Drupal - and most of the largest Drupal agencies in Texas), and began the talk explaining that my philosophy had largely been informed by my experience in what, despite ending earlier that week, had been by far the easiest relationship I'd ever had (we handled it like adults and we're still friends).
I also made sure my title and synopsis had impact and some humor to grab attention:
STOP BUILDING MODULES!!! 'How Drupal can coexist in a microservices world' or 'How to progressively decouple your backend'
OK, so the title starts off a little extreme. Don't scrap your module development just yet (if ever). At the same time, think outside the Drop, and not just on the front end.
Inspired by personal experience, a vision of a way forward for Drupal, and this recent article: about.gitlab.com/2019/06/17/strate...
Mike is a software architect and has been a Drupal developer for a decade, a JavaScript developer for nearly two, with prior backgrounds in IT and design. He founded Dominant Design & Development in 2018, and co-founded idealFunction() in 2019.
He has worked with clients ranging from small businesses and tiny, cash-strapped startups to global nonprofits, corporations, and state and federal government. In addition to building its own SaaS products, idealFunction() helps entrepreneurs who have great product ideas but lack the technical chops or staff to refine and/or architect/develop them.
I really appreciate the time you took to write such an elaborate answer. Delivering an awesome talk even when all else is going wrong, is definitely something I'm aiming for and I hope I reach this benchmark someday soon.
Thank you so much for sharing your experience!