Wer Softwareentwicklung in der öffentlichen Verwaltung nach modernen Maßstäben organisieren will, stößt schnell auf eine Wand: die Linienorganisation. Referate, Abteilungen, disziplinarische Zuordnungen, Beamtenstatus, klare Führungsketten. Das ist nicht Beharren, das ist Rechtsordnung. Eine Sachbearbeiterin gehört zu ihrem Referat, und das bleibt so, unabhängig davon, an welchem Produkt sie gerade arbeitet. Dass dahinter eine Reihe rechtlicher Rahmen wirkt (Dienstrecht, Weisungsbefugnis, Personalvertretung), sei am Rande erwähnt; es macht Umbauten schwerer, nicht leichter. Der Versuch, diese Struktur in Richtung flacher Produkt-Organisation umzubauen, würde Jahre dauern und den laufenden Betrieb gefährden. [^s023] In Großvorhaben wie KONSENS, bei dem Verfahren über Länder, Referate und Abteilungen verteilt sind, ist so ein Umbau schlicht nicht machbar.
Gleichzeitig braucht moderne Softwareentwicklung produktorientiertes Arbeiten, gerade im Public Sector, der dutzende komplexe Fachverfahren betreibt. Feste Teams, definierte Services, Backlogs, Sprintziele, klare Lieferobjekte. Das ist kein Mode-Trend, sondern der einzige Weg, wie man komplexe digitale Produkte nachhaltig weiterentwickelt. [^s018]
Die Frage ist also nicht, ob die Verwaltung produktorientierter arbeiten muss. Sie muss. Die Frage ist, wie das geht, wenn die Linienorganisation gleichzeitig bestehen bleiben muss.
Zwei Ebenen statt eine
Die pragmatische Antwort, seit Jahren in großen föderalen Verfahrens-Vorhaben erprobt, ist einfach: zwei Ebenen statt eine. Die disziplinarische Linie bleibt unverändert; darüber legt sich eine zweite Ebene aus virtuellen Produktteams. Mitarbeitende sind disziplinarisch weiter ihrem Referat zugeordnet, operativ arbeiten sie im Produktteam. Die Schnittstelle ist klar: Die Linie verantwortet Personal, Kompetenz und Führung. Das Produktteam verantwortet Services, Backlog, Sprintziele und Lieferobjekte. Eine Team-Charta regelt, wer welche Rolle übernimmt, wie eskaliert wird, wie lange das Commitment gilt.
Das ist kein theoretisches Modell. Es ist gelebte Praxis, und sie funktioniert, weil sie nichts abreißt. Sie ergänzt. [^s025]
Wer gehört ins Produktteam
Ein virtuelles Produktteam in der Verwaltung besteht heute aus drei Quellen. Aus der Linienorganisation selbst kommen die Fachexpert:innen, Menschen, die die Domäne kennen, die Regeln, die Fälle, die Eigenheiten. Aus externen Expertenpools kommen Dienstleister mit technischer Tiefe, die die Linie intern nicht vollständig vorhalten kann. Und als dritte Quelle kommen, neu, KI-Agenten als eigene Klasse von Teammitgliedern hinzu: spezialisiert, rund um die Uhr verfügbar, gut in strukturierten Aufgaben, nicht geeignet für alles, was menschliches Urteil verlangt.
Das klingt weniger nach Revolution, als es ist. Ein KI-Agent, der als Teammitglied geführt wird, ist etwas anderes als ein Chat-Assistent, den ein Einzelner aufruft. Er hat eine Rolle, einen Verantwortungsbereich, Eingaben, erwartete Outputs, Eskalationspunkte. Er erscheint im Team-Charter. Er wird vom Produktteam beauftragt, ausgewertet, iterativ verbessert. Was er nicht hat, und was sein menschliches Team weiter hat, ist die Letztverantwortung. Die liegt im Team, und über die Linie letztlich beim Dienstherrn.
KI-Agenten als neue Mitgliedsart
Diese Unterscheidung trägt die eigentliche Pointe. KI-Agenten sind keine Werkzeuge in Händen einer einzelnen Person, und sie sind auch keine automatischen Vertreter des Teams. Sie sind eine neue Art von Teammitgliedern: spezialisiert, weisungsgebunden, ohne Letztverantwortung. Ein Dokumenten-Agent klassifiziert eingereichte Unterlagen; ein Validierungs-Agent prüft Regeln; ein Test-Agent generiert und wartet Testfälle; ein Dokumentations-Agent pflegt die technische Beschreibung. Jeder mit klarem Zuschnitt, jeder im Team-Charter genannt, jeder einem menschlichen Verantwortlichen zugeordnet.
Die disziplinarische Linie wird davon nicht berührt. Die menschlichen Mitarbeitenden bleiben in ihren Referaten. Die Agenten gehören dem Produktteam als Kapazität, nicht einer Person als Werkzeug. Wer das trennt, kann skalieren, ohne die Verantwortung zu verschieben. Die sociomaterielle Transformationslogik, die Tangi, Rodriguez Müller und Janssen (EC JRC / TU Delft, 2025) für AI-augmented government transformation beschrieben haben, fordert genau diese Mehr-Ebenen-Integration: KI kommt als Zusammenspiel von Technik, Struktur, Governance und Kultur in die Verwaltung, nicht als Tech-Add-on. Der Mehr-Ebenen-Ansatz hier ist die organisatorische Übersetzung eines dokumentierten Befunds. [^s006]
Gas und Bremse
Skalierung in einer Verwaltungsorganisation funktioniert anders als in einem Start-up. Nicht alles auf einmal, nicht gleich alle Verfahren. Der bewährte Weg: klein starten mit einem oder zwei agilen Produktteams in einem Verfahren, Erfahrungen sammeln, Muster stabilisieren. Danach schrittweise weitere Teams bilden, bedarfsorientiert. Wenn ein Verfahren nicht mitkann, bremst man; wenn ein anderes Tempo aufnimmt, gibt man Gas. Die KI-Agenten werden den Teams in derselben Bewegung zur Verfügung gestellt, dort, wo sie gebraucht werden, nicht flächendeckend, weil es gerade Mode ist.
Dieses Gas/Bremse-Prinzip ist der wichtigste Unterschied zu klassischen Reorganisationen. Man zerstört nichts, man beschleunigt das, was trägt, und man hält zurück, wo es noch nicht trägt. Organisations- und Kulturentwicklung entsteht aus der Arbeit, nicht aus Reformerlassen.
Was das liefert
Die Linie trägt die Verantwortung. Das virtuelle Team liefert das Produkt. Der Agent erledigt, was sich klar definieren lässt. Jede Ebene tut, was sie kann, und nicht mehr. Verwaltungen, die so arbeiten, brauchen keine Reorganisations-Großbaustelle; sie liefern, während sie intakt bleiben. Wer stattdessen den großen Umbau versucht, verliert meist beides: den Betrieb während des Umbaus und das Produkt nach dem Umbau.
Grundlage dieser Serie sind Gespräche mit Projektleiter:innen in öffentlicher Verwaltung und Industrie über Probleme, an denen sie arbeiten und Stellen, wo es hakt. Verdichtete Beobachtungen, keine Strategiepapiere.
