Kategorie: Management

Wo sind die ITler hin? Zu ChatGPT??

Daemonic Coder

„Aus Gründen“(tm) beschäftige ich mich gerade mit dem IT Stellenmarkt… War es vor ein paar Jahren noch ziemlich problemlos möglich, im Bereich IT, Transformation und Agilität offene Stellen zu finden, so ist dies derzeit etwas schwieriger. Und immer wieder liest man von Unternehmen, die große Mengen an Stellen abbauen.

Die aktuelle Welle an Stellenstreichungen im IT-Bereich wird oft mit einem einfachen Argument begründet: Künstliche Intelligenz übernimmt Aufgaben, also braucht es weniger IT-Fachkräfte. Klatr, warum irgendwelche Junior-Entwickler, wenn Chat GPT das doch auch gut kann, das Entwickeln. Klingt logisch – ist aber nur die halbe Wahrheit. Denn wer mehr IT in einem Unternehmen will, braucht in der Regel auch mehr IT-Expertise, nicht weniger.Von ChatGPT ausgespuckter Code ist oft nicht fehlerfrei und insbesondere nicht automatisch in der IT-Landschaft deployed.

Gleichzeitig ist es jedoch nicht von der Hand zu weisen, dass viele Unternehmen in den letzten Jahrzehnten massive Overhead-Strukturen aufgebaut haben, die nun auf den Prüfstand kommen.

AI ersetzt IT? Nicht so schnell.

Die Vorstellung, dass AI-gestützte Tools die Entwickler, Systemadministratoren oder Architekten ersetzen, ist verlockend – aber kurzsichtig. Automatisierung kann Prozesse effizienter machen, aber sie schafft auch neue Herausforderungen:

  • Mehr IT bedeutet mehr Komplexität: Systeme müssen integriert, gewartet und angepasst werden. Automatisierung nimmt Routineaufgaben ab, aber jemand muss die Werkzeuge implementieren und weiterentwickeln.
  • AI produziert keinen Wert von selbst: Code, den AI generiert, muss überprüft, getestet und gewartet werden. Und je mehr Unternehmen sich auf generative AI verlassen, desto wichtiger wird die menschliche Expertise, um Fehlentscheidungen oder ineffiziente Lösungen zu vermeiden.
  • Neue Technologien bringen neue Sicherheitsrisiken: Mit der steigenden Automatisierung wächst auch die Angriffsfläche für Cyberangriffe. Unternehmen, die IT automatisieren, müssen gleichzeitig in Sicherheit und Governance investieren. Und wie wohl man sich mit dem Datenschutz fühlt, davon möchte ich gar nicht erst anfangen.

Das eigentliche Problem: Overhead und „Bullshit Jobs“

Trotzdem ist es nicht falsch, dass viele Unternehmen aktuell aufgeblähte Strukturen abbauen. David Graeber beschreibt in seinem Buch Bullshit Jobs, wie viele Organisationen im Laufe der Zeit Stellen schaffen, die wenig bis gar keinen direkten Wert erzeugen – oft im Bereich Management, Controlling oder interner Prozesse.

IT-Teams sind oft von solchen Strukturen betroffen. Je größer ein Unternehmen wird, desto mehr Layer an Projektmanagement, Koordination und Verwaltung entstehen. Plötzlich gibt es mehr Meetings als Codezeilen, und Entwickler verbringen mehr Zeit mit Excel-Reports als mit der eigentlichen Softwareentwicklung. Ich selbst habe in den letzten Jahren sicher mehr Powerpoint-Folien erstellt als „echte“ Architekturen. Dass Unternehmen diese Strukturen nun in Frage stellen, ist nicht falsch, streng genommen sogar zu spät.

Der richtige Fokus: IT als Werttreiber, nicht als Kostenfaktor

Anstatt einfach nur IT-Stellen zu streichen, sollten Unternehmen sich fragen: Wie kann IT zum Wachstum beitragen? Der Fokus sollte nicht auf der Reduktion von IT-Mitarbeitern liegen, sondern auf der Beseitigung von bürokratischen Hürden, die die Arbeit der IT-Teams ineffizient machen.

