Photo by Samuel Pereira on Unsplash
Det er mye å tenke på når man skal sende inn et forslag til en presentasjon. Ikke bare bør du ha en god idé til hva du vil prate om, men du må også klare å overbevise noen om at de bør velge akkurat ditt forslag! Da kan det være greit å vite hva de på andre siden av skjemaet tenker og ser etter.
Dette dokumentet er et forsøk på komme med noen perspektiver fra programkomitéen sin side, og ikke minst noen tips og triks for å hjelpe deg å øke sjansene for akkurat ditt forslag.
Før vi kommer til konkrete tips og triks er det verdt å ta et par øyeblikk til å si noe om hvem jeg er, og hvilken erfaring disse rådene bygger på. Man skal jo tross alt ikke høre på hvem som helst som mener noe på internett!
Jeg har vært med på å arrangere ulike konferanser i ca 8 år nå—nesten like lenge som jeg har jobbet i Bekk. Jeg var med JavaZone fra 2012 til 2017, der jeg i starten var mest aktiv på den tekniske siden med å lage diverse systemer og sette opp infrastuktur, men etter hvert også var med i programkomitéen. I 2016 var jeg med på å arrangere første utgave av DevOpsDays Oslo. Og jeg har vært med på å arrangere Oslo Elm Day fra starten, hvor vi nå er på tredje iterasjon (selv om 2020 nå desverre er blitt korona-utsatt).
Jeg har altså vært del av litt forskjellige programkomitéer, både for små og store konferanser.
Ikke alle programkomitéer jobber på samme måte.
En stor konferanse som JavaZone får for eksempel inn langt flere forslag, og har en mye større komité som skal bli enige om dem, enn det en liten konferanse som Oslo Elm Days har. For en liten konferanse kan du derfor anta at alle i programkomitéen vil ha tid til å sette seg nøye inn i forslaget du har sendt inn. Mens sender du inn til en stor konferanse, der du konkurrerer med hundrevis (om ikke tusenvis) av andre, så vil ikke alle i komitéen kunne sette seg like dypt inn i alle forslagene. Hva betyr det for deg i praksis? Jo, det gjør det ekstra viktig at forslaget ditt er lett å få oversikt over, slik at selv en rask gjennomlesing gjør komitéen interessert.
En annen forskjell er at noen konferanser benytter en såkalt double-blind review-prosess. Det vil si at ikke bare vet ikke du hvem som kommer til å vurdere forslaget ditt, men de vet ikke hvem du er heller! Dette gjøres naturligvis for å fjerne biases i vurderingen av forslag. Men det fører også til at forslaget må stå på egne bein, uten at dine tidligere meritter kan hjelpe til med å overbevise komitéen. Det bør fremkomme av CfP-en hvorvidt den gjøres blindt.
Uavhengig av størrelsen på konferansen så har alle de komitéene jeg har vært med i jobbet etter en forholdsvis lik metodikk. Vi har startet med en iterasjon der vi går igjennom alle forslagene og vurderer hvor aktuelle de er. En god del forslag ryker ut allerede her. Deretter iterererer vi gang etter gang på de resterende forslagene, gjerne med tanke på ulike dimensjoner av programmet, til antallet er kuttet ned til det programmet har plass til. Målet er å ende opp med en perfekt blanding av de tingene man har blitt enige om at programmet bør inneholde: Det kan være ting som fordelingen mellom nybegynner-vennlige vs avanserte foredrag, ulike temaer en ønsker dekket, praktisk matnyttige vs teoretiske eller artige foredrag, og mye, mye mer.
Vær klar over at vi som regel ganske tidlig i disse iterasjonene kommer til et punkt hvor det begynner å gjøre vondt å si nei til forslagene. Vi må alltid kutte mange, mange foredrag vi veldig gjerne skulle hatt med. Med andre ord, selv om du får avslag på et forslag du har sendt inn så betyr ikke det nødvendigvis at komitéen ikke likte forslaget ditt!
Okay, nok sirkling rundt grøten… Her kommer en liste med 16 (mer eller mindre) konkrete ting å tenke på når du skal skrive forslaget ditt.
Photo by Lukas Blazek on Unsplash
Det første tipset virker kanskje opplagt på de fleste. Men tro det eller ei, det er ikke alle som legger like mye flid i forslagene de sender inn. Det er ikke uvanlig at forslag forkastes, rett og slett fordi de er for dårlig beskrevet.
Det er generelt en høy korrelasjon mellom hvor mye arbeid folk ser ut til å ha lagt i utforming av et forslag, og sjansen for at forslaget blir valgt. Et godt utarbeidet forslag gir oss inntrykk av at du vet hvor du vil med foredraget, og at det ikke bare er noen løse tanker du kastet sammen på 5 minutter.
De foredragene som er dårligst beskrevet ryker ofte ut allerede ved de innledende vurderingsrundene til programkomitéen. Ved å ta deg litt ekstra tid—for eksempel ved å bruke tipsene herifra—unngår du forhåpentligvis å være blant dem.
Mange CfP-er skiller på beskrivelse av forslaget overfor programkomitéen og den beskrivelsen som konferansedeltagere skal få se. Feltene kan ha litt ulike navn i forskjellige skjemaer, men hhv “Outline” og “Description” har vært vanlig i de CfP-ene jeg har vært med og utforme.
“Outline”, altså beskrivelsen rettet kun mot programkomitéen, er det absolutt viktigste å fokusere på for å selge inn forslaget ditt. Her bør du være så konkret som overhodet mulig om hva du ønsker å formidle i foredraget ditt. Gjør du en god jobb her, så blir det tydelig for oss at du har tenkt igjennom ting, og har god kontroll på materialet.
Du trenger ikke stresse for mye med perfekte formuleringer og ordbruk her. Det viktigste er å få frem hva du tenker å gå igjennom. Et godt format er gjerne å skrive noen avsnitt som oppsummerer forslaget, fulgt av en punktliste som går igjennom de ulike delene av foredraget i form av stikkord eller setninger. Bonuspoeng hvis du legger på (ca) fordeling av tid på de ulike punktene.
Noe mange gjør er å hinte om ting det skal prates om, eller konklusjoner som skal trekkes, i foredraget. Sånt er fint overfor publikum, men hører ikke hjemme når du skal overbevise en programkomité.
“Description” er altså feltet hvor du beskriver foredraget slik det skal se ut i programmet overfor publikum. Feltet kan noen steder hete andre ting (“abstract” er en annen vanlig variant), men det kommer forhåpentligvis klart frem hva som er ment for publikum og hva som er rettet mot komitéen.
Komitéen er forhåpentligvis allerede solgt på foredraget ditt (siden du skrev en awesome outline). Det vi ønsker vi å finne ut her er om dette er noe som kommer til å trekke folk. Det hjelper ikke om vi tror foredraget blir bra, dersom det ikke trekker publikum.
Siden dette feltet gjerne skal være langt kortere enn “outline” er det også vanskeligere å skrive. Fokuser på å formidle hva du skal prate om, og hvorfor det er interessant!
Den største utfordringen er at folk er late, og du kan ikke forvente at de leser beskrivelsen din særlig nøye. For å sikre at du får formidlet det som trengs før folk har hoppet videre til å lese om neste foredrag er det derfor en god tommelfingerregel at en ved å lese de 2-3 første setningene bør kunne vite hva temaet for foredraget er.
Tittelen er din mulighet til å gi et godt førsteinntrykk, både til publikum som leser programmet og til komitéen som skal vurdere forslaget.
En god tittel får folk til å lese videre på beskrivelsen av foredraget. (Eller, hvis den er god nok, til å overtale folk til å dra på foredraget helt på egenhånd!)
Tittelen skal være både konsis og fengende. Den kan gjerne være morsomt, og gode ordspill og liknende kan være gull. Men husk at den også må være informativ. Det hjelper ikke om tittelen er kjempeartig hvis den ikke hinter noe om hva temaet for foredraget er. Det er veldig vanskelig å finne en god balanse her.
Som en liten bonus vil også en catchy tittel skille deg fra mengdene av andre forslag som skal vurderes av programkomitéen. Jeg husker fortsatt enkelte forslag vi vurderte for 5-6 år siden, nettopp fordi de hadde spesielt gode titler.
Photo by Jonas Jacobsson on Unsplash
Hvor avansert er dette foredraget? Hvem er foredraget ment for, og hvem ønsker du å se i salen? Er det noen forkunnskaper publikum bør ha for å få mest mulig ut av foredraget ditt?
Dette er spørsmål du bør adressere tydelig i forslaget ditt. Noen CfP-er har egne felter for dette, men hvis ikke bør det bakes inn i “outline”. Det bør gjerne også fremkomme av beskrivelsen av foredraget, spesielt hvis konferansen har flere tracks, slik at publikum selv kan vurdere om det er noe for dem.
Når du har beskrevet hvem foredraget er ment for bør du også kunne si noe om hva de kommer til å lære av å se det. Hvorfor bør en publikummer velge å bruke tid på å se ditt foredrag? Og hva vil vedkommende sitte igjen med etterpå?
Hvis vi som programkomité ikke klarer å se et tydelige svar på disse spørsmålene, hvorfor skulle vi ønske å ta foredraget med i programmet?
Det kan variere litt hvor det er naturlig å beskrive dette i forslaget ditt. Hvis mulig, prøv å få det frem i beskrivelsen mot publikum. Men om det ikke passer noe annet sted, sørg i alle fall for å ta med et avsnitt om det i “outline”.
Dette er også tanker som kan være lure å ta med seg når man skal jobbe videre med presentasjonen din. Hvis du har innhold som ikke understøtter de poengene du ønsker at publikum skal sitte igjen med etter foredraget bør du kanskje vurdere å kutte litt eller endre fokus.
Dette relaterer tilbake til punkt 1, om å ta seg tiden til å lage et godt forslag. Om du har kommet hit i dette dokumentet er sansen god for at du gjør dette riktig, men føler det kan være verdt å nevne likevel.
Jeg har overaskende ofte sett at folk ikke fyller ut alle feltene vi ber om. Eller, dersom vi har gjort feltene obligatoriske, bare fyller inn “TBD”, “TODO”, “samme som over” eller tilsvarende. Det er en grunn til at vi spør om ting i skjemaet, og om man ikke gidder å svare på alt, så sender det ganske dårlige signaler.
Det er ofte et eget felt for “annen info til programkomiteen” i skjemaet. Legg janteloven til side og bruk dette til å skryte av deg selv! Målet med CfP-forslaget ditt er å fremstå som noen som har peiling på det du skal snakke om og som kan presentere det på en god måte.
Vi vurderer ikke foreraget ditt alene, men totalpakka som også inkluderer deg som foredragsholder. Hvorfor bør akkurat du få prate om dette? Hvis du har skrevet bloggposter eller annet om temaet kan det være nyttig informasjon. Alt som viser oss at du har peiling er bra å få frem. Har du holdt foredrag tidligere som er tilgjengelig på video? Legg ved en link, selv om det kanskje var om et annet tema. Det hjelper oss å vite hvor flink du er til å presentere, og hvis du ikke linker til noe kommer vi antagelig til å google etter noe selv…
Dersom konferansen benytter blind reviews, som nevnt innledningsvis, så endrer dette naturligvis litt på ting. Men husk at det likevel er mulig å skryte av deg selv, du må bare gjøre det på en litt mer anonym måte. Du kan fortsatt fortelle hvor mye erfaring du har med teknologien du nevner, eller at du har holdt akkurat denne typen workshops mange ganger før, for eksempel.
Live coding er risikosport. Det kan bli kjemebra, men det har også stor fare for å bli ordentlig dårlig. Ikke alle kan gjøre dette bra, og hvis noe går galt kan det være vanskelig å hente seg inn igjen.
Vi vil gjerne ha med det beste foredragene, men ønsker ikke unødig høy risiko live coding trainwrecks heller. Hjelp oss å gjøre en risk-/reward-vurdering som lander i din favør ved å eksplisitt adressere følgende:
Når du nærmer deg ferdig med skrivingen, få noen til å se over og gi deg litt feedback. Du har antagelig skrevet deg ganske blind på eget forslag på dette punktet, og noen friske øyne kan hjelpe å gjøre forslaget ditt enda noen hakk bedre.
Tenk på dette som brukertesting av forslaget du skal sende inn. De spørsmålene du får fra den som leser over, vil antagelig vi i komitéen også sitte med.
Og dessuten er det en fin måte å luke ut de (forhåpentligvis) siste skrivefeilene og annet rusk og rask. Jeg har sett veldig mange forslag sendt inn med skrivefeil i alt fra tittel til beskrivelse, og det gir mildt sagt ikke et godt førsteinntrykk.
Det er mange i Bekk som gjerne hjelper deg med dette! Rop ut på #presentasjonshjelp på Slack hvis du ikke har noen av dem i umiddelbar nærhet.
Photo by Talia Cohen on Unsplash
Det er fristende å prøve å dekke over alt mulig gøy du vil prate om. Men tenk på tiden du har til rådighet. En av de feilene vi oftest ser er at folk ikke er flinke til å kutte ut det som ikke må være med. Det er ved å kutte at du får fokusert på de aller viktigste tingene, selv om det er en prosess som kan gjøre ganske vondt når man planlegger et foredrag.
Spisse foredrag er ofte bedre enn de generelle, nettopp fordi de gjør et typdykk i materiet i stedet for å bare plaske i overflaten. (Det er selvsagt unntak fra denne regelen, men gjør en vurdering på om akkurat ditt foredrag faktisk er ett av dem.)
Hvis vi i komitéen begynner å stille spørsmål ved om du vil rekke å gå igjennom om alt du har nevnt i outline på en god måte på tiden du har til rådighet, så er det et klart rødt flagg, og sjansen din for å bli valgt vil falle.
Det kan være nyttig med foredrag som tar for seg ting på et teoretisk nivå, men i mange tilfeller er det erfaringsrapporter fra Virkeligheten™️ som er de mest lærerike.
Jada, det er kult at man kan automatisere provisjonering av miljøer med TECH X på 10 minutter. Men hvis du kan vise meg hvordan de gjorde det på Nav eller hos KentBank 1, så blir vi virkelig interesserte!
Foredrag med erfaringsrapporter om hvordan noen fikk til noe de forsøkte på er vell og bra, men det er foredrag om negative erfaringer som virkelig er gull. Det er ikke bare en klisjé at det er feilene sine man lærer mest av. Ta den lærdommen og del den med alle i salen på JavaZone, da vel!
Det er vanskelig å forutsi nøyaktig hva det blir, men hvert år er det et eller flere “hot topics” det blir stor konkurranse om, og dermed vanskelig å få godkjent noe innenfor. Ratioen mellom antall forslag og antall plasser i programmet gjør nåløyet ekstremt lite akkurat her.
For åtte år siden var temaet “mikrotjenester”, noen år etter var det “sånn går du ut i skyen”, og for et par år siden var “maskinlæring” hot shit. Hvis du er så “uheldig” å foreslå noe innenfor årets trendy tema, så må du virkelig klare å skille deg ut for å ha en sjanse.
Samtidig er det alltid noen temaer vi får altfor lite innenfor. Et tips kan være å se hva det har vært litt lite av tidligere år, og send gjerne inn noe der du ser at programmet har vært ekstra tynnt. Det er en god sjanse for at det skyldes lavt antall forslag, ikke at programkomitéen ikke vil ha dem.
Se også gjerne etter hva det spørres etter i CfP. Noen konferanser er tydelige på hva de ser etter, og det kan være viktig å bruke. JavaZone har gjort dette noen år, men ikke alltid.
Protip: Forslag rundt sikkerhet har vært ettertraktet i alle årene jeg var aktiv med JavaZone, og går neppe av moten på det første. Et annet tips, som nevnt over, er erfaringsrapporter eller postmortems der ting ikke har gått som planlagt.
Photo by Steve Harvey on Unsplash
Vi får typisk inn mye mer som er på intro-nivå enn avanserte ting, til tross for at vi ønsker en god balanse av dette i programmet. Det betyr at det noen ganger kan være enklere å få godkjent et litt mer avansert forslag. Det er tross alt begrenset hvor mange “intro til X”-foredrag man kan fylle programmet med…
Hvis du submitter en intro, og kan temaet godt nok, send gjerne inn et forslag om litt mer avansert variant i samme slengen!
Og, som nevnt over, når du sender inn noe litt mer avansert: Husk å være tydelig på hvem det forventede publikumet er, og hva de bør kunne fra før.
Kunne foredraget ditt også fungert som en lyntale? Eller kanskje det kunne vært justert litt og laget som en workshop?
Noen ganger liker vi det du har å komme med, men klarer kanskje ikke rettferdiggjøre å allokere like mye tid til det som du har bedt om. Eller kanskje det er et så spennende tema at vi ønsker at du skal gå enda litt mer i dybden.
Hvis du er fleksibel på lengde og/eller format, skriv gjerne noe om dette i forslaget. Kanskje er det akkurat dét komitéen trenger for å finne en plass til deg i programmet.
Å sende inn flere forslag øker sjansene dine. Så enkelt er det faktisk.
Noen ganger konkurrerer du med veldig store navn—kanskje til og med hun som skrev rammeverket du vil prate om. Da er det veldig vanskelig å komme igjennom med akkurat det forslaget.
Eller kanskje du har sendt inn sammen med noen andre, og vedkommende fikk et annet av sine forslag godkjent. Folk får generelt ikke godkjent flere forslag på JavaZone, og dermed mister du dine muligheter fordi vennen din var heldig. Med mindre du også har flere forslag inne til vurdering, naturligvis!
Pass dog på å ikke overdrive. To til tre forslag er plenty. Hvis du sender flere blir det mye arbeid for komitéen å vurdere, så bruk heller tiden til å tenke godt igjennom dem du faktisk sender inn.
JavaZone har en policy om at vi ønsker å være et springbrett for nye foredragsholdere. Det betyr at vi i en ellers jevn vurdering mellom et kjent navn og noen som aldri har stått på scenen før typisk vil foretrekke sistnevnte. NDC har visstnok også en tilsvarende policy.
Med andre ord, selv om det er skummelt å sende inn noe, så vil vi veldig gjerne høre fra deg som ikke har gjort dette før!
Lykke til med forslagene dine!