Keynotes: bringing DevRel to the big stage

Speaker

Nick Walsh

Job title

Principal Technical Keynote Lead

Company

AWS

Event/Series

DevRelCon New York 2024

Nick shares his experience crafting high-impact keynotes at AWS, where he blends technical depth, storytelling, and strategic messaging to engage developers.
Drawing from his role in creating presentations for global audiences, he highlights the importance of understanding your audience, delivering clear technical insights, and using innovative storytelling techniques. Whether you’re presenting new products or inspiring developers, Nick offers valuable lessons on how to make your content resonate and leave a lasting impression.

Watch the video

Transcript

Nick: Alright, thank you for coming out. Hope you’re enjoying DevRelCon. My name is Nick Walsh. I’m extremely fortunate to have what I think is honestly one of the coolest jobs in the world. I get to work on keynotes, demos, and lots of other really fun strategic projects at AWS. And while no two days or keynotes are the same, I’ve gotten a unique perspective as someone who starts on day one with what do we want to talk about? What do we want to show to ultimately owning what shows up on stage. So today I’m going to talk a little bit about a topic that’s near and dear to me, keynotes, but I think there’s a lot of interesting lessons that I’ll share that could be applicable to your technical content no matter what it is that you work on. So I’m sure we’ve all seen a keynote from a tech company before.

Quick show of hands, who’s seen a keynote before? You’ve probably seen one at this event too, although it looks very different. So in each of our heads we can probably think of the good ones, the bad ones, and most of them probably mundane somewhere in the middle. But today I have a question I want to ask all of you and that’s how would you do things differently? A few years ago, this was the exact same question I found myself being asked through a series of what I’ll only describe as a series of happy, unfortunate accidents. I was faced with the scariest proposition of all a blank sheet of paper, the pen and a deadline for a keynote. Our company was set to deliver and with a bit of existential dread and some soul searching, I found the north star and it was this. I was going to write the keynotes that I wanted to see as a developer and longtime user of our products.

I had lots of opinions about how we could show up better for our customers. And as someone in DevRel, this is our superpower collectively the ability to know the customer, not because we’ve spent years of researching and studying them, but because that’s us. We are the customer. Today I’d like to walk through a number of the questions that have followed since this day and share a number of those lessons. Hopefully a number of them will be helpful for you. So the first is why do keynotes matter? What are they? What do they do? Who are they for? Well, some of these may seem really obvious, like the external ones. Keynotes are a primary vehicle to engender a preference for your brand. Educate your audience on technical concepts, establish thought leadership, entertain and inspire your viewers. Showcase your value like DEI and sustainability. Highlight the customers and inspire for what’s possible, but lesser known as the internal benefits of some of these keynotes.

They align your key messaging as a company. They set the tone for how you’re going to speak to your audience both in the field on the big stage and beyond. It provides recognition for internal teams and more. And when I compiled this list, I figured, doesn’t this sound awfully familiar in developer relations? These are a lot of the core vectors that we use in dividing our work and figuring out whether it’s successful. And so the more I thought about it, your keynotes are really just another way and one of the primary ways your company shows up for developers. When people ask me what I do, yes, I make keynotes and my day-to-day involves lots of different things. But what I really tell them, and it needs no explanation in this room, is that I’m a developer advocate that just sits in a very different seat nowadays.

And other companies, a Super Bowl or an ad might be their big thing, but for developers it’s how we get up on a stage, how we tell a story and how we show them what they can build with our products. So with this, we want to ask ourselves, what makes for a good keynote? Is it the turtleneck sweaters? Is it the leather jackets? They may look nice, but really these are not the things that make things great instead for my money, I’d say that a good keynote is defined by how you make the audience feel. And there’s a few different emotions that I think are really critical for us to land informed about. The latest technology news announcements inspired seeing examples of what’s come before and what may be possible for them. Confident that in choosing your company or products that they’ll have the tools support and more necessary to make use of these things.

