In IT-Projekten gibt es eine ganze Menge Dinge, die niemand hören möchte. Zum Beispiel, dass das Webformular eine Sicherheitslücke aufweist, das automatische Backup seit einer Woche nicht mehr funktioniert oder das bereits beworbene Feature ohne größeren Codeumbau nicht machbar ist.

Oft genug sieht sich der Überbringer der schlechten Nachricht selbst Kritik ausgesetzt. Kein Wunder also, dass viele genau überlegen, wie offen sie ihre Meinung in einem IT-Projekt äußern.

Schweigen und seine Folgen

Ob jemand Mängel anspricht oder sich Kritik verkneift, hat viel mit Erziehung, Kultur und Erfahrung zu tun. Was für eine Person ein technisches Argument ist, empfindet die nächste als Egotrip. Die unterdrückte Antwort: Diplomatie oder Heuchelei? Über persönliche Moralvorstellungen und Einzelfälle lässt es sich trefflich diskutieren. Der springende Punkt sind vielmehr die Auswirkungen auf das Projekt.

Ein ungeklärtes Problem ist wie ein unerkanntes Krebsgeschwür. Es kann wachsen, bis es sich irgendwann nicht mehr ignorieren lässt. Ein Beispiel dafür ist eine größere Aktualisierung einer Library. Die dafür notwendigen Änderungen im Code mitsamt Testen würden vielleicht eine Woche Zeit kosten. Niemand hat eine Woche Zeit übrig, also passiert nichts. Für die nächste größere Änderung der Library haben Entwicklerinnen und Entwickler natürlich noch weniger Zeit übrig. Irgendwann schlagen die Auswirkungen der veralteten Library im eigenen Code durch. Sie ist zu allem inkompatibel, moderne Funktionen sind unerreichbar. Das Problem: Statt eines Updates braucht es jetzt eine Neuimplementierung der betroffenen Stellen. Aus einem alltäglichen Stolperstein ist ein unüberwindbarer Wall geworden.

Manchmal bleiben Probleme einfach unerkannt. Das ist Pech. Oder Entwicklerinnen und Entwickler erkennen sie und entscheiden sich bewusst dafür, sie zu ignorieren. Das ist eine Ermessensfrage. Aber wenn Teammitglieder Probleme verschweigen, dann ist das eine verpasste Chance. Insofern wäre es in IT-Teams folgerichtig, das Ansprechen von Problemen aktiv zu fördern.

Bildungslücken bei der Diskussionskultur

Doch die Realität sieht anders aus; nicht nur, weil Diskussionskultur nicht zum Lehrinhalt eines Informatikstudiengangs zählt, sondern vor allem, weil IT-Projekte von Zeitdruck, überzogenen Erwartungen und mangelnder Management-Unterstützung geprägt sind.

Ein kaputtes Projekt macht alle kaputt. Die letzten drei Deadlines gerissen, Fachbereich oder Marketingabteilung sind sauer und machen Druck, im Team schiebt man sich gegenseitig die Schuld zu. Entdeckt ein Teammitglied jetzt ein neues Problem, wird es je nach Naturell entweder noch weniger bereit sein, es anzusprechen (wozu auch, es hat ja niemand Zeit, das Problem zu beheben) oder es besonders laut und aggressiv zur Sprache bringen (es ist fünf vor zwölf, jetzt muss endlich etwas passieren!). Das Problem bleibt bestehen und verkommt zum Streitfall, der das Projekt noch weiter verzögert und gefährdet.

Schade, dass es oft so weit kommt. Denn eigentlich wollen alle das gleiche: funktionierende Software, die jemandem das Leben in irgendeiner Form erleichtert und worauf Entwicklerinnen oder Entwickler stolz sein können. Und das wird umso unwahrscheinlicher, je weniger das Team Probleme offen ausdiskutiert.

Das einzelne Teammitglied könnte jetzt die IT-Welt verfluchen und Dienst nach Vorschrift erledigen – oder sich der Realität stellen und die Situation als persönliche Herausforderung annehmen. Die Rahmenbedingungen eines Projektes kann es üblicherweise nicht ändern und hat auch die Stimmung im Team nicht direkt in der Hand. Teammitglieder können jedoch Strategien entwickeln, um den eigenen Argumenten mehr Gehör zu verschaffen.

Fragen statt sagen

