Category: Training & Community

Supporting The Next Generation

Post author By Damien Jones
Post date July 20, 2026

In this post, I explain why I volunteer to give guest lectures for students and what supporting the next generation of developers, architects and engineers means to me.

Introduction

Opening LinkedIn one morning in June 2026, I was deeply touched to receive these kind and unexpected words from Ada‘s Steve Rich after my recent trip to sunny Sheffield:

I wasn’t initially sure how to respond without it turning into LinkedIn farming or a self-congratulatory fest, so writing about it here felt like the best option. I recently wrote some tips for anxious new panellists, and in a similar spirit this post seems like the best way to explain why I give these lectures and why I think they’re important.

Sure – it’s a good opportunity for me to practise and get out of my comfort zone. And as an AWS Community Builder and User Group Leader, I have access to tools and services that help me share knowledge and connect with the wider tech community. But there’s more to it than that, going back to my own experience studying technology in the early 2000s and why that motivates me to support today’s up-and-comers.

So in this post, I’ll talk about how I try to close the gap between the classroom and the real world. I’ll walk through what I did in Sheffield, and explain why supporting the next generation matters, both for Ada students and beyond.

About Ada

Firstly, some context about Ada:

Ada, the National College for Digital Skills, is a specialist further education college founded in 2015 and named after Ada Lovelace. They offer Sixth Form and Apprenticeship curricula, have campuses in London and Manchester and also operate a cohort in Sheffield. Ada works with employers including AutoTrader, HSBC and Siemens, aiming to transform the lives of 10,000 young people by 2028.

Starting in 2024, I’ve done four lectures for Ada covering topics including cloud computing, data analytics and my career journey. What began as stepping outside my comfort zone has become a semi-regular thing! As someone active in the wider AWS community, through AWS User Group Lancashire and beyond, I’m hopeful I’ll get similar opportunities with Ada and other colleges and universities in the months and years ahead. I feel that supporting the next generation, wherever I can, aligns closely with the goals of the Community Builder and User Group Leader programs.

Making It Real

Let’s rewind to the early 2000s when I was studying. Studying technology was very different then than it is today. There was no Stack Overflow to read and interact with, no YouTube lectures and tutorials to watch and no Discord servers to share ideas and pool experience.

Instead, there were textbooks, demo files, PowerPoint slides and internet forums of varying quality. And despite my best efforts, my attention and enthusiasm slowly drained. I couldn’t see how I would use what I was learning in the real world. It wasn’t real, and I couldn’t find a way to make it real.

These were entirely my issues. Others I was studying with at the time went on to great things, but we don’t all learn in the same way, and that’s just how things panned out.

Fast forward twenty years, and that gap has closed in one sense. Today’s students have resources I couldn’t have imagined. But having more resources doesn’t necessarily solve the problem. What’s still missing is context: how all this stuff actually gets used, day to day, by people doing the job. That’s the gap I try to fill with my lectures – my own attempt at supporting the next generation to help them reach and thrive in the tech industry.

Opening It Up

The recent lecture I delivered for Ada in Sheffield is a good example of the kind of things I like to do. After getting a brief from Steve on what the students were studying, I built a simple real-time voting web app for the lecture. To make it interesting, the app used a shared frontend and database, but split its backend across three different AWS compute services – EC2, ECS, and Lambda – each with its own endpoint:

My lecture had three parts. I began by discussing some core cloud concepts they’d touched on in class and which would soon come into play:

AWS Regions: Explaining what they are and how they address real-world concerns such as service latency, HADR and data sovereignty.
AWS Services: Exploring some of the service categories and explaining why AWS offer several services within each category.
Manual vs Managed: Discussing why managed services exist and exploring some of the high-level benefits and tradeoffs.

Then, I loaded up the app and let the students try it during a break.

In the second part, I broke the app down into its constituent pieces. I showed the architecture diagram and the CDK code, then accessed my AWS account and walked through everything: the shared CloudFront frontend and S3 storage, the different compute setups and even the Cost Explorer charts and CloudFormation deployment timelines.

This is something I rarely get to do in public, since most of my diagrams and code are subject to NDAs! This app was different – a bespoke build funded by my AWS Community Builder credits with nothing stopping me from opening it up to my audience completely. For the students, that meant a real AWS bill, a real deployment pipeline and real architecture decisions, not a sanitised slide-based classroom example.