Curious as to what the art of the possible might be and excited about what the future will bring when all of these things come together. Ultimately, if you’re able to land each of these things, these emotions your audience will walk away from. You get what your business wants, which is awareness, perception lift, organic evangelism, purchase, and long-term loyalty and trust. The ways you measure each of these things is a conversation to itself. I’m not going to get into it, but if you’re looking at things in this way, I think you’re on the right track. So if we know that we want to drive these emotions, how can we do that? Well, you want to tell a story. Very few textbooks or even documentation ever made people feel, and while informational, they didn’t reinvent the ways that people would think about things. That’s what stories did.

There are a lot of stories that exist in the world and there’s lots of breakdowns on how well-defined the formats are for telling these successfully. But at their core, a story is just a vessel for delivering a series of related events or details. And what happens between each of the bookends is up to you. But I think we all know what makes for a bad story too long on interesting, bad characters. Unsatisfying punchline. But what about good stories? Well, they’re an awful lot of examples we can look towards for inspiration here. Movies plays, TV shows, music, concerts, bedtime stories, fables. We don’t have to reinvent the wheel and we don’t have to look far. Good. Storytelling is what takes the individual components, the pieces of dialogue, the script, the visuals, the participants, the actors, the stage, and it elevates them to be more than the sum of their parts pair away.

The genre, the language, the format. They’re all just different ways of telling stories. And while each of ’em are made in very different ways, they have a certain set of common tools that they use to tell these stories effectively. But we’re not telling stories for just anybody, right? We’re telling stories for developers, the group that’s apparently allergic to marketing, potentially even divinely discontent, the kind that wants to go to war over Vim versus emax. So how do we tell stories for developers? When I think about this, I think back to a quote from Rob Spectre that I heard in 2016, and it’s this. If there’s one thing that I’ve learned, it’s that developers, regardless of skill level, regardless of where they work in the world and regardless of the company that they work at, they’re all turned on by the same stuff. They’re all bonafide technologists that are genuinely enthusiastic about learning new things.

Rob Spectre said that back at DevRelCon in 2016 in a talk that he gave about scaling developer relations at Twilio. It was true then and it’s as true as ever. Now, developers, technologists, builders, whatever you want to call our core audience, they’re not homogenous, but they do have a set of shared experiences and tendencies by virtue of what they and we do for work. So as technology companies, these are some of the tools we have in our toolbox to tell stories for them. Some of these are more cut and dry like launches. Hey, we have this new thing, here’s what it does. It’s really exciting for these reasons. Some of it is broader like thought leadership. Where is this space going? How should I be thinking about this? Case studies, what problems did others face and how did they solve them? Customer testimonials, architecture, diagrams, demos and more.

The list goes on. And when I think about how we assemble these tools, I think of these as part of the anatomy of a keynote. Here’s what most of us know as anatomy. There’s this visual here of the human body with a whole bunch of labels. I think I counted about 36 of them labelled, and it’s comprehensive. It’s probably not exhaustive, but it’s got a lot of detail, but it doesn’t tell us a whole lot about how we would build something like this. But if we look at the components on the last slide, we see some commonalities. Some of those parts serve different purposes. They may be adjacent or complimentary to one another. They form these different systems, skeletal, nervous, circulatory and beyond. And interestingly, notice that these systems don’t live in discreet sectionalized parts of the body. They’re often interspersed throughout and embedded, and this needs to be the case so that you can have their function applied broadly.

So what does this have to do with keynotes? Well, many of you look at this and you see a two hour presentation from the audience or on YouTube wherever you’re watching. But when I look at this, this is what I see. Now, if you’ll humour me for a second, I would say the keynotes are not that much different from the anatomy slide I showed you before. Here’s all the slides. It can be overwhelming, but you’d equally be overwhelmed if I was to show you a few hundred frames of a storyboard from your favourite movie. But there’s a method to the madness here, and that’s what I want you to be able to take away. The first is that like any good set of stories, you have some sort of narrative structure, an intro and outro, three sort of big sections here from this. We start with some of our big set pieces.

