diff --git a/Gemfile.lock b/Gemfile.lock index 9ce6a30..54e2a00 100644 --- a/Gemfile.lock +++ b/Gemfile.lock @@ -29,6 +29,7 @@ GEM ruby2_keywords (>= 0.0.4) faraday-net_http (3.0.2) ffi (1.15.5) + ffi (1.15.5-x64-mingw-ucrt) forwardable-extended (2.6.0) gemoji (3.0.1) github-pages (228) @@ -212,6 +213,8 @@ GEM jekyll-feed (~> 0.9) jekyll-seo-tag (~> 2.1) minitest (5.20.0) + nokogiri (1.15.4-arm64-darwin) + racc (~> 1.4) nokogiri (1.15.4-x64-mingw-ucrt) racc (~> 1.4) octokit (4.25.1) @@ -255,6 +258,7 @@ GEM webrick (1.8.1) PLATFORMS + arm64-darwin-23 x64-mingw-ucrt DEPENDENCIES diff --git a/_layouts/post.html b/_layouts/post.html index 652d5d2..0920908 100644 --- a/_layouts/post.html +++ b/_layouts/post.html @@ -6,15 +6,13 @@

{{ page.title }}

by {{ page.author }} - {{ page.date | date_to_string }}

{{page.description}}

-

-

About this series
+

{{ site.about }} -

-
- This guide is made available under the permissive Creative Commons CC BY-NC-SA 4.0 license -

+
+
+ This guide is made available under the permissive Creative Commons CC BY-NC-SA 4.0 license

