Suche
Kolumne: DevOps Stories

DevOps-Mitarbeiter einstellen: Wie finden wir jemanden, der zu uns passt?

Konstantin Diener

©SuS_Media

Welches IT-Unternehmen kennt die Situation nicht? Man müsste unbedingt weitere IT-Spezialisten einstellen. Die bestehenden Teams sind schon überlastet und schieben diese Aufgabe deshalb gerne an die HR-Abteilung ab. Auch Lukas und sein Team denken hier sehr stark in Silos.

Lukas und seine Kollegen sitzen mit Erik (ihrem Product Owner) und dem Scrum Master Ruben im Sprint Planning.

  • Erik: „Ich hatte mir erhofft, dass wir mit den neuen Themen für den Music-Store schneller vorankommen. Für den nächsten Sprint haben wir wieder so wenig Zeit eingeplant.
  • Christian: „Wer soll die ganze Arbeit denn machen? Wir haben alle nur zwei Hände! Und schuften schon wie wild!
  • Julia: „Wir brauchen dringend ein, zwei Leute mehr im Team!
  • Erik: „Aber HR hatte doch vorletzte Woche einen neuen Kollegen vorgestellt.
  • Christian: „Bleib mir bloß weg. Der hat uns keine Arbeit abgenommen, sondern nur welche gemacht. Der hatte nichts drauf!
  • Lukas: „Das ist ein bisschen unfair! Ja, er hat von den Skills nicht so super zu uns gepasst. Um ihn gekümmert haben wir uns aber auch nicht wirklich.
  • Christian: „Wann soll ich das denn machen? Vor allem bei einem, bei dem ich mit Adam und Eva anfange.
  • Ruben: „War jemand von euch beim Vorstellungsgespräch dabei?
  • Christian: „Haha, guter Witz. Natürlich nicht, hat HR gemach; weil die ja sooo viel Ahnung davon haben. Außerdem: Wann sollen wir das noch machen?

Ruben merkt, dass sein Team sehr unzufrieden mit der Situation ist und verabredet ein Treffen mit Silke von der HR.

  • Ruben: „Hallo Silke, ich habe dich um ein Treffen gebeten, weil wir im Team dringend Verstärkung brauchen. Außerdem waren die Kollegen mit dem letzten Kandidaten völlig unzufrieden.
  • Silke: „Grüß dich, Ruben. Ich weiß, wie eng es bei euch ist.
  • Ruben: „Das Team sagte, er passte von den Skills nicht richtig und war auch kein guter Softwareentwickler.
  • Silke: „Seltsam, der Lebenslauf sah gut aus. Und wir haben die Skills im Gespräch auch nochmal abgefragt.
  • Ruben: „Habt ihr ihn was programmieren lassen?
  • Silke: „Nein. Ich kann das Ergebnis auch gar nicht beurteilen.
  • Ruben: „Vielleicht sollte das nächste Mal ein Entwickler dazukommen.
  • Silke: „Ich weiß nicht … Das haben wir schon mal probiert und damit den Kandidaten nur abgeschreckt.
Abb. 1: Ruben spricht mit Silke

Abb. 1: Ruben spricht mit Silke

Fast jedes IT-Unternehmen sucht Mitarbeiter

Welches IT-Unternehmen kennt die Situation nicht? Man müsste unbedingt weitere IT-Spezialisten einstellen. Die bestehenden Teams sind schon überlastet und schieben diese Aufgabe deshalb gerne an die HR-Abteilung ab. Auch Lukas und sein Team denken hier sehr stark in Silos: „Die in HR sollen ihre Arbeit mal ordentlich machen. Wir haben keine Zeit, auch noch neue Leute einzustellen.“ Das Ergebnis zeigt aber, dass sich die Teammitglieder diese Zeit nehmen sollten und nicht nur eine Stellenausschreibung über den Zaun in das HR-Silo werfen. Mit dem Kandidaten, den Silke eingestellt hat, waren die Teammitglieder offensichtlich nicht zufrieden. Neue Leute einzustellen, ist eine gemeinsame Aufgabe.

Die HR-Kollegen können nämlich augenscheinlich die Eignung eines Kandidaten nicht vollständig bewerten. Das ist auch gar nicht ihre Aufgabe. Sie müssen nicht über ausreichend Wissen in der Softwareentwicklung verfügen und können nicht einschätzen, ob er zum Entwicklungsteam passt.

