Conference Speaking for Everyone – Submitting Chapter (FREE)

What even is this?

This is a full chapter from my started-but-never-finished book called Conference Speaking for Everyone. I’m posting this finished single chapter that’s been sitting on my laptop for nearly a year to a) Get some feedback and hopefully some impetus to finish the book, and b) Put what I hope is some useful information into the hands of the people who need it. So enjoy the entire full chapter (all 3000+ words of it), and if you like it and would like to see the finished book… MAKE SURE TO PESTER ME ON TWITTER!

— Gary



Call For Papers


So, How Do People Get Selected to Speak at Events Anyway?

In my experience, there are two ways speakers end up presenting at technical conferences. Either the conference organisers ask you directly if you’ll speak at their event, or there is a Call for Papers (CFP). As a new speaker, it’s unlikely a conference is going to ask you to speak directly, so you’ll likely get into the habit of looking out for Calls for Papers.

A CFP is when a conference invites potential speakers to submit the information on the sessions they’re interested in delivering. This information grouped together is often called an abstract, and once the conference has enough abstracts, or a set time has passed, they look through the abstracts and pick the talks they’d like at the event.

It can seem intimidating for the inexperienced; it used to scare the life out of me when I first started submitting to CFPs. Luckily, there are a few robust strategies we can use to stack the selection process in your favour.

What on Earth Am I Going to Speak About?

Before we discuss how to tackle our first CFP, perhaps we should think about what we would talk about. It’s easy to fall into the trap of thinking you have nothing exciting to say or aren’t knowledgeable enough to speak on a technical topic. Let me let you in on a secret; some of the best talks I’ve seen have been personal stories about how people solved problems, mistakes and all.

Think of the last big technical challenge you solved. It doesn’t need to be work-related; it could be a side project or an open source project. I’m willing to bet you didn’t solve it the first time. How you eventually got to the correct solution (for you) is an interesting story for many people. People love to hear how we failed just as much as how we succeeded, and the most intriguing stories I’ve listened to have been stories about the progression through the failed solutions until the problem is finally solved.

Have you used an exciting new tool or development concept recently? These can be ideal ideas to base a talk around. While you’ll see a lot of experts giving deep-dive style talks on subjects they are very knowledgeable about, there’s also room on a schedule for a gentle introduction to a tool or process a portion of the audience may have never used or even heard of.

During my developer career, I’ve learned about some handy tools and how they fit into my work, from gentle introductions to the topic. Things like Redis, Graphite, and Gherkin have all been introduced to me through very light conference talks, and I’ve adopted them all into commercial projects at some point!


There’s an essential point to make which also answers a commonly asked question—”Do I need to have written the talk before I write the abstract?”

No! At no point have I ever written even the outline of a talk before writing the abstract. With that said, I’ve always got an excellent idea of what the talk will contain before I write the abstract, and I know other speakers who will have an outline or mindmap before they even consider the abstract.

I curate ideas in my head for a time before I feel they are formed enough to make an abstract. Some talks will make it to abstract form a few weeks after thinking of them; others will take years before they’re developed enough to submit. Your mileage may vary (as they say).

Occasionally, I submit talks before I’ve learned all the information needed. This may seem crazy, but there are several technologies or tools that I want to know more information about; my to-do list is full of them. There’s nothing like having a talk about the OWASP Top 10 accepted to force you to do the research and learn all about that thing you never got around to learning!

I wouldn’t recommend submitting a “Deep Dive Into…” type talk without knowing the subject matter in depth, but I certainly think you can learn enough about a topic to submit “An Introduction To…” with only enough knowledge to understand the basics.

Talk Length

Every conference is different, but there are some slot types which persist across many of the events I’ve attended. Let’s take a look at the most common ones.

Lightning Talks

