Software Engineers suchen und einstellen

Der Hintergrund für die Story

Ende 2017 wurde ich von der Boxine GmbH als Head of Cloud & Operations eingestellt. Der Produzent der Toniebox ist ein technisches Unternehmen mit Sitz in Düsseldorf, welches sich 2013/2014 gegründet hat. Um jedoch als Start-Up so schnell und qualitativ wie möglich ein neues technisches Produkt auf den Markt zu bringen, arbeitete die Boxine viel mit Partnern aus der technischen Industrie zusammen. Das führte dazu, dass das Unternehmen die eigenen Anstrengungen in der Suche nach Experten in der Technik vollständig einstellte und sich auf Content Erstellung, Marketing und Vertrieb konzentrierte. Zum Zeitpunkt meiner Einstellung war ich der erste angestellte IT-Experte und einer von 40 Mitarbeitern.

Meine drei Kernaufgaben im Unternehmen:

Internalisierung und Weiterentwicklung der Plattformen und Software
Aufbau einer technologischen Abteilung
Einführung von Agilen Methoden

Jedes dieser drei Vorhaben hat das Potential, einige Jahre Zeit in Anspruch zu nehmen. Sogar unsere Technologiepartner haben damals von dem Projekt abgeraten und auf den unattraktiven Arbeitsmarkt hingewiesen. Vor allem IT-Spezialisten seien gefragt und deswegen nicht leicht zu haben.

Die Unternehmensstrategie war jedoch klar und das Ziel gesetzt. So startet ich also die Abnablung von Agenturen, suchte Expertinnen und Experten in unterschiedlichen Segmenten und plante die Transformation zum agilen Unternehmen hin.

Uns gelang der Trick. In den ersten 6 Monaten habe ich drei Entwicklerinnen und Entwickler einstellen können. Nach weiteren 6 Monaten waren 5 Entwicklerinnen und Entwickler an Board, 2 DevOps Spezialisten, 1 System-Operator und 1 Product Owner.

Die Schlüsselfrage: “Warum stellen wir ein?”

Zunächst erscheint die Frage sehr banal, da sie das Offensichtliche in Frage stellt. Aber ist es so offensichtlich, warum ausgerechnet in dem Moment ein Mitarbeiter eingestellt werden sollte?

Welches Problem soll der neue Mitarbeiter lösen?

Die Absicht der Fragestellung ist einfach: Zunächst soll ermittelt werden, ob wirklich weitere Mitarbeiter gebraucht werden. Damit ist der erste Schritt die qualitative Ermittlung des Personalbedarfs. Und genau festzustellen, was gesucht wird. Es ist nicht einfach, dies komplett selbst zu entscheiden, weshalb sich der Austausch mit Kollegen, Vorgesetzten und HR durchaus lohnt. Denn als Abteilungsleiter hat man vielleicht ein Problem für sich selbst erkannt, das da heißt: “Ich habe nicht genug Leute”. Aber es ist oft so, dass Probleme auf unterschiedliche Weise gelöst werden können, weil Probleme auch unterschiedlich wahrgenommen werden. Ein Austausch mit den Beteiligten soll sicherstellen, dass jeder das gleiche (oder möglichst ähnliche) Bild der Situation hat und versteht, warum sich die Frage nach mehr Personal überhaupt stellt. Wichtig hier: Nicht den Austausch mit dem Team selbst vergessen!

Die Ermittlung des Bedarfs

Jedes Unternehmen und unter Umständen sogar jede einzelne Abteilung wird seine eigene Methode haben, diesen Bedarf zu ermitteln. Für mich hat sich der Austausch immer als eine sehr gute Methode erwiesen, ein möglichst klares Bild von der Situation zu erhalten was auch gleichzeitig dazu führt, dass man sehr scharfe Such-Profile erstellen kann.

Die folgenden Fragen sind ein Auszug der Fragen, die ich versucht habe für mich zuerst zu beantworten, bevor ich eine Stelle ausgeschrieben habe:

