How to rock a technical keynote

Avery: I have to explain what engineering communications is. It's DevRel adjacent, I think of it as applied thought leadership, in presentations, in media and in application design. I'm the Head of Engineering Communications at MongoDB and I am here to tell you how to rock a technical keynote. I promise that's the last time I'm going to do that this time. A technical keynote, when I say that, what I'm talking about is specifically the kind of keynote that comes coupled with a big, sort of annual developer conference where a bunch of announcements happens and we roll in a bunch of like software demos as well. And, a really rocking technical keynote is going to, it's going to set the tone and the purpose of the whole event. It's going to take all of the facts that the event exposures, the product roll outs and the features and the competitive analysis and all of the vision stuff and tell everyone exactly what it means.

But even more importantly, a really good rocking technical keynote is going to generate excitement because developer excitement cannot be bought. It can only be inspired. And these things take a ton of work to do. There are a lot of hands that go into it and they have to sweat a lot of details that are not present in a lot of other types of keynotes. Yeah, it has to get all the vision, the narrative and the inspiration, but it also has to get all the code snippets and the architecture diagrams and, oh the live software demos. Correct. And it's really hard to do that, but it is also really worth it because, when you get this stuff right, it's really inspiring, and that's actually why I'm talking to you about this stuff because there's a dearth of people who really get the storytelling aspect and also the technical aspect of this stuff.

Now, for the past four years, my team has been building the keynote for MongoDB's CTO, Elliot Horowitz, which he presents at our annual developer conference, MongoDB world. And last year's, this past world keynote was about 90 minutes long and it contained five live software demos. And after we do that, we abridge it down to 60 minutes and three software demos if you take it on the road and present at our sort of regional conferences. When you get all this stuff right, it makes the difference between a really engaging experience. It makes a really good keynote. When you don't, it's like meh, fine. And meh fine keynotes are going to do the same thing to a developer conference as meh software is going to do for user experience. And it's unfortunately too common for that to be the case.

Today, I'm going to show a synopsis of the method that I use to break down this beast that takes tons of people to work on, and bring it into a five part agile process. Those parts are ideation, composition, slide-craft, rehearsal and present and production. And so what I want you to do, is take these methods and try and apply them to your keynotiest presentation. And if there isn't a keynote presentation on your horizon, I actually would like you to try and find a way for you to do that. Like I said, there's a dearth of expertise in this regard, in the hands that normally come to touch these things. And, it would be really helpful if you would find, take an interest and actually lead by interest in all this stuff.

I'm going to go through all this stuff with a lens towards the technical keynote and bring to you some of the pragmatic tactics that have enabled us to be pretty successful with this stuff. Like I said, it's going to take a lot of hands to do this, specifically, maybe over 100-150 hours worth of time; from comms engineers, a speaking coach, five engineers building software demos, supplementary people chipping in on the engineering effort, product managers, et cetera. Oh and the CTO also. And, so it takes a village, but, when you get this right, it doesn't just let them know what your plans are and how to use the software and everything like that, it actually helps all of the users who come to your conference tell your story to other people because they get that story and they saw it in action. Really commit to this whole thing and it'll pay off dividends.

The first phrase is ideation. It's a little bit like the calm before the storm because this is all of the setup work that has to happen before we can divvy out all of the tasks. You have to have something that stitches everything into a narrative. And you also know you have a concrete list of announcements that are going to go out and you got to weave those together and make sure that suits. And that's why you get into a room and you spitball and you hash it out and everything. This is an iterative process. You want to imagine the most expansive, most amazing keynote that you can deliver, but you know that time and resources are limited and some of the stuff is outside of your control. For example, some which software is done in time, and so you're going to iterate towards it. And, you want to get started by getting all that stuff that goes into a good storytelling. I'm not going to go into all that stuff because you're good at that. But what I will say, is when you're done and you have the, you've identified the audience that you're talking to and you've got that message and everything like that, you need to actually start committing that to artifacts of alignment. Because a lot of people are going to be working on this stuff and they have to be marching in the same direction. The first part with all of the messaging, that's what I would think of as a scope document for a keynote. And then once that's all taken care of, you're going to get started turning that into a spec document for a keynote or an outline, outline, but a special outline, because this one contains specs for demos.

