Miksi rekrytointi ei usein ratkaise IT-tiimin pullonkaulaa
IT-organisaatiossa rekrytointi käynnistyy usein näkyvästä oireesta: projekti viivästyy, tikettijono kasvaa tai kehitystiimin vauhti hidastuu. Ratkaisuksi määritellään uusi rooli, otetaan käyttöön uusi työkalu tai lisätään resursseja ja odotetaan helpotusta.
Viime vuosina sama keskustelu on saanut uuden muodon. Kun työ hidastuu, vaihtoehdoksi nousee rekrytoinnin rinnalle myös automaatio tai AI-työkalut.
Moni IT-esihenkilö tunnistaa tilanteen: tiimiin tulee uusi osaaja tai käyttöön otetaan uusi työkalu, mutta tikettijono ei lyhene eikä läpimeno nopeudu merkittävästi. Työ jatkuu lähes samalla tavalla kuin ennen.
Silloin ongelma ei yleensä ole ihmisissä tai työkaluissa. Ongelma on usein siinä, mihin kohtaan työnkulkua uusi kapasiteetti sijoitettiin.
Kapasiteetti ei korjaa rakennetta
Rekrytointi lisää kapasiteettia. Se ei korjaa arkkitehtuuria, työnjakoa tai prosessia. Sama pätee myös uusiin työkaluihin ja automaatioon: jos työn rakenne ei muutu, vaikutus jää helposti pieneksi.
Jos pullonkaula on väärässä osaamistasossa, epäselvässä omistajuudessa tai manuaalisessa työvaiheessa, uusi resurssi päätyy helposti samaan rakenteeseen kuin muutkin.
Tämä koskee monia IT-rooleja. Kehitystiimissä voidaan hakea senior-kehittäjää, vaikka varsinainen tarve liittyy integraatioarkkitehtuurin tai alustarakenteen selkeyttämiseen. Tukitiimissä lisätään resursseja, vaikka kuorma syntyy käyttöoikeusprosessista. Datahankkeessa palkataan analyytikko, vaikka ongelma on datamallin omistajuudessa.
Kun rekrytointi kohdistuu oireeseen, mittarit näyttävät tekemistä mutta eivät vaikutusta.
Rooli väärässä kohdassa työnkulkua
Kun tarvetta ei analysoida työnkulun kautta, rooli sijoitetaan helposti väärään kohtaan tekemistä. Tällöin uusi osaaja tekee työtä, joka ei poista pullonkaulaa.
Olennaista on tunnistaa, missä vaiheessa työ hidastuu ja millaista osaamista juuri se vaihe vaatii. Vasta tämän jälkeen voidaan arvioida, onko kyse pysyvästä roolista, määräaikaisesta tarpeesta vai rakenteellisesta muutoksesta.
Jo tässä vaiheessa alkuperäinen rekrytointitarve tarkentuu tai joskus muuttuu kokonaan.
Markkinanäkymä vaikuttaa päätökseen
Kun tarve on epäselvä, myös markkinanäkymää tulkitaan helposti väärin.
IT-esihenkilö näkee hakemusten määrän, mutta harvemmin koko markkinakuvaa siitä, kuinka saatavilla tietty osaaminen on ja millä aikataululla se voidaan tuoda tiimiin.
Ilman tätä näkymää päätös tehdään näkyvän tarjonnan perusteella. Silloin valitaan paras saatavilla oleva, ei paras mahdollinen ratkaisu.
Roolikuvaus ohjaa lopputulosta
Kun tarve on määritelty oikein, roolikuvaus ei ole teknologialista, vaan kuvaus vaikutuksesta: mitä ongelmaa rooli ratkaisee ja mitä tiimin arjessa muuttuu.
Tämä parantaa hakijalaatua ja lyhentää rekrytointia, koska keskustelu käydään oikeasta työstä, ei yleisestä osaamisesta.
Päätöksenteon tuki, ei CV-virta
Ilman kunnollista tarvemäärittelyä esihenkilö käyttää helposti kymmeniä tunteja hakemusten läpikäyntiin ja haastatteluihin, jotka eivät lopulta ratkaise alkuperäistä ongelmaa.
Kun tarve analysoidaan ennen haun käynnistämistä, rekrytointi tukee johtamistyötä sen sijaan, että veisi siitä aikaa.
Rekrytointikumppanin tehtävä ei silloin ole pelkästään etsiä ehdokkaita. Kumppani toimii päätöksenteon tukena: mitä osaamista tarvitaan, mihin kohtaan työnkulkua ja millä aikataululla.
Tavoite ei ole täyttää paikkaa, vaan poistaa pullonkaula.
Pasi Korhonen
Lähitukitiimin vetäjä
pasi.korhonen@fujitsu.com
p. 050 462 3647
Harkitsetko rekrytointikumppania IT-tiimisi tueksi?
Mitä tarvemäärittely kumppanin kanssa oikeasti tarkoittaa – ja miksi se ratkaisee rekryn onnistumisen? Lue lisää.