The final part opened the floor for questions about the app, my Steamhaus role and anything else on their minds.

Making It Stick

I approach these lectures the same way I approach creating my AWS community sessions. Diagrams and slides will always have their place, but I prefer showing people what things actually do. When students can see a system working in the real world, it sticks in a way slides rarely do.

It’s also, in a small way, me helping these students with something I found hard while studying myself. I didn’t get any real-world examples, so I had to make do with what I could find and struggled as a result. If I can now reduce that burden for someone else, even by a lecture’s worth, that is time well spent.

Lectures like this aren’t easy to prepare, and they don’t always go to plan. But that’s kinda the point! Sometimes, neither does the job!

1782326784261 — Mid-delivery @ Sheffield

Making It Accessible

When I was studying, there was always a question in the back of my mind that I couldn’t quite answer. What are the jobs like? What are the people like? What’s a typical day?

Without access to industry professionals it was impossible to know, and it’s easy to fill in those gaps with assumptions. And when your only experience of technology is via academia, you end up assuming the industry is full of academics.

The reality is very different. Yes, there are deep specialists who have been doing this all their lives. But there are also new starters, generalists, career-changers and everyone in between. This isn’t as obvious from the outside as it seems, so I try to improve the tech industry’s accessibility for students in two ways:

Bridging the gap between Levels 100 and 200.
Showing students that the people already doing the job are just as human as they are.

Levelling Up

Firstly, let’s talk about AWS levels. AWS uses a five-level scale to grade the audience knowledge expected of its talks, training and documentation. This ranges from Level 100 (Foundational) to Level 500 (Distinguished). It’s meant to help people find content pitched at the right depth for them, and help speakers and writers scope their material to a specific audience.

I’ve long held the opinion that there’s a missing layer between Levels 100 and 200 – and that’s where most students sit. There’s no exact science here, so I’ll use the AWS Community Day DACH Talk Levelling Guide for reference. It defines Level 100 audience knowledge as someone who might have heard of AWS but has little or no hands-on experience with it. Level 200 steps up to familiarity with the basics: spinning up resources and knowing core terms like VPC, EC2 and S3.

But going from not using AWS at all to spinning up AWS resources, and going from having limited knowledge of the public cloud to understanding the differences among networking, compute and storage services, are big leaps!

For example, students may be aware of AWS Regions but not understand their importance or utility. That understanding only really comes with real-world experience, and these students haven’t had the chance to build that yet. So a Level 100 session might teach them nothing new, while a Level 200 session might go over their heads.

I try to pitch my student lectures somewhere between. Expanding on the Level 100 fundamentals without assuming familiarity with Level 200 topics like containerisation, storage types and network subnets. It’s a tricky balance, and I don’t always get it right! But I aim to help them understand how services slot together for the kinds of things they’ll be doing in their careers. This understanding will, over time, help them manage resources and make their own architectural decisions, ultimately unlocking the myriad Level 200 and Level 300 materials that are widely available.

Keeping It Human

In our industry, there’s no always-right answer, and no answer without compromises or tradeoffs. I’m not a polished, gatekept authority handing down absolute truths. I’m just an engineer making things work.

This is why I prefer using an informal conversational style over a scripted, flawless “Here’s the correct solution” one. At Sheffield, I demonstrated the voting app in the same way I’d explain it to a colleague over coffee – mistakes, tangents and all.

Ultimately, if the students can see that this bumbling, slightly chaotic shark can make a half-decent go of things in the tech industry, then they should be emboldened enough to have a go themselves. To me, that’s what supporting the next generation is really about.

1726057746966 — Talking about career beginnings in Manchester

Paying It Forward

Like many within the tech industry, my career is built on the generosity and patience of colleagues and strangers. Without these people, I wouldn’t be in the position I am today. I still remember the growing pains associated with triaging a ticket, using a Python virtual environment and being shown how to exit Vi for the first time. And the second time. And the thir…, well – you get the idea.

Looking back, the best seniors I worked with understood that mentoring isn’t a one-way street. When you guide someone, it builds momentum that helps them, and helps you too:

The learner gains confidence: They start taking initiative and solving problems independently.
The load gets shared: As they build confidence, they can take on operational workloads and build real, hands-on experience.
Your own knowledge gets stress-tested: You arguably don’t truly understand a concept until you have to explain it to someone else.
You grow as a leader: Teaching forces you to refine your communication, empathy and patience.

