Public Speaking Tip 6 : How to handle questions (crowd control)

Handling questions was certainly one of the things I most feared when I started speaking at conferences. If there is one thing you take away from this post, it should be this.

“Never bullshit!”

Here’s a comment Jonathan Lewis left on my first post in this series.

“I think a very important thing to believe before anything else is that it’s perfectly acceptable to say “I don’t know” or “I’m not sure” if someone asks a question you can’t answer immediately.”

It sounds so simple, but it takes a surprising degree of confidence to say this when you are in front of an audience.

Here are some general thoughts on handling questions and basic crowd control.

  • If you are nervous and think questions will throw you off your stride, ask at the start if people can keep their questions until the end.
  • Sometimes you explain a topic in layers, adding information piece-by-piece. If someone in the audience wants to ask a question part way through that process, suggest they wait until you’ve finished that section, in case the upcoming material already answers their question.
  • Always repeat the question back to the audience (I’m crap at remembering to do this). This serves a number of purposes. It’s a good check that you have understood the question. It allows the rest of the audience to hear the question, before you answer it. It gives you time to think. 🙂
  • Educated guesses can be OK, provided they are presented as such. For example, you might say something like, “I don’t know the answer to that, but I know that X and Y, which would make me think the answer is probably Z, but it’s a guess and I would have to test that to be sure.” Of course, it depends on the specific question and the “supporting evidence” for your guess.
  • If someone asks a completely off-topic question, ask them to come and speak to you at the end of the session. I say something like, “That’s a bit beyond the scope of this session. Come and see me at the end and we can talk about it.”
  • If you are struggling to understand a question, say so and ask them to come and speak to you at the end of the session. Don’t waste everyone’s time trying to fathom it out.
  • If a question requires an answer that will take a significant amount of time to put across, say so and ask them to speak to you at the end of the session.
  • Use the questions you are asked to help refine your presentation, so they don’t need to be asked next time.

The reaction to the question and answer slot at the end of a session seems to split the audience into three distinct sections.

  1. The people who hate Q&A. You can see them itching to leave. Some just get up and walk out, which is fine.
  2. The people who love Q&A. They would happily keep you talking for the rest of the day. I’ve actually done sessions where I’ve spent longer answering questions after the session was over, than the session itself. I love speaking to people about this stuff, so I’m happy to do this.
  3. The people who don’t care. They’ll just carry on reading their email until the Q&A is over. 🙂

With that in mind, you have to exercise a little crowd control. I would suggest you draw the session to a close, which allows people to leave, but suggest if anyone wants to stay for a Q&A, that’s fine. When you are in other people’s sessions, check out how they manage questions. You will often pick up new ideas this way.

Check out the rest of the series here.

Cheers

Tim…

Public Speaking Tip 5 : Deliver what you say you will!

Go to a conference and I can guarantee you will hear people complaining about sessions they sat through that bare no resemblance to the title or the abstract.

It’s not easy to come up with an eye catching title and abstract, but don’t fall into the trap of trying too hard, then failing to deliver on the day. It’s better that you are honest and don’t get selected, than promise people an enlightening experience and fall short.

The vast majority of the problems are not so much the topic, but the depth of the material. If you start calling something a “deep dive” or mention “internals”, you better have something a bit more hardcore than a few sentences out of the manual. There are plenty of people out there who can melt your brain when they talk about Oracle, and I’m not just thinking about the famous names who get on stage. There are a lot of really bright people who you will never see on stage and you will never know their names. Don’t short-change those people by promising something, then not delivering.

The opposite is true also. If you include words like “introduction” or “overview”, then you can’t start hitting people with in-depth analysis. The people that come to an introductory session will get nothing out of watching you prove how cool you are.

Remember, getting a room full of people who leave disappointed is far worse than getting a handful of people who really enjoy the session!

If in doubt, ask a few colleagues to help you rate the level of your content.

Check out the rest of the series here.

Cheers

Tim…

Public Speaking Tip 4 : Have a disaster recovery plan!

