Tag: conferences

Well, it’s conference season again. I’ll be off to the West Coast for DeveloperWeek, then RSA, and, I’m sure, more conferences through the coming months. I had a good old rant a few months ago about what I hate about conference speakers, so this seems like a good opportunity to talk about all the good things that I actually enjoy. Well, it might to you, but I’ve got all sorts of spleen-venting that I still want to do, so bad luck: you’re getting another rant. This time round, rather than getting all shouty about product pitching (which was the subject of my last cross-fest[1]), this time it’s all about the slides and their delivery.

First, here’s a disclaimer, however, or maybe two. One is this: I’m not perfect[3]. I’m may well have been guilty of one or many of the points below in many or all of my presentations. If I have, I’m sorry: and I’d like to know about it, as I like to fix things.

The other is this: not everyone is excellent, or will ever be excellent, at presenting. However hard you try, it may be that it’s never going to be your top skill. That’s fine. On the other hand, if you’re not great at spelling, or you tend to zone out your audience, and you know it – in fact, if you struggle with any of the points below – then ask for help. It doesn’t need to be professional help – ask a colleague or family member, or even a friendly member of the conference staff – but ask for suggestions, and apply them.

Before we delve deeper into this topic, why is it important? Well, people (generally) go to conferences to learn – maybe to be entertained, as well. Most conferences require attendees or their organisations to pay, and even if they don’t, there’s an investment of time. You owe it to the attendees to give them the best value that you can, and ignoring opportunities to improve is arrogant, rude and disrespectful. You may not feel that bad spelling, punctuation or layout, or even poor delivery, will detract from their experience, but they all distract from the message, and can negatively impact on what people are trying to learn. They are also unprofessional, and here’s another important point to remember about conference speaking: it’s an opportunity to showcase your expertise, or at least get other people to be enthusiastic about the things you do. If you don’t do the best you can do, you are selling yourself short, and that’s never a good thing.

Here, then, are my top seven tips to improve your conference presentations. I’m assuming, for the purposes of this article, that you’re presenting a slidedeck at an industry presentation, though many of these points are more broadly applicable.

Layout

I’m not just talking colours and shapes, but also how much is on your slides, whether it’s in sentence or bullet format, and the rest. Because how your slides look matters. Not just because of your company’s or organisation’s brand, but because it directly affects how people process the information on your slides. The appropriate amount – and type – of information to put on a slide varies based on subject, technical depth, audience, for instance, but a good rule to remember is that people will generally read the slides before they listen to you. If you have more than about 20-30 words on a slide, realise that nobody’s going to hear a word you say until they’ve finished reading, and that’s going to take an appreciable amount of time. If in doubt, have multiple bullets, and reveal them as you talk (and never just read what’s on the slides: what’s the point of that?).

Spelling, punctuation and grammar

You may not care about spelling, but lots of people do. It can be distracting to many people to see bad spelling, punctuation or grammar on your slides. Everybody makes mistakes – and that’s why it’s worth reviewing your slides and maybe getting somebody else to have a look, too. The amount that this matters will depend on your audience – but correcting slips raises the credibility of the presentation as a whole, because mistakes reflect badly on you, whether you like it or not.

Pictures

Or graphs. Or diagrams. I don’t care: put something in there to break up the slides. I’m really guilty of this: I tend to have slide after slide of text, and forget that many people will just glaze over after the first few. So I try to find a few pictures, or, even better, relevant diagrams, and put them in. There are lots of free-to-use pictures available (search for “creative commons” online), and make sure that you provide the correct attribution when you use them.

Style

People have different styles, and that’s fine. Mine tends towards the jokey and possibly slightly over-enthusiastic, so I need to think about how I pitch different types of information from time to time. Play to your strengths, but be aware of the situation. People will remember you if you’re a bit different, and there are times for humorous t-shirts, but there are times for a jacket or tie and a more sombre approach, too.

Tone

Do. Not. Drone. There’s just nothing worse, particularly when the presenter is just reading the information on the slides. And after a long lunch[4], it’s so easy to nod off, or just start looking at stuff on your phone or laptop. If you think you might suffer from a boring tone, ask people for help: practice delivering to them, and then think about how you speak. It’s relatively easy for most people to learn to modulate their tone a little up and down with practice, and it can make all the difference. Equally, learning when to stop to allow people to digest the information on a slide can give you – and them – a break: a change is, as they say, as good as a rest.

Delivery

