Thema 7.0 — Teamstrukturen, Rollen und Verantwortlichkeiten

In einem Satz: Die Lieferung digitaler Gesundheit gelingt oder scheitert daran, wie Sie die Grenzen zwischen Teams ziehen und wie klar Sie benennen, wer was tut – strukturieren Sie Teams daher für einen schnellen, sicheren Fluss von Wert, besetzen Sie sie multidisziplinär und machen Sie Verantwortlichkeiten explizit.

Warum das in Gesundheit und Pflege wichtig ist#

Die Art, wie Sie Ihre Teams organisieren, wird zur Art, wie sich Ihre Dienste verhalten. Conways Gesetz – dass das Design eines Systems die Kommunikationsstruktur der Organisation spiegelt, die es gebaut hat – ist in Gesundheit und Pflege keine Kuriosität; es ist ein Risiko für die Patientensicherheit. Fragmentierte Teams erzeugen fragmentierte Patientenakten, brüchige Integrationen und Übergaben, in denen sich klinisches Risiko verbirgt.

Im NHS und in der Sozialpflege geben Sie auch öffentliches Geld aus und tragen gesetzliche Pflichten: klinische Sicherheit nach DCB0129/DCB0160, Informationsgovernance nach UK GDPR und der Verschwiegenheitspflicht nach Common Law sowie Pflichten zur Barrierefreiheit. Diese Pflichten lassen sich nicht am Ende aufsetzen. Sie müssen innerhalb des Teams vertreten sein, durch benannte Menschen mit der Befugnis und Zeit, sie zu erfüllen.

Ist die Struktur richtig, liefern multidisziplinäre Teams funktionierende Software aus, der Klinikpersonal vertraut und die Patientinnen nutzen können. Ist sie falsch, entstehen beschäftigte Spezialistinnen, die ihr eigenes Silo optimieren, während der Dienst als Ganzes stockt – das klassische Muster hinter verspäteten, überteuerten und still aufgegebenen digitalen Programmen.

Kernkonzepte#

Multidisziplinäre Teams (MDTs). Ein digitales Liefer-Team sollte jede Disziplin enthalten, die nötig ist, um einen Dienst ohne ständige externe Abhängigkeit zu gestalten, zu bauen und zu betreiben – Produkt, Lieferung, Design, Forschung, Engineering, Daten sowie die klinische und die Governance-Perspektive. Das spiegelt das klinische MDT-Konzept, das das Personal bereits kennt: gemischte Expertise, geteilte Rechenschaft für ein Ergebnis.

Team Topologies. Ein Modell (Skelton & Pais), das effektives Teamdesign auf vier grundlegende Typen und drei Interaktionsmodi reduziert, alles im Dienst eines schnellen Wertflusses:

• Stream-aligned Team (am Wertstrom ausgerichtetes Team) — um einen einzelnen wertvollen Arbeitsstrom (einen Dienst, eine Nutzerreise, ein Produkt) organisiert und verantwortet ihn Ende-zu-Ende. Das ist der Standardteamtyp; die meisten Menschen sollten in einem sein.
• Platform Team (Plattformteam) — liefert interne Self-Service-Fähigkeiten (gemeinsame Infrastruktur, eine Integrations-Engine, einen Login-Dienst, eine API der gemeinsamen Patientenakte), damit Stream-aligned Teams schneller werden, ohne sie neu zu erfinden.
• Enabling Team (befähigendes Team) — ein befristetes Team von Spezialistinnen (z. B. klinische Sicherheit, Barrierefreiheit, Testautomatisierung), das andere coacht, um eine Fähigkeit zu heben, und sich dann zurückzieht.
• Complicated-Subsystem Team — verantwortet einen Teil, der tiefes Fachwissen braucht (einen Risikoscore-Algorithmus, eine NHS-Spine-Schnittstelle), das ein Generalistenteam überlasten würde.

Die drei Interaktionsmodi bestimmen, wie zwei beliebige Teams zueinander stehen: Zusammenarbeit (Collaboration) (für einen definierten Zeitraum eng zusammenarbeiten, hohe Bandbreite, etwas Ineffizienz zugunsten von Entdeckungen tolerierend), X-as-a-Service (ein Team konsumiert die Fähigkeit eines anderen mit minimalem Aufwand, der reibungsarme Standard im großen Maßstab) und Facilitating (ein Team hilft einem anderen beim Lernen). Den Modus zu benennen verhindert die Mehrdeutigkeit, die Verzögerungen und Schuldzuweisungen erzeugt.