Typically between 10 and 20 minutes, lightning talks are a fantastic way to dip your toes into speaking at events because they are usually significantly shorter than the full scheduled slot. Lightning talks can cover a single technology or thought quickly and lightly, or can be a brief look at a tool or concept. Either way, having only 20 minutes of content to write can be less intimidating than writing a full talk—particularly first time out.

I’ve seen some delightful lightning talks that have amused, entertained, and informed; some of my favourites have not even been on technical subjects. Organisers are more likely to “waste” a slot on their schedule on a non-technical matter when it’s a lightning talk just because there are more of those spaces to go around.

Regular Slots

These are the bread and butter of most events and are usually between 45 minutes and an hour. This is an excellent length talk as it allows you to deliver content with an interesting narrative (more on this later), and work to a fulfilling conclusion. At most events I’ve attended, the talk slot length also includes questions, so it’s worth planning on finishing 5 or 10 minutes earlier depending on the number of questions you anticipate and are happy to answer.


Longer teaching slots are not really talks. Usually three, six, or even eight or more hours are for training rather than speaking engagements, and won’t be covered any further in this book.


Keynotes are sometimes picked from submissions but may be negotiated directly. These talks are typically the bookends of the conference. Usually, they are the only talk during that timeframe (in multi-track conferences) and are generally by people of note in (or out of) the community and contain a powerful message. Keynote slots are usually given to experienced speakers and aren’t something you should worry about at the start of your speaking career.

Writing Abstracts

I use a tried and tested formula when I’m writing my abstract. It’s crucial that your abstract conveys a certain amount of information for the eventual audience, but I always write my summary with the organisers in mind. I’m still trying to think of how I can convince the organisers to pick my talk when writing my talk abstracts. If the event organisers do not feel invested, the talk will never be delivered.

We’ll cover writing a great abstract soon, but first, we need to mention something equally as important.

Talk Titles

Your talk’s title is arguably the most essential piece of the puzzle. A good title can help an average abstract, but a great title can be intriguing enough to get the talk selected and entice more people to attend. It’s also worth mentioning that at most events the schedule the attendees pick talks from only show the title. People often make snap judgements based on the title alone and not the abstract. In my opinion, the title should clearly convey the topic of the talk with bonus points for clever wordplay, but I’ve seen many people have success with weird and wonderful titles that may have nothing to do with the topic.

My advice when beginning your speaking career would be to make the title clear and evident without trying to be too clever. You’ll have room to grow in this department as you get more experience. I’ve never seen a talk rejected because the title was too obvious.

Good Titles

  • Climbing the Abstract Syntax Tree

Explains we’ll be looking at something called the abstract syntax tree with a clever little pun.

  • Learning Machine Learning

Tells you exactly what you’re going to learn in the session without wasting any words.

  • Step Into Debugging

We’re going to learn about debugging and “Step Into” infers it will be an introduction, as well as being a term used in the debugging process.

  • DDD for Beginners

Almost the perfect title for me, we’re covering DDD, and it’s for people with no prior experience. But, would a beginner audience know DDD means domain-driven design?

Not-So-Good Titles

  • Lean, Extreme, and Bulletproof

What is this talk even about? It doesn’t tell us anything about what will be covered. It may be smart when considering the abstract, but don’t forget many people will never read your abstract.

  • The UI is application

This makes no sense. It makes me wonder if your abstract will make sense. Remember, organisers will be reading hundreds of abstracts and sometimes will not even read your synopsis if your title is not even grammatically correct.

  • Don’t fix bugs, prevent them and harden your code!

While this may seem like great advice, as a title, it doesn’t work for me. If I were going to attend this talk, I’d want to know what skills or tools were going to be covered to ensure I wasn’t learning about something I already use.


It’s too long, and it’s all in capitals. While you may be tempted to scream your title from the rooftops because you’re proud of your idea, it doesn’t help. Try and keep your titles short and catchy. The double space between “fewer” and “websites” also doesn’t help either.

The Abstract

