Die 6 großen Sünden für ein toxisches Arbeitsumfeld
Goldene Regeln, um Neulingen den Einstieg ins Projekt zu vermiesen
Software-Entwicklung ist hart und unfair – und so soll es auch bleiben! Du hast gelitten, also sollen die anderen auch leiden! Wie Du schon Neulingen den Einstieg in Dein IT-Projekt, Dein Unternehmen oder Dein Verfahren bis aufs äußerste ungemütlich gestalten kannst, erfährst Du in diesem Artikel!
Stell Dir vor, Du hast eine Rolle in Deinem Projekt, Deinem Unternehmen, Deinem Verfahren oder Deiner Organisation… ganz egal, ob Du nun Entwickler, Software-Architekt, Testmanager, Product Owner, Projektmanager bist oder was auch immer Du in deinem Umfeld machst. Und plötzlich bist Du für jemand Neues verantwortlich: Ein Neuling, ein Greenhorn, ein Junior-Developer, ein Junior-Tester, vielleicht auch ein frischer Product Owner. Brandneu aus der Ausbildung, aus dem Studium oder aus einem Traineeprogramm für Quer- und Umsteiger! Das gefällt Dir gar nicht, und daher willst Du es dieser Person auch nicht einfach machen. Du hast gelitten, alle sollen leiden! Das wäre ja noch schöner, wenn man das Onboarding angenehm gestaltet, Dir ist man schließlich auch nicht so entgegengekommen. Vielleicht fehlen Dir die richtigen Ideen, wie Du diesen Einstieg des Neulings unschön gestalten kannst, daher stellst Du Dir vielleicht auch die Frage: "Gibt es nichts, was mir dabei hilft? Eine Hilfestellung, Tipps, Tricks, vielleicht sogar eine Handreichung? Ich kann das nicht alleine!" Dazu kann ich nur sagen: "Ja, es gibt sie, diese Tricks, diese Tipps und Hilfen."
Du kannst sie nennen, wie Du möchtest, ob nun große Sünden, goldene Regeln oder auch ganz banal "Antipattern". Damit Du das richtige Bild vor Augen hast, beschreibe ich es Dir etwas genauer, ein wenig Fantasie wirst Du allerdings brauchen: Stell Dir Charlton Heston in der Rolle des Moses im Film "Die zehn Gebote" vor. Er steigt mit den Steinplatten, auf denen die besagten Gebote geschrieben stehen, herab, mit strengem Blick, das Firmament ist düster, Blitze zucken – siehst Du es schon vor deinem inneren Auge? Das ist das Mindset, was wir brauchen, um uns durch diese Sünden zu arbeiten.
Die großen Sünden. Es gibt viele davon, doch in diesem Artikel möchte ich über sechs dieser Sünden sprechen. Durch die Anwendung dieser Sünden gelingen Dir folgende großartige Dinge:
- Der Einstieg für die Neulinge wird äußerst unerfreulich gestaltet.
- Die Neulinge werden für ihr ganzes weiteres (Berufs-)Leben geprägt.
- Die Anwendung der Sünden kann dafür sorgen, dass Dein Projekt (noch) schneller an die Wand fährt.
Nennen wir es einfach "triple win". Klingt gut, oder? Genug des Vorgeplänkels, ich nehme Dich nun mit auf eine Reise: Schauen wir uns sechs auserwählte Sünden doch mal an…
Erfolgreiches Onboarding behindern – die erste Sünde
Es ist der erste Tag für den Neuling. Hochmotiviert kommt er zu Dir, in der Hoffnung, von Dir angemessen empfangen und eingearbeitet zu werden. Du erwartest ihn, und Du hast nur eins im Sinn: direkt am ersten Tag für Demotivation und ein negatives Mindset sorgen. Und damit fängst Du an, kaum dass die Begrüßung beendet ist. Dabei müssen Deine Aussagen nicht der Realität entsprechen, vielleicht übertreibst Du auch oder lügst gar, aber Du solltest nie vergessen, dass es darum geht, direkt zu Beginn ein negatives Bild zu vermitteln! Als erstes weist Du darauf hin, wie schlecht doch die Atmosphäre im Projekt ist: Keiner mag den anderen, niemand arbeitet gerne in diesem Team, es herrscht großer Druck und alle sind unzufrieden. Vielleicht betreibst Du auch Namedropping und weist schon mal auf – aus Deiner Sicht – "seltsame Kollegen" hin, um sofort schon Vorurteile oder Vorbehalte zu schüren. Darüber hinaus darf der Hinweis, dass das Projekt kurz vorm Zusammenbruch ist, nicht fehlen. Out of budget, out of control. Absturz ins völlige Chaos.
Und überhaupt: Als neues Teammitglied ist man ohnehin nur eine Ressource von vielen, und man hat zu funktionieren, mehr nicht. Das ist auch etwas, dass man immer neuen Kollegen, die als Externe ins Projekt kommen, mitgeben kann: "Du bist austauschbar, und wir werden dich austauschen." Schließlich wird im Projekt auch richtig gearbeitet, es wird gar täglich die Extrameile gegangen: Nur die Starken überleben, die Schwachen werden vergehen. Survival of the Fittest. Darwin gefällt das.
Durch Anwendung dieser ersten großen Sünde sollte es ein Leichtes sein, etwaige Motivation direkt zu Beginn eines Projekts bzw. bei Einstieg eines Neulings enorm zu dämpfen. Sollte es aber noch nicht reichen, den Neuling zu brechen, dann nehmen wir doch einfach die nächste Sünde auf unserer Liste.
Ansprechpartner nicht erreichbar – die zweite Sünde
Nun ist die erste Begrüßung vorbei, und nun ist er da, der Neuling. Ob nun remote im Homeoffice oder tatsächlich vor Ort im Office. Er weiß nicht, was er tun soll. Er hat Fragen. Viele Fragen. Aber er bekommt keine Aufgaben, keine Antworten. Alle Anrufe, ob bei Dir, oder bei anderen Mitgliedern der Teams, bleiben unbeantwortet. Mails ebenso. Wenn Du zufällig gerade auch im Büro bist und er auf die Idee kommen sollte, Dich aufzusuchen, hast Du Strategien, wie man am besten untertauchen kann. Und sollte er Dich wirklich mal zu greifen bekommen haben, entschwindest Du und versuchst alles auf "später" zu verschieben.
Sorge dafür, dass Du und Deine Vertreter für den Neuling nicht erreichbar sind.
Und somit bleibt der Neuling allein. Allein mit sich, allein mit seinen Fragen. Allein in seiner Einsamkeit, und er beginnt sich wirklich unbedeutend zu fühlen, bis er sich selber die Frage stellt: "Will wirklich niemand mit mir sprechen? Wie unbedeutend bin ich?" Man sieht: Der Einstieg in ein Projekt, ein Unternehmen, ein Verfahren oder eine Organisation kann tatsächlich Ansätze einer existenziellen Krise nach sich ziehen.
Sorge dafür, dass Du als Ansprechpartner und auch alle Deine Vertreter für den Neuling nicht erreichbar sind. Das ist sehr einfach, und damit erzielst Du sehr gute Ergebnisse. Nutze diesen Zeitraum ausreichend, denn diese Phase endet häufig sehr schnell, aber auch dafür haben wir die passende Sünde in der Hinterhand.
Wahllose Aufgabenverteilung – die dritte Sünde
Irgendwann ist es soweit: Personen, die in der Nahrungskette über Dir stehen, bekommen heraus, dass der Neuling bislang noch nicht produktiv am Projekt teilnimmt (er ist ja schließlich eine zu schröpfende Ressource). Jetzt liegt es an Dir und auch an Deinem Team, den Neuling mit Arbeit zu versorgen. Nun gut, dann denken sich Du und Dein Team das eine oder andere Thema aus, und dann ist es schließlich soweit: Das Teammeeting, in welchem der Neuling seine ersten "echten" Aufgaben bekommen soll, ist nun endlich angebrochen.
Ihr habt euch zwar Themen ausgedacht, aber nichts weiter dazu besprochen. Das ist gut, denn nun bekommt er von jedem Teammitglied eine andere, teilweise widersprüchliche Aufgabe zugeteilt:
- "Naja, Du kennst Dich hier nicht aus, aber Du könntest ja Bugs fixen!“
- "Auf keinen Fall Bugs fixen! Da macht der Neuling ja nur noch mehr kaputt!“
- "Na gut, aber er könnte doch kleine, ein bis zwei Story Points bearbeiten? Was kann da schon passieren...?“
Und so geht es dann weiter. Im Grunde kommt am Ende keine sinnvolle Aufgabe für den Neuling dabei heraus. Eine Variante dieser Strategie wäre aber beispielsweise auch, dass die Aufgaben gar nicht widersprüchlich sind, sondern dass Du mit Deinem Team dafür sorgst, dass der Neuling mit Aufgaben quasi überrollt wird. Wenn er dann sagt, dass es viel zu viel für ihn sei, dann quittiert ihr das lapidar mit einem "Du machst das schon, organisier Dich halt!"
Unabhängig von der gewählten Variante gibt es dann auch noch in jedem Team die eine Stimme, die grundsätzlich gegen jeden Neuling im Team ist und das auch gerne kundtut: "Warum haben wir einen weiteren Entwickler bekommen? Wir brauchen Tester!" Diese Aussage wird dem Neuling auf jeden Fall auch nicht helfen. Wenn Euch aber gar nichts einfällt, dann gebt dem Neuling einfach die Standardaufgabe, die schon seit Jahrzehnten in jedem Kontext angewendet wird: "Lies‘ Dich mal ein!" Dokumentation lesen, das scheint eine gute Idee zu sein. Schauen wir uns das mit der Beschreibung der nächsten Sünde doch mal gründlicher an.
Herausforderungen für Neulinge – die vierte Sünde im IT-Projekt
Es geht also um das Thema Dokumentation. Was kann es Einfacheres geben, um einen Neuling für einen längeren Zeitraum zu beschäftigen, ohne sich selbst die Hände schmutzig zu machen? Du bist zufrieden, der Neuling zunächst auch, denn er glaubt, das Lesen von Dokumentation wäre der beste und schnellste Weg, alles Wichtige über das Projekt, die Fachlichkeit und die Technologien zu erfahren. Welch ein Irrtum! Und das wird der Neuling schon sehr schnell merken…
Unabhängig vom gewählten Dokumentationstool (sei es z. B. Confluence, Sharepoint oder ein Wiki-System) lautet die erste Regel: Dokumentation nicht aktualisieren! Es gibt doch nichts Schöneres, als zu merken, dass man einer Anleitung nicht folgen kann, weil die Software seitdem schon einige Versionen weiter ist. Für Euch ist das sogar eine Win-Win-Situation: Ihr müsst Euch nicht um den Neuling kümmern, weil er ja die Dokumentation durcharbeitet (erreichbar seid ihr ohnehin nicht), und der Neuling kann dabei ja direkt die veraltete Dokumentation aktualisieren. Neben veralteter Dokumentation gibt es auch noch Beschreibungen, deren Zustand nicht ganz klar ist: Wird noch daran gearbeitet? Ist es fertig? Fehlt etwas? Gut sind auch Verlinkungen auf leere Seiten, in denen ein lapidares "To Do" als einziger Inhalt dargestellt wird. Irgendwer wird irgendwann unter ganz bestimmten Umständen dann dort auch sicher etwas dokumentieren. Vielleicht.
In einer Sache bin ich mir auf jeden Fall sicher: Du kannst schlecht dokumentieren, und wenn nicht, dann kannst du es lernen.
Agiles Projektmanagement – die fünfte Sünde
"Wir arbeiten ab jetzt agil!" – Das sagten sie Dir, und ob Du nun willst oder nicht, Du musst es mitmachen, denn schließlich willst Du Geld verdienen. Dabei ist es doch völlig egal, welchem Vorgehensmodell man folgt: Ist man in der klassischen Welt unterwegs, im Wasserfallmodell oder auch im V-Modell, da wird spezifiziert, implementiert, getestet und was ist das Resultat? Richtig, ein großer Haufen Mist.
Sorge dafür, dass Deine Meinung, Deine Einstellung auf den Neuling abfärbt.
Nun geht man aber hin und baut kleine Teile, in kurzen Abständen, in sogenannten Iterationen. Und so hat man nicht erst nach vielen Monaten (oder gar Jahren) einen großen Haufen Mist, sondern einen kleinen Haufen bereits nach kurzer Zeit, der nach jeder Iteration weiter wächst und irgendwann die gleichen Ausmaße einnimmt wie in der alten Welt. Iterativ. Inkrementell. Exkrementell, quasi. Nun, Du bist eher der Old-School-Typ und zeigst Deine Meinung zu diesen agilen Vorgehen, z. B. diesem "Scrum" offen nach außen. Und Du sorgst dafür, dass Deine Meinung, Deine Einstellung auf den Neuling abfärbt. Dafür musst Du dann ein gutes Vorbild sein:
- Nimm nur halbherzig an den Ritualen teil oder kapere sie!
- Stelle den Prozess immer in Frage: "…also nach gesundem Menschenverstand sollten wir das ganz anders machen."
- Sorge dafür, dass Sprints stets überplant sind und immer gerissen werden – um damit zu zeigen, dass dieser "moderne Quatsch nicht funktioniert".
- Zeige, dass Story Points nichts mit Komplexität zu tun haben ("Was ist das überhaupt?") und dass ein Story Point äquivalent zu einem Personentag zu sehen ist.
Nimm den Neuling mit, trichtere es ihm ein, und er wird Deiner Meinung sehr schnell folgen. Versprochen. Und ich bin mir sicher: Du kannst das!
Fünf Sünden habe ich nun beschrieben. Bleibt nun noch Platz für eine vorerst letzte…
Projektmanagement auf den diesjährigen IT-Tagen
Spannende Vorträge und Workshops zum Thema Projektmanagement erwarten Euch auch auf den IT-Tagen, der Jahreskonferenz von Informatik Aktuell. Die IT-Konferenz findet jedes Jahr im Dezember in Frankfurt statt – dieses Jahr vom 08.-11.12.
Absichtlich unverständlicher Code: die sechste Sünde
Bestimmt lesen auch die einen oder anderen Personen diesen Artikel, die sich selbst als "Software-Entwickler" bezeichnen, das heißt, du implementierst Sourcecode. Ob nun in Java, C#, TypeScript oder was auch immer, völlig egal! Die wichtigste Devise für deinen Code lautet: "Es war extrem schwer, diesen Code zu schreiben, es soll also auch extrem schwer sein, ihn zu verstehen!" Daher sind für Dich auch gängige Standards, Paradigmen oder Pattern nur Altpapier. Objektorientierung? Kann man machen, aber man sollte es entweder nicht übertreiben (brauchte man ja früher auch nicht), oder man überdesignt sein System mit so absurd vielen Abstraktionsebenen, dass man selbst die Übersicht verliert (und auch kein UML-Diagramm es mehr sinnvoll darstellen kann). Entwurfsmuster werden auch nicht berücksichtigt, schließlich willst Du Dir selbst Gedanken machen, wie man ein gängiges Problem lösen kann. Wurde schon das Thema "Testabdeckung" erwähnt? Das ist auch nicht der Rede wert! Über Dokumentation im Code brauchen wir auch nicht zu sprechen: Was man an anderer Stelle nicht tut, muss man auch in seiner Implementierung nicht machen. Darüber hinaus ist das Werkzeug des "To Do" auch hier wieder dein treuer Begleiter.
Lange Rede, kurzer Sinn: Du brauchst nur schlecht zu programmieren! Und ich bin der festen Überzeugung, dass Du das kannst, wenn Du nur willst! Du musst Dich nicht mal wirklich anstrengen. Schlechter Sourcecode erschwert jedem Neuling (oder auch alten Hasen) einen ohnehin schweren Einstieg, und am Ende geht es doch genau darum.
Das waren sie nun: Die großen Sünden, die quasi goldene Regeln, um Neulingen den Einstieg zu vermiesen, sie für ihr weiteres Berufsleben zu prägen und um Dein Projekt erfolgreich gegen die Wand zu fahren. Aber Moment…
…meint der Monschau das etwa wirklich ernst?
Diesen Artikel habe ich mit einem klaren Lehrauftrag geschrieben: Natürlich sollst Du diese Sünden NICHT anwenden! Abgesehen davon, dass sie für ein toxisches Arbeitsumfeld sorgen, decken sie im Grunde sehr massiv auf, dass Dein Projekt, Dein Verfahren, Deine Organisation oder auch Dein Unternehmen sich gehörig in Schieflage befindet oder auf dem besten Weg zum Scheitern befindlich ist! Bevor man in ein solches Projekt einsteigt, ob als Junior-Entwickler oder als Senior-Entwickler, sollte man sehr genau zuhören, um festzustellen, wie man dort "tickt". Und wenn sich herausstellt, dass es dort eher chaotisch zugeht, dann muss man schauen, in welche dieser drei Kategorien von Chaosprojekten es gehört:
- Sanierungsfall – es liegt einiges im Argen, aber man kann da noch was draus machen, wenn man die richtigen Schritte einleitet und die Verantwortlichen entsprechend unterstützt.
- Palliativpatient – das Projekt wird zugrunde gehen, aber mit einigen Kniffen kann man es vielleicht zu einem würdigen Ende bringen.
- Apokalyptisch – das Projekt wird zerbersten, und man selbst wird mit untergehen, also rette sich, wer kann!
Stufst Du das Projekt als einen Renovierungsfall ein, dann kannst du selbst entscheidend dazu beitragen, es in besseres Fahrwasser zu bringen – und sei es am Ende auch nur, indem Du das Onboarding von Junioren anders gestaltest, als Du es erlebt hast. Welche Knöpfe Du darüber hinaus drücken kannst, um das Projekt wieder in die Spur zu bringen, um vielleicht am Ende als Held (oder, falls es trotz aller Bemühungen nicht klappt, als Märtyrer) vom Platz zu gehen, nun, das ist eine andere Geschichte…