These are the launches in this case from this keynote. For some people in the audience, this is all they’re there for. They just want to hear the news and it might be their highlight of the entire event. So make them pop visually pacing and beyond, but launches themselves, don’t stand on their own. You need a support system around them, just like the body. If all you want to do is inform people, you could reach out with some patch notes or a Roundup blog, but that’s not what we are there for. Next, momentum and stats audience are technically minded. They don’t want hand waving. Developers don’t think in words like a lot or many. They think in orders of magnitude and performance metrics. So what does scale look like? This is where we dig in and try to look at the stats and the numbers and find ways to be able to demonstrate these concepts like how our authentication engine serves over half a billion requests per second, or that each day customers launch over 60 million virtual servers on Amazon EC2.

These are mind boggling numbers, but they’re way more impactful in terms of engendering that trust for your brand and inspiring what you want to get across to your developers. Next is customer use cases. Some of the best showcases of what our products are capable of are the things customers are currently doing with them. This says two things. One, provide social proof. Hey, other people are using this thing. But two, it helps the customer triangulate between the problem they have, the tool or problem we’re talking about and how they may use it to solve their problem and the benefits that they’ll get from it. Next, technical graphics, architecture diagrams. And more developers see around corners and know that these are tools they need to build with. They’re going to dive deep on them. So show them how these tools will fit in their toolbox. So one of the first things they’ll want to look for when they want to learn more about your product or when they use it, especially at scale.

So don’t leave it to chance and include it at the front. Next, service, service category, product messaging. This is the interstitial tissue and exposition in your talk. You can’t assume people know everything about your services you live and breathe it, but if you know your audience, odds are some of them may be new to your world and even power users, ones that go really deep may not maybe be familiar with one part of your ecosystem but not others. So take them along for the ride. Make sure you’re not leaving anybody behind. Next technical thought, leadership statements, things like direction. We see the industry going. Takeaways you want to drive the user to. I don’t love the term technical thought leadership. I feel like thought leadership generally gets a bad rep because of the ways it’s misused, but when done well, this can be some of the most enlightening content in your keynote, but it has to be done right.

What are the ways you’re thinking about a technological trend that motivates how we as a company are thinking about building products? Like in ai, these large language models are only getting even bigger, more expensive to train. So how does that motivate how we’re going to be building products? This is something the audience wants to hear or what is the direction we see this space going so that we can help developers skate to where the puck will be, not to where it is today. Like in the advent of microservices, creating mental frameworks like many systems loosely coupled, helping them rationalise how they would use these things. And it’s not just about checking the boxes for each of these independent things. I just went through the flow and composition really does matter in a keynote. We’re in the business of a 90 plus minute cohesive show. Nobody would enjoy a movie.

It’s designed to have a different scene for a different type of person where the rest of the scenes board them or didn’t bring them along for the ride. And similarly scenes running overly long or extra extraneous scenes that didn’t add to the plot, they take you out of the moment. So we want these wow moments distributed throughout to keep people’s attention. Here are the ones we aimed for, but you want to start strong, finish strong and keep the pacing going well throughout. There’s a lot of other things that don’t fall into the buckets of what I’ve made here. A lot of things like narrative garnish and tips and tricks, but ultimately those are more how you say these things rather than what you’re saying themselves. And this is the way that I look at a two hour presentation. And so with each of these systems, I hope you’ll see they need to be embedded throughout, holistically.