“Write for the organisers” is such good advice that it’s worth repeating. In my mind, the abstract is something I’m using to try and get the organisers to pick my talk, while the title is something I’m using to try and get the attendees to attend the sessio. With that said, there are three key pieces of information I like to include to try and get my talk selected.

I’ve stolen and adapted these ideas from the tweets and ideas of @grmpyprogrammer so my thanks go out to Chris Hartjes.

The Problem

You’ll likely be trying to teach the attendees about something, but before I want to learn about something, I need to know what problem it will solve for me. What’s hard in a developer’s life that you can make easier for them?

The Solution

Now that we’ve outlined what’s hard, here we can explain how we can make it easier. Talk about the technologies you’ll introduce or the skills you’ll hone. Make it clear that we’ll solve the problem outlined above using the tools or skills we’re informing about here.

While the problem and the solution should be provided, sometimes it’s possible to combine them into one paragraph or even one sentence.

The Take-Away

I like to finish by making it clear what anyone attending my talk will leave the session with. Often I’ll use phrases like “You’ll learn about $x,” or, “You’ll leave having a solid grounding of $y.” I like to set expectations in this section, so anyone who attends (who’s read the abstract) will have no illusions about who the talk is targetted towards, and what they’ll take away.


Here are some examples of my abstracts that follow this formula. I’m in no way saying these are great abstracts. These examples are from my own abstracts and show the formula at work, ensuring my submissions are at least getting read and understood by the people selecting the talks.

Getting started with Zend Framework 2 is relatively easy. But once you have a basic CRUD application up and running where do you go from there? Knowing how you should build your application with maintainability and scalability in mind can be very daunting. But there are some hard and fast rules you can use to help to factor your application into something functional, maintainable, and performant.

In this tutorial, we will take a pre-built ZF2 application straight from GitHub, and apply some simple(ish) rules to make a basic ZF2 application run in a more modern way. Say goodbye to getServiceLocator in your controllers, and say hello to the full power of dependency injection, event listeners, and framework plugins.

This is a good example of outlining the problem and solution, then finishing with the takeaways.

Dependency injection is everywhere, and dependency injection containers and programmatic service locators are very popular right now. Zend Framework’s Service Manager is one of the cornerstones of the framework, but using the right feature at the right time can be difficult. Join us as we cover exactly how and when you can use the Service Manager, from the simplest “invokables,” through “factories” and “abstract factories,” all the way to “initializers”
and “delegators.”

Here we combine the solution with the takeaways, but both points are covered.

At some point, in any successful web application’s life, you’re going to need to remove things from the request and response cycle to improve performance. From sending out emails to publishing information on social media channels, we’re finding ourselves trying to shoehorn more and more processes into the traditional HTTP request/response.

This talk will help explain how you can use ZF\Console based command line PHP to control workers that take and process jobs from a queue, helping to make sure each and every one of your responses is lightning fast. Using popular technologies like Redis and Beanstalkd to manage and monitor worker processes is a skill every developer will benefit from sooner rather than later.

Again we outline the problem, then give the solution and takeaways in the second paragraph.

While I find this system works very well for me, and I’d encourage you to use this in your early submissions, it’s likely that with experience you’ll find your style. As my own presentations evolve I sometimes see myself not outlining the solution because I want the big reveal to be in the talk itself, but this format has worked well for me and it’s something I end up going back to—particularly when I want to talk about a technology or tool.

Other Information

As well as the title and abstract, organisers usually ask for more information to judge your submission. Often organisers will provide a separate field to allow you to pitch your talk (and yourself) to them without the public ever seeing the information. I suggest that you use this field to your advantage to give organisers confidence that you’ll deliver a fantastic talk. Have you presented this talk before at a conference or user group (we’ll talk more about these later)? Make sure to let them know. You can also give some information about why you should be selected, and this is particularly useful if you’re a new speaker. Being honest can help, saying you’re new but you understand what’s involved and you’re confident you can deliver an exciting talk will help organisers to take a chance on you for your first few presentations.

