Wenn ich einmal groß bin

DevOps Stories: Warum wir Jobtitel über Bord werfen sollten

Konstantin Diener

Ruben, der Scrum Master des MusicStore-Teams, hat festgestellt, dass Christian (einer der Backend-Entwickler) in den letzten Wochen zunehmen gereizt und unzufrieden war. Er hat sich mit Christian auf ein Bier verabredet, um die Gründe herauszufinden. Sie sitzen an der Bar, und nach ein paar Sätzen Smalltalk kommen sie auf das eigentliche Thema zu sprechen.

Ruben: „Du wirkst in den letzten Wochen sehr demotiviert und gehst auch sehr ruppig mit deinen Kollegen um.“

Christian: „Findest du? Lukas und ich arbeiten doch super zusammen.“

Ruben: „Das stimmt, mit Lukas verstehst du dich gut. Aber dein Team besteht nicht nur aus Lukas. Vor allem mit dem neuen Kollegen Jens sprichst du sehr unfreundlich und bist sehr reizbar.“

Christian: „Weil Jens mir auch auf die Nerven geht. Ich arbeite jetzt seit sieben Jahren als Entwickler und er kommt direkt von der Uni.“

Ruben:Was stört dich daran? Und was ist bei Lukas anders?“

Christian: „Lukas hat’s einfach drauf, der Neue nicht! Er kommt ständig mit irgendwelchen Vorschlägen, die Quatsch sind.“

Ruben: „Warum meinst du, dass sie Quatsch sind?“

Christian: „Weil man das nicht so ,quick and dirty‘ macht, sondern direkt richtig!“

Ruben: „Ist das alles, was dich stört?“

Christian: „Naja, durch Jens habe ich auch gemerkt, dass ich in unserem Laden einfach nicht vorankomme …“

Ruben: „Wie meinst du das?“

Christian: „Ich arbeite jetzt seit sieben Jahren hier und bin auf derselben Stufe wie Jens. In einer anderen Firma wäre ich längst Senior Developer und könnte ihm ab und zu mal sagen, dass er einfach die Klappe halten soll – und das machen, was Lukas und ich ihm sagen. Stattdessen diskutieren wir ständig mit ihm.“

Ruben: „Und du meinst, dass ein Jobtitel etwas daran ändern würde? Hättest du dir vor sechs bis sieben Jahren von irgendwelchen Senior Developern Vorschriften machen lassen?“

Christian: „Nö. Ich hatte aber auch nicht so wenig Ahnung!“

Ruben (lacht): „Das lasse ich jetzt mal so stehen. Ich habe nämlich noch eine andere Frage.“

Christian: „Und die wäre?“

Ruben: „Warum du nicht gut auf Jens zu sprechen bist, haben wir jetzt geklärt. Du hast diese Woche aber auch Julia ganz schön angeblafft, als sie dich um Hilfe gebeten hat.“

Christian: „Wegen ihres blöden Frontend Builds? Damit ging sie mir auch ziemlich auf den Geist. Was kann ich denn dafür, dass sie so einen JavaScript-Mist verwendet und dann nicht in die Build-Pipeline reinbekommt.“

Ruben: „Du kennst dich aber mit dem Build-System gut aus …“

Christian: „Ich bin aber kein Frontend-Entwickler, Julia schon. Ich habe auch genug anderes zu tun.“

Ruben: „Du hättest also am liebsten „Senior Backend Developer“ als Titel?“

Christian: „Ja, das klingt gut!“

Abb. 1: Bei einem Bier lässt es sich leichter über die Arbeit reden

Neue Mitglieder bedeuten für bestehende Teams in der Regel Stress

Christians Team hat Verstärkung bekommen. Eigentlich sollte das eine gute Nachricht sein, aber er ist sehr verärgert über den neuen Kollegen – aus zwei Gründen. Zum einen „stresst“ das neue Mitglied das Team. Christian und Lukas sind aufeinander eingestellt und haben ihr Vorgehen beim Lösen von Problemen und beim Entwickeln von Software aufeinander abgestimmt. Für die beiden fühlt sich dieses Vorgehen gut und richtig an, objektiv gesehen muss es das nicht immer sein. Jens bringt jetzt frischen Wind ins Team und „stört“ die beiden in ihrem Paarlauf. Nicht ohne Grund gibt es die Faustregel, dass ein Team seinen Teamvertrag mit jedem neuen Mitglied neu justieren sollte [1].