My first presentation for UKOUG was at a Special Interest Group (SIG). I was invited to speak by Andrew Clarke, who at the time was the chairman of that SIG. I admitted I was a complete newbie and asked for some advice. Being a seasoned speaker, he gave me lots of good advice, but one of main things he told me was to have a disaster recovery plan. As it turns out, that was one of the best bits of advice I could have received so early in the game. Andrew is a really nice bloke and a great speaker. When I met him again at this years UKOUG event in Manchester I asked if I could take a picture with him, because I’m such a fanboy. 🙂

AndrewClarke

Presenting can be a nerve-racking experience. Even when you have a backup plan, when something goes wrong you still feel like a bit of you has died. Without a backup plan, it would feel like a world ender. 🙂 Just like in your job, disaster recovery is about dealing with the unexpected. It gives you one less thing to worry about. I’ll illustrate why it is important with a few examples of things that have happened to me over the years.

  • At an ORCAN conference in 2009 I was sitting in the session before mine, so I tried to start the VM I use for demos and it wouldn’t start. I use a lot of demos, so life was not going to be fun. Fortunately I had a backup of the VM, so I overwrote the VM and it started fine. A quick run through some of the demos and life was good. I got finished with the recovery about 5 minutes before my session started.
  • At an OUGF conference in 2009 my laptop died, so I had to present on someone else’s. I was not able to run any demos, but I had a text representation of the expected output for each demo, so I could at least talk through something when presenting off a memory stick.
  • At UKOUG 2011, I screwed up my demo VM before presenting about Clonedb, so I had to use my article to show what should have happened. That talk was described by someone on Twitter as “a mess“, so the backup plan was not all it should have been. 🙂
  • At the Montevideo, Uruguay leg of the OTN Latin America Tour last year I accidentally dropped all the tables in the SCOTT schema as I started my demo. I couldn’t remember the name of the script to recreate SCOTT (utlsampl.sql), panic does that to you sometimes, so I presented the examples using the article I had written that goes along with the presentation.

Notice how all my major disasters have been about demos being screwed. Having live demos is a nice thing, but not without its risks. 🙂

So for peace of mind, you really need to consider what you are going to do if things go wrong.

  • Keep a copy of your presentation on a memory stick.
  • Keep a copy of your presentation somewhere you can download it, just in case.
  • If you have demonstrations, have some way of replacing them if they are not working for some reason. Text output, screen shots or even better video capture of the demos is a great idea.

If you are lucky, you will never need them. If you are unlucky, you will be glad you made the effort!

Check out the rest of the series here.

Cheers

Tim…

Public Speaking Tip 3 : Pick a subject you are interested in!

Your presentation should be on a subject you have a genuine interest in. There will be a number of these tips that relate back to picking your subject for a presentation, but for now I will focus on this specific aspect.

Enthusiasm goes a very long way when you are presenting. When you are genuinely interested in a subject it draws people in. It is very hard to “appear” enthusiastic about something you have no interest in! It is even harder to maintain enthusiasm when you are presenting the same session multiple times. There has to be something there that gives you that spark, which the others around you can feed off.

When I look around at all the great speakers I’ve met and tried to learn from, they are all really into their subject. They are all speaking about something they feel passionate about. To do anything less than that is cheating yourself and the audience.

Check out the rest of the series here.

Cheers

Tim…

Public Speaking Tip 2 : Rehearse!

I can almost hear the chorus of, “Well durr!”, but stick with me…

Do you remember the kids at school that always said stuff like, “I’ve done no revision at all for these exams!”, when you knew full well they had been slaving away for weeks to prepare. Speak about rehearsing for a presentation at a conference and those kids all come out of the woodwork, but in the guise of Oracle geeks… 🙂 Now I’m not calling these people liars, but rehearsal means very different things to different people.

