Confessions of a recovering speaker



Ever feel that sinking feeling after a presentation?  The one where your audience seems to check out and the silence screams "unengaged"?  Been there done that. After delivering one of the talk to my teammates where I bombed, I decided to improve my presentation skills. Inside Amazon, engineers have the opportunity to deliver POA (Principal Of Amazon) talks. These presentations, crafted by senior engineers, share knowledge and insights with a wider audience.  A significant amount of effort goes into creating these presentations. Each speaker is assigned a dedicated coach who guides them through the process, offering invaluable guidance in polishing the presentation and ensuring the message is delivered clearly and succinctly.

My experience delivering multiple "POA talks" revealed a simple secret from the coaches: prioritize crafting a script before building slides.  During my first POA talk in 2014, I arrived with a prepared slide deck.  However, the coach's advice was clear: ditch the slides, focus on the story. He emphasized the importance of a central message – the big idea of the talk that the audiences take away with then. The big idea should be clear and center.  In this instance, for my talk about DynamoDB Streams, the core idea was to "demystify the power of real-time data streams".  This message resonated with developers because the launch of DynamoDB Streams coincided with the introduction of Lambda, allowing customers to leverage event-driven programming on their DynamoDB data. The talk went into details of how streams was built and how it can be used.
One of the thing that also stood out to me from the coach was building the presentation itself should only take about 30% of your overall time.  The true emphasis should lie on crafting a compelling narrative and a clear message.
New to the talk scene, I was eager to dive into the technical nitty-gritty.  Every detail – the algorithms, the design choices – seemed fascinating to me and I was excited to tell them in my talk.  But my coach wisely intervened, urging me to step back. He emphasized the crucial question: "Why should the audience care?"  They wouldn't be captivated by intricate technical details unless they understood the problem being solved and its impact. The key, was to start with the customer's perspective.  Clearly communicate the pain points they faced and how your solution, addressed their needs. Repeat this core message early, often, and in a way that resonates with the audience. The lesson I learnt from this was to explain the “why” before the “how”.

Comments

Post a Comment

Popular posts from this blog

When Hours Drag and Decades Dash

Image
For more than the past decade, I've had the privilege of being an engineer on the DynamoDB team. Being part of this exceptional group of individuals dedicated to tackle highly ambiguous challenges. I joined the team as an engineer with limited knowledge of databases and none of NoSQL databases. The fact that I was novice intimidated me and excited me, as it meant I would constantly face challenges that would push me to expand my understanding. One particular instance that I vividly recall from my early days at AWS, was being welcomed into a room filled with three senior engineers talking about solving a scaling challenge in the replication protocol of SimpleDB. The details of the specific problem is explained in this article by AWS titled   Summary of the Amazon SimpleDB service disruption . The opportunity to work on that project was solely due to my display of curiosity and eagerness to learn. The challenge was quite daunting because I had to ramp up on distributed systems, had t
Read more

Don't Just Work, Work with Purpose

Image
  Ever felt lost at work? Ever found yourself asking, 'What am I doing?' or 'Why am I doing this?' It's a sentiment many of us can relate to. I've pondered these questions numerous times throughout my career. One thing I've come to realize is that working in an environment where the foundations of a team are rooted in clear values and purpose, it leads to a vastly different experience. When everyone understands what matters most, decision-making becomes smoother, and frustration decreases across everyone. This doesn't mean you won't ponder these questions anymore, but the confusion will be less. Similarly, when you have a clear purpose, you feel excited about what you are doing. When your values and purpose clash with your workplace or peers, it can lead to frustration and a feeling of limited impact. It's almost like constantly swimming against the current. It's exhausting and limits your impact. On the other hand, if your values are aligned
Read more

Availability - What it really means?

Metrics are critical for all cloud services. One of the most common metric that is tracked by most cloud services is the availability metric. The general definition of the availability is the “the quality of being able to be used or obtained”. The key part of availability is “quality” but definition of quality is vague. So, I always wondered how different services choose to implement this? If a cloud service is serving multiple types of requests, should the availability values for each request type be considered in evaluating availability? Some type of requests are called more often than others, are all these request types equally important? Each request made by the customer has a time delay between customer sending the request and getting a response for it, does time delay play into the availability metric or is it just number of requests that got a response? What is the time scale that should be considered for the metic? Is it seconds, minute, hour, day, week, or month or something e
Read more