Was macht eigentlich ein Chef?

Ich weiß schon, warum ich Entwickler geworden bin. Im Studium hatte ich eine Vorlesung zu „Unternehmensführung“. Strategie, Organisation, Controlling, Personalwirtschaft, internationales Management… alles das hat man mir beigebracht. In der Klausur hab ich sogar ne ganz gute Note gekriegt, wenn ich mich richtig erinnere. Aber wäre ich dadurch ein guter Chef? Ich weiß schon, warum ich Entwickler geworden bin — und warum ich wahrscheinlich niemals ins Management wechseln werde.

Eins ist natürlich klar: Management kann manchmal echt verwirrend sein und zu Missverständnissen führen. Aber was macht eigentlich ein Chef? Fragt man in der Fußgängerzone, wird man vermutlich sowas hören wie „entscheiden und delegieren“. Ein Chef entscheidet, was gemacht wird und weist dann seine Untergebenen an, die dafür notwendige Arbeit zu tun. Dieses Führungsmodell stammt aus dem Militär und der Industrie — und es funktioniert in der Softwareentwicklung nicht. In „Leadership in der IT“ zeigt Johann-Peter Hartmann anschaulich wie sich Führungsstile über die Zeit entwickelt haben und warum man Produktionsstätten nicht mit Softwareentwicklung vergleichen kann. In Handwerksbetrieben ist die Aufgabe des Meisters gegenüber seinen Gesellen und Lehrlingen das Anleiten und nach Außen hin vertreten. In der Industrie ist es, wie gesagt, das Entscheiden und Delegieren. Mittlerweile schon weit verbreitet ist die Auffassung, Chefs sollten Ziele definieren und Feedback geben. Moderner wäre zu sagen, sie motivieren und etablieren Wertesysteme.

Ich behaupte jetzt aber mal folgendes: Ein Chef hat genau zwei Aufgaben: gärtnern und vorgaukeln. Aber ich glaub, das muss ich erklären…

Gärtnern

Menschen haben unterschiedliche Einstellungen. Das ist kein Geheimnis. Mir geht es hier um einen speziellen Aspekt dessen: Man kann eine statische Denkweise (Fixed Mindset) oder eine dynamische Denkweise (Growth Mindset) haben. Und das hat ganz lustige Auswirkungen. Das folgende Video zeigt den Unterschied ganz anschaulich:

Fixed Mindset heißt: Ich betrachte Intelligenz, Talent, Geschick — quasi jede Art von Fähigkeit — als gegeben. Jemand kann intelligent sein oder nicht, jemand kann talentiert sein oder nicht, jemand kann geschickt sein oder ungeschickt. Auswirkungen:

  • Ich werde danach streben, meine Fähigkeiten zu zeigen. Wenn andere sehen, dass ich etwas kann, merken sie, dass ich intelligent/talentiert/geschickt bin.
  • Ich werde alles vermeiden, was mich schlecht aussehen lässt. Wenn ich einen Fehler mache und andere bemerken das, meinen sie, ich sei dumm/unfähig/ungeschickt.
  • Wenn ich an etwas scheitere, ist das nicht schön. Scheitern nervt.
  • Ich werde denen, die ich für dumm/untalentiert/ungeschickt halte, keine Chance geben. Ist ja auch logisch: Sie können das halt nicht besser.

Growth Mindset heißt: Ich bin davon überzeugt, dass sich Fähigkeiten ausbauen lassen. Auswirkungen:

  • Das was ich nicht kann, kann ich noch nicht. Ich werde üben und scheitern und irgendwann werde ich es können.
  • Ich werde das tun, was mir die Möglichkeit gibt, meine Fähigkeiten auszubauen. Ich will an meinen Aufgaben wachsen.
  • Wenn ich an etwas scheitere, ist das normal. Scheitern mag zwar etwas weniger angenehm sein als alles zu können, aber so ist das nunmal. Es ist noch kein Meister vom Himmel gefallen.
  • Denen, die etwas nicht können, werde ich trotzdem eine Chance geben und bald schon werden sie viel intelligenter/talentierter/geschickter sein.

Beides sind selbsterfüllende Prophezeiungen. Wenn ich der Meinung bin, etwas nicht zu können, werde ich nichts dagegen tun und ich werde es auch weiterhin nicht können. Wenn ich der Meinung bin, dass jemand anderes etwas nicht kann, werde ich demjenigen auch keine Chance dazu geben und so wird sich auch das nicht ändern. Wenn ich aber davon überzeugt bin, dass ich etwas einfach noch nicht kann, werde ich daran arbeiten und irgendwann werde ich es können. Und wenn ich anderen eine Chance gebe und sie unterstütze, werden diese sich ebenfalls verbessern und meine Einschätzung, dass sie das können, wird sich bestätigen. Und sowas ist nicht nur Theorie.