These principles also apply to lectures like the one in Sheffield. It’s not just information flowing one way from me to the students, but something that sharpens my own thinking too – supporting the next generation and myself at the same time.

The idea of paying it forward is central to our industry, whether from a screen, at a desk or in a classroom. There will always be people with experience to pass on, and people with things to learn. Now I’m in a position to pay it forward myself, handing on knowledge that took me decades to gather. So I’ll do what I can to keep this industry flywheel spinning.

1780601676178 — Student Panel @ Comsum Birmingham

Summary

Twenty years ago, I didn’t have access to people working in the tech industry, and it would have made a real difference in the years that followed. Now that I’m in a position to be that person for someone else, I think it’s vitally important to make time for that.

Beyond the people I meet at conferences, meetups and user group events, there are entire generations of future developers, architects and engineers in classrooms around the world. And they’re all wondering what the industry holds for them. At a time of hiring uncertainty and AI-driven upheaval within the tech industry, supporting the next generation with honest, hard-earned advice is more necessary than ever.

Steve’s message is a good reminder of why all this is worth doing. If I don’t do it, who will? And if I do it often enough, and visibly enough, I’ll hopefully encourage others to do the same.

Like this post? Click the button below for links to contact, socials, projects and sessions:

Thanks for reading ~~^~~

Tags Amazon Web Services, Speaking

Training & Community

AWS DevOps Engineer Professional Exam Prep With Pepe Silvia

Post author By Damien Jones
Post date May 30, 2026

In this post, I share my experience passing the AWS DevOps Engineer – Professional exam, including study strategy, mock exams, time management and exam-day tactics.

Introduction

Back in March 2022, I wrote about passing the AWS Certified Developer – Associate certification. More recently, in May 2026, I took the AWS Certified DevOps Engineer – Professional – my first AWS Professional certification.

I don’t usually write about exam prep — the strategies are personal, the technology moves fast, and there’s no shortage of good advice already out there. But I don’t see much written about the gap between the Associate and Professional certifications, so I thought I’d share my experience in this post.

First, I’ll examine some of those differences in detail. Then I’ll outline my study approach. Finally, I’ll share some survival tactics I used during the exam. And along the way, you’ll find out why one of my Steamhaus colleagues compared one of my strategies to the Pepe Silvia scene from It’s Always Sunny in Philadelphia.

pepesilvia — “Can we talk about the DevOps Pro please, Mac? I’ve been dying to talk about the DevOps Pro with you all day, okay?”

Professional vs Associate

This section explores some of the key differences between the AWS Associate and Professional certifications.

Before diving in, a quick note. Both AWS and Tutorials Dojo (which I’ll discuss later) offer excellent practice resources. While AWS still hosts older sample question PDFs (many of which haven’t been updated since 2022), the best place for their official materials is now the free tier of the AWS Skill Builder platform.

Scenario Length

The most obvious difference between the AWS Associate and Professional questions is length.

Professional exam questions are often much longer, sometimes two to three times as long as the Associate ones. And not all provided information is relevant. A major part of these exams is your ability to filter out noise and identify which constraints matter.

As evidence, look at this zoomed-out screenshot of Question 7 from the AWS DevOps Engineer – Professional sample PDF. I mean, LOOK AT IT.

It’s the entire page long! And, as I’ll discuss later, there’s not much time to read questions like these either. As for why many Professional questions are longer…

Knowledge vs Judgment

Associate questions generally check your understanding of what a service does. Professional questions assume you already know the technical terms and instead test your judgment over what actions to take.

To explore this, the Solutions Architect track offers the nearest like-for-like comparison. Let’s contrast Question 4 from the Solutions Architect – Associate sample exam questions:

With Question 3 from the Solutions Architect – Professional sample exam questions:

While the questions are thematically similar, they differ significantly in areas including:

Structure: The Associate question has a single correct answer. The Professional question requires two answers, each addressing a different layer of the architecture. This requires an understanding of how the services interact.

Scope: The Associate question focuses on a single service to solve a straightforward problem. The Professional question looks at the entire request pipeline: S3 serving the frontend, API Gateway handling the POST request and Lambda processing in the background. You must debug the whole system, not just choose the right service.