Kognitive Belastung (Cognitive Load). Ein Team kann nur begrenzt viel im Kopf halten. Team Topologies argumentiert, Sie sollten die Domäne, die jedes Team verantwortet, auf das begrenzen, worüber es sicher nachdenken kann – ein entscheidendes Prinzip, wenn die Domäne klinisch ist.

Conways Gesetz und das Inverse Conway Manöver. Da Architektur der Organisationsstruktur folgt – eine soziotechnische System-Sicht, die Teams und Technologie als ein Design behandelt –, formen Sie Teams bewusst, um die gewünschte Architektur zu erzeugen. Wenn Sie eine modulare, interoperable Patientenakte wollen, bauen Sie sie nicht mit einem monolithischen Team.

Bewährte Praktiken#

1. Besetzen Sie um jeden Dienst ein volles multidisziplinäres Team. Nehmen Sie mindestens eine Produktmanagerin, einen Liefermanager, eine Nutzerforscherin, einen Service-/Interaktionsdesigner, Entwicklerinnen und eine Daten-/Analytikfähigkeit sowie benannten Input zu klinischer Sicherheit und Informationsgovernance auf. Ein Team, dem eine Disziplin fehlt, wird entweder auf jemand anderen warten oder diese Arbeit überspringen – und die übersprungene Arbeit in der Gesundheit ist meist Sicherheit, Barrierefreiheit oder Governance.

2. Machen Sie die meisten Teams zu Stream-aligned Teams und geben Sie ihnen Ende-zu-Ende-Verantwortung. Organisieren Sie sich um die Reise einer Nutzerin (z. B. „ambulante Überweisung“) statt um eine Technologieschicht (z. B. „das Datenbankteam“). Ende-zu-Ende-Verantwortung verkürzt Rückkopplungsschleifen und stoppt die Übergabelücken, in denen sich klinisches Risiko häuft.

3. Bauen Sie Plattformen als Produkte, konsumiert als Service. Behandeln Sie Ihre Integrations-Engine, Ihren Identitätsdienst oder die API Ihrer gemeinsamen Patientenakte als internes Produkt mit eigenem Team, eigener Roadmap und eigenen Nutzenden. Veröffentlichen Sie sie „as-a-Service“, damit Stream-aligned Teams sich selbst bedienen, statt Tickets zu erstellen und zu warten.

4. Nutzen Sie Enabling Teams, um knappe Expertise zu verbreiten, nicht um sie zu horten. Klinische Sicherheitsbeauftragte, Spezialistinnen für Barrierefreiheit und Sicherheitsingenieure sind selten. Setzen Sie sie ein, um Liefer-Teams zu einem höheren Standard zu coachen und dann weiterzuziehen, statt zu einem dauerhaften Engpass zu werden, hinter dem sich jedes Team anstellt.

5. Benennen Sie jede Rolle und ihre Entscheidungsrechte ausdrücklich. Nutzen Sie ein Verantwortungsmodell – RACI (Responsible, Accountable, Consulted, Informed) oder eine einfachere Aufteilung „Entscheider/Berater“ – für die Entscheidungen, die zählen: Freigabe der klinischen Sicherheit, Go-live, Genehmigung der Informationsgovernance, Ausgaben. Mehrdeutigkeit hier ist der Ort, an dem Rechenschaft verdunstet.

6. Geben Sie der klinischen Sicherheitsbeauftragten echte Befugnis und echte Zeit. DCB0129/0160 verlangen eine benannte, angemessen geschulte klinische Sicherheitsbeauftragte, die eine Freigabe stoppen kann. Machen Sie die Rolle im Team ausdrücklich, schützen Sie ihre Zeit und stellen Sie sicher, dass sie Nein sagen kann – eine CSO nur dem Namen nach ist ein Governance-Versagen, das darauf wartet, von einem Vorfall gefunden zu werden.