Wie sieht das Team genau aus und wie ist es besetzt?
Fehlt eine spezielle Rolle in dem Team?
Fehlt eine spezielle Expertise in dem Team?
Lässt sich fehlende Expertise durch gezieltes Nachschulen erreichen oder ist ein weiterer Experte notwendig?
Wie würden die Kernaufgaben des neuen Mitarbeiters aussehen?
Würde ein neuer Mitarbeiter zur Entlastung einzelner Teams beitragen oder zur Anhebung von Qualität oder Output?
Sind einige der alle Aufgaben saisonaler Natur?
Welches Beschäftigungsmodell wäre angemessen (Vollzeit, Teilzeit, Freiberufler)?
Welche Alternativen gibt es, um das bestehende Problem (die bestehende Lücke) zu lösen?
Wie sieht der Gehaltsraum aus?
Wie sehen die unternehmerischen Ziele und Strategien für die kommenden 6 - 12 Monate aus?
Wie sehen die strategischen Ziele für das Produkt für die kommenden 6 - 12 Monate aus?

Die aus den Diskussionen gewonnenen Erkenntnisse sollen nun einen guten Überblick über den tatsächlichen Bedarf geben. Außerdem entstehen nun auch detailierte Anforderungen an den neuen Mitarbeiter. In Prosa zusammengefasst bieten diese Informationen eine perfekte Vorlage für eine Stellenbeschreibung, die Ihren Namen würdig ist.

Diese Übung hat aber noch mehr Absichten.

Eine Stellenausschreibung sollte nicht nur vor dem Bewerber, sondern auch vor einem selbst kausal vertretbar sein. Gute Software Engineers können bereits aus einer Stellenanzeige heraus lesen, wie wichtig und wie vielversprechend die ausgeschrieben Stelle ist. Buzzword Bingo kommt ebenso wenig gut an sinnlose Formulierungen zum Füllen des Textes. Formulierungen wie “Du bist IT’ler und bist begeistert von deinem Beruf? Dann bist du hier genau richtig!” sind sehr oft zu lesen und unfassbar hohl. Es zeugt davon, dass sich niemand mit der Stelle auseinander gesetzt hat. Wenn wirklich klar ist, was gesucht wird, fällt das sinnvolle Texten leicht.
Ein zweiter Grund für die Art und Weise der Bedarfsbestimmung ist, dass man sich als Arbeit- und Auftraggeber klar sein muss, dass der Markt für IT-Fachkräfte extrem umkämpft ist. Derzeit ist es so, dass sich Unternehmen viel mehr bei den Bewerbern bewerben, als umgekehrt. Es ist nicht ungewöhnlich, wenn IT-Fachkräfte wöchtentlich bis zu einem halben Dutzend Head-Hunter Anschriften über LinkedIn und Xing erhalten. Um dagegen bestehen zu können, muss man selbst also wissen, was man von dem anderen benötigt und was man selbst bieten kann. Je eher und besser man als Unternehmen weiß, was man sucht und warum, desto besser ist der Auftritt im Vorstellungsgespräch und damit auch der Eindruck auf den Bewerber. Erst damit kann das Unternehmen auch einen Ausblick auf die anstehende Herausforderung geben und und damit Erwartungshaltungen treffen.
Last, but not least: Durch den Prozess wurden jetzt so viele Kolleginnen und Kollegen wie Möglich mitgenommen und abgeholt. Jeder im Team weiß, was lost ist und warum eine neue Fachkraft gesucht wird. Auf diese Weise können falsche oder voreilige Ableitungen (um nicht “Fehlinterpretationen” zu sagen) vermieden werden. Ich hatte tatsächlich sogar einmal den Fall, in dem ein wirklich herausragender Mitarbeiter dachte, dass der neue Bewerber ihn ersetzen solle, weil er nicht ausreichend performe. Solche Missverständnisse müssen um jeden Preis vermieden werden.

Software Engineer vs. Cloud Guru Special Expert