Effiziente IT bedeutet:

  • Reduktion unnötiger administrativer Aufgaben
  • Klare Fokussierung auf wertstiftende Arbeit
  • Sinnvolle Nutzung von AI als Unterstützung, nicht als Ersatz

IT ist heute das Rückgrat fast aller Geschäftsmodelle. Wer hier vorschnell den Rotstift ansetzt, könnte langfristig eine Schwächung des Unternehmens riskieren – und genau das Gegenteil von dem erreichen, was man eigentlich will: Effizienz.

Holokratie – Taylorismus 2.0?

Daemonic Coder

Winslow Taylor gilt als der Erfinder des „Scientific Management“ mit der Idee, die Arbeitsabläufe eines Unternehmens vollständig zu beschreiben und so „perfekte“ Abläufe schaffen zu können. Und er gilt heute beinahe schon als Feindbild der agilen Unternehmen, da seine Ideen als hierarchisch und starr wahrgenommen werden. Und zugegebenermaßen waren seine Ideen Grundlage für eine gewisse Dehumanisierung in der Arbeitswelt. Aber: Das ist meist gar nicht die hauptsächliche Kritik am Taylorismus aus Sicht Agiler Transformationscoaches. Diese merken eher an, dass es in der komplexen Arbeitswelt nicht möglich sei, eine exakte, immer gültige Arbeitsaufteilung vorzugeben. Softwareentwicklung beispielsweise funktioniert nicht „wie am Fließband“.

Dem stimme ich übrigens uneingeschränkt zu.

Um so mehr wundert mich der Zuspruch, den Holokratie oft erfährt. Ich möchte hier nicht Holokratie beschreiben, das ist sicher an anderer Stelle ausführlich genug geschehen, nur meine Kritik oder Verwunderung daran formulieren: Die Idee von Holokratie ist es, dass es ein „Betriebssystem“ ist, das eine Beschreibung „perfekter“ Abläufe hervorbringen kann. Sicher, im Unterschied zum Taylorismus wird diese Beschreibung kollaborativ und nicht vom „allwissenden Management“ erzeugt, aber nichts desto trotz ist das Ziel eine möglichst vollständige (wenn auch veränderliche) Beschreibung der Prozesse.

Für mich klingt daher Holokratie wie ein Taylorismus 2.0.

 

Entschieden entscheiden – egal wer da ist

Daemonic Coder

In „klassischen“ Organisationsstrukturen ist die Frage, wer entscheiden darf, oft recht eindeutig geregelt: Der Chef bestimmt. Und wenn es keine hierarchische Chef-Rolle gibt, dann oft eine fachliche Führung, die entscheidet und die Verantwortung für die Entscheidungen trägt oder zumindest tragen sollte.

Beim Wechsel hin zu einer agileren Organisation beobachte ich oft, dass Teams für sich einen Weg suchen, wie Entscheidungen im Team gemeinschaftlich getroffen werden können. Mehrere Methoden stehen dabei oft zur Diskussion:

  • Mehrheitsentscheid
  • Konsenzverfahren
  • Widerstandsmessung
  • Konsentverfahren

Sicher gibt es nicht die eine Methode, die immer und für alle am besten funktioniert. Aber ich möchte an dieser Stelle aus einem bestimmten Grund die Lanze für das Konsentverfahren brechen:

Gut abgestimmte Teams müssen beim Konsentverfahren keine Beschlussfähigkeit feststellen und sie sind jederzeit flexibel, Entscheidungen zu treffen.

Der erste Reflex vieler Teams für eine Entscheidungsfindung ist oft ein Mehrheitsentscheid. In der Diskussion wird dann aber schnell deutlich, dass zu besprechen ist, wie viele aus dem Team anwesend sein müssen, um eine Entscheidung überhaupt treffen zu können oder ob anstehende Entscheidungen gar im Vorfeld (Agenda) angekündigt werden müssen, um eine Beschlussfähigkeit zu haben. Meiner Meinung nach ist das bei einem Konsentverfahren gar nicht nötig.