7. Managen Sie kognitive Belastung, indem Sie die Domäne begrenzen. Wenn ein Team zu viele Dienste oder eine zu komplexe klinische Domäne verantwortet, teilen Sie es. Achten Sie auf das Signal: Ein Team, das die Sicherheitsfolgen seiner eigenen Änderung nicht mehr sicher erklären kann, ist überlastet.

8. Wenden Sie das Inverse Conway Manöver bewusst an. Ziehen Sie die Teamgrenzen so, dass sie zur gewünschten Architektur und Interoperabilität passen – modulare Teams für modulare, standardbasierte (z. B. HL7 FHIR) Systeme. Lassen Sie nicht ein zufälliges Organigramm Ihre Patientenakte für Sie entwerfen.

Fragen zur Diskussion im Team#

1. Wo entwirft unser aktuelles Organigramm bereits unsere Architektur für uns – und ist das die Architektur, die wir tatsächlich wollen? Conways Gesetz ist nicht optional: Wie auch immer die Form unserer Teams, die Systeme werden sie spiegeln; der ehrliche erste Schritt ist daher, auf die Patientenakte, die Integrationen und die Übergaben zu schauen, die wir bereits haben, und zu fragen, welche Teamgrenze jede Nahtstelle erzeugte. In Gesundheit und Pflege ist das der Ort, an dem sich klinisches Risiko verbirgt – eine fragmentierte Akte, eine brüchige Spine-Schnittstelle, ein Sicherheitsfall, den kein einzelnes Team verantwortet –, dies ist also ein Gespräch über Patientensicherheit, kein ästhetisches. Die zu debattierende Spannung ist, dass das Neuziehen von Teamgrenzen, um die gewünschte Architektur zu bekommen (das Inverse Conway Manöver), störend ist, etablierte Fürstentümer bedroht und quer zu Finanzierungs- und Linienführungsstrukturen schneidet, die wir womöglich nicht ganz kontrollieren. Bedenken Sie, zwei oder drei Ihrer schmerzhaftesten Integrationen auf die Teams zurückzuführen, die jedes Ende verantworten, und zu fragen, ob eine Grenze entlang des Wertstroms die Übergabe ganz beseitigt hätte. Eine gute Antwort benennt mindestens eine konkrete Grenze, die Sie verschieben würden, ist ehrlich, wer sich widersetzen würde und warum, und unterscheidet Änderungen, die die Störung wert sind, von solchen, bei denen eine As-a-Service-Schnittstelle die Reibung billiger beheben würde.

2. Sitzen unsere knappen Spezialistinnen – klinische Sicherheit, Informationsgovernance, Barrierefreiheit – mit echter Befugnis in Teams, oder sind sie externe Tore, hinter denen sich alle anstellen? Jeder Dienst dieser Familie trägt gesetzliche Pflichten (DCB0129/0160 klinische Sicherheit, UK GDPR und Verschwiegenheitspflicht nach Common Law, Recht der Barrierefreiheit), die sich nicht am Ende aufsetzen lassen, doch diese Fähigkeiten sind selten und teuer, was Organisationen dazu zieht, sie zentral zu horten. Der Zielkonflikt ist echt: Verankern Sie eine klinische Sicherheitsbeauftragte in jedem Team, verteilen Sie dünne Expertise, bis sie verwässert ist; zentralisieren Sie sie, schaffen Sie den heroischen Engpass, bei dem eine Person zu allem konsultiert wird und jede Freigabe wartet. Das Muster des Enabling Team – befristete Spezialistinnen, die Teams coachen, ihre eigenen Gefährdungsworkshops zu führen, und sich dann zurückziehen – ist die vorgeschlagene Lösung, funktioniert aber nur, wenn die Führung die Zeit der Spezialistinnen zum Lehren statt zum Tun schützt. Schauen Sie ehrlich auf Ihre eigene Freigabehistorie: Wie oft verzögerte sich ein Go-live, weil auf eine einzelne benannte Person gewartet wurde, und hatte diese Person die Befugnis und geschützte Zeit, sicher Nein zu sagen? Eine starke Antwort stellt sich der Knappheit direkt, nimmt für jede Pflicht eine bewusste Position zu Verankern gegenüber Befähigen ein und benennt die konkrete Befugnis (die Macht, eine Freigabe zu stoppen), die nie verwässert werden darf, wie auch immer Sie die Kapazität verteilen.