- {{ content }} + {{ content }} {% include footer.html %} diff --git a/_pages/ProjectWeekOne.md b/_pages/project-week-one.md similarity index 100% rename from _pages/ProjectWeekOne.md rename to _pages/project-week-one.md diff --git a/_pages/RemoteWorkshopReadiness.md b/_pages/remote-working-readiness.md similarity index 100% rename from _pages/RemoteWorkshopReadiness.md rename to _pages/remote-working-readiness.md diff --git a/_pages/technical-presentations.md b/_pages/technical-presentations.md new file mode 100644 index 0000000..e95f17a --- /dev/null +++ b/_pages/technical-presentations.md @@ -0,0 +1,302 @@ +--- +layout: post +title: "Talking Confidently about Technology" +date: 18-12-2023 +author: Colin Eberhardt +description: A practical set of tips and tricks to help you build confidence and make your voice heard. +--- + + +## Intro + +Software engineering is something we’d all consider to be a technical profession (whatever that might mean), and we’d like to believe that those who are the most technically proficient are the most prominent. However, this isn’t always the case. You’ll often find that the people who are the most knowledgeable, or have the deepest insights, are the quietest. Unfortunately, those that possess the sharpest communication skills, the gift of the gab as it is known colloquially, often have the greatest influence. + +In reality, for many of us in this industry, our focus isn’t all about having a successful career, climbing the promotions ladder, or sharing our deep insights. It is simply that having your voice heard, and feeling like your opinions are valued, is vital to an enjoyable working experience. + +There’s a wealth of materials that help build your technical skills, through courses and certifications, but relatively little that truly helps nurture communication skills. As a result, this is something that people tend to overlook, and those that lack confidence remain quiet. And when this happens, we all lose. Valuable ideas are not surfaced and the individual simply feels a little less valued. + +This guide isn’t going to fix all of this, but it aims to help empower the quieter or less confident among us to speak with real confidence. + +If you’re nervous about communicating your ideas, either in a formal presentation setting, or more informally, in meetings and small group conversations, this brief guide is for you. It’s a simple collection of thoughts and ideas; practical steps that you can take to build confidence, or feel more secure. You don’t need to try them all at once, building communication skills and confidence in yourself takes time. It’s better to introduce them little-by-little. + +Anyhow, enough of the introduction, let’s move onto something more practical. + + +## Practice, practice and practice some more! + +The heading for this section might seem somewhat obvious. We all know deep down that getting better at something requires practice, and this is certainly true for communication skills. However, how many of us intentionally practise different ways of communicating? + +Practice requires repetition, but don’t mistake repetition for effective practice. + +One of the keys to effective practice is constructive feedback, if you’re incredibly self-aware you may be able to determine areas of improvement yourself. But most of us are simply self-critical (finding faults that may not exist) rather than self-aware (a more genuine consciousness of your own abilities), which isn’t always constructive. You need this feedback to understand the areas where you are already good at communicating and also where you can make improvements or try different styles. + +So how do you go about getting some constructive feedback? This isn’t always easy, and I’d recommend starting with people you already trust. + + +### Build a network + +It’s always better to practice in the company of others. If you want to practice more formal presentation skills, why not see if you can find one or two friends or colleagues who are on the same journey? You can try out your presentation skills in a small group, with people who will be kind and who want to see you succeed. This helps build trust and empathy. + + +### Be specific + +The great thing about relying on people you trust is that they genuinely care about you and your feelings, and as a result, you’ll likely receive positive feedback and encouragement. While this is great for your confidence, it isn’t always the feedback you need to improve. + +To help tease out the really helpful feedback you can ask your reviewers to be more specific about an area of focus. + + + +* Can you please provide feedback on my rate of delivery, am I too fast? Too slow? +* Did I waffle a little in that meeting? Did I make my point clearly? +* Do my slides support the talk? Or are they a distraction? + +Don’t get me wrong, positive feedback (you were awesome!) is great, but you need a balance. + + +### Group practice + +One of the most effective things you can do is practice as a group, perhaps form a “speaking” club, or a more modestly titled “communication skills” group. This can give you a safe space to try things out. + +If you form a group, set some ground rules. If someone gives a presentation to the group, it is the responsibility of everyone to provide some constructive feedback. This in itself is a good exercise in communication skills. Delivering feedback, that some might consider negative, is a challenge in itself. And once again, worth practicing. + +Another useful group exercise is to watch presentations from conferences, or perhaps the odd TED talk. Watch as a group then discuss the presentation, focussing on the delivery, rather than the content. What techniques did they use that you might want to try yourself? How did they introduce themselves? How did they introduce the topic? Where did they stand on the stage? Who were they talking to, the whole audience or one or two key people? What made them appear confident? Did they falter in any way? And if so, how did they recover? + +Try to identify the techniques that you thought made the delivery of the presentation really good and also not so good. Once you have spotted these you can then try to emulate them yourself, or deliberately avoid the negative points. + + +### Create opportunities + +You’ll probably need to put a bit of work into creating opportunities to practice. If you’re working as part of a team, are there instances where you could take the lead, perhaps as a sprint demo? Or maybe it is worth suggesting ‘lunch and learn’ sessions, where you share a bit more about what you are working on with the team. Maybe your company already has some internal forums where people present on technical topics? + + +### Generating ideas + +In all honesty, this is probably the hardest part. So far this section has described various ways to practice and elicit feedback, but practice what exactly? + +It’s very frequent to hear people say “I couldn’t present on that topic, I’m not an expert”. I’ll let you into a little secret, there are very few genuine experts in the world, and if they were the only ones who are ‘allowed’ to speak, the world would be a very quiet place! + +It’s easy to think that everyone knows the same things that you do, or perhaps more, but this simply isn’t the case. Furthermore, there are so many ways to present a topic or concept, that sometimes you’ll be surprised by a presentation on a familiar topic, where the way it was delivered causes you to think differently. It’s happened to me on numerous occasions, and I always try to be an open-minded audience member. + +One top tip to remember is that when people come to your presentation they are doing so because they want to know about your topic. They want you to be successful in presenting it because they want to hear about the subject. How many people go to a talk to deliberately watch the presenter fail? Your audience is actually your biggest supporter, so you don’t need to feel scared of them. + +This still doesn’t quite answer the question of what you should talk about? Quite simply I believe you should aim to talk about things that you enjoy and that excite you personally. Developing a talk, and building your own confidence, is hard work - you’re going to have to enjoy the topic to make it worthwhile. + +It might be worth keeping a notebook, often you’ll find ideas come to mind when you’re at your most busy, and don’t have time to act upon them. If you don’t write them down, you’ll likely find you’ve forgotten all about them when you do get a bit of time to spare. + +Finally, there is no harm in asking a friend of a colleague, “would you be interested in a talk on ….?” + + +## Constructing a presentation + +Delivering a talk on a technical topic, whether it is something about programming, or perhaps a delivery methodology, can feel quite intimidating. You might want to consider presenting on a non-technical topic first, especially if you’ve managed to assemble a group who are all looking to practice their presentation skills. + +This section isn’t a recipe or a process you can follow to develop your presentation. I really think people approach this in very different ways. However, regardless of whether a presentation is on a technical topic or not, there are some basic tips that apply, which I’ll share here + + +### Beginning, middle, end + +I always think it helps to consider presentations as a form of storytelling, and some of the same basic rules apply. The beginning introduces the topic, or problem, and likely yourself also. The middle is where you dive into the content itself, and the end will typically refer back to the beginning. For most presentations the beginning and the end are relatively brief, but it is still worth thinking about your presentation as having some sort of narrative or story. + + +### Bring yourself to the presentation + +You may be wondering how a technical topic can have a narrative or be considered storytelling? That’s a good question - technical topics are by their very nature quite dry. They lack feelings and emotion! + +This is why “bringing yourself” to a presentation can help add a bit more narrative. There are a great many ways this can be done: + + + +* If you picked a topic, unit testing for example, why? What is it that interests or excites you about this topic? Why not include that in your talk? +* How did you learn about this topic yourself? When? For what reason? +* Can you relate this topic to some of your own experiences, good or bad? Specifics and stories bring a topic to life. +* How has this topic impacted you and how do you think it could impact others? + +Something you’ll probably be surprised to learn is that people like learning about people. You may think your audience is only here for the technical nuggets, but more often than not, they’re just as interested in you and your experiences. + +Finally, personal stories are simply more memorable to the audience. + + +### Include signposts + +This is an extension of the “beginning, middle, end” structure, for someone to follow your talk and the narrative it is important that they don’t get lost. I’m sure you’ve been in a presentation where you’ve lost the thread, or are unsure why they are telling you something? Here are some examples you can use: + + + +* **Tell the audience why you are going to tell them something, ahead of telling them the thing** - ok, that’s a bit of a mouthful. It’s easy for someone to get lost if they are not quite sure why you are telling them something. If it’s not entirely clear or obvious, simply tell them! … “This is a bit of background that I think is important to your understanding” +* **Segues **- no, not the self-balancing two-wheeled devices that were supposed to revolutionise travel. A segue in a talk is a clear transition from one topic to another. +* **Visible signposts** - sometimes it can help to add visible signposts on your slides, similar to the breadcrumb trails you find on websites. +* **Be clear about why a story matters** - your talk will likely include examples, stories, or background information that you have included for a specific reason. However, sometimes this reason isn’t obvious to the audience, and it is worth spelling out, “I’m going to tell you a little story because it illustrates my point …” + +The above might sound patronising, but they really do help people follow your presentation. Once someone gets a little lost it is very hard for them to pick up the thread once again. You can’t rewind a presentation in real life. + + +### Presenting with friends + +Presenting as a ‘double act’ likely feels like a good way to get started, having someone next to you can really help reduce your stress levels, and it is worth giving it a try. + +However, presenting as a pair can also be a bit more challenging in other ways. If you’re ‘passing the mic’ multiple times in a presentation, this will require more practice than if you’re doing it yourself. I’ve seen a few double-act presentations where there is confusion about how and when to hand off. + +Don’t be put off giving this a try, but do remember to practice the transitions, and if possible minimise them by structuring your presentation accordingly. + + +### Scripts, use with caution + +This topic comes up quite often with people learning to present, there is a temptation to script the entire talk so that you don’t stumble or need to ‘improvise’. However, reading from a script is a skill in itself! You run the risk of a ‘wooden’ delivery, one that lacks passion and genuine audience connection. + +Again, similar to ‘presenting with friends’ it’s not something I’d say you should never do, but it is worth practicing in smaller groups to see how well you can read under pressure. + +Rather than writing a script, I’d recommend using a bullet point style for developing your talk. At first these might be quite detailed, where each bullet point is a whole sentence, in a way that is not dissimilar to a full script. As you practice, try to compress the amount of material in your bullet points. You might want to make a few words, or key points bold so that they stand out when you’re reading your notes. Over time, drop the rest of the text so that the key points remain. + +There is absolutely nothing wrong with having speaker notes, but as you practise, you’ll find yourself using them less and less often. I’d advise against removing them completely, sometimes just knowing they are there just gives you a bit more confidence. However, by having a few key points in bullet points, you’ll find it much easier to pick up the narrative once again if you get lost. + + +### Connecting with the audience + +One of the main issues with a script is that your eyes will likely be glued to your notes rather than looking out into the audience. You’ve probably noticed that the most experienced and confident speakers hold eye contact with their audience. This helps create a genuine emotional connection and also holds their attention. Again, this is something that only comes with practice and confidence. + +At first, look for the people in the audience who are most engaged, perhaps your friends? A bit of eye contact and a reassuring smile, or nod of the head, goes a long way to help lift your tone. + +It’s also a good trick to find 3 or 4 people in your audience who you direct the presentation at. You can move from person to person making eye contact with them. Audience members will never be sure if you are talking to them or the person to their left or right. When you look at one person directly most of the people in that general area will feel like you are presenting specifically to them. If you select people who are scattered across the audience and talk directly to them, the result will be that most of your audience comes away feeling like you were looking at them + +You might also want to experiment with more direct audience interactions as a way to build a connection. At first I’d recommend against open-ended questions, “what do you think of this …?”, this might result in unexpected feedback or things you're not prepared for. A safer option might be ”hands up who has experienced this problem before”, but do bear in mind that there will likely be some reluctance, people don’t like being singled out or becoming the centre of attention. This is why people often scan the room first before raising a hand! Other prompts you might try are “shout out if you know the answer to this …”, again, this is a more directed question which is less likely to derail you. + + +### Avoid reading your own slides + +If you’re worried about remembering what to say, or leaving out some important detail, it can be tempting to pack a lot of content, or bullet points, into your slide. Unfortunately this has a few negative side-effects: + + + +* If you pack your slide full of text, there’s a good chance you’ll start reading it out verbatim, resulting in the ‘script’ issue discussed earlier +* Another risk with a slide packed with text is that people will start reading the slide and will naturally stop focusing on you, the presenter. +* Worse still, they’ll be able to read faster than you talk, meaning they’ll get to the end of the slide then have to mentally back-track when their focus returns to you. +* And worse again, they might not be able to read the slide at all because the font size is so small to accommodate all the words + +To stop people reading ahead and losing focus on the presenter, some people favour presentation slides that reveal one bullet point at a time, which isn’t a bad solution. However, it is better to minimise the content of your slides so that there is simply very little text and little to distract the audience from you! + +A trick you could use is to replace your bullet points with questions that you answer. For example, if you want to describe the role you have in a team, rather than have a slide with three bullet points describing the role, replace them with a question “how would I describe my role in the team?” + +As an aside, don’t worry if you don’t say exactly the same thing each time. However, if there are key points you want to get across, this is information to place in your slide notes. On that subject, whether you use PowerPoint, Keynote or Google Slides, they all have a presenter mode with notes that only you can see. This is something you should familiarise yourself with … and practice. You need to practice with the tech as well as your delivery. There is nothing more embarrassing than not being able to work your own slide deck. + + +### Ending your presentation + +The end of a presentation is something most people overlook. Here are some antipatterns that happen all too often: + + + +* The “I think I’ve finished” ending - “and that’s me just about done” +* The “I want to get off the stage fast” ending - “thank you, goodbye” accompanied by a quick dash off the stage +* The “I didn’t think of an ending” ending - “well, that’s about it for me” +* The “I’m out of time now” ending +* The apologetic “I hope you enjoyed that” ending + +I could go on … + +Probably the worst ending of all is “any questions?”, it seems like a very sensible thing to ask the audience, but there’s a big problem with ending this way. At the end of your talk people will likely want to show their appreciation, hopefully with a polite round of applause. If you immediately end with “any questions?” you immediately confuse the audience. Watch what happens next time a presentation ends with that line - you’ll no doubt see a bunch of people who have just lifted their arms, ready for applause, but all of a sudden are unsure if that is rude, so nervously put them back down again. No-one wants to clap at the wrong time. + +Always, always leave a pause before asking whether there are any questions from the audience. Give them the opportunity to show their appreciation. + +So what is a good ending? Remember the points about storytelling above. Your ending should likely refer back to the beginning of your talk. What was the overall purpose of your talk? Reiterate what the audience has been told and hopefully learnt. + +This still leaves the tricky job of the very last sentence. I’d recommend planning this in advance, without planning there is every likelihood that you’ll trail off at the end. Personally I favour ‘active’ endings, or a simple call to action. Here are a few ideas: + + + +* “I hope this has inspired you to give ChatGPT a try, you might be surprised by the result” +* “Next time you write a test, why not give BDD a try” +* “I hope I’ve given you something to think about, and next time someone suggests using blockchain, you have some concrete questions and polite challenges” +* “Open source is a community endeavour, why not roll-up your sleeves and give it a try?” + + +### Handling questions + +You’ve delivered your final line, given the audience the chance to applaud (which I’m sure they did), what about questions? For starters, there are no rules that say you have to take questions - often I feel they are a little superfluous, and take away from the ending you crafted. One simple option is to say “if you’d like to discuss further, come and find me for a chat, I’d love to talk some more …” + +If you’d like to ask questions, be prepared for a few situations: + + + +* You may get asked questions you don’t know the answer to. That’s fine, and not something you should hide. A polite response could be “I’d not thought of that, perhaps we could discuss later”. +* Some questions are not questions, some people simply want to share their own thoughts, which is fine. Simply thank them for sharting. +* Sometimes you will not get any questions, which can be quite embarrassing if you’re not ready for this. I’d have a line ready “I’ve clearly left you with a lot to think about, once it has sunk in, do catch me later fo a chat” + +Although, repeating the above, you don’t have to take questions, and if you’re new to presenting, I’d recommend avoiding putting yourself on the spot like that. At least not the first time around. + + +## Delivering Technical Talks + +This guide is supposed to be covering technical presentations, but so far I have focussed on generic communication and presentation guidance. So let’s shift our focus to the technical part. + +For many people presenting on a ‘technical’ topic can be particularly stressful. Not only do you have the worry of the presentation itself, there’s the additional worry that you might say something wrong. This is why I’d recommend starting off with ‘non technical’ presentations, where there isn’t such a clear-cut line between right or wrong. + +However, at some point you’ll have to take the plunge, and try presenting something technical. + + +### Don’t assume your audience are experts + +In fact, assume the opposite. + +Regardless of the setting, you’ll likely be presenting to a group with quite mixed abilities. Don’t try to immediately impress the experts in the room, instead try to create a presentation that takes everyone on a journey. Try to make sure that everyone stays engaged and follows along. I’d much rather re-iterate the basics, even if the experts have heard it all before, than jump in at the deep end. The risk here is that some of your audience will be lost immediately. + +Also avoid acronyms. Not everybody in the audience will know what the letters stand for. Using an acronym can be the difference between a person following and enjoying your talk versus losing interest within the first few minutes. + + +### And you don’t need to be an expert either + +This is a very common problem, “I can’t do a presentation on React, I’m not an expert”. Very few people genuinely are experts, and you certainly don’t have to be an expert to present on a topic. + +One way to build confidence and avoid the “I am not the expert” voice in your head is to present something as a personal opinion. Rather than presenting something as fact, present it as “This is what I learnt” or “This is what I found”. + + +### Technical talks can tell stories + +Stories can be quite subtle, you don’t have to have characters and a plot! A story can be a simple journey of discovery. They help bring a more human element to a talk, adding a little bit of emotion and connection. + +You can use this as an opportunity to introduce a character if you like, it can be you, or could be someone fictitious, for example “I’m going to tell the story of a Python developer who tried to learn Rust”. But if you do take this route, it’s probably something that you’ll have to maintain for much of the presentation or it may seem superfluous. + + +### Build empathy + +This is one of the most powerful tools for any form of talk (or communication). Empathy is built around feelings. Technology itself lacks feeling or emotion, so you need to be intentional about how you build empathy. + +This can be really quite simple, share your thoughts and feelings, your likes and dislikes. Or you can share what you’ve observed with others, e.g. “I know a lot of you struggle with …” + +If you think your own background or circumstance is relevant, maybe the course you studied, or a previous job you had, bring that to the talk. This is a great way of creating empathy. Consider talking about why this topic means something to you? Why did you pick it? Why is it a personal interest? What excites you about it? + + +### When showing code, keep it simple, and direct their focus + +The time people take to absorb and learn, is much longer than you’d expect. When introducing topics, especially those that are technical in nature, take it slowly. + +The need to take it slowly is especially important if you have slides that include code, API documentation, or simply have quite a few words. When you show code or text people will read it and try to understand it, which takes a surprising amount of time. You can minimise this by keeping the code as simple as possible, and also by directing them to specifics, perhaps underlining a specific piece of code when talking about it? + + +### The perils of live coding + +It’s hard, seriously hard. Being able to talk, write code that works, all while telling a story, under pressure, with sweaty palms. Don’t put yourself in that position without a backup plan. + +My typing skills are quite average, but I’ve learnt the hard way that under pressure, my typing skills are atrocious! I have given a few talks that involve live coding, but it has almost always involved a little bit of ‘off screen’ copy and paste magic. I also have a back-up plan with the code at various known states in case it all goes horribly wrong, which it does. + +Seriously though, this is very advanced stuff, and a skill that takes practice. Make sure you have prepared some filler lines to say whilst you are trying to recover the tech. A few seconds of silence in a presentation can feel like an eternity. + + +### Avoid ‘bigging yourself up’ + +As you’ll likely be reading this guide because you lack confidence right now, perhaps this isn’t all that relevant, but something to consider for the future. + +Often, more experienced, more confident speakers will start with their CV, career history and their biggest achievements. This certainly validates their expertise, but I’m not sure it really builds empathy. You can qualify yourself differently, rather than what you have done, maybe talk about what has made you proud? What has shaped you? It allows you to talk about your achievements in a different and more modest way. + +Also, avoid words like ‘obviously’. What may be obvious to you could be a complete revelation to your audience members. Using words like ‘obviously’ carries the risk of making your audience feel inferior and go on to dislike you. + + +## Smile + +The final piece of advice is simple. Smile. + +Whatever your presentation topic, try to put the nerves to one side, take a deep breath, look out into the audience and smile. It’s infectious. You’ll almost certainly be greeted by a sea of faces smiling back at you. + +So now you have the guidance, why not try it out? Be brave, and start with small steps talking with or presenting to a safe audience. The longer you put this off the more your fear of presenting will grow. + +Go on, pick a topic and go for it. Once you have conquered the art you will discover that what once seemed daunting is actually quite good fun. + diff --git a/assets/css/style.css b/assets/css/style.css index e576e70..ca3254b 100644 --- a/assets/css/style.css +++ b/assets/css/style.css @@ -89,6 +89,12 @@ h1, h2, h3, h4 { margin-left: 35%; } +#about-this-series { + margin-top: 20px; + padding: 20px; + background-color: lightblue; +} + #content { margin: auto; width: 80%; diff --git a/home.md b/home.md index 9c6be1e..47e12fa 100644 --- a/home.md +++ b/home.md @@ -6,9 +6,10 @@ permalink: / The Practitioner's Guides are designed to be small practical guides for IT professionals - authored by the team at [Scott Logic](https://www.scottlogic.com/). We draw on our collective experience to tackle topics that we don't feel are addressed elsewhere. Our hope is that these little 'value adds' will help you just as much as they have helped us. -Topics covered include: +The current catalogue of guides is as follows: + {% for item in site.pages %} -- {{item.title}} +- {{ item.title }} {% endfor %} The Practitioners Guides site is an ongoing project, where we expect new guides to be published on a somewhat regular basis, watch this space!