Da die Anforderungen an den neuen Mitarbeiter nun klar sind, ist es an der Zeit sich über einen Titel Gedanken zu machen.

Was ist eigentlich ein Titel und wozu dient er? Naja, ein Titel fasst die Stelle in einem kurzen und knackigen Worten zusammen und steckt den Rahmen für die Aufgaben ab. Manchmal ist sogar ein Verantwortungslevel darin zu erkennen. Ein “Junior Project Manager” wird vermutlich ein anderes Budget managen, als ein “Senior Key Account Manager”. Aber der Titel hat nicht den Sinn und Zweck einem selbst zu sagen, was man da macht, sondern den anderen. Aus diesem Grund sollte ein Titel kurz, verständlich und sinnvoll sein.

Natürlich muss man bei dem Thema auch immer auch die Unternehmens-Standards zu berücksichtigen. Start-Ups, mittelständische Unternehmen und größere Konzerne müssen hierbei völlig unterschiedlich bewertet werden, da sie ganz unterschiedliche Leitlinien verfolgen und Anforderungen an Titel haben.

Allgemeine Titel wie “Software Engineer” oder “Software Developer” werden häufig verwendet und erfreuen sich gerade in agilen Teams hoher Beliebtheit. Sie erlauben den Entwicklern fach-übergreifend zu arbeiten und bauen Hürden zwischen Disziplinen ab. Gerade in Scrum-Teams ist dies ein großer Vorteil. Spezifischere Titel dagegen haben den Vorteil, dass diese Fachkräfte einfacher zu finden sind (z. B. auf Xing) und ihre Spezialisierung deutlicher ist. In einigen Unternehmen ist es aber sehr wichtig, die eigene Funktion relativ genau durch den Titel zu repräsentieren. Sollte dies der Fall sein, sei hier zu einer groben Spezialisierung geraten. “Backend Developer” ist spezifisch und sprechend, aber fachlich nicht zu eingeschränkt. “Python Backend Developer” dagegen ist schon etwas zu viel. Kollegen ohne technischen Background werden bei so einem Titel Schwierigkeiten haben, sich was drunter vorzustellen.

Vermeiden Sie Begriffe wie “Guru” oder “Hacker”. Vor einiger Zeit erhielt ich sogar einen Brief von einem Personalvermittler, der nach einem “Lucky ‘Django’ Luck” suchte, einem, der “schneller entwickelt als sein Schatten”. Das ist nicht professionell und zieht keine IT-Profis an.

Merke: Der Titel sollte die Fachrichtung wiederspiegeln, nicht eine spezifische Tätigkeit.

Im Übrigen gibt es noch einen schönen Artikel von Marcela, CEO und Mitbegründer von Hello Alfred, der beschreibt, welchen Einfluss Titel in Startups haben.

Die Stellenausschreibung

Jede Branche hat ihre eigenen Dos and Dont’s, die beschreiben, wie eine Stellenanzeige aussehen soll. Das Gleiche gilt für die IT.

Eine Stellenausschreibung sollte kurz und knapp wie möglich erklären, worum es bei der Stelle geht. Im besten Fall beschreibt sich das Unternehmen selbst einmal kurz, erklärt dann, welche Abteilung was sucht und wie die Aufgaben aussehen. Gefolgt von einer überschaubaren Liste von gewünschten Fähigkeiten, die man entweder mitbringt oder bereit ist, sich anzueignen.

Einige Unternehmen möchten darauf hinweisen, dass sie auch gut feiern oder jede Woche eine Fußballmeisterschaft organisieren können. Das ist toll. Aber unfassbar unwichtig.

Da wir uns also hier im professionellem Umfeld bewegen, wird auch erwartet, dass in der Ausschreibung Fakten zur fachlichen Anforderungen genannt werden. Die Stellenausschreibung hat den Zweck, dem Leser einen Eindruck zu vermitteln, wer man ist und was man braucht. Nicht zuletzt einen Mitarbeiter zu finden, der das Geschäftsmodell eines Unternehmens implementiert. Nicht, um schüchterne Nerds aus dem Keller ihrer Eltern zu locken.