3. Woran würden wir merken, dass ein Team mehr kognitive Belastung übernommen hat, als es sicher tragen kann – und was würden wir tatsächlich dagegen tun? Kognitive Belastung ist der stille Regler sicherer Lieferung: Ein Team kann nur begrenzt viel klinische Domäne und begrenzt viele Dienste durchdenken, bevor sein Vertrauen in die Sicherheitsfolgen seiner eigenen Änderungen zu erodieren beginnt, und in der Gesundheit ist diese Erosion unsichtbar, bis ein Vorfall sie offenlegt. Die Schwierigkeit ist, dass Überlastung sich selten ankündigt – sie sieht aus wie etwas langsamere Lieferung, mehr Fehler, mehr „ich frage kurz jemanden“, und Teams unter Druck neigen dazu, sie zu absorbieren statt zu melden, besonders wenn das Teilen eines Teams politisch kostspielig oder Personal eingefroren ist. Debattieren Sie, was Ihre Frühwarnsignale wären (ein Team, das die Sicherheitsargumentation für seine eigene Freigabe nicht mehr sicher erklären kann, ist ein starkes), und ob Sie heute irgendeinen Mechanismus haben, der Überlastung sichtbar machte, bevor die Lieferung sichtbar stockt. Bedenken Sie auch den Gegendruck: Teams zu teilen erzeugt neue Grenzen und Übergaben, sodass die Heilung das Fragmentierungsrisiko aus Frage eins wieder einführen kann. Eine ehrliche Antwort einigt sich auf konkrete, beobachtbare Signale statt auf ein vages „wir würden es spüren“, benennt, wer die Befugnis hat, die Domäne eines Teams zu begrenzen oder es zu teilen, und räumt den Zielkonflikt zwischen Entlastung und Vermehrung von Grenzen ein.

4. Welche unserer gemeinsamen Fähigkeiten sollten als Plattformen betrieben und als Service konsumiert werden, und statten wir sie tatsächlich so aus – oder etikettieren wir nur eine Ticketschlange um? Das Versprechen eines Plattformteams ist, dass Stream-aligned Teams eine Integrations-Engine, einen Identitätsdienst oder eine API der gemeinsamen Patientenakte selbst bedienen, ohne ein Ticket zu erstellen und zu warten, sodass das ganze System schneller wird; das Versagen ist, etwas „Plattform“ zu nennen, während es eine unterbesetzte zentrale Funktion bleibt, hinter der sich alle weiter anstellen. Der Zielkonflikt ist real: Eine Fähigkeit als echtes internes Produkt zu bauen heißt, ihr ein eigenes Team, eine eigene Roadmap, Dokumentation und Nutzende zu geben, was eine ernste Investition ist, die mit der Auslieferung nutzerorientierter Features konkurriert, und in einem knappen NHS-Umfeld lässt sich diese Investition leicht unbegrenzt aufschieben. In Gesundheit und Pflege ist der Einsatz schärfer, weil die gemeinsamen Fähigkeiten oft die sicherheitskritischen sind – der Personenabgleichsindex, die FHIR-Schnittstellen, der Prüfpfad –, bei denen ein dünnes Plattformteam zum Single Point of Failure für jeden Dienst darauf wird. Schauen Sie auf die Fähigkeiten, von denen mehrere Teams bereits abhängen, und fragen Sie für jede, ob die Interaktion wirklich reibungsarmes X-as-a-Service oder eine verkappte Zusammenarbeit mit verborgenen Wartezeiten ist. Eine ehrliche Antwort benennt, welche Fähigkeiten jetzt gegenüber später Plattforminvestition verdienen, ist klar, wer sie finanziert und besetzt, und widersteht der Versuchung, eine Plattform auszurufen, die keine Produktverantwortliche, keine Roadmap und keinen Self-Service-Weg hat.