If you’re submitting on a given technology, it can help to explain why you’re qualified to speak on that topic. Do you contribute to an open source project that you’re submitting on? Make sure to mention it as these qualifiers can help tip the balance in your favour if there are many submissions on a similar topic. Don’t be afraid to sing your own praises. Not many people are comfortable with self-promotion, but an honest reflection of your incredible talents can help you get selected.

Don’t be tempted to leave the “other information” box empty, particularly if you’ve never spoken before. I always put something in the box, either links to feedback from previous talks I’ve given or if it’s a new talk why I think it’s incredible. You’re given the opportunity to pitch yourself to the organisers — use it!

An Aside on Expenses

Often organisers will ask you if you need help with travel and accommodation costs if your company is interested in sponsoring the event, where you’re travelling from and a myriad of other logistical information. If you need help paying for your travel and accommodation, then don’t be tempted to lie about the fact. You’re doing the organisers a massive favour by agreeing to speak at their event for free (or even at your own cost) so don’t undersell yourself by agreeing to pay your own way. Of course, I can only give my own opinions here the final decision is yours, but think about the time you will spend submitting to the event, writing the talk and slides, practising the presentation and then travelling to the conference and delivering your speech. This can add up to tens and sometimes hundreds of hours of time you won’t be compensated for, so the least the conference can do is to pay for your expenses to present for them.

Most conferences are open and upfront about their policy to reimburse speakers expenses, and I would personally advise to only submit to those with a transparent and fair expenses policy. Some events will try and claim that speaking for them will give you exposure and boost your career, but don’t forget they are charging people to be at an event that couldn’t happen without people like you speaking there.

Personally, as an experienced speaker who is lucky enough to count presenting as part of my job, I do sometimes break my own rules to speak at events while paying for hotel and/or travel myself. But these times are rare, and usually, when the conference has particular morals I agree with such as being free or very low price to encourage people to attend, or have a certain topic I feel is important enough to donate my time and money to present on (such as my talks on mental health). My rules of thumb is I expect a ticket to the event and my travel and hotel covered before I will submit to an event.

It can be tempting to attempt to pay your way to your early acceptances, but I would recommend against it.

Nerves Before Speaking

My good friend and fellow PHPUK keynoter, Jenny Wong posted an interesting post on Stage Fright, in which she explains how she minimises the stagefright before going on stage for a keynote talk. It’s fascinating because as those who know me will attest, I get terrible nervousness before going on stage, particularly with keynote talks and even though I’ve given several of them now.

One of the reasons that I found it so interesting is because Jenny’s experiences differ from mine in some regards, but hold up in others. In particular, I worry about the content of a talk the day before I deliver it, or if it’s a closing keynote then the morning of the session. During my recent closing keynote at PHPUK, I was probably the most worried I’d ever been about the talk and felt underprepared, even though I had put my usual 40-or-so hours of prep time and practice into creating the talk.

Interestingly, PHPUK will be the first time I’ve given this talk, and I haven’t had it seen by anyone — today’s audience will be the first. The concept has been vetted heavily by friends who I trust, so I’m happy the idea is solid. I love Jenny’s advice about setting a run-through date with friends to force you to create the content ahead of time. This has rarely been a problem for me which in itself is interesting. I can be as procrastinating as anyone, but I generally get my talk content prepared well ahead of time as I know what it feels like to be on stage and bomb. My rehearsals will have been in my front room with the TV connected as the projector, delivered to nobody, just to make sure I have the pace and cadence of the talk right. I feel like it’s important to fill any timeslot you’re given, and this kind of practice makes me feel confident I’ll run to time (even if everything else is a disaster).