Detail: The Associate question provides only essential information. The Professional question includes additional elements that provide further context. It mentions that the team successfully tested each API method in the AWS console, which rules out server-side failures. Understanding this distinction is crucial for effective debugging.

Domain Structure

Associate exams focus on specific technical domains. Depending on the certification, these domains may include architectural best practices, development tasks or operational duties. Each domain is separate, making it easier to study and concentrate on one topic at a time.

Professional exams do not have clear boundaries. They require you to integrate knowledge from multiple domains at the same time, revealing something significant about what is actually being tested.

To see this in action, let’s look at the Solutions Architect track. The current version of the Solution Architect – Associate exam guide focuses on four domains:

Design Secure Architectures
Design Resilient Architectures
Design High-Performing Architectures
Design Cost-Optimised Architectures

These domains focus on the technical qualities of a workload. They closely align with the AWS Well-Architected Framework, and test the ability to identify the right services, apply best practices and recognise common design mistakes.

Conversely, the Solutions Architect – Professional exam guide takes a very different approach:

Design Solutions for Organisational Complexity
Design for New Solutions
Continuous Improvement for Existing Solutions
Accelerate Workload Migration and Modernisation

These domains are action-oriented and contextual, each specifying an action to perform rather than a quality to evaluate. They are open-ended and organisationally aware, rarely having a single correct answer.

Revision Strategy

This section explores my ways of preparing for the AWS DevOps Engineer Professional certification, including courses, mock exams and mental models.

Career Experience & Courses

2026 marks my tenth year working in technology, with the most recent two as an AWS Consultant at Steamhaus. While my day-to-day role naturally exposes me to several aspects of the DevOps Professional blueprint, it doesn’t cover all of them. That is where targeted courses come in.

I’m a longtime fan of Stephane Maarek, and had already bought his AWS DevOps Engineer – Professional Udemy course in a previous sale. The course covers a lot, but I felt less confident after finishing it than after his Associate courses. His DevOps course combines new lectures with material from his Associate courses. As a result, I found that some modules reinforced concepts I had already learned from the Associate-level material instead of providing the deeper context I wanted.

To fill the gaps, I used one of my Community Builder benefits – a free QA subscription. Danny Jessee‘s DOP-C02 preparation course covered similar topics to Maarek’s but delivered several lectures with the greater technical depth that I was seeking. The hands-on labs were also a massive help in demystifying some of the services and features I don’t often use.

With those gaps filled, it was time to start testing.

Mock Exams

Mock exams are likely the most valuable part of my study process. Since earning my first cloud certification in 2019, I have relied on the Maarek course and the associated Tutorials Dojo exams for each AWS certification.

Tutorials Dojo (TD) offers practice exams, cheat sheets and labs for several cloud certifications, including AWS, Azure and GCP. Each TD question bank has several modes, which I usually tackle in this order:

Section-Based: This mode focuses on specific topics and domains, giving the correct answer and a detailed explanation immediately after each question. This is great at flagging things I’ve misremembered, misunderstood or simply never touched, letting me refine my knowledge without burning through the question bank.

Review: This mode is more open-ended, posing questions from multiple domains. It isn’t timed and gives answers and explanations as before. I use this mode to build the mental stamina needed to answer large blocks of questions in bulk.

Timed: This mode mimics the exam. Questions are given under timed conditions, with a full report only upon completion. While some questions in the bank will now be familiar, this approach teaches me the strategies and timings I need for the actual exam.

After each session, I review the answers and identify topics and domains that are unfamiliar or problematic. What I do next with this knowledge has changed over the years…

Connecting The Dots

There’s no single correct way to use the results of a mock exam. Personally, I like to look for patterns in the areas where I’m struggling and connect them to topics I already understand.

For example, I was getting some ELB routing questions wrong, so I used my existing Route53 routing knowledge to fill in some gaps. I also had issues with some Elastic Beanstalk questions because I’m not a big user of the service, so I stepped away from the practice exams entirely to do a deep dive into the documentation and FAQs.

My goal isn’t to memorise answers. It’s to understand why an answer is correct well enough to recognise the same pattern in other questions. This eventually evolved into building mental models: connecting unfamiliar concepts to existing knowledge rather than collecting isolated facts. It’s an approach influenced by books like Make It Stick and How to Take Smart Notes, both of which argue that writing is a tool for understanding rather than simply recording information.