I’ve already said that you mustn’t just read the words on the slides. I’ll say it again: don’t just read the words on the slides. Notes are fine – in fact, they’re great, as most people aren’t good at improvising – or you can learn a script, but either way, one of the most important lessons when delivering any type of information is to look at your audience. Sometimes this is difficult – there may be little light to see them by, or you may find it nerve-wracking actually to look at your audience – so here’s a trick: pretend to look at your audience. Choose a spot just a few centimetres[5] above where an audience member is – or might be, if you can’t see them – and speak to that. They’ll think you’re speaking to them. Next slide, or next bullet, move your head a little, and choose another spot. Engaging with your audience is vital – and will actually make it easier to manage issues like tone.

Audience

This could have gone first, or could have gone last, but it’s really important. Think about your audience. If it’s a conference for techies, don’t use marketing diagrams. If it’s for CEOs, don’t go into the weeds about compiler design. If it’s for marketing folks, well, anything goes, as long as there are pictures[6]. Remember – these people have invested their time (and possibly money) in coming to see you to learn information which is relevant to them and their jobs, and you owe it to them to pitch the right sort of information, at the right level.

Summary

I really enjoy conference speaking, but I know that this isn’t true of everybody. I often enjoy attendee conference sessions, but poor attention to any of the points above can detract from my enjoyment, the amount I learn, and how I feel about the topic and the speaker. It’s always worth trying to improve: watch TED-talks, take notes on what your favourite speakers do, and practice.

I’m at an EU Cybercrime Summit today and yesterday. This may not sound very exciting, and, maybe considering this, the organisers arranged a game for us to play yesterday. It was a simulation of a couple of different, but connected scenarios, and there was a web interface via which we could all interact with the engine.

The first scenario revolved around managing an attack on a piece of critical national infrastructure: we were acting as the CISO, and trying to work out our best course of action in terms of managing responses and communicating with various external agencies. The second scenario had us as the head of a national cybersecurity agency, watching and trying to manage an emerging set of issues, including a Meltdown/Spectre-type vulnerability and various piggy-backed attacks.

At each stage, there was some explanation, and then a serious of options for us to choose, along with a countdown, adding an element of tension to the process as we had to submit our answers[1]. Sometimes we had to choose a single option – “How serious is this issue? Not an issue; minor; substantial; significant; major; national crisis; international crisis” – and sometimes we could choose two or more – “Who will you inform about this? Internal only; trusted parties; national cybersecurity bodies; national intelligence; international parties.” We were encouraged to discuss our choices with our neighbours before we made them, and once all the answers were in, bar charts were displayed on the screen in front of us (and on our devices) showing how everbody had voted.

At the beginning of the process, we had been asked to enter some basic information about ourselves such as sector (public, industry, academic, etc.) and expertise (security, policy, justice, etc.), and for some of the bar charts, a further breakdown as given, showing how the sector and expertise voting had gone. Experts at the front gave their opinions of the “correct” answers, and reactions as to how people had voted.

I’d not participated in a game/simulation like this before, and had no idea either how it would go, nor how beneficial it might be. To my surprise, I enjoyed it and found it both interesting and educational. The scenarios were broad enough that they were unlikely to be many people in the room who had expertise across all of the different issues, I enjoyed discussing my thoughts with a neighbour who I’d only met earlier that day, and then discussing with him whether we agreed with the experts’ views.

In short, it was a very useful exercise, and I’m wondering how I could apply it to my work in different contexts. It was educational, fun, provided opportunities for forming relationships – we found ourselves discussing scenarios and issues with others around us – and allows for further analysis after the evene.t

1 – I’m not often one to link to external products, but this one seemed good, and has a free pricing tier: it was called Mentimeter. The game was run by AIT (Austrian Institute of Technology), Center for Digital Safety & Security.

Next week, I’ll be attending and speaking at Red Hat Summit in San Francisco. I’ve written before about how annoying I find it when people don’t stay on topic at conferences, so rest assured that I won’t be making any product pitches: in fact, I plan to hold a vote during the session to determine some of what I talk about, so if you’re attending, too, please come along and help choose.

In anticipation of the event and associated travel, I thought I’d compile a semi-humorous list of tangentially-security-related advice for anyone planning on attending a conference or associated exhibition/expo in the near future. I’ve been to way too many in my *cough* 20+ years in the industry: here are some tips for conferences.

Oh, and before we start, if you’re at DEFCON, be more paranoid even than this, or even more paranoid than you think you need to be. At most conferences, you don’t need to worry too much that someone might be spoofing the cell towers, for instance. At DEFCON, well…

