I det nya kapitlet “Hitta rätt folk – konsten att rekrytera” i boken Riv pyramiderna igen – agil HR from the ‘trenches'” skildrar jag hur vi skapade en för oss passande strategi och metod för att kunna rekrytera rätt folk till våra team. Här kan du läsa ett utdrag:
“Så vitt jag minns det kom förslaget till nästa initiativ från en diskussion om rekrytering med teamen. Minns jag rätt tyckte man att min utfrågning inte gav tillräcklig bra underlag för att verkligen förstå om kandidaterna var bra programmerare. Vi brukade förvisso be om arbetsprov, men många hade inga sådana av med tillräcklig verkshöjd och det var också svårt att utveckla någon form av rimliga kriterier som kunde användas att bedöma kodexempel av väldigt olika sort.
Julen 2008 fick ett team i uppgift att ta fram skelettet till ett arbetsprov. Vi utgick från en publik, men liten, specifikation och konstruerade ett grundpaket så att man kunde komma igång snabbt ifrån och fylla i med egen kod. Målet var att det skulle ta mellan 8 och 16 timmar att genomföra arbetsprovet, och det skulle visa på kvaliteter så som kodstil, vana vid testning, arkitekturell kompetens och inte minst förmåga att skriva multitrådad kod.
Nu hade vi således en process där jag och HR-chefen genomförde en semi-strukturerad intervju. Passerade man den var nästa steg att genomföra arbetsprovet. Möjligen gjorde vi något enstaka undantag över tid för någon person som vi fått rekommenderar, men annars var alla framtida kandidater tvingade att genomföra arbetsprovet för att gå vidare i processen.
Arbetsprovet behövde förstås bedömas. På den tiden hade vi “arkitekter”. Det var några seniora utvecklare hos oss som mer eller mindre officiellt bar den rollen, inte minst genom regelbundet deltagande i en arkitektgrupp. När vi fått tillbaka ett arbetsprov brukade jag skicka ut det till dessa och inom en eller ett par dagar hade vi ett möte där vi gick igenom arbetsprovet. Diskussionerna använde jag sedan för att ge återkoppling till den som gjort arbetsprovet.
För att jobba hos oss skulle man vara en “riktig” programmerare, om det var alla överens. Vi skrev, pratade och granskade kod dagligen. Man skulle kort sagt både vara duktig på och älska att göra detta för att passa in. Så vitt jag kan minnas hade vi dock aldrig suttit i en lite större grupp och diskuterat kod, inte ens vår egen, på det sätt vi gjorde nu. Det var en ganska fantastisk upplevelse. Vi började sätta ord på hur vi egentligen såg på programmering som yrke, vad man behövde kunna, hur god design och kod ser ut, och inte minst vilka kvaliteter (vad behövde man kunna innan, vad kunde man lära sig hos oss) som våra kandidater behövde ha (det ledde också så småningom till nya sätt att bedriva kompetensutveckling, men om det berättar jag mer i ett annat kapitel). Vi började helt enkel mejsa ut vår egen professionella identitet. Typiskt nog dokumenterade vi aldrig detta, utan det blev en delvis tyst kunskap som uppstod hos de som deltog i dess “kodseminarier”.
När vi startade med arbetsprov hade jag ingen särskild plan eller ens bild av vad det skulle leda till. Så här i efterhand kan jag se att just detta att alla fick göra ett arbetsprov som vi tog ett gemensamt ansvar för att utvärdera var en avgörande förändring: vi fick ett transparent och professionellt sätt att rekrytera på som alla kunde stå bakom och som många fler var involverade i. Vi hade med andra ord börjat skapa en process runt rekrytering, det vill säga ett repeterbart sätt att uppnå vissa mål. Vi anpassade oss till att allt arbete utfördes i lag.”
Vad är “tysk kunskap”?
Att man kan sin Hegel och Habermas, eller var det “tyst kunskap” det borde stå…?