Fragen sind ein didaktisches Instrument und helfen oft weiter als die Demonstration von Fachkompetenz. Wer ein Problem selbst erkennt, macht niemanden anderes dafür zum Sündenbock. „Dein Code ist Schrott!“, greift persönlich an und erzeugt schlechte Stimmung. „Dein Code könnte eine kleine Überarbeitung gebrauchen“, ist noch schlimmer, denn die angesprochene Person wird oft nicht einmal verstehen, dass es ein Problem gibt. Probieren wir es konstruktiv: „Dieser Code ist ineffizient, weil er innerhalb der Schleife dieselbe Berechnung mehrfach durchführt. Wir sollten diese aus der Schleife herausziehen“, oder „Diesen Code finde ich schlecht lesbar, weil ich die Aufteilung in Funktionen nicht nachvollziehen kann.“ Bei diesen Aussagen geht es um den Code, nicht um die Fähigkeiten der Person, die ihn produziert hat. Das Problem wird direkt benannt und lässt sich beheben.

„Das geht nicht!“, kann die Adressatin oder der Adressat der Kritik leicht als inkompetent oder bockig auslegen. Was genau geht denn nicht? Die notwendige Technik ist noch nicht erfunden? Also versuchen wir eine Lösung zu finden: Warum wird diese Funktion gebraucht? Welche Effekte wie Kosteneinsparung oder Fehlerreduzierung sollen dadurch entstehen? Mit ein paar Fragen macht man entweder die Sinnlosigkeit offensichtlich oder findet gemeinsam eine Lösung.

Oder ist das „geht nicht“ eine Zeitfrage? Dann vielleicht „Ich/Wir als Team arbeite/n gerade an Feature X, Test Y und Dokumentation Z. Wie sollen wir diese neue Anforderung priorisieren? Welche der anderen Aufgaben, die aktuell geplant sind, sollen wir hinten anstellen?“.

Antennen ausfahren

Jeder Mensch pflegt eine andere Diskussionskultur, vielleicht sogar unterschiedliche je nach Kontext. Es lohnt sich, die eigene Antenne für Befindlichkeiten gut zu kalibrieren.

Im alltäglichen Umgang mit Teammitgliedern ergeben sich viele Gelegenheiten zur Beobachtung. Ist der Mensch ein Morgenmuffel? Dann die heiklen Themen erst nach der Mittagspause auftischen. Geht es mit rationaler Begründung voran oder hilft es, auf den Angst- oder Belohnungs-Knopf zu drücken? Wie bringt das Teammitglied selbst Argumente vor? Ein schöner Zeitvertreib in langweiligen Meetings ist, sich vorzustellen, was die einzelnen Leute gerade denken oder warum sie überhaupt zu diesem Termin erschienen sind.

In einem gut eingespielten Team muss man nicht jedes Wort auf die Goldwaage legen. Zum Beispiel kommt die Chirurgin mit einem einfachen „Skalpell!“ durch, ohne zeitraubende Höflichkeiten wie „Würden Sie mir bitte das Skalpell reichen?“ Deshalb lohnt es sich, gegenseitiges Vertrauen aufzubauen und auch eigene Grenzen klarzumachen.

Kritik verarbeiten

Kritiker können auch selbst zur Zielscheibe von Kritik werden. Sei es durch eine andere Meinung zur abgelieferten Arbeit, ein Gegenargument in einer Diskussion oder durch einen offenen persönlichen Angriff. Wie geht man am besten damit um? – Erst einmal einen Schritt zurücktreten, tief durchatmen und analysieren. Worum geht es und warum fühle ich mich angegriffen?

Gibt es eine unterschiedliche Sichtweise der Situation? Ist die Sicherheitslücke in der Library ein Grund zur Panik oder ein theoretisches Angriffsszenario, das im Kontext gar nicht relevant werden kann? Entwicklerinnen und Entwickler müssen die Meinung des anderen nicht übernehmen, sondern sich nur bemühen, die andere Sichtweise nachzuvollziehen. Vielleicht kennt der andere nicht alle Fakten, hat weniger Erfahrung oder ein höheres Sicherheitsbedürfnis.

Oder will jemand nur Dampf ablassen und ein Sündenbock war gerade greifbar? Manchmal haben Motive für Kritik und Diskussionen gar nichts mit der Sache zu tun oder machen eine Kleinigkeit zur Staatsaffäre. Dann sollte man ruhig bleiben, Gegenfragen stellen und versuchen, auf eine sachliche Ebene zu kommen oder auch das Gespräch vertagen.