Es ist also gut, eine dynamische Denkweise, ein Growth Mindset zu entwickeln. Und da liegt die eine Aufgabe eines Chefs: Im Gärtnern. So, wie man für Pflanzen Möglichkeiten schafft, zu wachsen, schafft ein guter Chef Möglichkeiten für Mitarbeiter zu wachsen. Und das ganze gilt auf mehreren Ebenen: Einzelne Mitarbeiter sollen wachsen, Teams sollen wachsen, das Unternehmen soll wachsen. Man kann etwas für sich lernen, man kann etwas fürs Team lernen und man kann aus Projekten lernen — auch teamübergreifend. Je nachdem, welche Leute man hat, ist das irgendwas zwischen einem Selbstläufer und enorm schwierig. Typischerweise ist es recht leicht, einzelne Leute zum Lernen zu bringen. Das tun sie entweder automatisch oder man schubst sie in diese Richtung. Es gibt ggf. Leute, die sich wehren, aber das ist eine andere Baustelle. Je größer die Strukturen sind, die lernen sollen, desto schwieriger wird das. Auch gut organisierte Teams können sich recht gut selbst verbessern (regelmäßige Retrospektiven, etc.). Aus Projekten zu lernen, ist schon deutlich schwerer und wenn es daran geht, dass Team-, Abteilungs- und Standortübergreifend sich etwas verbessern soll, hat man in aller Regel wohl echt was zu tun.

Vorgaukeln

In den allermeisten Fällen ist Software in Schichten aufgebaut. Und das hat einen guten Grund: Die Komplexität wird dadurch erheblich reduziert, man kann schneller entwickeln und macht weniger Fehler. Ein Betriebssystem gaukelt einem vor, dass es so etwas wie Dateien gibt und Sockets und Fenster und Buttons. Aber das ist nicht wahr. Es gibt nur Bits auf der Platte, nur Potenzialschwankungen, die sich in einem Kabel ausbreiten, und nur Pixel auf dem Monitor. Die JVM gaukelt einem vor, dass alle Rechner gleich sind, dass es Strings gibt und Streams und Closures. TCP gaukelt uns vor, man könnte Daten verlässlich übertragen, Datenbanken, man könnte sie verlässlich speichern. In einer Software mag es eine Datenbankabstraktionsschicht geben, die vorgaukelt, alle Datenbanken seien gleich und eine Business-Schicht gaukelt vor, man könnte einen Computer anweisen, fachliche Aufgaben zu bearbeiten. Alles das ist gelogen. Und diese Lügen sind wichtig, denn ohne sie, wäre alles hoffnungslos chaotisch und undurchschaubar.

Ganz ähnliches gilt auch für ein Unternehmen. Entwickler funktionieren am besten, wenn man ihnen vorgaukelt, alles, was nötig ist, um ein Unternehmen am Laufen zu halten, alles, was nötig ist, um ein Produkt für einen Kunden zur Verfügung zu stellen, ist Anforderungen in Code zu überführen. Das ist eine Lüge. Aber eine wichtige Lüge, denn ohne sie wäre die Arbeitswelt hoffnungslos chaotisch und kein Entwickler käme noch dazu, seine Arbeit zu machen. Joel Spolsky nennt das den Development Abstraction Layer. Der Artikel ist im Übrigen ausgesprochen lesenswert und kurzweilig geschrieben; alle, die mein Geschreibsel bis hierher ertragen haben, sollten gleich als nächstes dort weiter lesen. Einen besonders schönen Abschnitt will ich daraus auch gleich mal zitieren:

That’s why you have management.

It’s for the kind of stuff that no company can avoid, but if you have your programmers worrying about it, well, management has failed, the same way as a 100 foot yacht has failed if the millionaire owner has to go down into the engine room and, um, build the engine.

Jede Abstraktionsschicht definiert eine gewisse Menge von Operationen, von Diensten: eine API. Auch der Development Abstraction Layer hat solche Dienste und die Aufgabe des Managements ist es, diese Abstraktion aufrecht zu erhalten. Die Illusion ist perfekt, wenn man die Versorgung mit gewissen Diensten für absolut selbstverständlich hält. Strom kommt aus der Steckdose. Das ist normal und wir halten es für selbstverständlich. Wir sorgen uns in aller Regel nicht darum, dass Strom da ist. Das ist einfach so. Es ist Teil des Development Abstraction Layers. Ebenso wie Wasser in der Toilette, Heiß- und Kaltgetränke in der Küche, Telefon, Mail- und Messaging-Dienste, Internet, Computer mit ausreichend Plattenplatz und Rechenkraft, Zugang zu Versionsverwaltung, Datenbanken und CI-Server… Im perfekten Idealfall ist das alles einfach da. Man muss sich nicht um Zugänge kümmern und vor allem nicht darauf warten. Ein perfektes Management würde dafür sorgen, dass das alles auf die selbe Art da ist, wie Luft zum Atmen. Und wenn man eine Frage hat, Informationen fehlen oder etwas geklärt werden muss, weiß der Chef Rat oder vermittelt jemanden, der Rat weiß. Auch das ist ein Dienst des Development Abstraction Layers. Es existiert ein Orakel, das Fragen beantwortet.