You would never have one of these on their own, at least not at the scale of a keynote. And in the same way you would be silly to think of constraining bones, nerves, or muscles to a part of the body. Powerful story is told by leaning on each of these techniques at the right times and the right proportions to have the right impacts. I think this auditing process, we did it retroactively. It could be really powerful for assessing your own work, identifying some gaps and thinking about ways you can do even better for your developers and for your customers. So here are some of the tenets I’ve developed that have steered me well over the years. Disclaimer, these are just the ones that I and my team have come to know and they’re constant work in progress. There are certainly some I don’t have time for here and you may know better, in which case let’s talk afterwards.

I’m excited to hear. The first is knowing your audience. I’m making this zero index because it’s the most important thing on the list. If someone comes to me and asks what they should talk about in a keynote or how they’re going to talk about it, my first question is, who are you writing for? This is because the same content presented in different places at different times will be wildly varied in its effectiveness. So who’s your audience? Are they 100 level expert practitioners? At the 400 level, this wildly dictates what you can expect from them and to a lesser extent the types of assumptions you can make about their knowledge. Where is your audience? We talk a lot about localization and DevRel often on big picture things like language localization and content and docs. But I think a lesser expressed nuance is the difference in geographic socio-technical trends.

Things like stances on data residency latest JavaScript web framework du jour in the US may not be the case somewhere else in the world. And even the types of use cases that are seen positively or negatively in region can be make or break in terms of your content resonating in region. So pay mind to it and ask your local teams. Lastly, temporality a talk always occurs at one very particular moment in time while the talk can live on for a while and evergreen content is really, really important. It’s important to understand what’s going on in the broader technology space and customer’s lives to effectively tailor the content to that moment. The content a customer may have wanted to see six months ago may not be the content they want to see today, especially in an area where technology is moving very, very quickly. Next up, context is needed for people to care.

It’s easy to assume that the audience can connect the dots and know as much as you do, but you need to recognise that you live and breathe your company’s products far more than anybody else ever will. So here’s one of these examples of how you can tell stories. It’s the three act structure, one of the many forms of narrative development that I mentioned before. Let’s take a look at using this in the context of launching a new product. First, the status quo. What’s the lay of the land today, day and life of developer in your domain? Second, what are the unsolved challenges with current tools? Developers working in this area struggle with x and y. Third, the hero arise. This is your launch, this is your product. That’s why today I’m excited to announce Amazon Elastic Problem Solver and they’re the hero comes to save the day.

Fourth, optionally, depending on the product, how it works, you may want to show it in action. It’s really, really easy. And this model works basically for launching any product. It’s not the only way to do things, but it is certainly a way that is reliable and will resonate with your users. But it goes beyond just a launch or any one particular topic. What about the context of your company, your mission, and your entire set of products? It’s probably no surprise to folks here that AWS has a lot of products. I think the count is over 300 and making sense of it all can definitely be a challenge. So people frequently ask us, why do we have so many? And so when we were thinking about this problem and how to communicate it, we came up with this mental model. That complex systems evolved from simpler systems.

We reached out to some of the primitives from engineering and physics with an overview of simple machines. It would be impossible to build every car complex machine that customers would want because of the variety of needs that customers would have. But ultimately, by providing the right primitives, we would enable customers to create what they need in as performative a way as possible, allowing the breadth and freedom of things customers would want to build with the depth of efficiency and innovation from our concentrated effort on a small set or a growing set of powerful primitives. Next, simplify the complex. This takes a lot of different forms, analogies, visuals, mental models when it comes to computer science. In our world there’s no shortage of technically accurate, but incomprehensible explanations for concepts. Mastery comes from being able to carve out simplicity without losing accuracy. Here’s one. It’s a concept called erasure coding.

And this is the Wikipedia page for Reed Solomon encoding. It’s a form of erasure coding used for data storage and transmission. It’s a really low level sort of concept. There’s a whole lot of math here. Formula is a funky line graph for the log axis. It’s a lot to digest and honestly kind of gross. So for the sake of the story we were telling, we really only needed the audience to understand the macro concepts. A lot of the detail was extraneous. And what’s really key here is that there’s an object that can be broken down into chunks and then reassembled from subsets of that. So we sketch it out and then it just really starts to come together. When we really get into animation without even having more talk track, the relationships between these entities start to become far more clear. It’s just simple geometry and movement.