I like to write things down because it forces me to use my own words and highlights gaps in my understanding. It also encourages selectivity – since space is limited, every word must earn its place.

I’ve used several methods for this over the years, including:

Flashcard apps like Anki.
Ring binders with A4 notes and diagrams.
Blank A3 sheets as wall posters.

And now…

Pepe’s Whiteboard

Which brings us to my latest iteration and the reason for this post’s title – a whiteboard, several index cards and loads of fridge magnets:

While I could write directly on the whiteboard, the paper and magnets let me move, group, replace and reorganise cards without forcing a complete rewrite of the board.

This combines several benefits from the other systems:

Anki’s ease of note creation, tagging and movement.
The binder’s ease of writing notes on my own terms and in my own words.
The poster’s visibility and its ability to passively reinforce study material.

It also proved useful in the final days before the exam. Any cards that were still causing problems could be moved from the main board onto smaller, portable boards for targeted revision:

This still has limitations, of course. It’s not portable as a complete knowledge source. The whiteboard also has limited space – in fact, I ultimately had to branch out to a nearby plastic box for overflow!

Despite the space constraints, I’m definitely a fan of this whiteboard approach and will use it for future exams. I might augment it with digital second brain tools like Obsidian or Google’s NotebookLM to inform what deserves a card, and I’ll be looking into this in the coming months.

Survival Tactics

This section examines some of my survival tactics for the AWS DevOps Engineer – Professional certification exam by optimising time, embracing personal kindness and checking my understanding.

The Maths is a Lie

The Professional exams have 75 questions with 180 minutes to answer them. This averages out at 2 minutes 24 seconds per question. In contrast, the Associate exams consist of 65 questions that must be answered in 130 minutes, averaging 2 minutes per question.

You may conclude from this that the Professional exam gives you a bit more breathing room. And you would be wrong.

I previously mentioned that the Professional questions are longer and more complex compared to the Associate questions. These factors quickly eat those ‘extra’ 24 seconds. Many candidates have noted anecdotally that the timing of the Professional exams is very tight and, having now taken one, I completely agree!

My preferred strategy is to go through the questions in order and get a quick gut feel for confidence. If the question involves services I frequently use, or if the answer is well established from my studies then I’ll answer it. If not, I flag it and move on. I’ll try to make this decision within 30 seconds.

My initial goal is to see all 75 questions with as close to 90 minutes remaining as possible. This way, when I reach the end of the questions, I know how many are unanswered and how long I have left to answer them. I can then revisit these questions using a more methodical approach, potentially drawing on other questions I have already answered.

However, this required a change to the way I recorded my progress…

Kindness Through Panic

Since my earliest certifications, I’ve used a Gut Feel system using my own notepad during mocks and the test centre’s whiteboards during exams. I create an empty table with three confidence ratings:

100: I’m 100% sure of the answer.
5050: I’ve narrowed it down to two answers.
?: I have no idea.

As I move through the questions, each question number is recorded in one of these rows.

However, there’s nothing here for situations where I’ve speed-read the question and chosen not to answer it. The closest option was ‘?‘, but that means ‘I don’t know the answer’, whereas I wanted ‘I haven’t properly read the question‘.

Enter my latest addition: PANIC.

Panic is somewhat hard to articulate, so I’ll describe how I use it. A question will get Panic if my initial thoughts are along the lines of:

I’m currently panicking (I mean yeah – Ed).
I don’t want to try this question yet (for whatever reason).
I don’t feel ready to try this question yet (for whatever reason).

Or any other reason – this list isn’t exhaustive.

Professional exams are expensive, time-consuming and complex. It is completely reasonable to get adrenaline and anxiety in this situation. Panic lets me be kind to myself and build some forward momentum. I can then do second, third and fourth passes to attack the Panic queue.

It’s similar to an SQS queue visibility timeout. When a Panic question is pulled from the queue, it temporarily disappears. While it’s invisible, I can process other messages without it blocking my progress. Once I’ve completed my first pass, the timeout expires, the message reappears and I can handle it with fresher eyes and more context from the questions I’ve already answered.

At the end of an exam, I end up with something like this:

Combining this physical ledger with the exam software’s flagging feature lets me track unanswered questions and the reasons for skipping them. This gives me more mental bandwidth to actually answer the questions.

Hallucinations Aren’t Limited to AI

