> ## Documentation Index > Fetch the complete documentation index at: https://lib.findy.co.jp/llms.txt > Use this file to discover all available pages before exploring further. # How to plan and run an online tech event, start to finish > Covers what distinguishes online events and the four phases of running one: planning, preparation, the day itself, and follow-up. ## Overview An online event is an event in which speakers and participants join over a streaming or video-conferencing service instead of gathering in one place. For a company practicing DevRel, it is one of the most common ways to host its own events, because it can be run repeatedly at modest cost. This page covers how to run an online tech event. It first describes what distinguishes the online format, then defines the four phases of running an event and works through what each phase requires. ## What distinguishes online events Four properties separate online events from in-person ones. Each widens what the event can reach in one direction and constrains it in another. Publishing the recording of an event afterward is called an archive stream. | Property | What it widens | What it constrains | | - | - | - | | Reach | Participants can join from anywhere, and the size is bounded by the streaming service's capacity rather than a venue's | The event competes for attention with everything else on the participant's screen | | Barrier to entry | No travel, so people can sign up on the day or join partway through | Signing up costs little, so a share of registrants do not attend | | Interaction | Questions arrive in writing through chat or a Q\&A tool, which makes them easier for quiet participants to ask | Speakers cannot read the room, and silence on a stream feels long within seconds | | Recording | An archive stream reaches people who could not attend at the scheduled time | Participants who know a recording will follow are more likely to skip the live session | These properties shape the practices in the rest of this page. Late joiners are why slides should carry what is said. The lack of a room to read is why facilitation and question handling need dedicated people. ## The four phases of running an event Running an event divides into four phases: planning, preparation, the day itself, and follow-up. Each phase produces what the next one depends on. ```mermaid theme={null} flowchart LR A["Planning
purpose, target,
metrics"] --> B["Preparation
speakers, title,
promotion"] B --> C["The day
facilitation,
questions"] C --> D["Follow-up
survey,
retrospective"] D -. "feeds the next plan" .-> A ``` Most of an event's outcome is decided in the planning phase. If the purpose or the target audience is vague, careful preparation and smooth facilitation cannot make the event reach the right people, because the speakers, the title, and the promotion are all chosen to fit what planning decided. Follow-up connects back to planning. What the survey and retrospective reveal becomes input to the next event's plan, which is why the phases are a cycle rather than a line. > [!NOTE] > > Lightweight formats such as an informal lightning-talk night or a co-working > session do not need the full sequence. The four phases pay off when an > event has a specific audience and a goal to reach. ## Planning Planning means deciding, provisionally, why the event is held, for whom, and how its result will be judged. A plan is complete when each of these can be stated in one sentence. ### Narrow the purpose to one Give each event a single purpose. With several purposes, each later decision can be justified by a different one, and it is common to finish preparation and then find that the chosen angle fits none of them well. ### Identify the target and ask them directly Name the target audience concretely: their role, their experience with the topic, and what they would want to take home. Then test the plan by asking people who match that description, such as engineers who use the technology at work. Asking is faster than research for this question. Published material shows what exists, but only the target can say whether they would attend and what would make the event worth their time. Before asking, write down who you want to attend, the goal, and what you want to learn from them. ### Set metrics for the purpose Decide in advance how the purpose will be measured. Without a measure, the follow-up phase has nothing to check the result against. | Kind | Examples | | - | - | | Quantitative | Registrations, attendance rate, visits to a page the event points to | | Qualitative | Survey satisfaction, what survey comments say participants learned | ### Judge a technology's maturity by what has been written about it For events about a specific technology, timing matters. Too early and no speaker has enough experience to talk about; too late and the audience that wanted an introduction has already moved on. The quality of articles published about the technology is a usable indicator. | What articles exist | Timing | Reason | | - | - | - | | Only summaries and announcements | Too early | Few people have used it yet | | Sample code and tutorials | Borderline | There is not yet enough experience for a talk | | Implementation notes and pitfalls | Suitable | People have started using it for real work | | Only case studies from production use | Audience is narrow | It no longer appeals to people who are about to adopt it | Attention on social media is not the same as demand. The test is whether engineers in the target audience would want to try the technology. ### Alternate between deciding and researching Do not try to settle the plan in one pass. Make a provisional decision, research whether it holds, and revise it. Each round raises the resolution of the plan. When the plan cannot be put into words, it usually means the provisional decision has not been tested enough. When a choice such as which speaker to invite or which format to use is hard to make, return to the two anchors — the target and the goal — and pick the option that serves them. ### Drop plans readily Dropping a plan is a normal outcome of planning, not a failure. Drop or postpone a plan when any of the following holds. * No published work or practitioner supports the premise. * Another organizer has recently held an event on the same theme. * The target or the goal cannot be settled. A plan pushed through despite these signs rarely draws its audience. A dropped plan often becomes material for a later one. Finally, check whether the people running the event want to hold it. Planning and preparation take sustained effort, and that effort is hard to maintain for a theme the organizers themselves are not curious about. ### Finding topics Topics come from watching where engineers discuss technology. The main sources are the following. * Social media accounts where engineers post about their work * Technology tags on social bookmarking services * Engineering blogs published by companies * Special issues of technical books and magazines * Internal chat channels where engineers share what they are reading * Events held by other organizers Keep a list of keywords that catch your attention, even ones you do not yet understand. Start researching a keyword when it crosses a threshold: it appears across several of these sources within a short period, or a well-known practitioner mentions it. Engineers inside the company are another source. Ask them what they find interesting about a technology, after doing your own research first so the conversation goes beyond basics. Past events that drew a strong response are also a valid starting point; identify which element — the speakers, the theme, the format — drove the response, and reuse it. ## Preparation Preparation turns the plan into an event people can find and attend. It covers inviting speakers, writing the title, aligning with speakers, and promotion. ### Invite speakers The invitation should make clear why this person is being asked. Mention the articles or talks of theirs that you read and how they fit the plan, so the recipient can see the request is based on research rather than sent in bulk. State who you are and what the event is. Keep the message short enough to read on a phone. Prepare more than one candidate for each slot, because invitations are often declined or go unanswered. ### Write the title The title is how the target audience decides whether the event is for them. Include the keywords the target would recognize, and make clear what the event covers and what participants will take away. Avoid the following kinds of expression. They attract attention once but cost trust over repeated events. * Alarmist or excessively negative phrasing, such as claims that something is about to become obsolete * Phrasing that favors one technology or role over another * Emphasis on age or other attributes that pushes other people away * Themes that already carry a strongly negative image Show the draft title to the speakers during the alignment meeting. A wording the speaker is uncomfortable with makes the talk harder to give and creates expectations the talk will not meet. ### Align with speakers in advance Hold an alignment meeting with each speaker, typically about 30 minutes. Explain the background of the plan, why you invited them, and the target and the goal. The same technical theme calls for different content depending on the audience, so the speaker needs this to decide what to say. Settle the talk theme by asking rather than prescribing. Ask which parts of the topic they could not talk about, and which parts would be interesting to go deeper on. Ask speakers to put what they will say on their slides. Participants who join partway through can catch up, and the organizers can follow the content and prepare questions in advance. ### Promote the event Promotion is the work of making the event known to the target audience and turning that awareness into registrations and attendance. Announcements from the speakers are the most effective channel, because they reach people who already follow the speakers' work. Speakers announce an event they are looking forward to. The alignment meeting is where that attitude forms, so use it to make the event something the speaker wants to do, and ask there whether they would share the announcement. Posting from the event's account with the speakers mentioned makes it easy for them to share. Send reminders the day before and on the day. A short, specific message about what participants will hear keeps their interest and reduces last-minute cancellations. ## The day of the event On the day, the organizers' job is to keep the event focused on what the target audience came for. That depends on checks before the start, a clear division of roles, and facilitation. ### Before the start Meet the speakers 15 to 30 minutes before the start. Confirm once more what the event is meant to give participants, and check audio, screen sharing, and the streaming controls. ### Divide the roles Assign the behind-the-scenes work to specific people so that the facilitator can concentrate on the conversation. | Role | What it covers | | - | - | | Chat and questions | Monitoring chat, collecting and organizing questions for the speakers | | Social media | Watching and responding to posts about the event | | Timekeeping | Tracking the schedule and signaling the speakers | | Speaker coordination | Relaying messages between speakers and organizers during the stream | | Next steps | Sharing links and pointing participants to what follows the event | The number of people needed grows with the audience. As a guideline, one person can cover an event of up to about 30 participants, two people up to about 100, and three or more beyond that. ### Facilitate the conversation Facilitation keeps the conversation moving and evenly shared. In panel-style sessions, watch the following. * **Do not let silence run long.** On a stream, a pause of a few seconds already feels like a problem. Keep spare questions ready for when a section ends early. * **Do not talk too much as the facilitator.** The participants came for the speakers. * **Let speakers address each other.** A session where only the facilitator asks questions becomes a series of interviews. * **Watch the balance of speaking time.** Bring in speakers who have spoken less before one voice dominates. At the opening, state what the session will cover and what it will not. This sets participants' expectations and reduces dissatisfaction from people who came for something the event never planned to address. ### Answer every question Make it the rule to answer every question during the event, not as many as time allows. Reserve enough time for this; for a 90-minute event, set aside at least 30 minutes for questions. Collecting questions at registration and sharing them with the speakers beforehand helps fill this time. Questions that cannot be answered on the day are answered afterward, for example in the follow-up message to participants. ## Follow-up Follow-up checks the result against the purpose and carries what was learned into the next plan. Analyze the participant survey while it is fresh, ideally by the next business day. Hold a retrospective with the speakers as well; they often have feedback on the plan and the facilitation that participants cannot see. Check the result against the metrics set during planning, and also look at the following from both sides. | Side | What to look at | | - | - | | Quantitative | Registrations and attendance compared with past events on similar themes; whether the date overlapped with other events for the same audience | | Qualitative | What survey comments have in common, both what worked and what did not; whether participants' level matched the intended target | Reflect the findings in the next plan. This works only if the purpose, target, and metrics were written down during planning, and if changes made between planning and the event were recorded. Without them, there is nothing to compare the result to. ## Related pages > [card] [The role of DevRel](https://lib.findy.co.jp/devrel/engineering-culture.md) > > Why a company hosts events at all, and the principles that keep them > serving the community. > [card] [Engineer Growth](https://lib.findy.co.jp/organization/engineer-growth.md) > > Team study sessions run on the same cycle of planning, holding, and > reflecting on a smaller scale. > [card] [Understanding Developer Productivity](https://lib.findy.co.jp/productivity/why-measure.md) > > How to choose metrics and avoid misreading them, which applies to judging > an event's result as well. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.