I made this animation in PowerPoint, but this goes a long way in making these complex dense topics easy for people to understand or take another mechanism, jokes which can work really well for lightning. The mood on otherwise dry subject matter. One of my favourites is this idea that these LLMs large language models are a bit like Swiss cheese. They have areas of information density, areas of information, sparsity, which are the gaps. And these hallucinations are when LLMs are trying to make predictions in the areas of sparsity. So we can use other techniques like fine tuning and guardrails to plug the gaps in the cheese and steer the model search space away from the areas of sparsity, thus improving the way it can work for us. It’s been hilarious for me to see this full bleed image of AI generated cheese across five screens in the Javits Centre.

But it gets the audience’s attention, it gives them a laugh, and it helps ’em understand a concept that’s understandably quite difficult to grasp. Next show don’t tell. It’s easy to say that a product experience is easy, but it’s lazy at best and lying at worst. If a user closes their eyes, can they understand what that product looks like from your words alone? Would they imagine what you built? Probably not. At the end of the day, most of what we build on as developers are experiential products. So get up there on stage and show it. These can take a lot of different forms, live coding demos, an animated explainer, a snazzy sizzle reel, showing all the different ways you could interact with products. But they’re all ways of telling your audience, look, you don’t need to trust me. Here’s what we’ve built for you and we’re showing you that we know how you’ll want to use it and that it matches up.

How you show up here also matters a tonne. Executives and main stage keynote presenters can certainly deliver demos, but there’s certainly times where seeing someone who’s closer to the end user persona like a developer, like a developer advocate, a business analyst, what have you, makes it much easier for the audience to see themselves in the shoes of the persona on stage and oftentimes can be delivered more authentically. Next, make it personal. The best stories of the ones that are unique to the speaker. I think we will all remember the first application we built that worked or the time we broke prod or we tried learning a new programming language. These probably evoke very visceral memories, not all of which are great, but they make us feel. And that’s something that’s very real from your past. And while many of these keynotes are put together by corporations, they’re always told by a person, a storyteller.

Things like hearing deeply about the system performance on a taco was writing since the very beginning that executive was able to think back to some of the earliest days of AWS and find an email from Jeff Bezos asking them about how performance was looking for beta customers of AWS in 2006 when we’re talking about motivation for technology, making a real impact in the world. Another executive I work with realised that his move into computer science and technology was largely driven by his motivation to scale his impact. He previously worked in radiology and he realised that by working on computer systems, he would be able to help far more people than he would otherwise. These stories can’t really be faked. You definitely don’t want to do it. As dev all practitioners, we know when something feels authentic and when it doesn’t. And this is really important as our audiences are hypersensitive to this sort of thing.

The stories are there, you may have to dig, but they make all the difference in landing what you want to say next. People often ask the question, how long should it be? And my answer for keynotes is actually the same answer I have for anything else. It should be as long as it needs to be and no longer. It’s easy to run long, but it’s not respectful of your audience’s time. Selfishly, if you run long-winded, you run the risk of people disconnecting and tuning out for the things they do tune into you risk diluting the impact of those statements you’re trying to make. There’s no fixed amount or magic silver bullet. Everyone always wants the answer. The sleigh of hand here is in being really, really honest with yourself and doing rigorous self-assessment of your content to make sure that you know what you’re trying to accomplish and how long you really need.

Eliminating everything else that is extraneous to that and making it really clear. You can always dive deeper elsewhere. You can’t regain your audience’s attention or trust. Next, think big. It may be cliche, but the technology we’re representing is likely changing the world in one way or another so that we show up should probably be similarly interesting or grandiose. One of my favourite examples of this is this AWS snowmobile launch from reinvent in 2016. It’s a niche service, not tonnes of customers, but shows the scale, the problems we work on and lengths we will go to solve this for customers. This snowmobile is basically a massive truck that helps exfiltrate data from your on-premises data store and migrated to the cloud more quickly. Because at certain scales, the speed of data, the bandwidth of data going down the highway on a truck is faster than the highest uplink you could have over the internet.