Vermeiden sollte man nach Möglichkeit nichts aussagende Formulierungen wie:

“Du bist der Cloud Meister und kannst AWS im Schlaf?”
“Hast du Lust auf einen richtig coolen Job mit ganz viel toller Technik?”

Viele Schreiben auch so etwas rein wie “Sie sind Querdenker und haben bei Anforderungen direkt Code im Kopf? Dann sind Sie bei uns genau richtig!”. Ist das wirklich so? Wie kommen Sie selbst mit Querdenker zurecht? Wie stehen Sie wirklich zu unkonventionellen Lösungsansätzen?

Der Joel-Test

Joel Spolsky, CEO von Stack Exchange Network und Mitbegründer von Trello, veröffentlichte im August 2008 den Joel-Test. Ziel davon war es, die Qualität des Arbeitsraums von Software-Teams auf einfache Weise zu messen. Der Joel-Test, bestehend aus 12 einfachen Fragen, die mit “Ja” oder “Nein” beantwortet werden, ist sehr beliebt geworden und hat auch heute noch eine große Bedeutung. Mit StackOverflow können Sie beispielsweise den Joel-Test direkt bei der Beschreibung Ihrer Stellenanzeige ausfüllen. Es ist eine feste Komponente.

Im Jahr 2012 aktualisierte und modernisierte Sven die 12 Fragen des Joel-Tests in seinem Blog svenpet.com. Ich denke, dass dieses Update viel Sinn macht, weshalb ich gerne darauf Bezug nehme. Ein Stück weiter unten habe ich die 12 Fragen festgehalten.

Bevor man sich also nun auf die Suche nach neuen Software Engineers macht, sollte man den Joel Test für sich einmal gemacht haben. Dabei erhält man nicht nur als Abteilungsleiter auch einen gutes Feedback dazu, wo der Schuh in der Praxis drückt. Der Test hilft nämlich auch Nicht-Technikern (z. B. HR) sich auf ein Gespräch mit Fachkräften besser vorzubereiten.

Die 12 (überarbeiteten) Fragen

Können Builds, Artefakte und Deployments in einem Schritt erstellt werden?
Wird ein Build automatisch nach jedem Check-in erstellt?
Werden regelmäßig Kennzahlen über den Code erhoben und ausgewertet?
Ist der Issue Tracker mit den Build und Versionskontrollsystemen verbunden?
Werden Fehler behandelt, bevor Features implementiert werden?
Wird irgendeine Form von Softwarefunktionalität vor der Implementierung aufgeschrieben und mit den Interessengruppen abgestimmt?
Haben die Programmierer ruhige Arbeitsbedingungen?
Werden die besten Werkzeuge verwendet, die verwendet oder gekauft werden können?
Gibt es Mitarbeiter, die Vollzeit an den Tests arbeiten?
Müssen Bewerber während der Bewerbungsphase Quellcode schreiben?
Werden Usability-Tests mit Endanwendern durchgeführt?
Wird jede Zeile des Codes geändert und neu programmiert?

Ich halte es für optional, die Fragen zu beantworten und sie der Stellenausschreibung beizufügen. Es ist jedoch ein Zeichen von Selbstreflexion und eines gewissen Know-Hows bei der Bewältigung dieser Fragen. Außerdem bietet es dem Bewerber die Möglichkeit, sich vor bösen Überraschungen zu schützen.

An dieser Stelle muss ich auch erwähnen, dass es nicht schlecht ist, wenn nicht alle Fragen mit “Ja” beantwortet werden. Durch eine wahrheitsgemäße Aussage werden keine falschen Erwartungen geweckt.

Stelle ausschreiben und veröffentlichen

Damit die Ausschreibung auch gefunden und gelesen werden kann, muss sie ausgestellt werden. Optimal ist natürlich die Job-Section der eigenen Unternehmenswebsite. Auch gut sind Portale wie Xing oder LinkedIn. Hier haben viele Unternehmen entsprechende Unternehmensseiten und präsentieren sich, ihre Produkte und offene Positionen.