Ein Konstentverfahren beschreibe ich so: Steht eine Entscheidung an, so können alle Teammitglieder entweder ihre Zustimmung ausdrücken (Daumen hoch), eine Entscheidung des Teams mittragen (Daumen seitlich) oder gegen die Entscheidung stimmen (Daumen runter). Letzteres ist aber nur mit einem „qualifizierten Einwand“ möglich, also einem Vorschlag, wie der Widerspruch aufgelöst werden kann. Ein solcher Einwand kann auch sein „das können wir nur unter Einbeziehung einer weiteren Person entscheiden“.

Ein Beispiel: Ein Team möchte über eine Änderung der Softwarearchitektur entscheiden, beispielsweise, ob bestimmte Funktionalitäten aus einem Monolithen herausgezogen und in Microservices migriert werden sollen. Bei der Entscheidung darüber kommt es zu einem Widerspruch mit der Begründung „Heute ist Sarah nicht da, die am meisten Erfahrung mit Microservices hat, wir sollten sie auf jeden Fall in die Entscheidung einbeziehen, wenn sie morgen wieder da ist.“

Der Vorteil dessen ist, dass man eine Entscheidung nicht von einem bestimmten Quorum abhängig macht, sondern von der Entscheidungskompetenz der Teammitglieder. Es würde in diesem Beispiel nichts bringen, wenn aus dem Team alle Frontend-Entwickler anwesend wären, die kaum Aussagen zu Microservices machen können.

Voraussetzung, damit dies funktioniert, ist allerdings eine gewisse Teamreife. Nur, wenn man die Fähigkeiten der anderen im Team einschätzen kann, ist ein solcher Widerspruch überhaupt nötig. Aber dann ist das Verfahren meiner Meinung nach besser geeignet, als ein Quorum, das eventuell am Ziel vorbei geht oder eine Verpflichtung zur Vorveröffentlichung, was die Flexibilität sehr einschränken kann.

Kurz gesagt: Nutzt das Konsentverfahren ohne Quorum. Erst, wenn das nicht greift, sollten meiner Meinung nach andere Entscheidungsverfahren genutzt werden.

Was redet der da? Wenn Juristen mit Coaches und Informatikern zusammentreffen

Daemonic Coder

Vor einer ganzen Weile bereits durfte ich (ja, sowas mache ich gerne) eine Abschlussarbeit eines Kollegen und Freundes zur Korrektur lesen. Es handelte sich um eine Arbeit im Fach Wirtschaftsinformatik. Allerdings hatte der Autor vorher einige Semester Jura studiert, was dazu führte, dass ich über einige Formulierungen in der Arbeit sehr stolperte. So wurde im Text ab und an darauf hingewiesen, dass manches „grundsätzlich anders“ gemacht werden solle, als der gewählte Umsetzungsweg, außerdem wurde an der ein oder anderen Stelle eine „billige“ Umsetzung gewählt.

Nach Rücksprache mit meinem Kollegen wurde mir klar, dass er die Begriffe einfach anders verstand, als ich es tat. „Billig“ war für ihn nicht auf die Kosten der Umsetzung bezogen, schon gar nicht war das abwertend „billig“, sondern „angemessen“. Und wenn ein Weg, der „grundsätzlich“ gegangen werden sollte, nicht gegangen wurde, so wich man nur (mit guten Gründen) vom Grundsatz ab. Wir hatten von den verwendeten Begriffen auf Grund unserer unterschiedlichen Ausbildungen ein anderen Verständnis.

Sprachbarrieren existieren nicht nur hin zu Fremdsprachen, sondern auch innerhalb einer Sprache, dort sind sie aber für die Beteiligten oft schwerer zu erkennen.

Wenn sich ein Unternehmen transformiert, so brechen bisherige „Sprachgruppen“ unter Umständen auch auf. Sei es innerhalb eines Teams, weil es sich cross-funktional aufstellt, oder sei es, weil klassische Kommunikationswege durch direktere Kommunikation ersetzt werden. Auf einmal muss der Informatiker mit dem Juristen reden. Erwähnt dann der Informatiker eine Regel als „grundsätzlich“, so ist es etwas, wovon er wohl nicht abweichen will. Alleine die Aufführung des „grundsätzlichen“ erweckt im Juristen die Erwartung, dass im Folgenden auf die Ausnahme eingegangen wird und für einen Coach mögen die „Grundsätze“ die Basis sein, auf der weiter detailliert werden sollte.