Zum anderen ist Christian verärgert, weil er sich Jens vor allem in der Softwareentwicklung überlegen fühlt. Durch den neuen Kollegen wird ihm klar, dass er durch diese Überlegenheit eigentlich Sonderrechte haben möchte, aber nicht hat. Jens’ Meinung hat genauso viel Gewicht wie seine eigene. Er will gerne einen Titel haben, der seine Überlegenheit dokumentiert und es ihm erlaubt, die von Jens ausgehenden Störungen zu minimieren.

DevOpsCon Whitepaper 2018

Free: BRAND NEW DevOps Whitepaper 2018

Learn about Containers,Continuous Delivery, DevOps Culture, Cloud Platforms & Security with articles by experts like Michiel Rook, Christoph Engelbert, Scott Sanders and many more.

Ändern Titel irgendetwas?

Agile Teams leben davon, dass die verschiedenen Sichten und Informationen der Teammitglieder zu einem Gesamtbild zusammengefügt werden [2]. Außerdem strebt das ideale agile Team nach steter Verbesserung (Inspect and Adapt in Scrum). Diese beiden Grundgedanken lassen sich nur umsetzen, wenn alle Meinungen im Team gleich viel wert sind und nicht der Jobtitel darüber entscheidet, welche Meinung gewinnt. Nach Larman und Vodde ist dies der eine negative Effekt, den Jobtitel auf agile Teams haben können (Hierarchy: „Ich glaube dem Senior mehr“) [3]. Der zweite negative Effekt taucht ebenfalls im Gespräch zwischen Christian und Ruben auf. Christian sagt, er sei Backend-Entwickler und habe mit Julias Problemen nichts zu tun (Specialization). Je spezifischer die Jobtitel sind, desto schneller gerät in Vergessenheit, dass Teams immer nur als Ganzes gewinnen können. T-shaped Personalities sind das Ziel.

Außerdem führt der Verweis auf den Titel bei Mitarbeitern wie Jens über kurz oder lang zu Frust, wenn sie immer unbegründete Bastaentscheidungen der Kollegen umsetzen müssen. Christian gibt ja sogar zu, dass er sich von Senior-Entwicklern früher auch nichts hätte sagen lassen. Im siebten der „Ten Commandments of Egoless Programming“, [4] ist das Prinzip echter Führung sehr treffend zusammengefasst: „Echte Autorität fußt auf Kenntnissen, nicht auf (hierarchischer) Position“.

Wann ist man eigentlich Senior Developer?

Christian ist verärgert, weil man ihn nach sieben Jahren Betriebszugehörigkeit nicht mit einem Titel als Senior Developer dekoriert hat. Er lässt offen, was für ihn genau einen solchen Entwickler ausmacht. Dieser Frage widmet sich ein Blogpost mit dem Titel „On Being A Senior Engineer“. Zunächst einmal beschreibt der Autor dieses Texts seine Schwierigkeiten mit dem Begriff „Senior“. Wenn Christian nach sieben Jahren Senior Developer wäre, was möchte er dann nach zehn Jahren sein? Super Senior Developer? Vice President Technology? Der Autor schlägt vor, eher von „Mature Developer“ zu sprechen. Dieser Mature Developer ist aber kein Titel, sondern ein Zielbild mit bestimmten Eigenschaften.

Einige dieser Eigenschaften scheinen Christian zu fehlen. Zusammenfassend wird dieser Entwickler als jemand beschrieben, mit dem die Kollegen gerne zusammenarbeiten. Jens arbeitet vermutlich nicht so gerne mit Christian zusammen, weil dieser ihn immer seine vermeintliche Überlegenheit spüren lässt, und auch Julia kann sich spätestens seit dieser Woche vermutlich angenehmere Gesprächspartner vorstellen. Es ist völlig unerheblich, wie viel Christian weiß und kann, wenn niemand mit ihm arbeiten möchte.

Aus Sicht des Bloggers zeichnet einen Mature Developer eine „Good-enough-for-now“-Mentalität aus. Im Gegensatz zu Christian ist er der Meinung, dass man Software nicht immer „gleich richtig“ machen kann, sondern sie sich Stück für Stück entwickelt („Premature optimization is the root of all evil.”).