Gerade für den IT Segment auch relevant ist StackOverflow. Für viele IT’ler der erste Anlaufpunkt, wenn es um die Suche nach neuen Jobs geht.

Weniger Relevant sind Portale wie StepStone oder Indeed.

Der Bewerbungsprozess

Sind wir hier erst angekommen, haben wir es bereits weit geschafft. Zeit für einen kurzen Rückblick:

Wir wissen, was wir suchen und warum
Wir wissen zu welchen Konditionen
Wir haben alle eingeweiht
Wir haben die Arbeitsbedingungen vor Ort ermittelt
Wir haben eine Stellenbeschreibung geschaffen, auf die sich jemand meldet

Nun müssen wir ein Verfahren haben, bei dem wir allen Parteien die Möglichkeit geben, die andere Seite gut kennen zu lernen. Definitiv keine einfache Aufgabe, da man über den Prozess im Detail geteilter Meinung sein kann.

Grundsätzlich sollte man erwähnen, dass Software Engineers viele Angebote erhalten und, je nach Lebenssituation, auch mehrere Gespräche führen. Selbst dann, wenn gar keine echte Absicht zum Wechseln besteht. Manche wollen auch einfach mal sehen, was andere derzeit so bieten oder wollen ihren eigenen Marktwert bestätigen.

Daher sollte der Prozess wenige Schritte beinhalten, aber ausführlich genug sein, um sich ein gutes Bild vom anderen machen können.

Wie bereits gesagt gibt es hier sicherlich viele Ansätze, meiner sah aber wie folgt aus.

Eingang der Bewerbungsunterlagen. Ich schaue mir die Unterlagen an und recherchiere den Bewerber (GitHub, GitLab, LinkedIn). Zudem bitte ich mindestens einen Kollegen aus dem entsprechenden Team die Unterlagen ebenfalls zu prüfen. Wenn keine Einwände gegen einen ersten Termin sprechen, folgt prompt eine Einladung.
Das erste Gespräch. Es findet mit mir und mindestens einem weiteren Kollegen statt (z. B. CTO, CEO, Entwickler, PO). In dem Gespräch geht es darum, das Unternehmen und die Produkte vorzustellen, die Vision und Mission aufzuzeigen, uns als Personen vorzustellen und natürlich um den Bewerber kennen zu lernen. Wir sondieren die Karrierewünsche des Bewerbers, erfahren, was er sucht, was er hofft, wo er hin will, was er braucht. Das selbe gilt auch für uns. Das erste Gespräch ist erstes Kennenlernen oder “sich beschnuppern”. Nach dem Gespräch reflektiere ich das Gespräch mit dem Kollegen. Ist Potential zu erkennen, wird der Bewerber zum zweiten Termin eingeladen, um das Team kennen zu lernen. Während des Interviews achte ich besonders auf die folgenden Punkte:
- Sind die Angaben des Bewerbers aus den Unterlagen korrekt? Widerspricht er sich?
- Wo sind die Grenzen der fachlichen Expertise?
- Wie stark sind die Soft Skills ausgeprägt?
- Würde der Bewerber in das Team passen?
- Erfüllt der Bewerber die grundsätzlichen Anforderungen an die Stelle? Und wenn nicht, ist der Bewerber bereit dazu, die notwendigen Fähigkeiten zu erlernen?
- Sind die Vertragsbedingungen in Ordnung?
- Was ist die Gehaltsvorstellung des Bewerbers?
- Welche Fragen stellt der Bewerber? Was ist ihm wichtig?
- In welche Richtung möchte sich der Bewerber beruflich entwickeln?
Das Assessment. Sollte der Bewerber ebenfalls weiter wollen, erhält der Bewerber eine kleine Aufgabe zum Lösen. Die Aufgabe besteht in der Regel aus einem logischen und einem praktischen Teil, für den der Bewerber maximal 8 Stunden aufbringen darf. Ziel ist es zu sehen, wie der Bewerber denkt und mit welchen Instrumenten er Probleme löst. Die Aufgabe selbst hat nicht die Anforderung “fertig” zu werden. Sollte der Bewerber jedoch über ein aussagekräftiges GitHub/GitLab Konto verfügen, verzichte ich auf die Aufgabe und untersuche mit meinen Kollegen den Code.
Das zweite Gespräch. Zu diesem Termin wird das gesamte Team eingeladen. In dem Meeting legt der Bewerber seinen Code vor oder wird zu bestehenden öffentlichen Projekten befragt. Wir simulieren also ein Team Event, ein Code-Review, in dem auf der einen Seite geprüft wird, wie sich die Dynamik des Teams entwickelt, wie Kritifähig der Bewerber ist und wie er seine eigene Arbeit kommentiert. Darüber hinaus ist es nun auch möglich zu sehen, wie stark sein Fachwissen tatsächlich ist, oder ob der erstellte Code schnell eben von Plattformen kopiert wurde. Diese erste Phase dauert etwa 20 Minuten und geht anschließend in ein entspanntes Gespräch über, in dem sich alle besser kennenlernen können.
Die Entscheidung. Ob ein Bewerber nun in das Team kommt, ist die Entscheidung des Teams. Hätten die Rahmenbedingungen nicht gepasst, hätte ich den Bewerber erst gar nicht zum Team durchgelassen. Der Bewerber wird nach dem Gespräch rausgebeten und das Team startet eine Diskussionsrunde und Bewertung. Erst wenn alle damit einverstanden sind, den Bewerber aufzunehmen, erstelle ich ein konkretes Angebot. Sollte nur eine anwesende Person gegen die Einstellung sein, sage ich dem Bewerber ab.

