Så rekryterar du en teknisk skribent: rollen som betalar sig i färre supportärenden

Hur lång tid tar det för en ny utvecklare att bli produktiv hos er? Och hur stor del av era supportärenden beror på att någon inte hittade svaret själv? Bakom båda frågorna gömmer sig ofta samma brist: dokumentation som ingen äger. Den tekniska skribenten är rollen som löser det, och en av de mest missförstådda rekryteringarna i IT.

Det här är inte en administratör

En vanlig felrekrytering är att se rollen som ren textproduktion: någon som snyggar till det utvecklarna redan skrivit. Men en bra teknisk skribent är en undersökande journalist i teknisk miljö. Personen intervjuar utvecklare, testar systemet själv, hittar hålen i logiken och skriver så att rätt läsare förstår på första försöket. Det kräver teknisk nyfikenhet, integritet och förmågan att ställa dumma frågor tills svaren blir smarta.

Det du ska leta efter

• Skrivprov på riktigt material: be kandidaten dokumentera en verklig funktion eller process hos er, kort och avgränsat
• Teknisk grundförståelse: kandidaten ska kunna läsa ett API-anrop och testa en funktion själv, inte vänta på att bli matad
• Vana vid dokumentation som kod: versionshantering och samma verktygskedja som utvecklarna använder
• Läsarperspektiv: fråga vem den senaste texten skrevs för och hur kandidaten vet att den fungerade

Så säljer du rollen internt och externt

Internt möter du ofta invändningen att utvecklarna kan dokumentera själva. Det kan de, ungefär som skribenten kan skriva kod: långsamt, motvilligt och med varierande resultat. Räkna i stället på vad otydlig dokumentation kostar i supportärenden och onboardingveckor, så blir kalkylen sällan svår. Externt gäller det att beskriva mandatet: får skribenten driva struktur och ställa krav, eller ska hen bara städa efter andra? De bästa kandidaterna har lämnat städjobb förr och känner igen dem i annonstexten. Visa att ni menar allvar genom att ge rollen en plats i utvecklingsprocessen, inte efter den. Då får ni en person som gör hela teknikorganisationen begripligare, för nya kollegor, för kunder och för er själva om två år när ingen minns varför systemet byggdes som det byggdes.

Börja gärna smått om osäkerheten är stor. Ett avgränsat uppdrag på några månader, med ett tydligt mål som en ny utvecklarintroduktion eller dokumentation av ert viktigaste gränssnitt, visar värdet snabbt och ger båda parter ett ärligt beslutsunderlag. De flesta som provar förlänger. Inte för att dokumentationen blev vackrare, utan för att frågorna i supporten blev färre och introduktionerna kortare.