Selbst wenn ein Argument sachlich und korrekt ist, mag es uns nicht gefallen. Oft beschleicht einen das unangenehme Gefühl, etwas falsch gemacht zu haben. Dabei sollten wir nicht vergessen, dass auch das größte Genie mal daneben liegt. Gut vorgebrachte Kritik ist ein Zeichen dafür, dass das Team funktioniert. Immerhin macht sich jemand die Mühe, uns darauf hinzuweisen.

In vielen Fällen stört uns auch einfach die Konsequenz des Gesagten, wenn daraus weitere Arbeit folgt. Fertig geglaubter Code muss geändert werden oder nicht eingeplante Aufgaben verzögern den Zeitplan. Darüber freut sich niemand. Trotzdem sollten wir uns hüten, die Meinungsäußerungen anderer zu ignorieren, als irrelevant abzutun oder den eigenen Unmut am Nachrichtenüberbringer auszulassen. Wer selbst den Respekt fordert, gehört zu werden, sollte ihn auch anderen zuteilwerden lassen.

Multi-Krisen, Transformationen, KI – die Herausforderungen für agile Führungskräfte sind klar und mannigfaltig. Die Online-Konferenz Agile Leadership Day (ALC) gibt am 1. und 2. Dezember 2026 Antworten darauf. Vormittags laufen Vorträge, nachmittags kommen die Teilnehmerinnen und Teilnehmer in praktischen Kurz-Workshops zusammen.

Wer mehrere Coding-Agenten parallel an verschiedenen Projekten arbeiten lässt, muss auf deren Ausgaben warten und vor allem den Überblick behalten: Welcher Agent rechnet noch, welcher ist fertig, und wo blockiert eine Rückfrage den nächsten Schritt? Genau an dieser Stelle setzt Herdr an. Der freie Terminal-Multiplexer hält Sitzungen am Leben, ordnet sie nach Projekten und fasst den Zustand von Agenten in einer Seitenleiste zusammen.

Das im März 2026 veröffentlichte Projekt hat inzwischen auch institutionellen Rückhalt erhalten. Gründer Can Celik kündigte Anfang August die Aufnahme in den Herbstjahrgang 2026 des US-Gründerprogramms Y Combinator an. Y Combinator führt Herdr als Ein-Personen-Unternehmen mit Sitz in Ankara. Y Combinators Standard Deal investiert in jedes aufgenommene Start-up 500.000 US-Dollar. Eine weitere, individuelle Finanzierungsrunde nennt Herdrs Ankündigung nicht.

Herdr liefert kein Sprachmodell und ersetzt keine Agenten wie Claude Code, Codex oder OpenCode. Als auf Coding-Agenten zugeschnittener Konkurrent zu tmux führt Herdr gewöhnliche Terminal-Prozesse aus, ergänzt deren Darstellung aber um die Zustände working, blocked, done,idle und unknown. Die aktuelle stabile Ausgabe ist 0.9. Das in Rust entwickelte Programm steht unter der Apache-2.0-Lizenz. Binärpakete gibt es für Linux und macOS auf x86-64 und ARM64 sowie für Windows auf x86-64. Hinzu kommen unter anderem Homebrew, Nix und mise. Einzelne Funktionen bleiben unter Windows eingeschränkt.

Vom Pane zur Aufmerksamkeitsliste

Die Herdr-Architektur folgt dem Client-Server-Modell klassischer Terminal-Multiplexer. Ein Server stellt die Terminal-Instanzen bereit, unter Unix als Pseudoterminals (PTYs) und unter Windows per ConPTY-Konsolen. Der Client stellt diese nur dar, sodass Shells, Entwicklungsserver und Agenten weiterlaufen, sollte er getrennt werden. Herdr organisiert Terminals in Workspaces, Tabs und Panes, sodass der Nutzer sie entsprechend seines eigenen Workflows gruppieren kann.

Um die Aufmerksamkeit des Nutzers auf die richtigen Agenten lenken zu können, erkennt Herdr Zustände der KI-Agenten per Hook, Plugin oder die Analyse der Terminal-Ausgabe. Optionale Integrationen liefern je nach Werkzeug zusätzlich Sitzungskennung oder Informationen zum Lebenszyklus. Herdr verdichtet die Zustände auf Workspace-Ebene und meldet unbeachtete Rückfragen.

Auch Automatisierung ist vorgesehen. Über Kommandozeile und eine lokale Socket-API lassen sich Panes anlegen, Ein- und Ausgaben übertragen sowie Agentenzustände abfragen. Unter Unix nutzt sie einen Unix Domain Socket, unter Windows eine Named Pipe. Auch tmux lässt sich automatisieren, allerdings ohne die native Integration von Agenten und deren Zuständen.

Dauerhaft ist nicht unsterblich