The talk was about things I wish I’d known earlier in my developer career and was (loosely) linked with gaming, and my central panic was that the advice I’m giving was too obvious, too fundamental to warrant being told in a keynote slot. Information like “learn to say no” has been really important in my career, but when you’ve heard the advice before, then it may seem worthless. I’m a firm believer that everything is obvious when you know it, but how simple can you be without being too simple?

My other massive concern is that the gaming references would alienate parts of the audience and make the talk exclusionary. I try not to make jokes just for people who are “in” on them because that makes the rest of the audience feel left out. For speakers who’ve been around a bit, this can be difficult as anything I say can be construed as an “in joke” by friends who will laugh leaving everyone else confused.

ASIDE: I hate this and try hard to make any jokes that most of the audience will get, but it’s impossible – even a word or two I didn’t think about can cause only my friends to laugh which is terrible. I remember being at talks before I was a speaker baffled at what people were laughing at and feeling completely disconnected from the rest of the room. It’s horrible.

To combat my weird feeling of underpreparedness, I spent the morning of the talk in my room going over my slides and practising out loud. Rehearsing out loud is the super-power that allows me to combat fear, although I don’t want to practise too much as my talk can lose the story-telling spontaneous edge that I enjoy so much. In general I don’t practice the morning of my speech, but in this case, I couldn’t shake the feeling, so I decided to break the rules and do it.

I then did my usual ritual of eating very early, in this case for a 5pm slot I ate at 12pm and then only a small meal, and getting to the venue well in time. Typically I’ll be at the conference all day on the day of my talk, although I’ll find somewhere to hide out when I need to be alone. I also like to try and see any other keynotes that come before mine so I can reference them in my talk, it’s excellent for conference organisers if the themes flow (although as mentioned in the particular case I felt practising was more critical).

Once at the venue, there’s a few things I need to do to combat nerves. I need somewhere to hide. In the case of conferences that have the speaker hotel attached, this isn’t a problem as I can quickly get to my room, but where the hotel is a distance away, it can be a problem. I try and find either the conference organised quiet room (or speaker green room in some cases), or some off-the-beaten-track part of the venue where nobody goes. This is important for me to have some quiet time when I need it, and to run through slides if I want to.

The second thing I find it a toilet. It’s not nice to talk about bowel movements, but very often when I’m nervous, it has a physical impact on my digestive system. Sometimes my bowels feel the need to empty, and quickly. Experience has taught me that having a lavatory close to hand makes me feel more comfortable — again if I’m speaking at the speaker’s hotel then no problem, but if not I try to find an out-of-the-way bathroom that is little used so there won’t be a queue. You can usually find these at any venue by wandering away from the conference or even asking at reception. I’ll stop talking shit now.

Once I get into the hour before the talk, all bets are off. I usually go for a walk with my headphone on, but I won’t listen to music. I tried this after seeing it work very well for people like Anthony Ferrara but it ended up making me feel even more manic and frantic which if you’ve seen me speak isn’t a good thing. I need to calm down not psych up! I will listen to an audiobook or podcasts and go for a reasonably long walk away from the venue, usually about 45 minutes making sure to get back in plenty of time for the tech check. This is personal to me, I feel the exercise and attempt to switch off really help me to keep calm (toilet issues notwithstanding). Before heading to the tech check, it’s one final visit to the toilet and then head off to the room.

ASIDE: People often ask if I have a beer before speaking, and the answer is always no. I’ve never had a drink a talk and I never would because beer tends to make me need to pee, and I can’t think of anything worse than being on stage needing to pee. When you’ve got something working, I think it’s foolish to risk breaking it.

The tech check can be stressful in itself, but having done so many now, I don’t feel so bad. I have a copy of my slides in PDF and Keynote format on a pen drive that doubles as my clicker, so if all else fails I’m covered, but I don’t have as many slide decks as Jenny does. I think Jenny’s advice is golden if you’re just starting out and want to take as much stress as possible out of the day, but for me, I’m comfortable that I can fix any problems in-situ. Experience has taught me that my high-contrast slide theme works well on most projectors as that was a priority when I got it designed. I have the feeling that now I’ve said that this will bite me in the bum sometime soon, but I generally don’t feel nerves about getting my slides and mic setup.