wifi – if you’re going to use wifi, use official hotel / conferences access points, rather than random ones which have names like “useme” or “theNSA” or “notRussianSpies” or “dataCollectionforFB”. And even when you’re using the official ones, don’t trust them: use HTTPS and/or a VPN. You know this: don’t forget it just because you’re at a conference.

what happens in Vegas makes it back to your boss – maybe not your family members, but definitely your boss. I’ve been to conferences in Vegas. I’ve seen … things.

bluetooth – your safest option? Turn off bluetooth, particularly on your phone. If you must leave it on (so that you can use your watch/headphones/other cool accessories), then never accept unsolicited pairing requests.

conversations – do you want to be talked to by random strangers? Some people prefer to be left alone, and a growing number of conferences allow you to put a sticker onto your badge which will tell other attendees whether or not you’re happy to be addressed. These are typically:

green: I’m so gregarious I’m probably not in a technical job, and am more likely to be in marketing

red: please, please don’t talk to me, or even glance in my direction

yellow: I’m in two minds about it. If you’re going to offer me a job, make a pass at me or we’ve already met, then it’s probably OK.

(I have a serious question about this, by the way: what if you’re red/green colourblind and either very shy or very gregarious? This approach seems seriously flawed.)

don’t leave your phone on the boothtable – unless you want it to be stolen. I’m always astonished by this, but see it all the time.

decide whether you’re going to give out your email address – for most shows, you give your email address out whenever you have your badge scanned. So you need to decide whether you want to be scanned. There are lots of other ways of giving out your email address, of course, and one is to drop your business card into those little glass bowls in the hopes of winning a prize. That you never win[1].

getting pwned by booth staff – how do you get enough information about a company to decide whether actually to visit the booth and maybe talk to the staff? Well, you’re going to need to approach it, and you may have to slow down in order to read the marketing messages. There’s a set of rules that you need to be aware of around this behaviour, and it’s that staff on the booth can engage you in conversation if they catch you doing any of the following:

stepping on the coloured carpet tiles around the booth;

making eye contact[2];

dawdling[3].

languages – if you’re attending a conference in a foreign environment, you may wish to include a sticker on your badge to let people know in which languages you’re conversant. US English is standard, but other favourites include Java, Python, UML and, in some circles, COBOL[4].

beware too much swag – I’ve only had to do it once, but I did once buy an extra case to take swag back in. This was foolish. There really is such a thing as too much swag, and as we all know, once you have more than three vaguely humorous techie t-shirts, you can rotate them through the washing[6] until you get the chance to visit another conference and pick up some new ones.

useful phrases – not even vaguely security-related, and this really relates to the languages point, but I was told a long time ago by a wise person[7] that you only need five phrases in the language of any foreign country[8] that you’re visiting:

yes;

no;

please;

thank you;

I’ll have five beers, and my colleague’s paying.

1 – except once, when I won a large drone which was really, really difficult to get home from the US and then turned out to be almost impossible to control in the windy part of the UK in which I live.

2 – do you know nothing?

3 – this is the tricky one: I reckon anything over half a second is fair game, but exact timing is culturally-specific, based on my observations.

4 – if you find yourself at a conference where lots of people are going around with stickers saying “COBOL” on them, or, more dangerous still, wearing t-shirts with “I know COBOL, and I’m not ashamed”, you have two options: a) run, fast; b) stick around, learn to converse with the natives and end up with a job for life making shockingly large amounts of money maintaining legacy banking code[5].

5 – but getting invited to a vanishingly small number of dinner parties or other social engagements.

6 – if you don’t wash your t-shirts, you’re not going to need to worry to much about [5] becoming a problem for you.

7 – I can’t remember when, exactly, or by whom, in fact, but they must have been pretty wise: it’s good advice.

8 – I include the North of England in the “foreign countries” category.

Yesterday, I wrote some jokey resolutions for 2018 – today, as it’s a Tuesday, my regular day for posts, I decided to come up with some real ones.

1 – Embrace the open

I’m proud to have been using Linux[1] and other open source software for around twenty years now. Since joining Red Hat in 2016, and particularly since I started writing for Opensource.com, I’ve become more aware of other areas of open-ness out there, from open data to open organisations. There are still people out there who are convinced that open source is less secure than proprietary software. You’ll be unsurprised to discover that I disagree. I encourage everyone to explore how embracing the open can benefit them and their organisations.