Der Prozess ist so strukturiert, dass wir in möglichst kurzer Zeit eine möglichst effiziente und fundierte Entscheidung darüber treffen können, ob der Bewerber passt. Und auch umgekehrt. Schließlich hat auch der Bewerber nur begrenzte Zeit und kann sich bei Bedarf nicht fünfmal Urlaub nehmen (oder will es auch nicht einfach), um zu einem Vorstellungsgespräch zu kommen. Zudem ist das gesamte Team involviert und die Entscheidungskriterien damit sehr vielfältig. Da sich aber alle darauf commiten, mit dem neuen Kollegen zu arbeiten, muss auch jeder seinen Teil dazu beitragen, den neuen Kollegen in das Team aufzunehmen und das Team für ihn zu öffnen. Ein “Mit dem arbeite ich nicht! Den hätte ich niemals eingestellt!”, gibt es hier nicht.

Unterstützung bei der Suche nach Talenten

Die Unterstützung einer internen Personalabteilung ist natürlich Gold wert, wenn sie weiß, worauf sie bei Bewerbern achten muss.

Der Einsatz von Headhuntern wird bei einem guten Vertrauensverhältnis empfohlen. Wenn ein Headhunter nicht vorbeikommt, um “uns” als Unternehmen und als Menschen kennenzulernen, bekommt er keinen Auftrag. Headhunter sollten so effizient und genau wie möglich sein. Dazu müssen sie aber auch den Spirit des suchenden Unternehmens kennen. Sobald man einen guten Headhunter gefunden hat, kann dieser Wunder wirken.

Fazit

Die Suche nach Talenten im IT-Bereich unterscheidet sich etwas von der in anderen Branchen. Die Kunst besteht darin, sich bewusst zu sein, was man braucht und was man braucht und investieren will. Souveränität und Authentizität werden hoch geschätzt. Gleiches gilt für die Aussicht, an Projekten zu arbeiten, die den Bewerber fachlich voranbringen und sinnstiftend sind.

Investieren Sie aber unbedingt die Zeit, zu reflektieren, was Sie brauchen. Software Engineers gießen nicht selten die Business Prozesse in Software, die Unternehmen überhaupt erst wirtschaftlich machen. Vergessen Sie das nicht.

Cover Image von Fotografierende