Nun ist es wohl leider utopisch anzunehmen, dass wirklich alles so selbstverständlich da ist wie Strom und Luft. Manchmal hakt es an der ein- oder anderen Stelle, manchmal muss man auf Zugänge warten, SLAs werden nicht eingehalten oder sind noch gar nicht definiert. Manchmal klappt die Zusammenarbeit mit einem anderen Team nicht gut und manchmal sind Anforderungen unklar oder Informationen fehlen. Das passiert und das ist nicht schön. Die Abstraktion wird löchrig. Je schneller der Idealzustand, in dem alles funktioniert, wiederhergestellt ist, desto besser ist das Management. Denn je länger das fehlt, je mehr wir Entwickler uns selbst um das Ganze kümmern müssen, desto weniger können wir uns um das kümmern, was wir eigentlich gut können: Software entwickeln. Und es ist eine echt gute Sache, sich darauf konzentrieren zu können.

Und ich

Je nachdem, wie man es betrachtet, hab ich einen Chef oder zwei bzw. momentan nur einen oder faktisch keinen und bald doch wieder einen. Bisher kenne ich schlechte Chefs nur aus den Dibert-Comics. Zum Glück. Aber ich weiß, wie es ist, wenn der Development Abstraction Layer bröckelt, weil der Chef grad viel um die Ohren hat. In gut funktionierenden Teams, wie dem, in dem ich arbeite, kommt man zur Not auch so zurecht. Aber jemanden zu haben, der das ganze organisatorische, firmenpolitische Blah erledigt, eine hübsche Abstraktionsschicht für einen aufbaut und dafür sorgt, dass man sich aufs Entwickeln konzentrieren kann — das hat was.

Ich weiß schon, warum ich Entwickler geworden bin. Ich kann das nicht, was ein Chef können muss. Vorgaukeln und Gärtnern. Also den Laden am Laufen halten und dafür sorgen, dass er morgen besser läuft als heute. Natürlich könnte ich das alles lernen und doch noch ins Management wechseln. Schließlich habe ich ein Growth Mindset. Also müsste ich eigentlich sagen: Ich kann es „noch“ nicht. Ich könnte es lernen, aber nicht alles, was ich können kann, muss ich auch können wollen. Ich habe mich entschieden, Entwickler zu sein und darin immer besser zu werden. Management überlasse ich lieber anderen — denen, die sich dafür entschieden haben, das Gärtnern und Vorgaukeln zu lernen. Ich weiß schon, warum ich Entwickler geworden bin.

3 Kommentare


  1. Also Unternehmertum ist weit umfangreicher als Du hier glaubst und wesentlich pragmatischer. Ab und an benötigst Du eine Kalaschnikow.
    Wenne die ein, zwei Mal rausgeholt hast, wird die Notwendigkeit weniger.

    Wichtig ist halt auch, dass Du den Umgang damit beherrscht und die anderen das wissen.


  2. Damals in der Schule hatte ich einen Physiklehrer, der mitunter recht laut werden konnte. Seine Bemühungen sich Respekt zu verschaffen waren jedoch nicht sonderlich erfolgreich. Im Gegenteil: Im Nachhinein denke ich, seine Reaktion war ein Zeichen von Überforderung und Hilflosigkeit.

    Und ich hatte eine Erdkundelehrerin. Sie ist absolut niemals laut geworden, aber kaum hat sie den Klassenraum betreten, waren alle mucksmäuschenstill.

    Ich hatte mit beiden keine sonderlichen Probleme. Trotzdem: Das waren nicht unbedingt meine Lieblingslehrer und wenn man sie daran messen wollte, wie groß der Lernerfolg bei den Schülern war, so behaupte ich, waren andere erfolgreicher. Die erfolgreichsten Lehrer waren die, die man respektiert hat, nicht weil sie geschimpft hätten oder besonders streng waren, sondern weil sie den Schülern gleichermaßen Respekt zollten und es so schafften, dass man gerne ihren Unterricht besuchte.


  3. Okay, Du schreibst hier von Personalführung. Das ist aber nur eine Teilaufgabe eine UnternehmensBoss.
    Als Unternehmensführer hast Du eigentlich nur eine Grundbedingung zu erfüllen :
    Einnahme >= Ausgabe

    Dazu benötigt man eben auch mal Gewalt.
    In Rechtsstaaten nutzt man dann üblich die Staatsgewalt.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.