5. Wo verlassen wir uns auf beauftragte Lieferanten oder geliehenes Personal, und welche Rollen müssen wir im Haus behalten, um eine intelligente Auftraggeberin statt einer ausgehöhlten zu bleiben? Viel digitale Lieferung in Gesundheit und Pflege ist ausgelagert, und ein Lieferant kann Kapazität und Spezialisierung schnell bringen – doch wenn Produktverantwortung, technische Assurance und Freigabe der klinischen Sicherheit alle mit dem Vertrag das Haus verlassen, verliert die Organisation die Fähigkeit zu beurteilen, was ihr verkauft wird, zu spezifizieren, was sie braucht, oder das Ergebnis sicher zu verantworten. Die Spannung liegt zwischen Tempo und Fähigkeit: Personalaufstockung und Schlüsselfertig-Bauten bringen schnell etwas live, können aber still die hauseigene Muskulatur erodieren, die einen Lieferanten zur Rechenschaft halten lässt, und liefern oft komponentenförmige, übergabelastige Strukturen statt Stream-aligned Teams, die ein Ergebnis verantworten. In dieser Domäne gruppieren sich die unverhandelbar behaltenen Rollen um Rechenschaft, die nicht delegiert werden kann – die Senior Responsible Owner, die klinische Sicherheitsbeauftragte, die den Go-live freigibt, die Produktverantwortliche, die Prioritäten entscheidet, und genug technische Assurance, um zu prüfen, was Lieferanten bauen. Prüfen Sie Ihre aktuelle Lieferung und fragen Sie, welche Fähigkeiten Sie nicht wiederherstellen könnten, wenn ein Lieferant morgen ginge. Eine gute Antwort unterscheidet Arbeit, die sich gut beauftragen lässt, vom Kern der intelligenten Auftraggeberin, der im Haus bleiben muss, besteht darauf, dass beauftragte Teams auf Ergebnisverantwortung statt auf Personalvermittlung verpflichtet werden, und benennt die Sicherheits- und Governance-Entscheidungen, die stets bei Ihren eigenen rechenschaftspflichtigen Menschen liegen müssen.

6. Woran werden wir erkennen, dass unsere Teamstruktur tatsächlich schnellen, sicheren Wertfluss erzeugt – und was würde uns auslösen, sie neu zu ziehen? Teamdesign ist ein Mittel, kein Zweck: Der Sinn von Stream-aligned Teams, Plattformen und benannten Interaktionsmodi ist schnellere, sicherere Lieferung von Wert, doch Organisationen messen selten, ob die Struktur das leistet, sodass Reorganisationen auf Politik und Intuition statt auf Evidenz beruhen. Die Schwierigkeit ist, Signale zu wählen, die Fluss und Sicherheit widerspiegeln, ohne sie zu manipulieren – rohe Velocity oder Story-Point-Durchsatz lädt zum falschen Verhalten ein, während Flusskennzahlen (Durchlaufzeit von der Idee bis live, Deployment-Häufigkeit, Zahl der Übergaben je Änderung) und Sicherheitsindikatoren (wie schnell Gefährdungen geschlossen werden, ob Teams ihren eigenen Sicherheitsfall verantworten) mehr darüber sagen, ob Grenzen helfen oder schaden. Es besteht eine echte Spannung zur Stabilität: Ständige Reorganisation zerstört die Langlebigkeit von Teams und den gemeinsamen kognitiven Raum, die Lieferung sicher machen; Sie brauchen also eine hohe Latte und klare Auslöser, bevor Sie Grenzen neu ziehen. Besprechen Sie, welche Evidenz Ihnen sagen würde, dass eine Grenze falsch ist – anhaltende teamübergreifende Wartezeiten, ein Sicherheitsfall, den kein einzelnes Team verantwortet, eine Plattform, die niemand selbst bedient – und wer befugt ist, darauf zu handeln. Eine ehrliche Antwort verpflichtet sich auf einen kleinen Satz von Fluss- und Sicherheitssignalen, die Sie tatsächlich beobachten werden, setzt eine bewusste Schwelle, die die Teamstabilität schützt, und benennt die Auslösebedingungen und die Entscheiderin für jede künftige Umgestaltung.

In der Praxis: ein Beispiel aus Gesundheit und Pflege#

Ein Integrated Care System (ICS) führt eine gemeinsame Patientenakte über Akut-, Gemeinde-, psychiatrische Versorgung, Primärversorgung und Sozialpflege ein.

