Remote Leadership heißt, Vertrauen und Sichtbarkeit aufzubauen, wenn das gemeinsame Büro als Treffpunkt fehlt. Ohne den informellen Kontakt auf dem Flur wird die Teamleitung zur Brücke zwischen Team und Management und berichtet dort aktiv über Erfolge und Fehlschläge. Transparenz, feste Einzelgespräche und schriftliche Updates ersetzen den Flurfunk und halten verteilte Teams zusammen.
Das Wichtigste in Kürze
- Hybride Arbeit ist Remote-Arbeit: Sobald Teammitglieder an unterschiedlichen Tagen ins Büro kommen, gelten dieselben Führungspraktiken wie im reinen Remote-Team.
- Die wichtigste Aufgabe einer Teamleitung im Remote-Setting ist es, die Arbeit des Teams beim Management sichtbar zu machen, weil das zufällige Gespräch in der Kaffeeküche diese Information nicht mehr nach oben trägt.
- Wer Fehlschläge offen und ohne Schuldzuweisung meldet, erreicht mehr als mit reinen Erfolgsberichten: Das Management kann Ressourcen anbieten und festgefahrene Initiativen wieder in Gang bringen.
- Technische Leute sind dem Management bei der Bewertung von KI-Tools einen entscheidenden Schritt voraus, weil sie eine echte Fähigkeit von einer teuer bezahlten Hülle um eine öffentliche Modell-API unterscheiden können.
- Wer Teammitglieder ermutigt, mit KI zu experimentieren, macht sie zu Menschen, die mit der Technologie stärker werden. Das schützt besser vor dem Abbau von Rollen, als das Thema zu meiden.
Hybrid bleibt Remote-Arbeit
Wer Remote Leadership für ein Übergangsthema hält, das sich mit der Rückkehr ins Büro erledigt, irrt sich. Michał Buczko hält genau dagegen: Ein hybrides Modell löst die Probleme verteilter Teams nicht. Sitzt eine Person zu Hause und die andere im Büro, führst du weiterhin über Distanz, und es gelten dieselben Regeln.
Für viele Führungskräfte kam der Umstieg abrupt. In Polen gab es vor der Corona-Pandemie kaum Remote-Arbeit. Über Nacht wurden die Teams nach Hause geschickt, und die Führungskräfte sollten selbst sehen, wie sie damit zurechtkommen. Was im Büro funktioniert hatte, ließ sich nicht einfach mitnehmen.
Als Beispiel nennt Michał “Managing by Walking around”. In britischen Unternehmen hatte er gelernt, bei den Leuten am Schreibtisch vorbeizuschauen, einen Blick auf den Monitor zu werfen und aus dem, was er dort sah, ein Gespräch zu beginnen. Remote fällt das weg. Die beiläufige Nähe, aus der Vertrautheit entstand, ist nicht mehr da. Du musst sie bewusst neu aufbauen.
Remote-Teams führen: Warum Vertrauen auf Distanz schwerer entsteht
Wenn du nicht neben jemandem sitzt, entsteht Vertrauen nicht nebenbei. Das ist die zentrale Schwierigkeit, wenn du Remote-Teams führen willst, und sie wirkt in zwei Richtungen: Die Führungskraft braucht das Vertrauen ihres Teams, und das Management darüber muss der Führungskraft vertrauen.
Der Kalender verschärft das Problem. Im Büro waren Meetings durch freie Räume und Arbeitszeiten begrenzt. Remote wird jede Lücke im Kalender zur Einladung, noch einen Termin einzustellen. Wer sechsunddreißig Stunden pro Woche in Meetings sitzt, hat keine Zeit mehr für sein Team. Dort stauen sich Dutzende Themen, und es findet sich nie der Moment, sie anzusprechen.
Michał steuert dagegen, indem er feste Termine im Kalender blockt, die einzelnen Teammitgliedern gehören. Er kommt hinein und stellt eine einzige Frage: Wie kann ich dir helfen? Die Agenda bestimmt das Teammitglied. Es kann den Termin absagen, über etwas reden, das mit der Arbeit nichts zu tun hat, oder sich Rat zu einem Nebenexperiment holen. So bleibt der Kanal offen, statt dass die Führungskraft ihn mit eigenen Themen füllt.
Vertrauen macht ehrliche Karrieregespräche möglich
Wer dir vertraut, sagt dir, wenn er aus seiner Rolle heraus will. Ohne dieses Vertrauen gehen die Leute einfach. Für Michał sind Karrieregespräche der direkte Ertrag der Beziehung, die er in diesen Einzelterminen aufbaut.
Erzählt ihm jemand, dass er über einen Wechsel nachdenkt, kann er handeln. Im Unternehmen kann er die Person mit einem Mentor zusammenbringen. Parallel kann er bei der Leitung nachfragen: Diese Person denkt über eine Veränderung nach, gibt es bei uns eine passende Stelle? Wenn ja, klappt der Wechsel intern. Wenn nein, ist das Risiko, die Person zu verlieren, wenigstens früh bekannt.
Die Alternative ist Schweigen und dann die Kündigung. “Ich wechsle nächstes Jahr in eine Scrum-Master-Rolle, und es ist mir egal, ob es in unserer Firma dann noch Scrum Master gibt.” So klingt es, wenn nie Vertrauen da war. Dann ist es zu spät, noch etwas zu tun.
Wie Remote Leadership die Arbeit des Teams sichtbar macht
Die Teamleitung ist die Brücke zwischen Management und Team, und in der Remote-Arbeit ist diese Brücke der einzige Weg, auf dem die Arbeit des Teams nach oben sichtbar wird. Darauf baut Michał sein ganzes Plädoyer für aktive Fürsprache auf.
Im Büro passierte Anerkennung nebenbei. Du hast deine Chefin oder jemanden aus der Geschäftsleitung an der Kaffeemaschine getroffen und erzählt, woran du gerade arbeitest. Remote gibt es dieses Gespräch in der Küche nicht mehr. Oben sieht niemand die Arbeit, wenn sie nicht jemand gezielt zeigt.
Michałs Werkzeug dafür ist eine halbjährliche E-Mail an das Management mit einer Liste dessen, was das Team erreicht hat. Er erwartet nicht, dass jede Führungskraft sie liest. Ihr Wert zeigt sich später: Wenn jemand ein Ergebnis bemerkt und es einem anderen Team zuschreibt, belegt die E-Mail, wer die Arbeit tatsächlich geleistet hat.
Er hat dafür ein konkretes Beispiel. In einer Komponente sank die Zahl der offenen Fehler um 80 Prozent. Das Management rechnete das dem Verantwortlichen der Komponente an, der die Prioritäten geändert habe. Tatsächlich hatte ein Qualitätsmanager aus Michałs Team die Komponententeams gebeten, sich stärker um die Wartung zu kümmern, und den Verantwortlichen überzeugt, die Priorität von neuen Features dorthin zu verschieben. Der Anstoß kam also von außen, nicht vom Komponentenverantwortlichen selbst. In der E-Mail stand Mateusz aus Michałs Team namentlich drin, und drei oder vier Leute in der Leitung erkannten, dass ein anderes Team das Ergebnis erreicht hatte.
Warum E-Mail für das Management besser funktioniert als Slack
Für diese Art der Fürsprache taugt E-Mail, weil sie asynchron ist und bleibt. Michał entscheidet sich bewusst dafür und gegen ein Messaging-Tool wie Slack.
Eine Slack-Nachricht baut Druck auf. Wer sie bekommt, fühlt sich zur Antwort verpflichtet, und die Nachricht kann nicht einen Monat lang liegen. Eine E-Mail hat dieses Gewicht nicht. Sie darf warten, bis das Management Zeit hat. Kommt ein halbes Jahr später ein Dankeschön zurück, ist das der Beleg, dass sie gelesen wurde, und diesen Beleg kann die Führungskraft ans Team weitergeben. Eine Slack-Nachricht liefert so eine Bestätigung nicht.
Dazu kommt eine ganz praktische Hürde: Du musst die Leute dort erreichen, wo sie sind. Nicht jeder Manager ist im Chat-Tool unterwegs. E-Mail haben alle.
Fehlschläge zeigen, nicht nur Erfolge
Transparente Kommunikation heißt, neben dem, was geklappt hat, auch das zu berichten, was gescheitert ist. Michał beschränkt seine Updates nicht auf Erfolge. Er schreibt klar hinein: Das haben wir versucht, und es hat nicht funktioniert.
Gründe oder Schuldige stellt er nicht an den Anfang. Fragt jemand nach dem Warum, kann die Diskussion folgen. Es geht darum, dass das Management die Arbeit sieht und nicht nur die Ergebnisse. Auch der Aufwand für einen Versuch, der nicht aufgegangen ist, zeigt, was sich das Team in dem Zeitraum vorgenommen hat.
Ein offen benannter Fehlschlag kann sogar Hilfe auslösen. Eine festgefahrene Initiative weckt vielleicht das Interesse des Managements, und mit dem Interesse kommen manchmal Ressourcen.
Michałs eigenes Beispiel: Ein Manager hatte ihn beauftragt, den Softwareentwicklungsprozess der F&E-Abteilung zu reviewen. Nur hat die Abteilung diesen Prozess nie erstellt. Bis zu drei Jahre lang wurde er immer wieder verschoben. Als Michał berichtete, dass er mehrfach nachgefragt und nie eine klare Antwort bekommen hatte, schlug ein Abteilungsleiter einen Weg vor: Arbeitsgruppen, die den Prozess entwerfen, wenn Michał sie koordiniert. Heute koordiniert er fünf Arbeitsgruppen in einer anderen Abteilung, und die Arbeit ist zu etwa 90 Prozent fertig. Hätte er den jahrelangen Stillstand als persönliches Versagen verschwiegen, hätte niemand der Sache Priorität gegeben oder Teams dafür freigestellt.
Damit das funktioniert, braucht es eine Disziplin: keine Schuldzuweisung. Sag, dass etwas gescheitert ist, ohne zu sagen, es lag an denen oder an mir. Transparent, nicht anklagend. Dann springt ein, wer helfen kann, und der Versuch startet im nächsten Halbjahr neu.
Wo KI in die Remote- und Hybridarbeit passt
KI-Tools gehören für Michał in dieselbe Kategorie wie andere Werkzeuge für die Remote-Zusammenarbeit, und sie werfen dieselben Abstimmungsfragen auf. Er sieht KI als Remote-Instrument, das manchmal mehrere Teammitglieder gemeinsam nutzen: Alle schreiben am selben Prompt mit und müssen ihre Arbeit über die Distanz koordinieren.
Sein Unternehmen schränkt den KI-Einsatz stark ein. Die Firma arbeitet mit der Google-Office-Umgebung, freigegeben ist Gemini, meist im Zusammenhang mit Dokumenten. Daneben experimentieren Michał und zwei Kollegen aus dem Team auf privaten Rechnern mit verschiedenen Modellen, um herauszufinden, was geht und was nicht.
In einem dieser Experimente entsteht eine mobile App komplett mit KI: Entwicklung, Test und Projektmanagement übernehmen KI-Agenten. Die Infrastruktur umfasst rund zwanzig Agenten-Personas, jede mit eigenem Verantwortungsbereich. Aufbau und Ergebnisse will er auf der Testing United in Mailand vorstellen.
Wie schnell sich das Feld bewegt, prägt das Experiment selbst. Der Call for Papers lief etwa ein halbes Jahr vor der Konferenz, und Michał hat seinen Vortrag schon in sieben Versionen geschrieben. Ende Oktober wird ein neues Modell erwartet, die Konferenz ist etwa Mitte November. Ist das neue Modell groß genug, fängt er mit dem Vortrag noch einmal von vorn an, mit anderen Ergebnissen.
KI-Ergebnissen vertrauen, ohne jede Zeile zu lesen
Bis Michał der KI so weit vertraute, wie er es heute tut, hat es Monate gedauert. Aufgebaut hat er dieses Vertrauen über Prototypen, nicht über zeilenweise Reviews. Innerhalb einer klar definierten Schleife vertraut er dem Modell vollständig.
Die Schleife sieht so aus:
- Er lässt die KI einen Prototyp entwerfen und dann umsetzen. Den Code liest und reviewt er nicht.
- Er testet den Prototyp so, wie ihn ein Mensch benutzen würde.
- Funktioniert der Prototyp, soll die KI ihn auf Produktionsniveau bringen.
- Funktioniert er nicht, lässt er die Agenten einen neuen Prototyp bauen, kein Anleitungsdokument, und wiederholt das, bis eine lauffähige Version steht.
- Ist er zufrieden, lässt er die KI den freigegebenen Prototyp dokumentieren.
Das Tempo ist beachtlich. Im Sprecherraum einer Konferenz bat er ein Modell, ein einzelnes blockierendes Problem aus seinem Projekt zu lösen. Nach zwei Minuten lag eine hundertseitige Anleitung vor, zugeschnitten auf seine Agenten-Infrastruktur, mit einer geschätzten Umsetzungszeit von vier Stunden.
Tester als kritischer Filter für KI-Tools
Die Aufgabe technischer Leute im KI-Umbruch ist es, die eigene Arbeit mit KI zu verbessern und Tools kritisch zu beurteilen. Die eigene Rolle gegen die Automatisierung zu verteidigen, gehört nicht dazu. Michał zieht eine klare Linie zwischen dem Optimismus des Managements und dem prüfenden Blick, den Ingenieure mitbringen.
Er wünscht sich, dass alle Tester und Entwickler KI wie ein Werkzeug am Gürtel tragen. Entscheidend ist die Haltung: KI, die den Menschen stärker macht, nicht KI, die ihn ersetzt. Was zählt, ist die Arbeit, die du dir ausdenkst und von der KI umsetzen lässt, während du das Ergebnis prüfst.
Im kritischen Urteil zeigt sich, was technische Leute wert sind. Michał hat sich KI-Tools für die Testautomatisierung angesehen und hinter einer aufwendig gestalteten Oberfläche einen direkten API-Aufruf an ein Modell gefunden. Dasselbe Ergebnis bekommst du, wenn du das Modell direkt promptest, ohne eine halbe Million für die Hülle zu bezahlen. Dem Management fehlt oft der Blick dafür. Ingenieure erkennen, ob ein Tool echte Arbeit übernimmt oder nur einen Modellaufruf hübsch verpackt.
Das Risiko ist handfest. Michał verweist auf einen Fall, in dem OpenAI eine Änderung angekündigt hat, die den direkten API-Zugang sperrte, den Startups als Microservice nutzten. Das Unternehmen sagte offen, dass das viele Startups das Aus kosten werde, für die eigene Profitabilität aber nötig sei. Ein Tool für eine halbe Million kann wertlos werden, sobald die API dahinter dichtmacht. Der einzige Schutz: Technische Leute prüfen das Tool vor dem Kauf, statt dass ein Verkaufsgespräch die Entscheidung trifft.
“Wenn ich sage, kauft dieses Testautomatisierungstool nicht, dann verteidige ich damit nicht meinen Job. Ich halte dieses Tool einfach nicht für eine Lösung für uns. Und genau dieses Vertrauen brauchen wir vom Management.”
(Michał Buczko)
Damit schließt sich der Kreis zum Vertrauen. Rät eine Führungskraft von einem Tool ab, muss das Management darauf vertrauen können, dass dahinter ein technisches Urteil steht und kein Selbstschutz. Fehlt dieses Vertrauen, führen Unternehmen Tools ein, vor denen die eigenen Ingenieure gewarnt haben, und das geht selten gut aus.
Häufig gestellte Fragen
Löst die Rückkehr zu einem Hybridmodell die Probleme bei der Führung eines Remote-Teams?
Nein. Solange eine Person von zu Hause aus arbeitet, während eine andere im Büro sitzt, findet Führung weiterhin über die Entfernung hinweg statt, und es gelten ausnahmslos dieselben Vorgehensweisen. Was wegfällt, ist alles, was mit physischer Nähe zu tun hat: zum Schreibtisch gehen, einen Blick auf den Bildschirm werfen und ausgehend von dem, was man dort sieht, ein Gespräch beginnen. Diese Vertrautheit muss bewusst wieder aufgebaut werden.
Wie kann ein Leiter eines Remote-Teams genügend Zeit für einzelne Teammitglieder freihalten?
Indem er Termine im Kalender reserviert, die bestimmten Teammitgliedern gehören und nicht der eigenen Agenda des Leiters. Michał Buczko kommt mit einer einzigen Frage: Wie kann ich dir helfen? Das Teammitglied entscheidet, was passiert, und kann den Termin absagen, über etwas Nicht-Arbeitsbezogenes sprechen oder um Rat zu einem Nebenprojekt bitten. Ein Teamleiter mit 36 Stunden Besprechungen pro Woche hat dafür keine Zeit mehr.
Was kann ein Teamleiter tun, wenn die Geschäftsleitung einem falschen Team die Lorbeeren für ein Ergebnis zuschreibt?
Führe schriftliche Aufzeichnungen, die vor der falschen Zuordnung entstanden sind. Eine halbjährliche E-Mail an die Geschäftsleitung, in der die Erfolge des Teams aufgelistet sind, dient genau diesem Zweck. In einem Fall sanken die offenen Fehlerzustände in einer Komponente um 80 Prozent, und die Geschäftsleitung schrieb den Erfolg dem Komponentenverantwortlichen zu, obwohl ein Qualitätsmanager im Team diesen davon überzeugt hatte, die Priorität auf die Wartung zu verlagern. In der E-Mail wurde er namentlich genannt, und mehrere Führungskräfte haben das erkannt.
Ist es eine gute Idee, fehlgeschlagene Initiativen der Geschäftsleitung zu melden?
Ja, und oft führt das eher zu Unterstützung als zu Kritik. Das Review eines F&E-Softwareentwicklungsprozesses zog sich bis zu drei Jahre hin, weil der Prozess nie auf den Weg gebracht wurde. Die Meldung des Stillstands veranlasste einen Abteilungsleiter, stattdessen Arbeitsgruppen vorzuschlagen, wobei die Koordination übertragen wurde; es folgten fünf Arbeitsgruppen, die zu rund 90 Prozent abgeschlossen sind. Die Disziplin, die dafür sorgt, dass das funktioniert, besteht darin, den Fehlschlag beim Namen zu nennen, ohne jemandem die Schuld zu geben.
Warum sollten Ingenieure ein KI-Tool prüfen, bevor ein Unternehmen es kauft?
Weil eine ausgefeilte Benutzeroberfläche nur sehr wenig verbergen kann. Ein getestetes KI-Tool zur Testautomatisierung entpuppte sich als direkter API-Aufruf an ein öffentliches Modell, das Ergebnisse lieferte, die jeder selbst mit einem Prompt direkt an das Modell erhalten könnte, anstatt eine halbe Million zu bezahlen. Hinzu kommt das Plattformrisiko: OpenAI kündigte an, den direkten API-Zugang zu sperren, den Start-ups als Microservice genutzt hatten.
Wie sollte das Management es interpretieren, wenn die eigenen Ingenieure von einem KI-Tool abraten?
Als technische Einschätzung, nicht als Selbstschutz. Buczko macht deutlich, dass die Ablehnung eines Tools für die Testautomatisierung nichts mit dem Schutz seines Arbeitsplatzes zu tun hat; er hält das Tool einfach für keine Lösung für das Unternehmen. Diese Interpretation hängt vom Vertrauen ab. Wo dieses fehlt, kaufen Unternehmen Tools, vor denen ihre eigenen Entwickler gewarnt haben. Der sinnvolle Ansatz ist KI, die Menschen unterstützt, nicht KI, die sie ersetzt.
