Prämisse
Die IT wird in der Zukunft noch wichtiger, als sie jetzt schon ist. Geschäftsprozesse werden immer digitaler, neue rein digitale Geschäftsprozesse kommen hinzu. Outsourcing im großen Stil ist gescheitert. Weil die IT immer näher ans Kerngeschäft rückt, ist es für jedes Unternehmen unerläßlich, selbst gute IT-Mitarbeiter zu haben. Innovation wird in der Zukunft immer häufiger aus der IT heraus stattfinden. Ohne gute IT-Mitarbeiter findet keine Innovation aus der IT heraus statt.
Gute IT-Mitarbeiter benötigt also jeder – und hier startet schon das Problem aus Unternehmenssicht. Der IT-Spezialist kennt die Angst vor dem Arbeitsplatzverlust nicht. Wenn die Bedingungen nicht so sind, wie er sie gerne hätte, zieht er weiter. Viele Unternehmen haben genau das Problem – sie bieten nicht die richtigen Bedingungen und kämpfen damit, dass gute IT-Mitarbeiter das Unternehmen verlassen.
Also, was fordert ein guter IT-Mitarbeiter?
- Freiheit
- Verantwortung
- Geld
Geld an dritter Stelle – denn natürlich ist es so, dass man gute Mitarbeiter nicht bekommt, indem man 10.000 Euro unter Marktdurchschnitt zahlt. Aber auch nur an dritter Stelle, denn die guten IT-Mitarbeiter, die ich kenne, machen ihren Job aus Leidenschaft.
Ein guter Mitarbeiter möchte die Lösung eines Problems nicht in einem sehr stark eingeschränktem Lösungsraum suchen, gleichzeitig möchte er für seine Lösung geradestehen, die Verantwortung übernehmen.
In vielen Unternehmen findet sich ein Command & Control Stil im Management – viele Hierarchie-Ebenen, Micro-Management bis auf Task-Ebene. Die Verantwortung dafür, was gemacht wird, liegt häufig im Management – Mitarbeiter haben wenig Mitbestimmungsmöglichkeiten und können sich leicht selbst zurückziehen – wer kann schon etwas für die Fehlentscheidungen des Managements?
Es gibt viele Ebenen, auf denen sich dieser Stil – Command & Control – verankert hat. In diesem Blogpost möchte ich auf eine Ebene eingehen, die nicht so offensichtlich ist.
Das Command & Control Prinzip findet sich auch in den IT-Architekturen wieder, die in den letzten zwanzig Jahren entstanden sind. Mit dem Siegeszug von Java wurden in vielen Unternehmen eigene Frameworks entwickelt. Häufig bestimmen sie sehr stark, wie Probleme zu lösen sind und geben einen Lösungsweg fest vor. Häufig verhindern sie aktiv alternative Lösungswege. Meist wurde ein Architekturteam installiert, das darüber wacht, dass das Framework richtig eingesetzt und alternative Lösungen im besten Fall wenigstens bewilligt werden müssen, im schlechten Fall direkt abgelehnt werden.
Freiheit und Verantwortung hat der Entwickler in diesem System wenig. Diejenigen, die das nicht so stark stört, dass sie das Unternehmen verlassen, arrangieren sich – es wird alles nach Vorschrift gemacht, und wenn etwas mal nicht funktioniert, wird es schnell mal auf das Framework geschoben. Das Architekturteam macht viel Support und beschwert sich darüber, dass die Entwickler wegen Problemen zu ihnen kommen, die sie auch selbst mit etwas Googeln lösen könnten. Allein Eigenverantwortung, selbstständige Problemlösung sind in diesem System nicht vorgesehen. Und die guten Leute, die sich mit diesem System nicht arrangieren können, gehen wieder (ein paar von ihnen können vielleicht im Architekturteam gehalten werden, da dort tendenziell mehr Freiheiten existieren).
Und nun? Macht man so weiter wie bisher, kann sich Human Resources so anstrengen, wie es geht – die guten Leute bleiben nicht. Ideal wäre es natürlich, wenn Vorstand und Management die Problematik sehen und gegensteuern – das ist aber häufig nicht zu erwarten.
Ich denke aber nicht, dass man deswegen grundsätzlich machtlos ist – das Architekturteam hat die Möglichkeit, zumindest die Voraussetzungen dafür zu schaffen, dass eigenverantwortliches Arbeiten möglich ist:
Bibliotheken über Frameworks
Statt eines ganzheitlichen Frameworks, das alle Aspekte einer Anwendung regelt und bestimmt und nur ganz oder gar nicht verwendet werden kann, sollten besser einzelne Bibliotheken angeboten werden, die eine Sache machen, und die diese eine Sache gut machen. Wenn man beispielsweise einen einheitlichen Umgang mit Properties im Unternehmen hat, könnte es eine Bibliothek property-management geben, die genau diese Sache regelt. Jede dieser Bibliotheken sollte wie ein gutes Open-Source-Projekt behandelt werden, mit Dokumentation direkt am Source-Code-Repository, Issue Tracker, der Möglichkeit, Pull Requests einzureichen, genauer Angabe von Requirements und mindestens einem direkt Verantwortlichen. Das ganzheitliche Framework entstand in vielen Unternehmen auch zunächst, um nur ein Problem zu lösen, häufig eine Innendienst-Verwaltungsanwendung. Heutzutage gibt es viel mehr digitale Kanäle, die alle bedient werden müssen, und für die ein einheitliches Framework nicht die Lösung sein kann.
Pull über Push
Es gibt keinen Zwang, die angebotenen Bibliotheken zu verwenden. Am Ende entscheiden die Linienentwickler, ob die Bibliothek verwendet wird oder nicht.
Community-Kultur
Jeder kann Pull Requests für Bibliotheken erstellen und diese so verbessern. Außerdem können Bibliotheken auch von Linienentwicklern erstellt, gepflegt und bereitgestellt werden, das ist kein Privileg des Architekturteams mehr.
Der nächste Schritt wäre nun, in Zusammenarbeit mit Operations weitergehende Freiheiten zu schaffen, die es erlauben, weitere Typen von Software zu betreiben, wenn das Team die Verantwortung übernimmt – ein erster Schritt zu echter DevOps-Kultur.
Kann das gutgehen? In Diskussionen höre ich immer wieder, dass das mit den Leuten im entsprechenden Unternehmen nicht funktionieren würde. Teilweise sehe ich das so wie im folgenden Zitat:
"We hired them from you and got out of their way" @adrianco on engineers @ Netflix https://t.co/Hu8ZaSNErp #DOES15 pic.twitter.com/wOpNhvUE3n
— Matthew Skelton (@matthewpskelton) 22. Oktober 2015
Wie kann man dem entgegenwirken? Eine mögliche Lösung sieht so aus: Das Architekturteam liefert ein Framework wie bisher, das ein Bundle der nun modularisierten Bibliotheken mit einem übergreifenden Korsett ist. Das Architekturteam macht klar, dass es keinen Zwang gibt, das Bundle zu verwenden. Und dann lässt man den Dingen seinen Lauf. Es wird Teams geben, die die neue Freiheit nutzen, und es wird Teams geben, die sich erst einmal zurückhalten.
Das Wichtige ist: Die Voraussetzungen für selbstständiges, eigenverantwortliches und daher befriedigendes Arbeiten wurden geschaffen.
War dieser Beitrag hilfreich?
Weitere Beiträge
von Tobias Flohre
16.2.2022 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Tobias Flohre
Senior Software Developer
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.