Der Instinkt ist, ein großes „Team für die gemeinsame Patientenakte“ zu schaffen. Stattdessen wendet das ICS Team Topologies an. Ein Plattformteam verantwortet den Kern der gemeinsamen Akte: den Personenabgleichsindex, die FHIR-APIs und die Integrations-Engine, als Self-Service-Fähigkeiten veröffentlicht. Mehrere Stream-aligned Teams verantworten je eine reale Nutzerreise darauf – „die Akte einer Patientin in der Notaufnahme ansehen“, „Kinderschutz-Sicht der Sozialarbeit“, „Medikationsabgleich in der Hausarztpraxis“ – und konsumieren die Plattform als Service. Ein Complicated-Subsystem Team verantwortet den probabilistischen Patientenabgleich-Algorithmus, bei dem ein falscher Treffer ein echter Sicherheitsvorfall ist. Ein Enabling Team aus Spezialistinnen für klinische Sicherheit und Barrierefreiheit rotiert durch die Stream-aligned Teams und coacht sie, ihre eigenen DCB0160-Gefährdungsworkshops zu führen, statt sie für sie zu erledigen.

Jedes Team hat eine benannte Produktmanagerin, einen Liefermanager und eine klinische Sicherheitsbeauftragte, und eine RACI stellt klar, dass der Go-live gegenüber der Senior Responsible Owner rechenschaftspflichtig ist, aber ohne Freigabe von CSO und IG nicht fortfahren kann. Wenn das Notaufnahmeteam ein neues Datenfeld braucht, ist der Interaktionsmodus ausdrücklich: X-as-a-Service vom Plattformteam über eine dokumentierte API-Anfrage, keine sechswöchige Zusammenarbeit. Die Lieferung ist schneller und, entscheidend, der Sicherheitsfall jeder Reise wird von dem Team verantwortet, das sie ausliefert.

Sektorperspektiven#

Startup#

Ein Startup der digitalen Gesundheit mit zehn Personen kann nicht vier verschiedene Teamtypen besetzen – es ist meist ein einzelnes Stream-aligned Team, in dem eine Person mehrere Hüte trägt (ein Entwickler, der auch Nutzerforschung betreibt, eine klinische Gründerin, die faktisch die klinische Sicherheitsbeauftragte ist). Die Priorität ist, das ganze Team in einem gemeinsamen kognitiven Raum zu halten, damit Entscheidungen schnell sind; eine formale RACI ist übertrieben, wenn alle im selben Raum sitzen. Das reale Risiko ist der Gründer-Engpass: Klinische Sicherheit und Informationsgovernance ruhen auf einer beschäftigten Person, und die Pflichten nach DCB0129/0160 sind leicht aufzuschieben. Wenn das Unternehmen seinen ersten NHS-Vertrag gewinnt, sollten die ersten Fachkräfte, die eingestellt werden, jene sein, die dieses Tor entschärfen – eine benannte CSO und eine IG-Leitung –, bevor die Engineering-Personalstärke skaliert wird.

Kleines Unternehmen#

Ein etablierter kleiner Anbieter – eine Hausarztpraxis, eine Gemeindeapotheke, ein Pflegeheim oder eine Einzelstandort-Klinik – hat reale Patientinnen und laufenden Betrieb, aber selten ein dediziertes Digital- oder IT-Team, sodass es keine „Team-Topologie“ zu gestalten gibt; die Praxismanagerin oder eine klinische Leitung ist neben der Tagesarbeit faktisch die gesamte Lieferfähigkeit. Der realistische Schritt ist nicht, Plattform- und Enabling Teams aufzubauen, sondern Verantwortlichkeiten ausdrücklich auf den Menschen zu benennen, die Sie bereits haben – wer ist die klinische Sicherheitsbeauftragte für die Systeme, die Sie einsetzen, wer verantwortet Informationsgovernance, wer gibt eine Änderung frei –, selbst wenn das Teilzeit-Hüte auf einer Handvoll Personal sind. Weil dieselben gesetzlichen Pflichten (DCB0129/0160, UK GDPR, Barrierefreiheit) gelten wie für einen großen Trust, ist das praktische Muster, sich auf die gemeinsamen Plattformen und die befähigende Unterstützung Ihrer Lieferanten und Ihres ICS zu stützen, statt sie neu zu erfinden, und gerade genug Fähigkeit der intelligenten Auftraggeberin zu behalten, um Lieferanten zur Rechenschaft zu halten. Das größte einzelne Risiko ist der Ein-Personen-Engpass: Wenn die einzige Person, die das klinische System versteht, geht, gehen Sicherheit und Kontinuität mit ihr; die RACI aufzuschreiben und eine zweite Person quer einzuarbeiten zählt hier daher mehr als jedes formale Teammodell.

