20 February 2023
Presentation, Code
Also Known As: Talk; Presentation
Problem: Your product/service is out, but adoption is low, and part of the problem seems to be that developers don't quite know how to use it or get started with it.
Context: Complex information, particularly abstract and conceptual information, is often hard to communicate in a purely "visible" spectrum (a la writing). For whatever reason, humans still seem to learn and understand more effectively when multiple communication channels are engaged simultaneously--that is to say, when they are shown things at the same time they are told things (so long as those things are supporting each other).
Perhaps there are conceptual parts to what the product/service does that are confusing, or the product/service has a large "surface area" of material that is overwhelming. There may be nuances to certain features that aren't visible at first, or advanced features that require some foundational understanding before being able to be used effectively.
Solution: Deliver a technical presentation at a third-party conference (that is, run by a group or company that isn't your own). It can be in a variety of different forms, ranging from an "all-code, no-slides" presentation in which you have the outline memorized in your head and you code-on-the-fly interactively with the audience, to an "all-slides, no-code" presentation in which you talk about concepts and ideas that would be tricky to pull off "on the fly". Most "breakout" presentations are somewhere in the middle, depending on the topic, the presenter, and (sometimes) the culture of the event.
Most conference breakout sessions are just under an hour in length; anything less than 45 minutes is better categorized as a "lightning talk" (see Variants).
Consequences: (Longer-term planning; submission to CfPs, which come 3-9 months before the event.)
Conference sessions come with financial and logistical requirements for the speakers, travel planning being the biggest of the lot. While many DevRel teams handle these themselves, consider making it easier for them to do so: allow them to work with a travel agency (a human one, not an online one) to make it easier to book travel (and get them home in the event of a travel disruption), and consider working with Accounting to streamline and expedite the process of reimbursement; although it is tempting to tell the team "just float it on your credit card", that may not be feasible and/or financially disadvantageous to the team.
Conference sessions often pair well with conference Sponsorship, including the purchase of Booth space and copious amounts of Swag. If you have more than one session, or more than one of your team is speaking at the same event, consider bringing a Pit Crew and have them visibly present in each of your company's talks, not to act as a cheering section, but to be available for qustions that the audience might have but aren't willing to wait very long to ask. In these situations, consider putting somebody in charge of logistics and event coordination for all of those committed to the event (including Pit Crew), as doing the event as a team can be a strong emotionally-bonding experience to do things as a group (share the same flights, be at the same hotel, coordinate dinners and evening activities, and so on).
Variants:
Beta/Buzz Talk. Although this is less common in an era of open-source, sometimes the desire is to "build buzz" around an upcoming release of the product/service, and one great way to do that is to do a presentation on the new features of the upcoming release before it is generally available. This way developers and customers can be "ready to go" when the release drops, and the feature set might even help attract new customers because they heard about it at the conference. Ambassadors in particular love to give "Upcoming Features" talks, as it positions them and their own branding as being smart and "in the know" when it comes to the product/service. This material is also very powerful when used in a Pre-Sales meeting.
User Group Session. Meetup Session. A common staple of the User Group is to have somebody from the company (or an Ambassador come and speak to the group on some technical topic related to the product/service (more or less). The DevRel team can either help facilitate Ambassadors speaking at the group(s), or have members of the DevRel team do it directly (in which case the DevRel team will need to handle many of the logistics and expense for doing so).
Note that because most user group sessions are more informal than other settings, expect that the presenter will spend more time with the attendees than at a conference. (It is common to go out for food and drinks after the event, or to mill in the room both before and after the talk.)
It is common for DevRel teams to use user group sessions as an opportunity to practice a talk before it is delivered as a Conference Session. Some groups welcome this, but some resent it. If the relationship with the group is strong, ask for feedback on the talk; if it is not, treat it as a formal presentation every bit as "real" as the conference or a Customer Meeting.
Sponsored Conference Session. At times, a conference will sell a speaking slot to a sponsoring company, guaranteeing the company will have a speaker at the event without going through the traditional Call-for-Presentations process. Be warned that developers historically have not taken well to these slots, doubly so when the sponsor chooses to do a presentation or talk specifically around their product/service. If your team is sponsoring the slot (perhaps the Marketing or Sales team decided to buy it without consulting you), consider not taking it--let somebody from Marketing or Sales do the presentation, so as to preserve the credibility of the DevRel team with their developer audience. If the DevRel team must do the sponsored presentation, then be up front and respectful of the developer audience: "Hi, my name's Denny, I'm from ToolCorp, and we threw some money at the organizers to get this time slot. What I'd like to do is show you the pros and cons of our tools, and give you some idea of when--and when not--to use our stuff." Don't try to "hide" the fact that this is a sponsored session--most attendees can already tell, owing to the different advertising around sponsored sessions. If metrics are captured for this session, do not compare them to other Conference Sessions, as the surrounding context of each are different enough that it is comparing apples to oranges.
Brown Bag. Lunch-n-Learn. When the direction of the activity is pointed internally, these become known as "brown bags" or "lunch-n-learns", wherein the DevRel team (or other internal employees of the company) deliver the presentation (often over the lunch hour) to other engineers within the company. These can be organized periodically (weekly or monthly), as part of an internal Hackathon, or as part of the company's internal conference (or all of the above). If there is no formal internal training team, the DevRel team should take on the organization, logistics, and "acquisition" of speakers (internal or external) for such events; if there is a training team, DevRel can be frequent speakers, and/or help with the acquisition of speakers, and/or help with some of the logistics. Note that if internal employees are interested in speaking, DevRel should (must!) volunteer to assist that employee in the preparation and practice of delivering the presentation, since many developers are not comfortable delivering or preparing presentations.
Note that if DevRel is scheduling these, it's often best to start with monthly events, then move to biweekly and weekly as the "pipeline" grows. Let the upcoming pipeline grow to six months' in advance before reducing the timing--for example, if you are doing monthly sessions, and you have six months' speakers/topics in the pipeline, go biweekly (thus reducing your pipeline to three months' worth) and rebuild the pipeline out to six months' worth before going weekly.
Lightning Talk. Any presentation that is 30 minutes or less is generally best considered to be a "lightning talk", and requires very different preparation and delivery considerations. (You will not have time to write code on the fly. You will not have time to take questions. Instead of three things to talk about, focus on one. Scripting the talk is easier when it's shorter like this, particularly if the deadlines are "hard" and no wiggle room.)