One of the biggest mistakes I repeatedly made during my mock exams was adding details that weren’t in the text. Who says AI is the only thing that can hallucinate?

I’ll illustrate what I mean with a paraphrased mock exam question:

A company has confidential files in an Amazon S3 bucket. Actions on objects need to be monitored, such as PUT, GET, and DELETE. The goal is to easily search for and review these actions for auditing purposes.

Four answers were provided. I narrowed it down to two options, one of which seemed wrong because it would trigger unnecessary Lambda executions.

But this answer was correct. And the reason my chosen answer would never have worked? It assumed a CloudTrail trail was already enabled on the bucket. The Lambda answer didn’t make that assumption, explicitly enabling the trail as a step. I’d hallucinated a prerequisite into existence because it’s what I’d have done instinctively in a real environment. Oops! This wasn’t the only time I caught myself out like that either.

So yes. Read the question. Then READ THE QUESTION. And then choose the answer that fits the requirements, not the one that needs some bending and stretching. And not the one that you’ve hallucinated into correctness.

Summary

Going into the AWS DevOps Engineer – Professional exam, I wasn’t sure what to expect. A harder version of the Associate exam? A different beast entirely?

As it turned out, both are true. The transition from Associate to Professional reminds me of the progress I’ve experienced in my own career. In my earlier roles, I primarily solved clearly defined problems with straightforward solutions. In my current consulting role, I concentrate on understanding context, navigating ambiguity, evaluating trade-offs and making decisions when no clear right answer exists.

While I did find the exam brutal, it does exactly what it sets out to do. I must often make important architectural and procedural decisions under time pressure and with appropriate justification, and the DevOps Pro held up a mirror to that perfectly. Would I do another? Absolutely. Although next time I might need a second whiteboard.

Like this post? Click the button below for links to contact, socials, projects and sessions:

Thanks for reading ~~^~~

Tags Amazon Web Services, Certifications, YearCompass Goals

Training & Community

Three Tips For The Anxious New Panellist

Post author By Damien Jones
Post date April 30, 2026

In this post, I share some of the reasons I decided to try panels and podcasts, along with three practical tips that helped me as an anxious new panellist.

Introduction

In 2024, I wrote Three Mantras For The Anxious New Speaker, a post about my experiences with presentations, public speaking and personal anxiety. Since then, I’ve been working to become more comfortable with spontaneity through panels and podcasts.

This has not been easy. Unlike presentations, panels remove much of the structure and predictability that I usually rely on. However, I have also found them to be valuable experiences for developing confidence and conversational skills.

In this post, I want to share what I’ve learned about panelling so far, including my motivations for trying it and some practical tips that helped me as an anxious new panellist. Although my experience in this area is still limited, I hope this information is useful to others in similar situations.

Choosing Panelling

As an anxious new panellist, I quickly realised that speaking and panelling are fundamentally different experiences. This section explores some of the things I’ve learned so far about these differences.

Panelling Is Not Speaking

Panelling and speaking have some key differences. These don’t make panelling harder than speaking; they just make them different types of activity. Adjusting to those differences needed a very different mindset from traditional presenting.

Predictability

Speaking is fundamentally easier to rehearse. Slide order, speaker notes and demos can be practised until they feel familiar. Even if nerves appear on the day, there is comfort in knowing roughly what comes next.

A panel discussion is different because, while the main theme is known in advance, the direction of the conversation is not. Conversations can move unexpectedly, panellists may introduce entirely new perspectives, and moderators may skip planned topics altogether if the discussion naturally flows elsewhere.

Control

Speaking is largely under the speaker’s control. They decide the pacing, the structure and how long to spend on each point. Points can also be expanded or adjusted depending on the audience and timings.

Panels are more collaborative and less predictable. The moderator guides the discussion, and control shifts between panellists and the audience as the conversation develops.

As a frequent overthinker, I initially found this surrender of control uncomfortable. However, I discovered that it can in fact reduce pressure, as no single person is responsible for carrying the entire session alone.

Focus

During presentations, much of the audience’s attention is directed towards the slides, demos or visuals. While the speaker is important, they are often sharing attention with the content on screen.

Panels and podcasts are different. The audience is watching the panellists: how they react, listen and respond to one another. Audiences here are usually looking for authenticity and conversation rather than a perfectly delivered performance.

Presence matters more than polish.

Understand Your Why