Großunternehmen#

Ein großer NHS Trust oder ein Health-Tech-Unternehmen hat das gegenteilige Problem: zu viele Teams, entlang alter Komponenten- und Abteilungslinien gezogen, mit Übergaben überall. Hier bewährt sich ein bewusstes Teamdesign-Modell – Komponententeams zu Stream-aligned Teams umformen, Plattformteams für gemeinsame Fähigkeiten der Patientenakte und Integration einrichten und Enabling Teams nutzen, um knappe Expertise für klinische Sicherheit und Barrierefreiheit zu verbreiten. RACI und explizite Entscheidungsrechte werden unverzichtbar, weil die schiere Zahl der Stakeholder informelle Koordination unmöglich macht. Das Inverse Conway Manöver ist hier ein lebender Hebel: Ein jahrzehntealtes Organigramm prägt die Architektur bereits, sodass Führungskräfte Teamgrenzen absichtlich neu ziehen müssen, statt die Struktur die Patientenakte für sie entwerfen zu lassen.

Regierung#

Eine nationale Stelle (NHS England, DHSC) oder eine Kommunalbehörde setzt die Standards, an denen andere ihr Personal ausrichten – das Government Digital and Data Capability Framework, den Service Standard, DCB0129/0160 – und ist gegenüber Parlament und Öffentlichkeit rechenschaftspflichtig dafür, wie Geld Teamkapazität kauft. Strukturen werden hier von Beschaffungs- und Finanzierungsregeln geprägt: Viel Lieferung wird an Lieferanten vergeben; die entscheidenden im Haus zu behaltenden Rollen sind daher die der intelligenten Auftraggeberin (Produktverantwortung, technische Assurance, Freigabe der klinischen Sicherheit), die verhindern, dass Fähigkeit ausgehöhlt wird. Rechenschaft ist formal und prüfbar – eine benannte Senior Responsible Owner, veröffentlichte Ausgabenkontrollen, Transparenzpflichten –, sodass Verantwortungsmodelle eine Angelegenheit öffentlicher Aufzeichnung sind, keine optionale Hygiene. Das charakteristische Risiko ist, dass die Struktur zu dauerhaften Programmvorständen und Toren verknöchert, die den Fluss drosseln; der Gegenzug ist, Lieferanten auf Stream-aligned, ergebnisverantwortende Teams statt auf Personalaufstockung im Body-Shop-Stil zu verpflichten.

Häufige Fehlermuster#

• Die Komponententeam-Falle. Teams, nach Technologieschicht geteilt („Front-End-Team“, „Datenbankteam“), erzeugen bei jedem Feature Übergaben und verantworten kein Ergebnis. Reorganisieren Sie um Wertströme.
• Cargo-Cult-Spotify. „Squads, Tribes, Chapters, Guilds“ als Etiketten zu kopieren, ohne die zugrunde liegende Autonomie, Ausrichtung und Plattforminvestition. Das Spotify-Modell war die Momentaufnahme eines Unternehmens zu einer Zeit – selbst Spotify ist weitergezogen. Borgen Sie Prinzipien, nicht das Organigramm.
• Der heroische Engpass. Eine CSO, ein Architekt oder eine IG-Leitung als Konsultierte bei allem, sodass jedes Team wartet. Wandeln Sie sie in eine befähigende Fähigkeit um, die die Kompetenz aller hebt.
• Governance als Nachgedanke. Klinische Sicherheit und IG als externe Tore statt als eingebettete Teammitglieder vertreten, sodass ihre Anliegen zu spät eintreffen, um billig darauf zu handeln.
• Unbegrenzte Teams. Ein Team, das weiter Dienste aufsaugt, bis niemand das Ganze versteht. Kognitive Überlastung zeigt sich als langsamere Lieferung und erodierendes Sicherheitsvertrauen.
• Dauerhafte Zusammenarbeit. Zwei Teams, die unbegrenzt „zusammenarbeiten“, sind meist eine fehlende Grenze. Befristen Sie Zusammenarbeit und wechseln Sie zu einer sauberen As-a-Service-Schnittstelle.