For me, rehearsing involves the following to a greater or lesser degree:

  • I’ll talk myself through little sections or topics. Not a formal thing. Just a quick couple of minutes when I’m bored, like waiting to fill the car with petrol.
  • Try and remember what anecdotes, used to explain a point, come where in the presentation.
  • Anticipating questions and thinking of how I would approach answering them.
  • Walk through of the presentation while sitting at a computer. This is normally a super quick pass through. An hour presentation might take 15 minutes to practice in this way.
  • A formal walk through, where I stand up and present to the window in my room, which typically takes about as long as the full presentation.

When people speak about rehearsal, they are normally only thinking about the last point. They seem to forget all the hours of work they’ve put in before that. If you are new to presenting and you read stuff by people saying they “just wing it”, I think you may be surprised at how much work actually goes into “just winging it”! 🙂

There are a few warnings I should give about rehearsals though, which may be specific to me, or common to others…

  • Don’t try to learn lines so your presentation is word-perfect. This invariable sounds really dry and lifeless, unless you are a trained actor. You should be learning cues, which set you off down the next path. This way, your presentation is semi-ad-libbed, but has some structure. If you’ve rehearsed enough, you won’t get lost for words.
  • Following on from that point about trying to be word-perfect, if you do forget “the script”, or someone interrupts you with a question, it can throw you so badly. Better to avoid this.
  • Don’t rehearse to the point where you are bored of the presentation. Your lack of enthusiasm will be visible to all. Another point in favour of the semi-ad-libbed approach is each time you present the same slides it will be different.
  • If you are doing multiple dates in a tour, you probably need to back off the rehearsals a little. It’s hard not to get stale when you’ve presented the same three talks 6 times in a couple of weeks.

Ultimately, you need to learn what works for you. If you watch someone like Connor McDonald, you know he’s put in crazy amounts of hours to get that stuff so slick. Others have a looser style, that probably requires less total rehearsal time. Suffice to say, if your talk goes badly, you probably need to put more effort in next time. 🙂

Check out the rest of the series here.

Cheers

Tim…

Public Speaking Tip 1 : Do some public speaking!

A number of people have asked me how they can improve their public speaking. I don’t consider myself an expert, but I thought I’d share my thoughts over a series of posts. Why a series? Because I figured if I tried to write an all encompassing post on the subject it would become long and boring, so small sound-bites it is! 🙂

So the first suggestion I would make about improving your public speaking, is to actually do some public speaking. There’s a pretty simple rule in life, you tend to get good at things you do regularly. I would suggest that very few people in life can stand up in front of an audience for the first time and feel the audience is about to witness greatness. No matter how bad you are at presenting, after you’ve done 20, you will be better than you were at the start. After 40 you will be better than you were at 20…

So I’m suggesting you get up in front of 1500 people at OpenWorld for your first gig right? Wrong! That’s likely to turn you into a neurotic wreck. There are a whole bunch of ways you can break yourself in gently, including some of the following:

  • Organise a regular session in your company. You could get together with a bunch of colleagues and arrange to present stuff to each other on a regular basis. This not only improves your presentation skills, but adds greatly to knowledge spreading in the organisation. I was first introduced to this during my PhD. Every Friday we had a meeting where 2-3 people from the lab were picked to present for 10-15 minutes each. If you had made some progress in your research, you might present about that. If not, you might present about a specific scientific paper you had read recently. I do a similar thing in my current company. Every 2 weeks I present to my colleagues for an hour. I’ve suggested someone else steps up to the plate occasionally, but so far that’s not really happened. 🙂
  • Speak at a Special Interest Group (SIG). There will probably be a number of SIGs happening around your region for a variety of user groups, including your local Oracle User Group. They are always on the hunt for new speakers. It’s much easier to do something like this first, rather than rock up to a full blown conference.
  • Toastmasters. I’ve never tried this myself, but a number of people I respect have said very good things about it.

Whatever you decide to try, the main thing to remember is, you will never get good at speaking in public if all you do is sit at home and bitch about the fact you are crap at speaking in public! 🙂

Check out the rest of the series here.

Cheers

Tim…

Scheduler Enhancements in Oracle Database 12c