Once you have these specs done, you can get started, moving on. But, I want to say one thing about outlines for these things, like I said again, and I'll say it over again, a lot of people have to work off the same artifacts and so an outline needs to be really specific in what goes on. Now when you work on your own outline, you might use some shorthand and be like, okay, I'm going to cover this section like that. Here's an example of something that's vague. Okay, blah, blah, blah, we're talking about stuff and it's like, okay, we're going to talk about the benefits of distributed systems. I can't give that to a designer and say, I need icons for the benefits of distributed systems. I need to know what the speakers are exactly going to talk about. I can't tell the demo presenter who's going to be building a demo that might demonstrate something exactly the point. No, I actually need something actionable that says, well, we're going to talk about scale out, uptime and workload isolation. So this is these, this is the sort of thing that you need to do when you want to parallelize all of this effort, because you worked for three months on this thing. You have a lot of moving parts and they need to come together.

Software demos. I know it's a fraught topic in this crowd, there is no substitute for a live software demo in one of these keynotes because we're not trying, we're not trying to teach people to use the software that's being presented on this keynote stage. This is not about pedagogy. This is actually about something else. It's about testifying to the truth of your claims. The demo presenter's job is to basically show the world that the thing that you're announcing is capable of doing the things that you claim it's capable of doing and also showed it in a context that makes it seem useful to do. That's the storytelling part of the thing. That is why it's part of the demo outline or sorry, rather the keynote outline itself, they are messages that you need to get out there. And you obviously have a session about how to use all of the stuff that you're announcing. That's the whole point is that you've got this big conference, you're going to teach everybody how to use this stuff.

The demo presenter gets up there, gets them excited, directs them to the session and gets out. In order to make sure that this happens really effectively and gets on message, we use a spec document for the software demos that includes a bunch of stuff that you wouldn't necessarily find in any other, in any other spec because this is about messaging goals. Demo name and presenter name, that should be obvious. But, one thing that might come clear from this, is that this isn't just about aligning a facilitator to someone who's going to build a demo, it's also about visibility. Anyone should be able to look at these documents and understand what's being built and what state it's in. It's not just for the two people involved in talking about that. But then of course, there's the section that you want to be like, okay, it's happening in this section. Again, you're going to have a conversation with the person who's building this demo about that. But then they can go back to this document as they're going through and building it, and know what they're doing without having to come back to you. And then we talk about messaging headlines. Here, I'm going to give you an example of this.

There's a full tech search product built on Lucene. So here's a message headline that if the demo does nothing else but this, it has to do this, Atlas full text search uses the power of Lucene to search your MongoDB data with a single click. Boom. That's the message that we have for you. Okay, but, we can go deeper. For example, use it, you can use advanced Lucene features. It automatically kept in sync, no servers to manage, it doesn't matter what they are. The whole point is that these are touchpoints along the way that have to be communicated. And then of course, as we go further along into the process, this document got, has to get filled in with the outline and the script and set up instructions for later because this has to be reproducible. This is not going to be just the demo presenter's job to carry around the sacred laptop with the demo on it. This has to be operationalized. You got to have a number of people who can do that. We're going to talk about how many laptops we're using for this later. Okay, great. Composition is where the rubber meets the road. And, you can now start getting all kinds of stuff going on in parallel.

There are a lot of sub parts to this process. First of all, you got to learn to say real words instead of  outlined bullet points. You got to build those working demos. And then you're going to use a lot of restraint and build slide wireframes instead of real slides and you have to practice strong transitions. I think everyone here gets that. And then finally, this is in order of how late you can defer into the process. These things obviously, you got to start working on those demos and late into the process, you can insert the callouts to sessions. I'm only going to talk about the things that are really specific to these big multi-person efforts, for these keynotes because again, this is why I'm talking to you. You already get to say real words and how to make sure that people are aligned on story. We just watched a great talk about that.

Let's talk about the building working demos process. Okay, so first, pragmatic advice. This stuff is coming in hot. Often the features aren't even done being built yet and it's being often in our case, we really like to showcase the engineers who produce this stuff, the demos being produced by the same engineer who's on the hook for delivering the feature. There's a little tension there. So you want to make sure that that stuff is set up early and that you're checking in weekly.