So your company may not have an end-to-end data trucking with an 18 wheeler as a service, but implore you to think what’s your company’s examples of this, of going the extra mile? It may not even be a product at all. I said before, the customers will always surprise you on what they do. And we heard that in the last talk too. This photo was taken on a cell phone inside the International Space Station where our edge device service is being used for remote compute. I love this because there’s no editing, there’s no Photoshop in this. It’s just a photo of a customer taking a picture that’s already doing something really cool. And these are my favourite types of stories to be able to share with the world. And in another case where something is supposed to be nearly indestructible, why not show that? Why not take a flame thrower to it and show it living to tell the tale?

These are the ways that we make these concepts more real for our customers and more exciting. So next, and at risk of sounding like a sceptic is to question everything. I never wrote keynotes for anyone else before I entered this job. I never even wrote talks for anyone else before I entered this job. So if you don’t understand how something works, a question that helps you to get more knowledge, I think day-to-day. I ask way more questions and do way more learning than I do writing or explaining. But it’s one of those measure twice, cut once sort of scenarios questions can lead you to new heights, break you out of the mould that came before. And this is something I truly believe is necessary to do. Things that make history questions like why do we do things a certain way? Should we continue doing it like this?

Or when that crazy idea comes to you in the shower, sometimes the most powerful questionable is one. It’s simple is why not? Why not drive a truck out on stage in the middle of the keynote hall? Why not put full bleed photos of cheese to explain AI concepts? Why not put a developer advocate in charge of this keynote thing? The ingenuity of developers in our entire industry can’t be understated. We live in an era where the computers in our pockets were just the thing of sci-fi just a decade or two ago. Nobody knows for certain where this whole thing leads. So lean in, don’t be afraid to experiment and think differently. Don’t do things just because it’s how it’s been done before.

So here’s my list of tenets. This list has certainly evolved over time, but I can stand by each of these as things that will help improve your content. If there’s one thing you take away from this talk, hopefully it’s these. So thank you. It was a real pleasure to get to share these stories. I’ll be here for the rest of the event. My team is also hiring. If you’re interested in hearing more about keynotes AWS or chatting about our work, I have lots of fun stories to share. I’ll be around at the event. I think I have a little extra time. Also could do q and a.

MC: Yeah, q and a. Anyone have questions? Alright, I’m coming for you.

Audience member 1: I’ll get this one. Thank you. That’s a great presentation. And a question for you. With doing presentations, do you try to stay away from pop culture stuff and memes? Does it feel dated or is it a good way to connect with people? I’m wondering what your opinion is.

Nick: Yeah, great question. Pop culture and memes. I think one of the things that I have learned in this role, particularly at such a global company is that you start to become more sensitive to things that may be funny or a good match for yourself, but then you can be ignorant to how it may not as well internationally or to a broader audience. And so I think when you’re trying to make cultural references in particular, memes are just one example of that. I would try to do that in a hyper localised fashion if I’m working at a talk that’s delivered at one event in one region, but broadly, I feel like sometimes there’s a better way to do it in a more accessible, broader context that may even be less moment in time. As an example, I’ll give one example of that actually. We had a talk.
We were trying to conceptualise how much data was being generated in the world and the need to store it and process it and all of this, it’s another number was something very large on this scale of exabytes. And so we were like, okay, how do we conceptualise this number?