2 – Talk about risk

I’m convinced that we talk too much about security for security’s sake, and not about risk, which is what most “normal people” think about. There’s education needed here as well: of us, and of others. If we don’t understand the organisations we’re part of, and how they work, we’re not going to be able to discuss risk sensibly. In the other direction, we need to be able to talk about security a bit, in order to explain how it will mitigate risk, so we need to learn how to do this in a way that informs our colleagues, rather than alienating them.

3 – Think about systems

I don’t believe that we[2] talk enough about systems. We spend a lot of our time thinking about functionality and features, or how “our bit” works, but not enough about how all the bits fit together. I don’t often link out to external sites or documents, but I’m going to make an exception for NIST special publication 800-160 “Systems Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems”, and I particularly encourage you to read Appendix E “Roles, responsibilities and skills: the characteristics and expectations of a systems security engineer”. I reckon this is an excellent description of the core skills and expertise required for anyone looking to make a career in IT security.

4 – Examine the point of conferences

I go to a fair number of conferences, both as an attendee and as a speaker – and also do my share of submission grading. I’ve written before about how annoyed I get (and I think others get) by product pitches at conferences. There are many reasons to attend the conferences, but I think it’s important for organisers, speakers and attendees to consider what’s most important to them. For myself, I’m going to try to ensure that what I speak about is what I think other people will be interested in, and not just what I’m focussed on. I’d also highlight the importance of the “hallway track”: having conversations with other attendees which aren’t necessarily directly related to the specific papers or talks. We should try to consider what conferences we need to attend, and which ones to allow to fall by the wayside.

5 – Read outside the IT security discipline

We all need downtime. One way to get that is to read – on an e-reader, online, on your phone, magazines, newspapers or good old-fashioned books. Rather than just pick up something directly related to work, choose something which is at least a bit off the beaten track. Whether it’s an article on a topic to do with your organisation’s business, a non-security part of IT[3], something on current affairs, or a book on a completely unrelated topic[4], taking the time to gain a different perspective on the world is always[5] worth it.

What have I missed?

I had lots of candidates for this list, and I’m sure that I’ve missed something out that you think should be in there. That’s what comments are for, so please share your thoughts.

1 GNU Linux.

2 the mythical IT community

3 – I know, it’s not going to be as sexy as security, but go with it. At least once.

4 – I’m currently going through a big espionage fiction phase. Which is neither here nor there, but hey.

As I mentioned last week, I’ve recently attended the Open Source Summit and Linux Security Summit. I’m also currently submitting various speaking sessions to various different upcoming events, and will be travelling to at least one more this year*. So conferences are on my mind at the moment. There seem to be four main types of conference:

industry – often combined with large exhibitions, the most obvious of these in the security space would be Black Hat and RSA. Sometimes, the exhibition is the lead partner: InfoSec has a number of conference sessions, but the main draw for most people seems to be the exhibition.

project/language – often associated with Open Source, examples would be Linux Plumbers Conference or the Openstack Summit.

company – many companies hold their own conferences, inviting customers, partners and employees to speak. The Red Hat Summit is a classic in this vein, but Palo Alto has Ignite, and companies like Gartner run focussed conferences through the year. The RSA Conference may have started out like this, but it’s now so generically security that it doesn’t seem to fit**.

academic – mainly a chance for academics to present papers, and some of these overlap with industry events as well.

I’ve not been to many of the academic type, but I get to a smattering of the other types a year, and there’s something that annoys me about them.

Before I continue, though, a little question; why do people go to conferences? Here are the main reasons*** that I’ve noticed****:

they’re a speaker

they’re an exhibitor with a conference pass (rare, but it happens, particularly for sponsors)

they want to find out more about particular technologies (e.g. containers or VM orchestrators)

they want to find out more about particular issues and approaches (e.g. vulnerabilities)

they want to get career advice

they fancy some travel, managed to convince their manager that this conference was vaguely relevant and got the travel approval in before the budget collapsed*****

they want to find out more about specific products

the “hallway track”.

A bit more about the last two of these – in reverse order.

The “hallway track”