DevOps Docker Camp
Erkan Yanar

Teilnehmer lernen die Konzepte von Docker und die darauf aufbauenden Infrastrukturen umfassend kennen. Schritt für Schritt bauen sie eine eigene Infrastruktur für und mit Docker auf.

Lasst sie entwickeln!

Die technischen Fertigkeiten eines Kandidaten zu bewerten, ist Aufgabe der Teammitglieder. Gehen wir mal davon aus, dass es um die Einstellung eines Softwareentwicklers geht. Über dessen technische Fähigkeiten lässt sich am besten urteilen, wenn er für das Vorstellungsgespräch oder während des Gesprächs Programmcode entwickelt und präsentiert. Tom DeMarco und Timothy Lister schreiben in ihrem Buch „Peopleware: Productive Projects and Teams“ [1], dass man schließlich auch keinen Jongleur einstellen würde, ohne dass er etwas von seinem Können gezeigt hat. Manche Firmen gehen sogar so weit, dass sie Kandidaten einen Tag oder sogar einen ganzen Sprint im Unternehmen mitarbeiten lassen, um sie einschätzen zu können.

Technische Fähigkeiten sind bei Weitem nicht alles

Den Kandidaten etwas vorführen zu lassen, hat noch einen weiteren Aspekt: Man lernt seine Arbeitsweise kennen. Viele Bewerbungsprozesse und -gespräche für Softwareentwickler konzentrieren sich heute nämlich noch viel zu sehr ausschließlich auf die technischen Fähigkeiten, die das Team heute braucht („Wie gut kann er Java EE programmieren?“). Gerade in crossfunktionalen Teams ist aber wichtig, dass wir keine reinen Spezialisten einstellen. Diese Teams benötigen T-shaped Mitarbeiter, die sowohl über breites als auch über tiefes Wissen verfügen, [2]. Entwickler müssen sich z. B. auch für Ops-Themen interessieren. Dabei hat dieser Punkt nicht unbedingt etwas mit Technologie zu tun. Eigentlich geht es um die Lernfähigkeit und -bereitschaft eines zukünftigen Teammitglieds. Diese Themen zählen zu den viel zitierten Soft Skills. Gerade in agilen Teams mit DevOps-Ansatz sind viele Themen aus diesem Bereich relevant:

  • kein Silodenken („Nicht meine Aufgabe oder mein Problem“)
  • offenes, konstruktives Feedback
  • Umgang mit Konflikten
  • Ziele des Teams verstehen und mitgestalten

Beide Aspekte, technologische Fähigkeiten und Soft Skills, müssen bei einer Einstellung mit entsprechender Sorgfalt behandelt werden.

Standortbestimmung hilft Unternehmen, die passenden Kandidaten anzusprechen

Aber wie soll man diese Punkte alle in einem doch so kurzen Bewerbungsprozess abklopfen? Meist hilft schon eine Standortbestimmung. Die Mitarbeiter des Unternehmens legen fest, wie sie arbeiten möchten, was ihnen wichtig ist und welche Anforderungen sie an neue Teammitglieder haben.

The Joel Test

  1. Do you use source control?
  2. Can you make a build in one step?
  3. Do you make daily builds?
  4. Do you have a bug database?
  5. Do you fix bugs before writing new code?
  6. Do you have an up-to-date schedule?
  7. Do you have a spec?
  8. Do programmers have quiet working conditions?
  9. Do you use the best tools money can buy?
  10. Do you have testers?
  11. Do new candidates write code during their interview?
  12. Do you do hallway usability testing?

Ein guter Einstieg auf der technischen Seite ist der sogenannte Joel Test. Der ursprüngliche Test besteht aus zwölf Fragen (Kasten: „The Joel Test“) und wurde von Joel Spolsky entwickelt. Einen speziell auf den DevOps-Kontext zugeschnittenen Fragenkatalog gibt es auf GitHub. Die Fragen darin sind nach dem folgenden Muster aufgebaut:

  • How fast is a change deployed into production?
  • 0: Within months
  • 1: Within weeks
  • 2: Within days
  • 3: Within hours
  • 5: Within minutes