Panels and podcasts can be uncomfortable experiences, especially when you are naturally anxious. Before throwing yourself into them, it helps to understand why you want to do them in the first place.

For me, there were several reasons, framed around becoming more comfortable in unscripted conversations:

Practising Questions

Many speakers dread the post-presentation Q&A. Even experienced speakers such as Sheen Brisals have discussed how difficult it can feel. The challenge is that there are not many ways to practise it authentically.

Panels and podcasts are effectively extended Q&A sessions. Panellists are constantly listening, interpreting and responding in real time. Over time, this helped me become much more comfortable with unexpected questions and with creating frameworks to handle and respond to them.

Practising Being Off-Script

Presentations have pre-set structures. Even when nerves appear, there are usually familiar slides, demos or rehearsed transitions to fall back on.

Panels are different. Their inherent unpredictability forces you to think aloud, adapt to others and contribute without knowing exactly what’s coming next. Instead of mentally searching for what to say, the focus is on listening and responding naturally.

For me, this was one of the most valuable skills to develop because it carried over into presentations, meetings and everyday conversations.

Learning Different Types of Confidence

Confidence is not a single skill. It has many aspects, such as:

Presentation confidence: Delivering something prepared.
Conversational confidence: Joining discussions naturally.
Recovery confidence: Staying calm when losing a train of thought, misunderstanding a question or needing to change direction.

For a long time, I confused preparation with confidence and began hitting unexpected walls. Now, speaking develops my confidence in prepared and expected situations, and panelling is helping me build my confidence in spontaneous and ad hoc ones.

Talk About What You Know

Presentations can sometimes hide uncertainty behind preparation. A polished slide deck, rehearsed demos and carefully memorised transitions can do lots of heavy lifting. Conversely, the conversational nature of panels makes uncertainty much more visible, especially when discussions move into unexpected territory or follow-up questions appear.

In general, greater knowledge and experience with a topic make conversations easier. On the other hand, unfamiliarity increases the mental effort required to think, respond, and adapt in real time. And audiences often notice when someone sounds unsure, especially in conversational settings.

For me, speaking from genuine experience made a huge difference. Conversations became more natural, answers became less rehearsed and I spent far less energy trying to sound credible.

Panelling Tips

This section covers some practical tips that have helped me as an anxious new panellist.

Do Your Research

I am not saying to go full CSI or Sherlock Holmes here, but doing a bit of homework before a podcast or panel can make a big difference. It helps you avoid obvious mistakes, tailor your answers to the audience and feel more settled before you start.

While this section covers both established and new events, some advice applies to both kinds:

Arrive early. As an event organiser myself, I know the “What if my speakers don’t show up” feeling well. The sooner you’re there, the sooner the organiser can relax a little.
Speak to the event organisers before the panel starts. Whether you’ve met them before or not, an informal pre-event chat is a great icebreaker and helps ensure everyone knows what’s planned.
If there’s an audience, speak to some of them before the panel starts. You’ll get a feel for who’s in the room and what they’re hoping to get out of the evening.

Not everything on this list may be required (or even possible), but the more context you have going in, the better.

For Established Events

Established events usually have some kind of online presence. This might be Meetup pages, LinkedIn posts or event websites. Review these for examples of:

Topics that past events have covered.
Speakers who have been at past events.
Recorded sessions, if they exist.

These are good indicators of the usual event tone and the level of detail expected. They can also tell you whether the audience prefers practical advice, big-picture discussion or a more conversational approach. Clues can also come from the event’s organisational team and intended audience.

For example, in April 2026 I spoke on panels for Logicast and Preston Tech Connection. Logicast is an online event that is more technically oriented and AWS-specific, so my preparation included reading the latest AWS blogs and topical news stories.

Preston Tech Connection is an in-person event geared more toward exchanging ideas and community support, so this time I drew more on my personal experience and broader industry observations for preparation.

For New Events

It’s also possible that this might be an entirely new event, or the first time the event has done a panel. If so, that can actually work in your favour. If there is no history, there are no fixed expectations. There is more freedom to shape the tone, bring your own style and help set the standard for that event.

Reach out to the organisers. Ask questions. Clarify expectations. Remember – they’ll want the event to be a success too! Find out if there are any topics they definitely want to cover, what they expect from the audience and what their vision of success looks like.

Have Talking Points