I’ve spent the last couple of days playing around with the scheduler enhancements in Oracle 12c.

I guess the big news is the new “script jobs”, which are pretty cool. This kind-of passed me by until Brynn Llewellyn mentioned them at UKOUG in his Multitenant presentation, at which point I made a note to check them out.

I’ve been having some trouble with the “BACKUP_SCRIPT” jobs up until a few minutes ago. My problem was I couldn’t see what the stdout/stderr text was, so I couldn’t determine why there were not working. The “$ORACLE_HOME/scheduler/log” directory was empty and there were no messages in the trace files or alert log. Then I stumbled upon the new columns added to the ALL_SCHEDULER_JOB_RUN_DETAILS view. The OUTPUT column, not surprisingly, gives you the output from the scripts. Once I could see the error message it took me a few seconds to fix the issue and Bingo! 🙂

The new job types are a nice addition, allowing you to run file-based scripts or incline scripts much more easily that before.

Cheers

Tim…

 

Data Pump Enhancements in Oracle Database 12c

Another one to file under “Not sexy but flippin’ awesome!”

If you are a DBA, you are going to spend a lot of time with Data Pump. All roads seem to lead back to it. 🙂 There are some more headline worthy features, like transportable database, but the two that jumped out at me were actually pretty small, but awesome.

  • “TRANSFORM=DISABLE_ARCHIVE_LOGGING:Y” – Switches table and/or index imports to NOLOGGING for the lifespan of the import operation.
  • “LOGTIME=ALL” – Puts a timestamp in the output message so you can see how long individual operations took.

I wrote up an article about it here.

Cheers

Tim…

PL/SQL White Lists in Oracle Database 12c Release 1 (12.1)

I’ve been playing about with the ACCESSIBLE BY clause to create PL/SQL white lists in Oracle 12c. Here’s the article I wrote about it.

There seem to be some discrepancies in the documentation*, which I’ve highlighted in the article. Not sure if they are documentation errors, functionality that has been pulled and will reappear in 12cR2, or just misunderstandings on my part. 🙂

Cheers

Tim…

* I’ve posted comments on the docs, so if they are documentation errors they may get fixed.

Please, please, please instrument your code!

I’m always telling people to instrument their code. Invariably they don’t. Then this happens:

  • Dev: Why is this call failing?
  • Me: What are the parameter values you are calling it with in your code?
  • Dev: Values X, Y and Z.
  • Me: Have you called the routine directly with those values?
  • Dev: Yes, and it worked fine.
  • Me: That would suggest those are not the values you are really using then.
  • Dev: But they are.
  • Me: How do you know. Have you traced the variable values before you made the call.
  • Dev: No, but they are the correct values.
  • Me: Can you put in some trace messages to check?
  • Dev: (walks away) … grumble … grumble … stupid trace … wasting my time …
  • Me: (some time later) So what values were you passing in?
  • Dev: One of the values was not what I was expecting, which is why it broke.

No matter who you are or how cool you think you are at programming, you can never know exactly what is going on in your code unless you instrument it. Just shut up and do it!

How?

  1. Use DBMS_APPLICATION_INFO to indicate exactly what your code is doing at all times. The information can be used for targeting SQL tracing (DBMS_MONITOR), it shows up in the performance reporting (ADDM, AWR, Cloud Control) and some of it gets added to the audit trail, which is very handy. You might prefer to use the Method-R wrapper called ILO.
  2. Put tracing messages into your code. You can use DBMS_OUTPUT directly, but it is probably better to use one of the wrappers that allows you to do clever things, like redirecting the output to different destinations. I wrote my own wrapper code (dsp.pks and dsp.pkb), but there are a few out there. You might want to consider log4plsql or logger.
  3. You can even direct messages to the alert log or trace files using the undocumented package DBMS_SYSTEM, if you are feeling brave. 🙂

Experience tells me you will read this and ignore it, but that is a big mistake! A real professional *always* comments and instruments their code!

Cheers

Tim…