I’m becoming more and more convinced that this is often the most fruitful reason for attending a conference. Many conferences have various “tracks” to help attendees decide what’s most relevant to them. You know the sort of thing: “DevOps”, “Strategy”, “Tropical Fish”, “Poisonous Fungi”. Well, the hallway track isn’t really a track: it’s just what goes on in hallways: you meet someone – maybe at the coffee stand, maybe at a vendor’s booth, maybe asking questions after a session, maybe waiting in the queue for conference swag – and you start talking. I used to feel guilty when this sort of conversation led me to miss a session that I’d flagged as “possibly of some vague interest” or “might take some notes for a colleague”, but frankly, if you’re making good technical or business contacts, and increasing your network in a way which is beneficial to your organisation and/or career, then knock yourself out*******: and I know that my boss agrees.

Finding out about specific products

Let’s be clear. The best place to this is usually at a type 2 or a type 3 conference. Type 3 conferences are often designed largely to allow customers and partners to find out the latest and greatest details about products, services and offerings, and I know that these can be very beneficial. Bootcamp-type days, workshops and hands-on labs are invaluable for people who want to get first-hand, quick and detailed access to product details in a context outside of their normal work pattern, where they can concentrate on just this topic for a day or two. In the Open Source world, it’s more likely to be a project, rather than a specific vendor’s project, because the Open Source community is generally not overly enamoured by commercial product pitches. Which leads me to my main point: product pitches.

Product pitches – I hate product pitches

Just to be entirely clear: I hate product pitches. I really, really do. Now, as I pointed out in the preceding paragraph, there’s a place for learning about products. But it’s absolutely not in a type 1 conference. But that’s what everybody does – even (and this is truly horrible) in key notes. Now, I really don’t mind too much if a session title reads something like “Using Gutamaya’s Frobnitz for token ring network termination” – because then I can ignore if it’s irrelevant to me. And, frankly, most conference organisers outside type 3 conferences actively discourage that sort of thing, as they know that most people don’t come to those types of conferences to hear them.

So why do people insist on writing session titles like “The problem of token ring network termination – new approaches” and then pitching their product? They may spend the first 10 minutes (if you’re really, really lucky) talking about token ring network termination, but the problem is that they’re almost certain to spend just one slide on the various approaches out there before launching into a commercial pitch for Frobnitzes********* for the entirety of the remaining time. Sometimes this is thinly veiled as a discussion of a Proof of Concept or customer deployment, but is a product pitch nevertheless: “we solved this problem by using three flavours of Frobnitzem, and the customer was entirely happy, with a 98.37% reduction in carpet damage due to token ring leakage.”

Now, I realise that vendors need to sell products and/or services. But I’m convinced that the way to do this is not to pitch products and pretend that you’re not. Conference attendees aren’t stupid**********: they know what you’re doing. Don’t be so obvious. How about actually talking about the various approaches to token ring network termination, with the pluses and minuses, and a slide at the end in which you point out that Gutamaya’s solution, Frobnitz, takes approach y, and has these capabilities? People will gain useful technical knowledge! Why not talk about that Proof of Concept, what was difficult and how there were lessons to be learned from your project – and then have a slide explaining how Frobnitz fitted quite well? People will take away lessons that they can apply to ther project, and might even consider Gutamaya’s Frobnitz range for it. Even better, you could tell people how it wasn’t a perfect fit (nothing ever is, not really), but you’ve learned some useful lessons, and plan to make some improvements in the next release (“come and talk to me after the session if you’d like to know more”).

For me, at least, being able to show that your company has the sort of technical experts who can really explain and delve into issues which are, of course, relevant to your industry space, and for which you have a pretty good product fit is much, much more likely to get real interest in you, your product and your company. I want to learn: not about your product, but about the industry, the technologies and maybe, if you’re lucky, about why I might consider your product next time I’m looking at a problem. Thank you.

*Openstack Summit in Sydney. Already getting quite excited: the last Openstack Summit I attended was interesting, and it’s been a few years since I was in Sydney. Nice time of the year…

**which is excellent – as I’ll explain.

***and any particular person going to any particular conference may hit more than one of these.

****I’d certainly be interested about what I’ve missed. I considered adding “they want to collect lots of swag”, but I really hope that’s not one.

*****to be entirely clear: I don’t condone this particular one******.

******particularly as my boss has been known to read this blog.

*******don’t, actually. I’ve concussed myself before – not at a conference, to be clear – and it’s not to be recommended. I remember it as feeling like being very, very jetlagged and having to think extra hard about things that normally would come to me immediately********.

********my wife tells me I just become very, very vague. About everything.

*********I’ve looked it up: apparently the plural should be “Frobnitzem”. You have my apologies.

**********though if they’ve been concussed, they may be acting that way temporarily.