Und mein Lieblingsbeispiel der „ausbildungsinduzierten Sprachbarriere“: Wenn ein Psychologe von „5 plus minus 2“ als idealer Teamgröße spricht, so ist nicht der vom Mathematiker verstandene feste Zahlenraum gemeint, sondern „Mittelwert 5, Standardabweichung 2“.

Mein Appell: Werdet euch der verdeckten Sprachbarrieren bewusst, drückt aber niemandem „eure“ Definition auf. Fragt, was das Gegenüber meint und nehmt am besten diese Definition — grundsätzlich. 😉

 

Nachtrag:

Zum Juristendeutsch habe ich noch einen empfehlenswerten Artikel bei leemata gefunden:
https://www.leemeta-uebersetzungen.de/blog/interessantes/deutsch-der-rechtswissenschaft

 

Digitalisierung – Was ist das?

Daemonic Coder

Bei „Captain Power and the Soldiers of the Future“ war das mit der Digitalisierung noch ganz einfach: Ab und an kam der Antagonist, ein fliegender Roboter namens Soaron und digitalisierte Menschen, die dann zu Robotern werden sollten. (Okay, ich gebe es zu: Ich bin ein alternder Nerd.) Heute ist das etwas schwieriger – jetzt wollen alle digitalisieren und eigentlich wissen die meisten gar nicht, was sie damit überhaupt meinen.

Digitalisierung ist „Agilität“, „Schnelligkeit“, „Kundenzentrierung“… Ich weiß gar nicht, was ich alles schon an Erklärungen gehört habe, was Digitalisierung sei. Es scheint also in erster Linie zu sein: Ein Buzzword ohne Bedeutung.

Trotzdem wird jedoch versucht, mit dem Begriff ein Phänomen zu beschreiben, das uns und die Wirtschaft sehr betrifft.

Die ursprüngliche Bedeutung des Wortes ist übrigens ziemlich nahe an dem „Captain Power“-Beispiel: Dokumente werden beispielsweise mit einem Scanner digitalisiert, also in ein Dateiformat für den Computer verwandelt. Die „Digitalisierung“, die in der Wirtschaft oft gemeint ist, ist davon meiner Meinung nach gar nicht so weit entfernt, hier geht es um die Abbildung von Geschäftsprozessen und Vertriebswegen in der IT. Sicherlich begann nach dieser Definition die Digitalisierung bereits, als Mainframe-Computer mit COBOL-Programmen die Folianten in manchen Unternehmen ablösten – aber wenn man nur dies unter Digitalisierung verstehen würde, so wären sogar deutsche Amtsstuben schon vorbildlich digitalisiert.

Digitalisierung geht meiner Meinung nach insofern noch weiter, als dass die IT nicht nur unterstützende Funktion in einzelnen Prozessschritten hat, sondern indem der (Geschäfts-)Prozess an sich durch die IT verändert wird. Das mag nach einer etwas haarspalterischen Unterscheidung klingen, ist jedoch ein fundamentaler Unterschied, ob ich einen Computer verwende, um in einer Autowerkstatt die Fehlerbeschreibung eines Kunden zu erfassen, oder ob der Motor selbst per IoT-Technologie einen Wartungstermin ausmacht, zu dem die benötigten Ersatzteile bereits geliefert wurden.

Die Herausforderung besteht daher in der „Digitalisierung“ darin, dass Entwickler nicht mehr nur in der Umsetzung der Geschäftsprozesse zuarbeiten. Früher war es durchaus möglich, dass sich der „Fachbereich“, der die Geschäftsprozesse definierte, der IT nur als Unterstützung bedienen konnte. Durch die Digitalisierung ist dies nicht mehr ausreichend! Der Fachbereich braucht selbst tiefes IT-Wissen, da das Design des Geschäftsprozesses von der IT stark beeinflusst werden muss.

