Digitalisierung. Entwickler zu rekrutieren ist eine besondere Herausforderung. Die wenigen, die es auf dem Markt gibt, sind von den unzähligen Abwerbeangeboten genervt. Wieder einmal heißt das Zauberwort: agil arbeiten.
Der klassische Recruitingprozess darf als bekannt vorausgesetzt werden, mit allen seinen Schwächen: Gesucht wird grundsätzlich ein Wunderwuzzi, der viel mehr können soll als eigentlich benötigt. Ist er endlich gefunden, lässt man ihn warten. Bis der CEO seinen Segen gibt, ist der Kandidat weg.
Ivo Betke, deutscher Country Manager von Talent.io, dachte sich eine agile Variante aus. Agil vielleicht nicht streng im Sinn des agilen Projektmanagements, aber deutlich verkürzt und auf die Zielgruppe abgestimmt.
Schritt 1: Vorarbeit. Weg von den Weihnachtswunschlisten, hin zur Kernanforderung. Mit der kurzen Frage: Welches Problem muss das Team gerade lösen? Nur diese Skills kommen ins Suchprofil. Weiters wird eine Scorecard geschrieben, in die technisches Wissen (z. B. die wichtigsten Programmiersprachen) und Soft Skills eingetragen werden. Auch die Priorität dieses Recruitingauftrags im Vergleich zu anderen wird erfasst, weiters Budget und Beteiligte. Die Time-to-Hire, die Zeitspanne von der Auftragsdefinition bis zur Vertragsunterzeichnung, darf bei Entwicklern nicht länger als drei bis vier Wochen sein. Traditionelle Recruiter lachen an dieser Stelle auf.
Schritt 2: Bewerber finden. Jobinserate funktionieren immer noch, sind aber meist vollgepfropft mit Unnötigem. Betkes Credo: Im Inserat mehr über das Unternehmen und Team reden als über die gesuchte Qualifikation. Entwickler wollen begeistert, von der Vision angesteckt werden. Idealerweise liegt dank Fuzzy Search (unscharfe Suche) ein gepflegter Kandidatenpool vor. Dann reichen Newsletter, um bei Bedarf auf offene Stellen aufmerksam zu machen. Erste Faustregel: Entwickler wechseln alle 24 bis 36 Monate den Job. Zweite Faustregel: In einem gut gepflegten Pool melden sich 25 von 250 Interessenten auf ein Inserat.
Schritt 3: Blitzprozess. Das Bewerbungsgespräch besteht hier aus einem halbstündigen Vergleich der Basics („Sanity Check“), gefolgt von einem umgedrehten Interview: Nicht der Recruiter fragt den Bewerber aus, sondern umgekehrt. Hat der Bewerber keine Fragen, ist er nicht interessiert. Der zweite Tag ist „Testtag“. Hier programmiert der Kandidat gemeinsam mit einem „Pair“, einem der künftigen Kollegen, damit dieser seine Denkprozesse kennenlernt. Das Schlimmste für IT-Kandidaten ist, an der Tafel zu stehen und wie in der Schule geprüft zu werden. Leider kommt das viel zu oft vor.
Schritt 4: Entscheidung. Anhand der Scorecard wird extra schnell entschieden und zugesagt. Wer fühlt sich mehr wertgeschätzt: Der Kandidat, dem sein Vertrag mit den lapidaren Worten „Schauen Sie mal drüber“ geschickt wird, oder der, dem die neuen Kollegen kollektiv am Telefon gratulieren?
Schritt 5: Onboarding. Nicht nur Entwickler fühlen sich willkommen, wenn ihr Arbeitsplatz am ersten Tag bereitsteht. Betke rät, auch die Scorecard zu enthüllen und die Erwartungen an den künftigen Beitrag offenzulegen.
Die besten Mitarbeiter sind übrigens jene Entwickler, die auf interne Empfehlung kommen, was – dritte Faustregel – auf jeden Dritten zutreffen sollte. Damit das klappt, müssen allerdings die Internen wissen, dass man dies von ihnen erwartet. Doch leider: Meist haben sie keine Ahnung.
AUF EINEN BLICK
Rekrutierungsfehler wirken sich bei Entwicklern stärker aus als bei anderen Professionen. Statt unerfüllbarer Wunschlisten sollte ein Suchinserat nur die nötigsten Skills (ein bis zwei Programmiersprachen) beinhalten. In einer Scorecard werden Hard und Soft Skills, Suchpriorität, Budget und Beteiligte eingetragen. Der Bewerbungsprozess selbst ist abgespeckt und darf maximal drei Wochen dauern. Ein Drittel sollte auf interne Empfehlung kommen.
("Die Presse", Print-Ausgabe, 03.11.2018)