One of the most common fears for an anxious new panellist is sitting there with nothing to say. One of the easiest ways to reduce anxiety here is to arrive with some familiar, relevant topics that you know you can talk about.

Personal Introduction

Have a short, direct personal introduction that you’ve practised to the point where it feels natural. Introductions will vary depending on the event, but most should quickly cover:

Name
Occupation
Relevance to discussion topic

For example, my prepared intro for Preston Tech Connection was:

Damien Jones
AWS Consultant at Steamhaus
Presented an AI-assisted web app at last week’s AWS London Summit.

During The Event

An anxious new panellist may worry about awkward silences or moments where they suddenly can’t think of anything useful to contribute. To prevent this, keep a safety net of notes and bullet points to use. A live panel isn’t a closed-book exam, so carrying notes is a smart move.

These notes can help you stay focused and relaxed during the event. I find that writing my ideas down guides my thinking and stops my mind from going blank. A quick glance at a notepad or device is preferable to staring blankly at the audience while your thoughts dry up.

VIbreCodingNotes — Some of my Preston Tech Connection OneNote notes

Not all points will be relevant as the conversation develops, but it’s better to have an unused point than to need one and not have it.

Closing Remarks

You may want to, or be expected to, give closing remarks at the end of the event. Prepare for this either way.

A good closing remark doesn’t need to be long. A sentence or two summarising your key takeaway or position, or a quick mention of where people can continue the conversation afterwards, is fine.

Give Yourself Kindness

As an anxious new panellist, the pressure to have a perfect answer for everything can feel overwhelming. You don’t need one. All three points below come back to the same idea: being honest about your limits is better than pretending you don’t have any.

These points also apply to post-presentation Q&As as well – in fact, some of this advice was born there!

Taking Thinking Time Is Reasonable

You may get a question that you need time to think about. That’s completely normal. I use two ways to handle this:

Say “I need a moment to think about that.” Yup. People generally perceive silence as bad. Silence with a purpose is perfectly acceptable, especially when it results in a relevant, focused answer. This gives you some breathing room to gather your thoughts.
If you need more time than that, say so and consider if this question is best answered after the panel. Remember – the rest of the audience is in the room too! If so, offer this and anyone interested can join you then. Alternatively, ask the moderator to move to another panellist while you gather your thoughts.

We’ve all seen someone visibly making up an answer on the spot, and it’s usually obvious. Don’t be that person. Take the time you need. The quality of your answer will improve, and you’ll maintain the room’s trust and respect. People are far more likely to appreciate a thoughtful answer than a rushed one.

One resource that helped me a lot with this was the following Luxury Academy video. While it’s about interactions with high-net-worth people, the advice on handling silence has helped me massively.

‘I Don’t Know’ Is An Answer

This isn’t a memory test or an exam. Frankly, admitting you don’t know something is a stronger response than trying to force an answer that might be substandard or wrong.

While saying “I don’t know” in front of a group is hard, the audience is more likely to value your honesty than to accept attempts to bluff your way through. In the worst-case scenario, you’ll know what to research next. In the best case, someone in the room might have the answer, leading to a more engaging conversation than you could have had by yourself.

‘I Don’t Have An Opinion’ is An Answer

You simply may not have an opinion about something. Reasons for this may include:

Having no experience in the question’s domain or speciality.
Not having encountered the problem or situation described in the question.
The question being contested or nuanced, with no clear answer either way.

Indeed, a response of ‘I don’t have an opinion on that, because…” is valid. During a lecture, I was once asked whether I preferred tabs or spaces when writing SQL. I replied that, as long as the code is readable and standardised, I don’t mind. So while not answering the question directly, my answer still had some value.

Don’t present this as ‘I don’t care’ though. While not having an opinion is neutral, not caring is usually negative. People can struggle to ask questions, so always treat inquiries with respect.

Summary

In this post, I shared some of the reasons I decided to try panels and podcasts, along with three practical tips that helped me as an anxious new panellist.

I examined the differences between speaking and panel discussions, emphasised the value of preparing key talking points, and highlighted the importance of being honest when you do not know something or need time to think.

Panel discussions don’t have to be perfect. At their best, they are conversations among people sharing experiences and perspectives. While preparation is helpful, it’s equally important to let yourself be human and spontaneous during the process.

Like this post? Click the button below for links to contact, socials, projects and sessions:

Thanks for reading ~~^~~

Tags Speaking