Gerade für große Unternehmen und Konzerne bedeutet dies meiner Meinung nach, dass einige bisherige Trennung von operativen Bereichen und der IT aufgehoben oder zumindest aufgeweicht werden muss; die Rollen von CEO und CIO müssen verschmelzen.

Entwickler dürfen auch mal kochen

Daemonic Coder

Ich hatte dieser Tage die Gelegenheit, mit einem Kollegen über ein Thema zu sprechen, das mich hin und wieder beschäftigt, nämlich der Angewohnheit von Managern, die Arbeit in der Softwareentwicklung ständig mit anderen Branchen zu vergleichen. 

Dieses interessante Gespräch brachte mich dazu, einen früheren Artikel zu dem Thema zu überdenken und meine Meinung (ein wenig) zu ändern.

Zunächst möchte ich klarstellen, dass ich nicht den Eindruck erwecken wollte, Softwareentwicklung sei etwas „absolut Einzigartiges“, was so besonders sei, dass die anderen Branchen keine nützlichen Erfahrungen für uns Softwareentwickler bieten. 

Da setzte auch das Argument meines Kollegen an, das ich sehr gut finde: Manchmal hilft der Vergleich mit anderen Branchen oder Metaphern aus anderen Hintergründen, um das eigene, festgefahrene Denken zu verlassen. Nach dem Motto „Wenn Libraries und Frameworks Nahrungsmittel wären und ein Entwicklerteam ein Thermo-Mix, worauf müssten wir dann achten?“ Vielleicht darauf, dass die Nahrungsmittel nicht abgelaufen sind, Libraries also nicht veraltet, und darauf, dass Allergene angegeben werden, dass wir also die „Nebenwirkungen“ der Frameworks kennen.

Unter einem solchen Gesichtspunkt ist es denn auch in Ordnung, wenn ein Manager oder eine Managerin sagt „Nehmen wir an, ein Entwicklungsprojekt wäre eine Küche.“ So lange man ihm oder ihr abnehmen kann, genug Ahnung von der Softwareentwicklung zu haben, um die Unterschiede zwischen einer Herdplatte und einem Schreibtisch zu kennen. 😉

Gefangen im Zielsystem

Daemonic Coder

Zielsysteme sind ein wichtiger Bestandteil in der Steuerung fast aller größerer Unternehmen. Manchmal ganz „klassisch“ mit vorgegebene Zahlen-Zielen, an denen noch irgendein Bonus hängt, manchmal etwas „moderner“ in der Form von OKRs.

Viele dieser Systeme sind meiner Meinung nach allerdings kaputt; sie sind in der Realität nicht so brauchbar, wie es die Theorie erstmal vermuten lässt. Darauf möchte ich in ein paar Artikeln hier eingehen, vorher möchte ich jedoch etwas Theorie stellen, da diese das meiner Meinung nach gängigste Problem von Zielsystemen erklären kann: das Gefangenendilemma.

Das Gefangenendilemma kennt vielleicht der ein oder andere aus der Spieltheorie. Die Geschichte in dem Modell funktioniert in etwa so:

Zwei Personen, die gemeinsam ein schweres Verbrechen verübt haben, werden verhaftet und einzeln verhört. Das schwere Verbrechen kann leider nicht zweifelsfrei bewiesen werden, wohl aber ein kleineres Verbrechen. Daher bietet der Staatsanwalt folgenden Deal an: Wenn Du gestehst, Dein Kollege aber nicht, so wirst Du als Kronzeuge frei kommen und der andere kommt für 20 Jahre ins Gefängnis. Gesteht ihr beide, kommt ihr beide für jeweils 15 Jahre in den Knast. Gesteht keiner von euch, so kommt ihr zumindest wegen des kleineren Vergehens für jeweils 5 Jahre ins Gefängnis.

Der rationale Verbrecher denkt nun so: Wenn mein Kumpel nicht gesteht und ich auch nicht, so muss ich für 5 Jahre ins Gefängnis. Wenn ich gestehe, dann gar nicht. Also wäre es in diesem Fall besser für mich, wenn ich gestehe. Wenn mein Kumpel uns aber verpfeift und ich nicht, so muss ich für 20 Jahre ins Gefängnis, es sei denn, ich gestehe auch, dann sind es nur 15. Also wäre es auch in diesem Fall besser, zu gestehen. In beiden Fällen wäre es also die rationale Entscheidung jedes Einzelnen, das Verbrechen zuzugeben. Am Ende werden also beide gegen den anderen Aussagen, womit insgesamt 30 Gefängnisjahre (15 für jeden) fällig werden.