And away we go, baring technical problems there’s not much more you can do. To echo Jenny’s point, nobody in the room wants you to fail, and it’s vital to settle everyone down (including yourself) as quickly as possible. I read a LOT of autobiographies by stand up comedians, and most of them mention that getting the audience relaxed as soon as possible makes life easier for everyone. It’s slightly different in the stand-up world, but the premise is that everyone wants you to do well but they’re nervous you’ll be poor. Reassuring them with a good joke right off the bat settles everyone and stops people being scared for you — they can just enjoy the show. This translates to me trying to be calm and self-confident as soon as I can so the audience knows they are in safe hands and can relax. Usually, this is in the form of either a scripted laugh (a funny picture of myself usually works well) or some observation. In the case of PHPUK I mentioned how much I liked the new round seating setup which seemed to put everyone at ease.

Technical problems can be a nightmare and are usually out of your hands, I don’t know what to say about this as each case is different. I tend to plough on through while making a joke about it if it’s possible but I have no idea what I’d do if the problem meant I couldn’t continue. At PHPUK my slide deck started flickering on the main screen and the comfort monitors (the displays below the stage facing up that show the speaker what’s on the main screen). This was extraordinarily off-putting and pulled me out of the moment a few times. I tried making a joke about it, but even that fell flat which made me feel worse — I have no idea what I could have done differently. In the end, the tech team started pausing my slides on the output and then updating them by hand when I flicked through, which created its own problems as lots of my jokes are timing based on the slide changing. This could have been so much worse, but I have no idea what I could have done differently, it’s something I want to investigate in the upcoming weeks to see if it’s something I can learn and improve on (but I suspect it’s not).

There you have it, a brain dump of my very nervous keynote talk at PHPUK. I hope this helps someone, if you have questions or want to talk about this with me, hit me up on Twitter, I’m always happy to discuss this stuff!

Good luck.

New Opportunities

It’s with equal parts excitement and amazement that I’m making myself available for consulting development or training work from the 1st October 2017.

This does not mean I’m leaving JetBrains!

Luckily for me, I’ve somehow managed to cultivate the unique opportunity to continue with JetBrains as a Developer Advocate for PhpStorm on a part time basis — keeping my role as the face of PhpStorm in the PHP community, speaking at conferences and working on the booth which is a job I love doing.  However, when I’m not attending events, I’m now going to be back working for Roave providing consulting, training and mentoring which is also something I’ve missed and love doing.

Please continue to talk to me on Twitter or at conferences with all your PhpStorm stories, troubles and recommendations as this will very much still be part of my job.

If you need consulting services from someone with now very close to 20 years experience in the technology industry, training on all aspects of PHP but particularly Zend Framework, or are interested in hiring me for short to mid-term contract work then please get in touch, my DMs are open on Twitter @GeeH.

This new development is truly going to give me the best of both worlds as I’ll be even more useful as the voice of the PHP community to the fantastic PhpStorm developers when I’m solving the real-world problems that we (the users of PhpStorm) face on a daily basis.

Open Sourcing Mental Illness Handbooks

One of the most important objectives for the Open Sourcing Mental Illness project is to help people get the support they need for mental health challenges in the workplace. I’m so proud that we’ve had our Mental Health in Tech guidelines available as ebooks from our website for the last six months, but today, we’ve released these handbooks on the Leanpub platform.

Continue reading

Yes, I’m Learning Laravel

I can hear large parts of the internet laughing at the joyous irony. Gary Hockin, the vocal proponent of mocking Laravel, is going to sit down and learn the framework. Not just play around with it, not just read the manual, but build something extensive and meaningful from beginning, to end. For real.

Continue reading