Reifegradmodell#

Checkliste#

• Jeder Dienst hat ein Stream-aligned Team, das ihn Ende-zu-Ende verantwortet.
• Jedes Team enthält oder hat benannten Zugang zu Produkt, Lieferung, Forschung, Design, Engineering, Daten, klinischer Sicherheit und Informationsgovernance.
• Eine benannte, geschulte klinische Sicherheitsbeauftragte je Team hat geschützte Zeit und die Befugnis, eine Freigabe zu stoppen.
• Gemeinsame Fähigkeiten (Integration, Identität, APIs der Patientenakte) werden als interne Plattformen betrieben und als Service konsumiert.
• Knappe Spezialistinnen arbeiten über befristete Enabling Teams, nicht als dauerhafte Engpässe.
• Eine RACI (oder Äquivalent) existiert für klinische Freigabe, Go-live, IG-Genehmigung und Ausgaben und wird tatsächlich genutzt.
• Jede teamübergreifende Abhängigkeit hat einen benannten Interaktionsmodus (Collaboration / X-as-a-Service / Facilitating).
• Teamdomänen sind auf eine handhabbare kognitive Belastung begrenzt; überlastete Teams werden geteilt.
• Teamgrenzen sind bewusst so gewählt, dass sie die gewünschte Architektur und Interoperabilität erzeugen.

Zentrale Quellen#

• Team Topologies — Matthew Skelton & Manuel Pais (vier Teamtypen, drei Interaktionsmodi, kognitive Belastung): teamtopologies.com
• NHS Digital Service Standard und NHS Service Manual — Rollen und Arbeitsweisen multidisziplinärer Teams
• GOV.UK Service Manual (GDS) — „Set up a service team“ und Leitlinien zu agiler Lieferung
• Government Digital and Data (früher DDaT) Profession Capability Framework — Rollendefinitionen: ddat-capability-framework.service.gov.uk
• Standards des klinischen Risikomanagements DCB0129 (Herstellung) und DCB0160 (Einsatz), NHS Digital — Rolle der klinischen Sicherheitsbeauftragten
• Conways Gesetz — Melvin Conway, „How Do Committees Invent?“ (1968)
• Spotify-Engineering-Kultur (Henrik Kniberg) — Squads/Tribes/Chapters/Guilds, kritisch als Momentaufnahme gelesen

Referenzen#

1. Conway's law — Wikipedia — https://en.wikipedia.org/wiki/Conway%27s_law
2. Cognitive load — Wikipedia — https://en.wikipedia.org/wiki/Cognitive_load
3. Responsibility assignment matrix (RACI) — Wikipedia — https://en.wikipedia.org/wiki/Responsibility_assignment_matrix
4. Interdisciplinarity — Wikipedia — https://en.wikipedia.org/wiki/Interdisciplinarity
5. Sociotechnical system — Wikipedia — https://en.wikipedia.org/wiki/Sociotechnical_system
6. Fast Healthcare Interoperability Resources — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
7. Team Topologies: Organizing Business and Technology Teams for Fast Flow — Matthew Skelton & Manuel Pais — https://teamtopologies.com
8. NHS Service Manual and NHS Digital Service Standard — NHS England — https://service-manual.nhs.uk
9. Service Manual — Government Digital Service (GDS), GOV.UK — https://www.gov.uk/service-manual
10. Government Digital and Data Profession Capability Framework — GOV.UK — https://ddat-capability-framework.service.gov.uk
11. Clinical risk management standards DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety
12. "How Do Committees Invent?" (1968) — Melvin E. Conway — http://www.melconway.com/Home/Committees_Paper.html

Siehe auch Thema 7.2 — Personalplanung, Thema 7.3 — Personalstrategie, Thema 7.5 — Personal- und Organisationsentwicklung und Thema 8.1 — Veränderungsmanagement.