Beim Trennen eines Clients oder bei einem Netzwerkausfall laufen Server und Prozesse weiter. Nach einem Neustart des Herdr-Servers oder Rechners dagegen sind Prozesse natürlich beendet. Laut der Restore-Matrix des Projekts stellt Herdr dann Workspaces, Tabs, Pane-Aufteilung, Arbeitsverzeichnisse und Fokus wieder her und setzt Agenten, die das unterstützen, über deren native Sitzungskennung fort.

Die optionale Speicherung der Terminal-Historie ist standardmäßig abgeschaltet, weil sie Zugangsdaten, Token oder Prompts enthalten kann. Ein experimentelles Live-Handoff versucht, Prozesse bei bestimmten Updates zu erhalten, bietet dafür aber keine Garantie.

SSH bleibt der Transportweg

Auch bei entfernten Rechnern ersetzt Herdr nicht SSH. Nutzer können sich wie gewohnt anmelden und Herdr dort starten. Alternativ verbindet die Remote-Funktion herdr --remote host einen lokalen Herdr-Client über OpenSSH mit einem Herdr-Server. OpenSSH übernimmt Authentifizierung und Host-Key-Prüfung. Als Ziel unterstützt dieser Modus nur Linux und macOS. Windows kann seit Herdr 0.8.2 als lokaler Client dienen, aber nicht als Server.

Seit Version 0.9.0 können mehrere Clients unabhängig voneinander verschiedene Workspaces und Tabs anzeigen. Unterschiedliche Tabs passen sich der Größe des jeweiligen Clients an. Teilen sich Clients einen Tab, bestimmt der zuletzt darin aktive Client dessen Größe.

Die am 7. September 2026 veröffentlichte Version bündelt außerdem lokale und per SSH angebundene Server in einem Fenster. Eine gemeinsame Agentenliste zeigt deren Zustände. Während die ausgewählte Maschine die sichtbaren Terminal-Inhalte liefert und Eingaben erhält, aktualisieren die übrigen Verbindungen weiterhin Statusinformationen und Benachrichtigungen. Diese Funktion wird derzeit unter Linux und MacOS unterstützt. Ein gespeichertes Maschinenprofil bindet jeweils eine Sitzung ein, nicht sämtliche Sitzungen eines Hosts.

Omarchy integriert Herdr und steuert Code bei

Besonders sichtbar wurde Herdr durch Omarchy, die Linux-Distribution des umstrittenen David Heinemeier Hansson. Deren vierte Hauptversion Quattro hat den Multiplexer zusätzlich zu tmux integriert. Die mitgelieferte Konfiguration orientiert sich mit Ctrl+Space als Prefix an Omarchys tmux-Belegung. Die Versionshinweise zu Herdr 0.8.2 nennen DHH als Mitwirkenden an Fenstertiteln, Pane-Größenänderung und Tab-Verschiebung. Omarchy ist damit Konsument und DHH Contributor.

Für ein oder zwei Sitzungen, deren Inhalt bekannt ist, bleibt ssh plus tmux die nüchterne Wahl. tmux ist seit fast zwei Jahrzehnten erprobt, breit paketiert und detailliert konfigurierbar. Wer Statusleisten, Hooks und Benachrichtigungen eingerichtet hat, gewinnt durch einen Wechsel womöglich wenig.

Mehr Orientierung, weniger Reife

Herdr wird interessanter, wenn mehrere Agenten über Repositories und Rechner verteilt arbeiten und die menschliche Aufmerksamkeit knapp wird. Statusübersicht, Benachrichtigungen, Sitzungswiederaufnahme und semantische API reduzieren dann Eigenbau. Mausbedienung und repositoryorientierte Organisation senken zudem die Einstiegshürde.

Herdr bleibt jedoch jung: In weniger als fünf Monaten sprang es von Version 0.1 auf 0.8. Auch der Plugin-Marktplatz ist keine kuratierte vertrauenserweckende Anlaufstelle. Einträge werden laut Projekt automatisch erfasst und nicht geprüft. Plugins, Hooks und Socket-API haben Zugriff auf Entwicklungsumgebung und Terminal-Inhalte und verlangen entsprechende Vorsicht.

Somit macht Herdr tmux nicht überflüssig. Es behandelt Terminals zusätzlich als Warteschlange für menschliche Entscheidungen. Ob das ein eigenes Laufzeitsystem rechtfertigt, hängt weniger von der Zahl offener Panes ab als davon, wie oft eines unbemerkt auf eine Antwort wartet.

(axk)