Als Berater und Trainer für Softwareprojekte stelle ich mir immer wieder die Frage, wann eine Organisation eigentlich Hilfe benötigt? Wann sollte sie sich verändern? Mit meiner Hilfe oder auch einfach durch Eigenleistung.
Ich komme gern in jedes Projekt und gebe einen Impuls oder begleite eine Veränderung des Produktionsprozesses oder der Architektur. Das macht mir Spaß, damit verdiene ich mein Geld. Befriedigend ist es allerdings nur, wenn meine Hilfe auch wirklich nötig ist. Wann ist das der Fall, wie kann man das feststellen?
Eine Analogie kommt mir in den Sinn: Wann ist es nötig, einem Menschen in Gesundheitsdingen zu helfen? Klar, natürlich nur, wenn der das will. Aber auch dann stellt sich ja die Frage, wie krank jemand ist.
Beispiel “dicker Mann”: Ist der Mann auf dem Bild rechts gesund? Er scheint sich ja seines Lebens zu freuen, wenn er so für das Foto posiert.
Ich traue mich nicht zu beurteilen, ob er gesund ist. Er mag nach meinem Ideal nicht gesund aussehen. Aber wer bin ich, dass ich meinen Maßstab als universell gültig ansehen könnte? Reicht es denn nicht, dass er sich wohlfühlt?
Doch, ich glaube, das reicht. Wer sich wohlfühlt, der ist gesund.
Mit einer Einschränkung: Das Wohlgefühl sollte nicht nur in einer Situation abgefragt werden, sondern unter Veränderungen. Denn Leben ist nicht statisch, sondern dynamisch. Irgendwas passiert ja immer. Wir müssen uns immer wieder unterschiedlichen Herausforderungen stellen.
Der Mann auf dem Bild wird aufstehen und aus dem Haus gehen wollen. Schafft er das? Er wird mit unterschiedlicher Witterung fertig werden müssen. Schafft er das? Er wird plötzlich einem Auto ausweichen müssen, das er bei der Straßenquerung übersehen hat. Schafft er das? Er wird sich einen Platz in einem Flugzeug oder Zug suchen müssen. Schafft er das? Oder er wird, wie der Mann in dieser Geschichte durch ein Drehkreuz gehen müssen. Schafft er das?
Wie schon in einem anderen Blogartikel beschrieben, halte ich die Fähigkeit, Veränderungen kompensieren zu können, für eine zentrale Anforderung an Gesundheit. Wer sich gesund nennen will, muss anpassungsfähig sein.
Solche Anpassungsfähigkeit hat aus meiner Sicht zwei Seiten: eine subjektive und eine objektive. Es gibt einige objektive Anforderungen, die alle Menschen erfüllen können müssen, wenn sie als Gesund gelten wollen. Dazu zähle ich mal die Fähigkeit, auf eine unerwartete Ansprache von hinten nicht mit einem Herzschlag zu reagieren oder bei einer Temperatursteigerung von 20° auf 30° Celsius nicht an einem Hitzschlag zu sterben.
Jenseits relativ enger objektiver Grenzen ist das Feld subjektiver, ganz persönlich als notwendig angesehener Kompensationsfähigkeit weit. Ich persönlich fühle mich nur gesund, wenn ich zu meiner Wohnung im 4. Stock über die Treppe zügig hochgehen kann. Neulich haben jedoch zwei Frauen einige Regale bei mir abgeholt, die ich per ebay Kleinanzeigen verschenkt hatte, die mit dem 4. Stock nicht wirklich zurecht kamen. Sie waren Anfang 30, sehr korpulent und haben mich mehrfach gefragt, wie ich das denn aushalten würde, so hoch droben ohne Fahrstuhl zu leben.
Aber wie gesagt, selbst wenn ich diese Frauen für nicht gesund halten mag… Sie selbst fühlen sich bestimmt nicht so. Jedenfalls nicht in dem Maße, wie ich sie einschätze.
Und ich fühle mich nicht ungesund, wenn ich mich heute nicht in der Lage sehe, aus dem Stand einen Marathon zu laufen. Ein passionierter Triathlet kann das jedoch anders sehen.
Wie viel Kompensationsfähigkeit ist also nötig? Im Wesentlichen nur so viel wie man meint zu brauchen. Der Mann oben im Bild hält sich vielleicht für gesund, weil er Drehkreuze und Flugzeuge vermeidet und zuhause bleibt, um keinen Autos ausweichen zu müssen. Er hat dann sein Leben so eingerichtet, dass Veränderungen/Anforderugen, die Sie und ich kompensieren könnten, an ihn gar nicht erst herangetragen werden.
Das halte ich für völlig legitim. Jeder ist da seiner Gesundheit Schmied.
Jetzt von der Analogie zurück zur Softwareproduktion.
Organisationen sind für mich auch Organismen, die gesund oder krank sein können. Deshalb reicht auch dort nicht die Frage, ob sich eine Organisation gerade wohl fühle, um den Gesundheitszustand zu beurteilen. Vielmehr ist zu fragen, inwiefern sie sich fähig sieht, Veränderungen zu kompensieren.
Die Antwort auf diese Frage hängt natürlich davon ab, welche potenziellen Veränderungen eine Organisation überhaupt sieht. Wo können denn Herausforderungen lauern? Was ist das Äquivalent einer unerwarteten Ansprache von hinten oder einem Bus hinterherlaufen zu müssen?
Ich glaube, Organisationen im Allgemeinen und Softwarehersteller im Besonderen haben davon eine nur recht schwammige Vorstellung. Man baut nicht gezielt Kompensationsfähigkeiten auf, sondern mokelt einfach vor sich hin. Hauptsache man verdient genug Geld. Damit lässt sich doch im Grunde alles kompensieren, oder?
Da bin ich anderer Meinung. Aber das möchte ich hier gar nicht vertiefen. Ich will vielmehr überlegen, wo denn die Veränderungsherausforderungen lauern könnten. Vor Augen habe ich dabei ein Softwareunternehmen, das vielleicht 20 Jahre am Markt ist. Das sagt, es gehe ihm gut. Und als Beleg wird nicht nur der aktuelle Umsatz angeführt, sondern auch das Unternehmensalter. Ist das denn nicht Beweis genug für Gesundheit?
Ich erlaube mir, anderer Meinung zu sein. Nur weil jemand vielleicht 80 Jahre alt ist und sich gerade gut fühlt, heißt das noch nicht, dass er gesund ist. Der einzige Nachweis für Gesundheit liegt in der Zukunft durch Meisterung deren Herausforderungen.
Insofern glaube ich, dass mache, einige, wahrscheinlich sogar viele Unternehmen etwas zu selbstsicher sind, was ihre Gesundheit angeht.
Was hätte Lehman Brothers wohl im Jahr 2007 zur eigenen Gesundheit gesagt? Der Aktienkurs – als ein akzeptierter Gesundheitsindikator – sah doch stabil aus.
Leider war man dann doch aber weniger kompensationsfähig, als man dachte, würde ich sagen. Man rekelte sich wie der Mann oben auf dem Bett – und konnte nicht auf das Feuer reagieren, das ausbrach – obwohl es auch noch mitverschuldet war.
Eine Organisation, die schon 20 Jahre lebt, hat natürlich einige Erfahrung gesammelt. Sie hat selbstverständlich Kompensationsfähigkeit bewiesen. Doch ich glaube, dass wir diese Fähigkeit zunehmend unterschätzen. Wir haben immer noch ein veraltetes Bild im Kopf, nämlich das einer relativ statischen Welt. Denn in der ist vergangener Erfolg Garant für zukünftigen Erfolg.
Es gibt zwei Wege, sich gesund zu definieren: Man baut Kompensationsfähigkeit aus – oder man korrigiert seine Ansprüche nach unten. Mir scheint letzteres in weiten Bereichen synonym mit Altern zu sein. Wer älter wird, meint, sich bestimmten Herausforderungen nicht mehr stellen zu müssen.
Das ist natürlich legitim.
Aber es funktioniert nur, wo man unter Kontrolle hat, welche Veränderungen man kompensieren muss.
Da scheint es mir gerade für Softwareunternehmen jedoch Grenzen zu geben. Man unterschätzt bei aller Erfahrung des Unternehmensalters, dass es zu Veränderungen kommen kann, ob man will oder nicht. Und man unterschätzt, wie groß die sein können. Manche hat man überhaupt nicht auf dem Schirm und wähnt sich in einer statischen Welt.
- Produktmarkt: Veränderungen in den Anforderungen an die Produkte lassen sich nicht kontrollieren. Kunden wollen immer mehr. Was sie wollen, ist letztlich nicht vorherzusehen. Wie schnell, mir wie viel Aufwand kann eine Organisation auf neue Anforderungen vom Markt reagieren? Nur weil man bisher ja auch irgendwie reagiert hat, heißt das nicht, dass man auch in Zukunft ökonomisch reagieren kann. Was wird also getan, um Kompensationsfähigkeit zu erhalten oder gar auszubauen?
- Technologien: Technologien ändern sich. Darauf muss reagiert werden können. Früher oder später. Wie einfach ist das möglich? Neue Technologien können Aufwände senken oder Märkte erhalten/erschließen. Was wird getan, um hier Kompensationsfähigkeit zu erhalten oder gar auszubauen?
- Personalmarkt: Weil sich Technologien entwickeln, entwickelt sich auch der Personalmarkt. Wie ist ein Unternehmen darauf vorbereitet, dass morgen die Fachkräfte die man heute braucht, nicht mehr zu finden sein werden? Was wird getan, um hier Kompensationsfähigkeit zu erhalten oder gar auszubauen?
- Codemenge: Völlig unterschätzt wird das Wachstum der Codemenge, gerade weil man Erfolg hat. Diese zwangsläufige Veränderung braucht Kompensationsfähigkeit ganz eigener Art. Wer heute mit 50.000 LOC umgehen kann, kann nicht unbedingt mit 500.000 LOC in gleicher weise ökonomisch umgehen. Was wird getan, um hier Kompensationsfähigkeit zu erhalten oder gar auszubauen?
Wer meint, in diesen und anderen Unternehmensgesundheitsdimensionen heute ausreichend oder gar mit Puffer kompensationsfähig zu sein, den beglückwünsche ich. Das ist wunderbar.
Doch auch dann bleibt noch eine Frage offen: Wie sieht es denn in der Zukunft aus? Ich halte es für sehr wichtig, Kompensationsfähigkeiten zu beobachten. Ich persönlich kann das z.B. täglich beim Treppensteigen. Wenn ich merke, dass ich kurzatmig werde, dann ist meine Kompensationsfähigkeit gesunken. Dann sollte ich gegensteuern – auf die eine oder andere Weise. Ich kann ins Erdgeschoss ziehen oder mit Fitnesstraining beginnen. Je nach Anspruch. Welcher meiner ist, können Sie sich denken ;-)
Aber weiß auch eine Organisation, wie sich ihre Kompensationsfähigkeit entwickelt? Kann sie überhaupt gegensteuern, wenn die Tendenz nach unten zeigt?
Davon hängt letztlich ab, ob ich zum Einsatz komme. Denn meine Aufgabe ist es, Kompensationsfähigkeit herzustellen bzw. aufzubauen. In Zukunft werde ich darauf noch mehr achten und schauen, in welchen Bereichen es einen Mangel an Kompensationsfähigkeit gibt – und inwiefern darüber Bewusstsein besteht. Denn wenn ich entgegen den gesundheitlichen Grundvorstellungen eines Unternehmens anfange, Kompensationsfähigkeit aufzubauen, wird es früher oder später zum Konflikt kommen – oder meine Bemühungen verpuffen. Das macht dann keiner Seite Spaß.
Ich hatte das Buch echt vergessen, das ich 1985 geschrieben hatte. Jetzt ist es mir beim Ausmisten meiner Regale in die Hand gefallen. 220 Manuskriptseiten ausgedruckt auf einem Nadeldrucker. Wahnsinn!
So hatte ich begonnen – zunächst mit meinem Schulfreund Helge Baumann –, eine Anleitung zum Programmieren für Pascal zu schreiben. Die trockenen, eher akademischen Bücher, die ansonsten verfügbar waren, schienen ungeeignet für den Schulgebrauch. Wenn ich mich recht erinnere, hatten wir im Unterricht auch kein Lehrbuch.
Die Beispielprogramme sollten durchaus ganze Anwendungen sein, nicht nur Algorithmen. Und auch der Entwurf und die Lesbarkeit von Software waren wichtig. Deshalb gibt es viele Struktogramme. Niedlich, oder? Aber das war damals state-of-the-art.
Spannend finde ich, dass mir das Manuskript wirklich entfallen ist. Anfang der 2000er, als ich einige Bücher zu .NET und Datenbankprogrammierung geschrieben habe, war mir, als hätte ich noch nie so lange Texte entwickelt.
Und andererseits… Wahnsinn, wieviel dann doch bei der Programmierung gleich geblieben ist. Die Syntax hat sich verändert - Java, C#, JS statt Pascal –, auch das Programmierparadigma ist anders – objektorientiert statt prozedural – dennoch stehen Menschen, die ins Programmieren einsteigen wollen, vor denselben Problemen. Mit einer Programmiersprache statt mit Hammer oder Pinsel umzugehen, ist eine ganz eigene Herausforderung.