Die optimale Lösung aus der Gesamtsicht (zumindest aus der Gesamtsicht eines Verbrecherkonsortiums) wäre es natürlich, wenn beide schweigen, da dann insgesamt nur 10 Jahre Gefängnis drohen. (Gesteht einer, so sind 20 Gefängnisjahre abzugelten, was auch schlechter ist.) Allerdings ist rein aus der Spieltheoretischen Sicht das Ergebnis „beide halten dicht“ nicht erreichbar, da es für den Einzelnen IMMER besser wäre, den anderen zu verraten.

Verallgemeinert man diese Geschichte, so sprechen wir davon, dass die beiden Verbrecher die „Spieler“ in diesem Spiel sind, wenn der Eine gegen den Anderes aussagt, so defektiert er. (Das ist das Gegenteil von Kooperation. Natürlich kooperiert der Verbrecher mit der Staatsanwaltschaft, aber hier geht es um die Kooperation der Spieler untereinander.)

Zusammengefasst: In einer Situation wie in einem Gefangenendilemma ist es für die Spieler immer rational zu defektieren. Das ist das sogenannte „Nash-Gleichgewicht“, das heißt, kein Spieler kann durch einseitige Abweichung seines Verhaltens (also Kooperation) sein Ergebnis verbessern. Im Gefangenendilemma ist das Nash-Gleichgewicht allerdings keine Pareto-optimale Lösung. Pareto-optimal wäre die Lösung dann, wenn aus Gesamtsicht das Ergebnis nicht verbessert werden könnte. Im Gefangenendilemma ist das grundlegende Problem, dass die Pareto-optimale Lösung eben kein Nash-Gleichgewicht ist und somit nicht erreicht werden kann.

Tiefer möchte ich auf das Gefangenendilemma an dieser Stelle gar nicht eingehen, es gibt außerdem Seiten, die das Thema umfänglicher und besser darstellen. (Zum Beispiel hier oder hier.) Insbesondere wird es interessant, wenn man das Modell auf mehr als 2 Spieler (n-Personen) ausdehnt oder sogar wiederholt (das iterierte Gefangenendilemma).

Allerdings möchte ich an dieser Stelle schon eine Feststellung in den Raum werfen, meiner Meinung nach das Grundproblem aller Zielsysteme:

Jedes hinreichend komplexe Zielsystem eines Unternehmens stellt ein n-Personen-Gefangenendilemma dar, wodurch die Kooperation der Bereiche effektiv verhindert wird.

Planeinhaltung

Daemonic Coder

In einem anderen Artikel hatte ich ja bereits darauf hingewiesen, dasses wichtig ist, einen Plan von einer Prognose zu unterscheiden. Wichtig ist dies insbesondere auch, weil er offensichtlich macht, wie unsinnig es in solchen Situationen ist, eine Planeinhaltung sicherstellen zu wollen.

Bleiben wir beim einfachen Beispiel aus dem genannten Artikel: Ich prognostiziere, dass es Im Dezember in Deutschland schneit. Ich plane daher, einen Mantel anzuziehen. Nun passiert irgendwas und ich ziehe den Mantel nicht an. Beispielsweise ist es doch viel zu warm oder ich befinde mich entgegen meiner ursprünglichen Prognose gar nicht im kalten Deutschland, sondern in Australien. Es wäre ziemlich widersinnig, die Planeinhaltung zu überprüfen, sinnvoll wäre es aber eventuell zu untersuchen, warum die Prognose nicht stimmte – zumindest bevor uns der Klimawandel in erster Linie deswegen zu Schaffen macht, weil wir uns in dicke Mäntel einwickeln.

Eine Planabweichung zu betrachten ist oft Unsinn. Statt dessen sollte eine Abweichung der zu Grunde liegenden Prognose betrachtet werden.