So weekly demo demos. And then sort of in the middle of this process, we're going to set up a midpoint demo review panel where everyone who's on the hook for a demo, now all along the facilitators have been checking in with these weekly demos and making sure that they're progressing from a software development standpoint and that they're sort of hitting the messages that you've outlined in those goals. But this is the opportunity for the CTO who has opinions, and the product managers and everyone to get in a room and see how things are shaping up and spitball and steer and tune up. And then, there's time left to make some changes. I would love for you to code freeze two weeks out, shift that schedule back. Make sure that you're not sweating the night before. But, I have no promises.

And here's the thing, ultimately, like I said, it's iterative. And you can cut a demo. That's what happens. We have to cut scope. It's not working. The demo isn't working, the feature isn't delivered, that gets pushed out. That's the real world. I mentioned slide wireframes before and a judicious, judicious restraint, during the spit-balling process, we're like, we're in a room and hashing things out and talking to an outline and it's awkward because you're delivering a talk that you've never even done before. That's where I'm sort of sitting in the room, in my part of this process, sketching out ideas for slides, getting inspiration over these graphics like this. We want to build like that. It is not worth it, to start polishing slides at this point.

There are two real main reasons why you want to use wireframes, which I'll show you examples of in a moment. Number one, this talk track can evolve without blocking on graphics. This is such a big endeavor. I think there were 119 slides in last year's world. If you had to wait for graphics to get done, so the presenter could actually start rehearsing and get real sidebar, we talk about heading towards a click, click stable click stable demo, you're rehearsing these clicks, they're probably 500 clicks in the last world talk. This is an enormous part of rehearsing, so you have to make sure that the presenter can actually get there and not have to relearn all that muscle memory. That's part of why they're rehearsing with these wireframes and you're making sure that even if the graphics aren't done, it's approximating what they're actually presenting. Okay, and the other thing is you want to defer work on that, what might change. It's an iterative process and it's an agile process. And anytime in there you can say, "Oh, this isn't working. Let's cut this slide. Let's consolidate these slides. Oh, we have to go into more detail". You've done all this work for nothing if you really polish those up.

Here's an example of wireframing with sketches. This is the drawing that I did on my iPad during a spitball. And once a graphic designer gets to it, it's actually pretty nice. Here's a, you can also do them, with wireframes in the deck. And so for example, here's a build that could actually be in a slide, but, then later on it looks like this. Nice, right? And one of the, so, pause. Session callouts are the things that you use they're like a CTA, they're a call to action and, so you're going through your keynote, you're really jamming, you're rocking, you've got the messages, they're tied into the demos. People are excited. What do they do next? Well, that's when you drop one of these in front of them. If you like what you just saw, please go see this talk at X o'clock in this room. And it's not just that you're directing it to them, they could look at the program. It really improves the integration of the keynote to the event. And that is the whole point, because it's supposed to feel like one thing. If this software conference for developers is a term paper, your keynote is your thesis.

Now, we have wireframes and we want to move to polished graphics and everything. Slide-craft, again, I think a lot of people here are actually better at that than I am. But what I can tell you a little bit about is the process of making sure that things go from those wireframes to really nice looking stuff. And for that I use a punch list. That's a term that comes from construction. I don't know if it's common, but it basically means the list of stuff that you got to do. And we know that as we get towards the end of the process, we're going to be time constrained and we're going to want to, we're going to look to cut scope and try and get away with what we can. And so we use this punch list to coordinate all the work. Here's a picture. I don't think it's a, this is actually excerpted from our Google sheet. The really important things here are, we've got priority and effort up in here. And, here I'll show you my priority key in webpage brokenness terms. The most important one is 404, number two, dig header image missing, three, only runs in Chrome. Whatever you can get by, loads a little slowly, that's fine. Whatever, the whole web loads slowly and no favicon. Whatever, I didn't even look in that bar. Okay, but this is the metaphor for the sorts of ways that I file how urgent something is. And then of course there's the effort, scale five minutes, half an hour or an hour or two hours, four hours. You don't need any more granularity than that. And by weaving those two things together and iterating, you can wind up with something, well, it's a two until you replace it with something that's better and then it becomes a four because it's not perfect, because you imagine something way better. I do all the time, but it'll do, you're not going to look stupid putting it up there.