Well, I took the latest run of the mill data centre, hard drive size and said, okay, how many of those would it take? And then if you stacked them in a tower, it would be some amount of 1.5 times the moon and back or something like that, which feels very visceral. People can kind of conceptualise that. And I said, okay, well what if we localise this to a whole bunch of different countries? And I just kind of sheepishly went on Wikipedia, found the tallest buildings in every country, assumed people would all know what they were.

And after putting these drafts in front of some of my teammates globally, they said, oh, well, you may not realise this, but this building is kind of riddled with scandal or this building. It’s very tall, but it’s in the middle of nowhere and nobody knows it. And so this is just one of these examples where even with the best intentions and something that may not be feeling as particularly as even a meme, you don’t know what you don’t know. And so that’s where I’ve really, one developed my spidey sense for what types of content I should do in making those references. But also just being really cognizant of working with local teams. You’ll never know better than they will. Thank you.

Audience member 2: Thank you for your presentation. That was very insightful. I do have a question about if you want to get into doing keynotes. Do you have any? You knew I was going to ask that. You’re laughing.

Nick: No, it’s, sorry.

Audience member 2: You’re like, how did I know that this question was going to come up? I’m curious if you have any recommendations on how somebody goes about actually getting into speaking at keynotes, there’s usually not really CFPs that are aligned for that. It’s usually hand-selected and handpicked.

Nick: Yeah, it is a great question. So how do you get into keynotes? Well, I’ll start with the caveat that before I did this job, I don’t think it quite existed as a full-time role in the way that it does. The role was kind of created and invented. I think in the same way that developer relations is just this intersection of communications, technical software development, marketing, strategic communication.
There’s just all of these different things. If you work at a company, which I think any of us do that perform all of these tasks, find what your highest value, your highest leverage communication channel is. For me at my company. That happens to be keynotes, right? You may not be giving keynotes on massive stages in the same way, but the ability to have someone that can be a single-threaded owner, or at least a feedback provider, which is a great foot in the door to be able to then hold the pen on some of these things is the best way I would go about it.

I don’t think there’s many people that would say no to another. Well-positioned voice in the room to help guide that. And if your company is working on particular things like a demo or a launch of a product, those are great individual work streams that ladder up to a keynote that you could be able to start getting FaceTime with executives and a body of work behind you that ultimately can build your trust internally at the organisation, which is largely what happened for me. I joked it was a series of happy accidents, but it was just a whole lot of different things I had worked on with visibility that ultimately resulted in me being in the right place at the right time.

MC: Any other questions? Yeah, we got one. That was great. Thank you. I’ve got a question. When you are presenting a keynote that you expect is going to be good, but it bombs, how do you get the feedback? How do you know why and what you should be doing differently unless it’s never bond, in which case, ignore my question.

Nick: No, I wish I could say I’ve had ideas that were only good. That’s definitely not the case. Thankfully, most of them get shot down in the writer’s room before we get on stage. But one thing I didn’t talk too much about is measurement. Yes, it’s easy to think as developer advocates, we are our customer, but there’s always some degree of separation. And so you want to measure, you want to assess and reassess your assumptions about your customers and your content. So there’s qualitative and quantitative ways of doing this, but the short answer is it’s an and not an or. We do surveys where we ask people to rate quantitatively what they felt about the keynote distributed on vectors like the speaker and the content and the visuals so that we can actually start to separate the way they feel about it. But separately, the qualitative responses, what are people saying on social media?

What are people saying out in the wild in the hallway when you talk to them? What are some of our most invested customers or our community heroes saying, you take all of this and holistically analyse it to understand one, whether they liked it, because no matter how much you think you know need to ask, but two, why they felt that way, the things that they really liked. Those are the things that we’re going to want to do more of and the things that they didn’t. Well, that’s a lesson that we hopefully learn and then don’t repeat again. So just a whole lot of ear to the ground measurement is the way we do it, but it’s holistic. It’s not like we put into a formula and it tells us how much time we should spend on different things.

MC: Anyone else? Okay, let’s give it up for Nick.

Nick: Thank you everybody.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.