Alles war programmiert, alle Funktionen waren umgesetzt, das Demo-Meeting konnte kommen. Und dann saßen sich zwei Seiten gegenüber, die einander kaum verstanden: das Entwicklungsteam auf der einen, der Kunde auf der anderen. Es ging gar nicht um Fehler. Es ging um eine Kleinigkeit, die noch angepasst werden sollte.
Beide Seiten meinten es gut. Trotzdem wurde die Stimmung dünn, und am Ende saßen dort ein paar beleidigte Leberwürste. Meine Aufgabe war an diesem Tag nicht Technik. Meine Aufgabe war, zu übersetzen, bis beide Seiten wieder zusammenfanden.
In meinen Jahren in der IT habe ich wenige Projekte gesehen, die an der Technik gescheitert sind. Gescheitert sind sie an unausgesprochenen Erwartungen, an Rollen, die niemand geklärt hat, und an Konflikten, die alle bemerkt und niemand angesprochen hat.
Technik lässt sich planen. Zusammenarbeit muss man führen. Das ist die eigentliche Aufgabe, wenn Sie ein IT-Team leiten, und sie steht in keiner Sprintplanung.
Warum Führung in der IT besonders ist
Vier Dinge treffen hier zusammen, die es anderswo so nicht gibt:
- Fachliche Tiefe schlägt Hierarchie. Die Person mit dem meisten Wissen hat oft mehr Einfluss als die mit der Rolle. Das ist gut, solange es ausgesprochen ist.
- Mehrere Fachsprachen in einem Raum. Entwicklung, Betrieb, Fachbereich und Einkauf meinen mit denselben Wörtern Verschiedenes.
- Hoher Druck bei hoher Spezialisierung. Wenn nur eine Person ein System versteht, ist jeder Urlaub ein Risiko und jede Reibung teuer.
- Der Markt ist offen. Wer sich nicht wohlfühlt, hat morgen ein anderes Angebot. Bindung entsteht über Führung, nicht über Obstkörbe.
Wenn die beste Fachkraft Führungskraft wird
Der häufigste Weg in die IT-Führung führt über die fachliche Leistung. Wer am meisten kann, bekommt das Team. Nur ist das eine andere Tätigkeit, nicht dieselbe mit mehr Verantwortung.
Ich habe diesen Wechsel selbst gemacht. Vorher habe ich viel allein an Projekten gearbeitet, danach gemeinsam mit einem Team an einer Sache. Das war eine schöne Erfahrung, und überrascht hat mich vor allem eines: wie viel Rückhalt ich von den Kolleg:innen bekommen habe, gerade als Führungskraft.
Schwer war etwas anderes. Nicht mehr selbst zu programmieren. Ich habe mich bemüht, mich nicht einzumischen, und trotzdem habe ich manche Dinge für mich ausprobiert und dem Team nichts davon gesagt. Rückblickend war das der eigentliche Teil des Rollenwechsels: aushalten, dass andere es anders lösen als ich.
Woran man den offenen Rollenwechsel erkennt: Die Führungskraft schreibt weiter Code und schiebt die Gespräche auf. Entscheidungen werden im Vorbeigehen getroffen. Das Team fragt zu allem nach, weil unklar ist, wer was entscheiden darf. Hier hilft kein weiteres Fachwissen, sondern eine klare Rollenklärung: Wofür stehe ich ab jetzt gerade, und wofür nicht mehr?
Vier Hebel für die Teamdynamik
1. Sicherheit vor Geschwindigkeit
Teams werden schnell, wenn Fehler besprochen werden können. Das entsteht nicht durch eine Ansage, sondern dadurch, wie Sie auf die erste schlechte Nachricht reagieren. Diese Reaktion entscheidet, ob Sie die nächste noch rechtzeitig erfahren.
2. Konflikte früh und konkret
Spannungen in IT-Teams entstehen selten aus Bosheit, meist aus unterschiedlichen Arbeitsweisen: gründlich gegen schnell, Zuständigkeit gegen Zuruf. Sprechen Sie das Verhalten an, nicht die Person, und zwar zeitnah. Die Regeln dafür stehen in Feedback – eine Hilfe.
3. Feedback als Routine, nicht als Jahresgespräch
Ein kurzes Gespräch alle zwei Wochen bringt mehr als ein Formular im Dezember. Fragen Sie auch nach oben: Was brauchen Sie von mir, damit Ihre Arbeit leichter wird? Die Antworten sind unbequem und nützlich.
4. Agilität mit Maß
Agile Methoden sind Werkzeuge, kein Selbstzweck. Ein Daily, das zum Statusbericht an die Führungskraft wird, kostet nur Zeit. Eine Retrospektive ohne Folgen kostet Glaubwürdigkeit. Prüfen Sie jedes Format einmal im Quartal: Wozu machen wir das, und was wäre, wenn wir es weglassen?
Aus meiner eigenen Zeit als Product Owner habe ich eine Lektion mitgenommen, die ich in Aufmachen aufgeschrieben habe: Fixzusagen in einem Vorhaben, dessen Weg man noch nicht kennt, schaffen keine Sicherheit. Sie verschieben nur den Zeitpunkt, an dem es unangenehm wird.
Übersetzen: die unterschätzte Führungsaufgabe
Zwischen Technik und Geschäft stehen selten Sachfragen, sondern Übersetzungsfragen. „Technische Schulden“ ist im Vorstand kein Argument, „drei Ausfälle im Quartal und zwei Wochen Mehraufwand pro Release“ schon.
Genau hier entscheidet sich, ob ein IT-Team gehört wird. Wer beide Sprachen spricht, verschafft dem Team Spielraum, ohne die Fachlichkeit zu verraten. Das ist die Brücke zwischen Mensch und Technik, und sie wird gebaut, nicht gefunden.
Vier Fragen für Ihr nächstes Teammeeting
- Wer entscheidet was, und wissen das alle im Team?
- Welches Wissen hängt an einer einzigen Person?
- Welcher Konflikt ist allen bekannt und wurde noch nie ausgesprochen?
- Welches unserer Formate würde niemand vermissen?
Ein Muster sehe ich im Coaching immer wieder: Führungskräfte kommen mit einem Anliegen, zu dem sie ihre Haltung erst finden müssen. Sie probieren dann etwas aus, meist an der Art, wie sie mit Menschen sprechen. Sie gehen zu, sie hören zu, sie fragen nach, statt gleich zu antworten. Wer als Führungskraft ein Stück in Richtung Zuhören geht, bekommt erstaunliche Dinge erzählt. Und im Team verändert sich etwas, das man schwer messen und leicht spüren kann: Wertschätzung. Was aktives Zuhören dafür braucht, habe ich an anderer Stelle beschrieben.
Wie ich Sie unterstütze
Ich arbeite mit IT-Führungskräften genau an dieser Schnittstelle: Rollen klären, Konflikte bearbeiten, Feedback etablieren, agile Formate auf ihren Zweck zurückführen. Je nach Situation im Einzelcoaching, im Sparring oder mit dem ganzen Team.
Was das konkret heißt, steht auf der Seite Führung und Teamdynamik in der IT. Wenn Sie lieber zuerst reden: In einem kostenfreien Erstgespräch von 30 Minuten klären wir, woran es bei Ihnen gerade hängt. Termin wählen oder anrufen: +43 699 19253551.