Here's an example from our world deck of build of all these icons; full text search, charts, triggers, Kafka connector, real mobile database and MongoDB Data Lake. And this was a bill that we did that incorporates all of the services in the cloud platform. It didn't start out this way though. And if we didn't get these graphics, if they were, if they'd never been built and I needed to ship the keynote, it would have been okay if we had done this. But that would have been a two because these are important and they have to be nicer. And we could have done this also. And this was slightly better cause it's a little more design and actually we could make these look prettier without them being graphics. And then maybe that would be a three. That's using the punch list to iterate fan out batch work, get it back and cut scope when you need to.

And then rehearsal. Okay, so everyone here again, I assume I'm new to this crowd, but, I'm getting that everyone, people are good at this, around here. And so rehearsal is the difference between professionals and amateurs. My friend and the speaking coach for MongoDB is fond of saying, and I have worked with like, I don't know, like 100 speakers. My friend Greg has worked with 1,000. We keep hearing reasons that someone doesn't want to rehearse. You got to work through that stuff.

The tip that Greg gave me was to think about this; do you know how many minutes or hours of time, what the multiple of rehearsal time to performance time is when you're doing professional productions? Anyone? Guess? Yeah, okay, right. So, professional performers put in one to two hours of rehearsal per minute of stage time. And when you look at it that way, my ask that you put in a minimum of 10 times is really quite humane, I think. Now, again, skipping most of the stuff about making sure that you're polished and getting your rehearsals done, there is one thing that I'll tell you doesn't come up a ton unless you're doing live software demos, which is fire drills for those demo presenters. And, I will admit that I do enjoy this a little bit. Naomi thinks it's because I have a cruel streak. But, I make the demo presenters get up there and I yell at them, your network's out or the laptop crashed. And because it's really important for them to be able to learn how to get off the stage gracefully. I mean, I don't make them sink or swim. I tell them what to do. Like I tell them, "Okay, well you got to make sure that there's no dead air, blame the network", all this stuff. And ultimately be like, "Oh, I'm sorry, demo's not working. I don't want to waste your time. I'm going to be at that booth later. Come, I'd be happy to give you a demo in person, back to you Off stage".

Okay, so the production side is where everything really starts to heat up. I mean, it's already hot, but at this point you have cut down all the stuff that you don't need to do and it's time to start making sure that those demos really work on stage. So the checklist of stuff to do for this from here on out. Okay? No personal accounts. I know, I don't want my demo presenters using their own AWS credentials or MongoDB Atlas credentials of their own, my own stuff that I'm in control of all of the keys and you should have that. You want to be in control of that and be able to have other people do it. And have everybody be able to know that they can open up the demo laptop and log into that one account. Okay, so, here's a little tip for web apps. You have to, using synced bookmarks will let you administer these stuff on multiple laptops and have redundant laptops, which you should have, redundant laptops, because you don't want, some sort of Catalina based disaster, which I have been experiencing, to interrupt your demo.

You always want to use what I would call the cooking show time-lapse maneuver where it's like, "Okay, I'm going to give you a demo". "Hey, we're going to build a full tech search index right now" "Oh, and look, here's one where the full tech search index is already built". Okay. So, pre-production means making sure that all the T's are crossed and the I's are dotted because Slack will crash on you on world keynote day as it happened to me two years ago. And you need to know everybody's contact info so you can call them on the phone and make sure where they are, need to run of show document that shows by the numbers where things are and you need to know, you need to set up conference room dress rehearsals in advance so that you don't have to do your first rehearsal on site. On site, when you get to it, you need at least one gopher. Because when you're setting, putting out fires, you do not want to also be getting USB cables from Best Buy. You need that full shakedown run the day before, you show up, set up the laptop, everything's good and make sure screen resolutions, et cetera.

Let's cut to the review over here. So, we've got ideation, where you're working on where you're making sure that these scope and spec docs are there. So everyone's aligned and, we've got composition where you're actually turning this back into something that you can perform, with demos working and slide wireframes, so that you're not wasting your time and session callouts later in the process. You've got your slide-craft, working on punch lists and rehearsal time, which is so important and changes everything from amateur to professional. Okay, and then production. Oh, and then my connection is lost in the Apple kit and the keynote crashes. But I will tell you how I wrap it up, which is that if you do all this right, then you've got yourself an amazing keynote and you can talk to the people in your audience later and find that they're ready to tell your story for you. Thank you everyone.