Eine Standortbestimmung kann nun folgendermaßen aussehen: Die Mitarbeiter eines Teams oder des ganzen Unternehmens einigen sich auf eine ehrliche Bewertung der einzelnen Punkte und veröffentlichen diese zusammen mit ihren Stellenausschreibungen. Natürlich können auch Fragen bzw. Antworten hinzugefügt oder entfernt werden. Ein potenzieller Bewerber beantwortet die Fragen ebenfalls und sieht dann schon vor der Bewerbung, ob er zum Team bzw. Unternehmen passt (Abb. 2).

Abb. 2: Abgleich zwischen Unternehmer und Bewerber

Abb. 2: Abgleich zwischen Unternehmer und Bewerber

Dieselbe Standortbestimmung lässt sich auch für die Soft Skills und andere Aspekte außerhalb der Technologiekompetenz durchführen. Johanna Rothman hat dafür in ihrem Buch „Hiring Geeks That Fit“ [3] sehr umfangreiche Vorschläge – bis hin zu Fragen wie „Ist Geld oder sinnstiftende Arbeit wichtiger?“ Natürlich kann diese Standortbestimmung dazu führen, dass sich weniger Kandidaten bewerben. Die verbleibenden Bewerber passen aber in der Regel sehr viel besser zum Unternehmen.

Das Team entscheidet über die Einstellung

Nachdem das Team eine Standortbestimmung vorgenommen hat („Wie arbeiten wir? Was ist uns wichtig? Was erwarten wir von neuen Kollegen?“), ist es nur logisch, dass sie die Bewerber anhand dieser Kriterien bewerten – und über die Einstellung entscheiden. Das ganze Team? Larman und Vodde sind der Meinung, das ganze Team sollte den Bewerber interviewen und über seine Einstellung entscheiden [2]. Schließlich muss er auch zum ganzen Team passen. Wem das zu radikal ist, der sollte zumindest einen Teil des Teams involvieren.

Das Team entscheidet? Warum sollte es nicht entscheiden? Weil es manche Faktoren nicht beurteilen kann? („Passt der Kandidat ins Gehaltsgefüge?“) Dann sollten an der Entscheidung alle beteiligt sein, die notwendige Informationen haben – z. B. das Team, ein Manager und HR. Wichtig ist aber, dass alle gleichberechtigt sind (Delegationsstufe Agree). Das Team kann Kandidaten genauso ablehnen wie der Manager oder HR.

Nach der Einstellung beginnt das Coaching

Wenn das Team in die Auswahl neuer Mitarbeiter eingebunden ist, wird die Situation vermieden, dass es jemanden „vorgesetzt“ bekommt. Damit fühlt sich das Team in der Regel auch stärker für die Begleitung in den ersten Wochen verantwortlich, die in Lukas’ Team offensichtlich zu kurz gekommen ist. Dabei ist besonders zu beachten, dass eine agile Unternehmenskultur aus vielen ungeschriebenen Regeln besteht. Diese müssen neue Mitarbeiter erst erlernen – am besten durch Coaching, Pair Programming oder Ähnliches.

Silke aus der HR-Abteilung hat zugestimmt, mit Lukas’ Team einen Pilotversuch zu machen. Das Team hat eine Standortbestimmung vorgenommen, die Stellenausschreibungen wurden entsprechend angepasst und in den Interviews ist es nicht nur dabei, sondern entscheidet auch zukünftig mit über die Einstellung. Wenn sich das Verfahren bewährt, soll es auf andere Teams ausgeweitet werden.

LESEN SIE AUCH:

DevOps Stories: Warum cross-funktionale Teams funktionale schlagen

Geschrieben von
Konstantin Diener
Konstantin Diener
Konstantin Diener ist CTO bei cosee. Sein aktueller Interessenschwerpunkt liegt auf selbstorganisierten Teams, agiler Unternehmensführung, Management 3.0 und agiler Produktentwicklung. Daneben entwickelt er noch leidenschaftlich gerne selbst Software. Twitter: @onkelkodi
Kommentare
  1. Dimitri Lätt2018-01-22 18:27:18

    Toller Beitrag!
    DevOps bringt viele neuen Chancen und Möglichkeiten, gleichzeitig aber auch Herausforderungen und Möglichkeit, neue Vorgehensweisen zu entwickeln.
    Danke für den Beitrag und dass Sie diese Erkenntnisse teilen. Ich werde auf jeden Fall weiterlesen!

    Dimitri Lätt
    Recruiting Consultant für DevOps-Spezialisten in der DACH-Region.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.