Ein solcher Entwickler ist sich auch darüber im Klaren, dass unsere menschliche Wahrnehmung kognitiven Verzerrungen (Cognitive Biases) unterliegt. Christians Argumentation deutet auf mindestens zwei dieser Verzerrungen hin. Zum einen auf „Self-serving Bias“: Was er selbst tut, ist per definitionem immer besser als das, was Jens tut. Zum anderen auf einen „Fundamental Attribution Error“: Die Fehler, die andere machen – wie Julia oder Jens –, liegen immer an deren Person, seine eigenen Fehler immer am Kontext.

DevOps Stories

„Agilität“, „Management 3.0“, „New Work“ oder „DevOps“ – all diese Bewegungen verändern die Art und Weise, wie Softwareentwicklung organisiert wird. Und wenn man ihren Denkmustern und Ideen konsequent folgt, beeinflussen sie stark die Kultur des Unternehmens. Über solche Kulturveränderungen berichtet Konstantin Diener (CTO von cosee) in dieser Kolumne. Doch wie lassen sich Erfahrungen zu Veränderungen der Unternehmenskultur transportieren? Er ist der Meinung, so wie die Menschheit seit Jahrtausenden Erfahrungen transportiert: durch Geschichten, den DevOps Stories.

Wie sieht eine Organisation ohne Titel aus?

Jobtitel scheinen gefährlich für (agile) Teams zu sein. Wie aber sieht die Alternative aus? Sollte eine Organisation vollständig auf Titel verzichten? Larman und Vodde schlagen folgende Optionen vor [3]:

  • generisch: Alle Mitarbeiter tragen generische Jobtitel wie „Entwickler“ oder sogar „Mitarbeiter“.
  • selbstgewählt: Die Mitarbeiter sind frei in der kreativen Ausgestaltung ihrer Titel. Je lustiger desto besser (z. B. „Retro-Queen“, „DB-Gott“ …)!
  • Levels: Wenn es aus irgendwelchen Gründen zwingend eine Unterscheidung geben muss, sollte man Levels verwenden (z. B. „Entwickler 1“, „Entwickler 2“ …).

Diese drei Optionen funktionieren intern meist sinnvoll, führen bei der Kommunikation mit der Außenwelt aber zu Irritationen. Die Autoren schlagen deshalb vor, die internen auf externe Jobtitel abzubilden. Wenn ein Mitarbeiter das Unternehmen verlässt, kann der neue Arbeitgeber ihn anhand des externen Titels entsprechend einstufen und seine Erwartungen definieren.

Ruben hat Christian im weiteren Verlauf ihres Gesprächs vom Zielbild des Mature Developers erzählt und ihn insbesondere auf kognitive Verzerrungen hingewiesen. Sie haben sich auf ein gemeinsames Gespräch mit Jens geeinigt, in dem Christian mal explizit aussprechen kann, was ihn stört. So bekommt Jens die Chance, sich zumindest ein wenig in Christian hineinzuversetzen. Ruben hat Christian angeboten, ihm in Vier-Augen-Gesprächen regelmäßig sein Verhalten zu spiegeln und mit ihm auf das Zielbild eines Mature Developers hinzuarbeiten.

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

Hinterlasse einen Kommentar

1 Kommentar auf "DevOps Stories: Warum wir Jobtitel über Bord werfen sollten"

avatar
400
  Subscribe  
Benachrichtige mich zu:
Robert Heisterli
Gast
Der Artikel zeigt nach meiner Auffasuung einmal mehr die ganze Verlogenheit der agilen Verhaltenskontrolle. Wie immer wird das „Verhalten“ eines Mitarbeiters bemängelt, seine Arbeitsergebnisse spielen eine untergeordnete Rolle. Die Aussage „jede Meinung ist GLEICHVIEL wert“ ist ein Hohn auf Sachkompetenz und Erfahrung! [Meinungsfreiheit bedeutet i-ü., dass jede Meinung – auch die abwegigste – wenn in ordentlicher Form vorgebracht, geäussert werden darf ohne Verfolgung oder Zensur des ggflls. Oppositionellen. Es bedeutet weder im politischen, noch technischen Kontext natürlich NICHT, dass alle Meinungen deshalb GLEICHWERTIG wären, ganz im Gegenteil, manches ist einfach dumm oder unsinnig.] Dass jemand aufgrund jahrelanger nachgewiesener Sachkompotenz +… Read more »