Onderwerp 7.0 — Teamstructuren, rollen en verantwoordelijkheden

In één zin: Levering in digitale gezondheid slaagt of faalt op hoe u de grenzen tussen teams trekt en hoe duidelijk u benoemt wie wat doet — structureer teams dus voor een snelle, veilige stroom van waarde, bezet ze multidisciplinair en maak verantwoordelijkheden expliciet.

Waarom dit ertoe doet in gezondheid en zorg#

De manier waarop u uw teams organiseert wordt de manier waarop uw diensten zich gedragen. De wet van Conway — dat het ontwerp van een systeem de communicatiestructuur weerspiegelt van de organisatie die het bouwde — is in gezondheid en zorg geen curiositeit; het is een risico voor patiëntveiligheid. Gefragmenteerde teams produceren gefragmenteerde zorgdossiers, brosse koppelingen en overdrachten waar klinisch risico zich verbergt.

In de NHS en de sociale zorg besteedt u ook publiek geld en draagt u wettelijke plichten: klinische veiligheid onder DCB0129/DCB0160, informatiebestuur onder de UK GDPR en de plicht tot vertrouwelijkheid uit het gewoonterecht, en verplichtingen voor toegankelijkheid. Deze plichten kunnen niet aan het eind worden aangebracht. Ze moeten binnen het team worden vertegenwoordigd, door benoemde mensen met het gezag en de tijd om ze te vervullen.

Krijg de structuur goed en multidisciplinaire teams leveren werkende software die clinici vertrouwen en patiënten kunnen gebruiken. Krijg haar fout en u krijgt drukke specialisten die hun eigen silo optimaliseren terwijl de dienst als geheel stilvalt — het klassieke patroon achter late, budgetoverschrijdende en stilletjes verlaten digitale programma’s.

Kernbegrippen#

Multidisciplinaire teams (MDT’s). Een team voor digitale levering moet elke discipline bevatten die nodig is om een dienst te ontwerpen, bouwen en runnen zonder voortdurende externe afhankelijkheid — product, levering, ontwerp, onderzoek, engineering, data en de klinische en bestuurlijke perspectieven. Dit spiegelt het klinische MDT-concept dat personeel al kent: gemengde expertise, gedeelde verantwoording voor een uitkomst.

Team Topologies. Een model (Skelton & Pais) dat effectief teamontwerp terugbrengt tot vier fundamentele typen en drie vormen van interactie, alles in dienst van een snelle stroom van waarde:

• Stroomgericht team (stream-aligned team) — georganiseerd rond één waardevolle stroom van werk (een dienst, een gebruikersreis, een product) en het van begin tot eind bezittend. Dit is het standaardtype team; de meeste mensen horen in zo’n team te zitten.
• Platformteam — levert interne zelfbedieningsmogelijkheden (gedeelde infrastructuur, een integratie-engine, een inlogdienst, een API voor een gedeeld zorgdossier) zodat stroomgerichte teams sneller gaan zonder ze opnieuw uit te vinden.
• Ondersteunend team (enabling team) — een tijdgebonden team van specialisten (bijv. klinische veiligheid, toegankelijkheid, testautomatisering) dat anderen coacht om een vermogen te verhogen en zich daarna terugtrekt.
• Team voor een ingewikkeld subsysteem (complicated-subsystem team) — bezit een deel dat diepe specialistische kennis vraagt (een algoritme voor risicoscore, een koppelvlak met de NHS Spine) en een generalistisch team zou overbelasten.

De drie vormen van interactie bepalen hoe twee teams zich tot elkaar verhouden: samenwerking (nauw samenwerken gedurende een afgebakende periode, brede bandbreedte, enige inefficiëntie tolererend om dingen te ontdekken), X-as-a-service (het ene team gebruikt het vermogen van een ander met minimaal gedoe, de standaard met weinig wrijving op schaal) en faciliteren (het ene team helpt een ander te leren). De vorm benoemen voorkomt de dubbelzinnigheid die vertraging en schuldvraag voedt.

Cognitieve belasting. Een team kan maar zoveel in zijn hoofd houden. Team Topologies betoogt dat u het domein dat elk team bezit moet beperken tot wat het veilig kan overzien — een beslissend beginsel wanneer het domein klinisch is.

De wet van Conway en de omgekeerde manoeuvre van Conway. Omdat architectuur de organisatiestructuur volgt — een blik van sociotechnisch systeem die teams en technologie als één ontwerp behandelt — moet u teams bewust vormen om de architectuur te produceren die u wilt. Als u een modulair, interoperabel zorgdossier wilt, bouw het dan niet met één monolithisch team.

Beste praktijken#

1. Stel rond elke dienst een volledig multidisciplinair team samen. Neem minimaal een productmanager, een leveringsmanager, een gebruikersonderzoeker, een service-/interactieontwerper, engineers en een vermogen voor data/analyse op, plus benoemde inbreng van klinische veiligheid en informatiebestuur. Een team dat een discipline mist zal ofwel op iemand anders wachten ofwel dat werk overslaan — en het overgeslagen werk in de gezondheid is gewoonlijk veiligheid, toegankelijkheid of bestuur.

2. Maak de meeste teams stroomgericht en geef hen eigenaarschap van begin tot eind. Organiseer rond de reis van een gebruiker (bijv. “poliklinische verwijzing”) in plaats van een laag van technologie (bijv. “het databaseteam”). Eigenaarschap van begin tot eind verkort terugkoppellussen en stopt de gaten bij overdrachten waar klinisch risico zich ophoopt.

3. Bouw platforms als producten, gebruikt als dienst. Behandel uw integratie-engine, identiteitsdienst of API voor een gedeeld zorgdossier als een intern product met een eigen team, roadmap en gebruikers. Publiceer het “as-a-service” zodat stroomgerichte teams zichzelf bedienen en niet tickets indienen en wachten.

4. Gebruik ondersteunende teams om schaarse expertise te verspreiden, niet om haar te hamsteren. Klinischeveiligheidsfunctionarissen, specialisten in toegankelijkheid en beveiligingsengineers zijn zeldzaam. Zet ze in om leveringsteams naar een hogere standaard te coachen en dan verder te gaan, in plaats van een permanent knelpunt te worden waar elk team achter in de rij staat.

5. Benoem elke rol en haar beslissingsrechten expliciet. Gebruik een model van verantwoordelijkheden — RACI (Responsible, Accountable, Consulted, Informed) of een eenvoudiger splitsing “beslisser/adviseur” — voor de beslissingen die ertoe doen: klinische goedkeuring van veiligheid, go-live, goedkeuring van informatiebestuur, uitgaven. Dubbelzinnigheid hier is waar verantwoording verdampt.

6. Geef de klinischeveiligheidsfunctionaris echt gezag en echte tijd. DCB0129/0160 vereisen een benoemde, passend getrainde klinischeveiligheidsfunctionaris (Clinical Safety Officer, CSO) die een release kan stoppen. Maak de rol expliciet in het team, bescherm haar tijd en zorg dat zij nee kan zeggen — een CSO alleen in naam is een falen van bestuur dat wacht om door een incident te worden gevonden.

7. Beheer cognitieve belasting door het domein af te bakenen. Als een team te veel diensten of een te complex klinisch domein bezit, splits het dan. Let op het signaal: een team dat de gevolgen voor veiligheid van zijn eigen wijziging niet meer zelfverzekerd kan uitleggen is overbelast.

8. Pas de omgekeerde manoeuvre van Conway bewust toe. Trek de grenzen van teams zo dat ze passen bij de architectuur en interoperabiliteit die u wilt — modulaire teams voor modulaire systemen op basis van normen (bijv. HL7 FHIR). Laat een toevallig organigram uw zorgdossier niet voor u ontwerpen.

Vragen om met uw team te bespreken#

1. Waar ontwerpt ons huidige organigram al onze architectuur voor ons — en is dat de architectuur die wij werkelijk willen? De wet van Conway is niet optioneel: welke vorm onze teams ook hebben, de systemen zullen haar uiteindelijk weerspiegelen, dus de eerlijke eerste zet is te kijken naar het zorgdossier, de koppelingen en de overdrachten die we al hebben en te vragen welke teamgrens elke naad voortbracht. In een setting van gezondheid en zorg zijn die naden waar klinisch risico zich verbergt — een gefragmenteerd dossier, een bros koppelvlak met de Spine, een veiligheidsdossier dat geen enkel team bezit — dus dit is een gesprek over patiëntveiligheid, geen esthetisch. De spanning om te debatteren is dat de grenzen van teams opnieuw trekken om de architectuur te krijgen die we willen (de omgekeerde manoeuvre van Conway) verstorend is, gevestigde domeinen bedreigt en dwars door financierings- en leidinggevende structuren snijdt die we mogelijk niet volledig beheersen. Overweeg twee of drie van uw pijnlijkste koppelingen terug te volgen naar de teams die elk uiteinde bezitten en vraag of een stroomgerichte grens de overdracht helemaal zou hebben weggenomen. Een goed antwoord noemt minstens één concrete grens die u zou verschuiven, is eerlijk over wie zich zou verzetten en waarom en onderscheidt veranderingen die de verstoring waard zijn van die waar een interface as-a-service de wrijving goedkoper zou oplossen.

2. Zitten onze schaarse specialisten — klinische veiligheid, informatiebestuur, toegankelijkheid — in teams met echt gezag, of zijn zij externe poorten waar iedereen in de rij voor staat? Elke dienst in deze familie draagt wettelijke plichten (klinische veiligheid onder DCB0129/0160, de UK GDPR en de plicht tot vertrouwelijkheid uit het gewoonterecht, wetgeving over toegankelijkheid) die niet aan het eind kunnen worden aangebracht, maar deze vermogens zijn zeldzaam en duur, wat organisaties naar centraal hamsteren trekt. De afweging is echt: neem een klinischeveiligheidsfunctionaris in elk team op en u spreidt dunne expertise tot ze verwatert; centraliseer haar en u schept het heroïsche knelpunt waarbij één persoon over alles wordt geraadpleegd en elke release wacht. Het patroon van het ondersteunende team — tijdgebonden specialisten die teams coachen om hun eigen workshops over gevaren te houden en zich dan terugtrekken — is de voorgestelde oplossing, maar werkt alleen als de leiding de tijd van de specialisten beschermt om te onderwijzen en niet te doen. Kijk eerlijk naar uw eigen geschiedenis van releases: hoe vaak liep een go-live vertraging op doordat hij wachtte op één benoemde persoon, en had die persoon het gezag en de beschermde tijd om veilig nee te zeggen? Een sterk antwoord kijkt de schaarste recht in de ogen, neemt voor elke plicht een bewuste positie in tussen inbedden en ondersteunen en noemt het specifieke gezag (de macht om een release te stoppen) dat nooit mag verwateren, hoe u de capaciteit ook spreidt.

3. Hoe zouden wij weten dat een team meer cognitieve belasting heeft opgenomen dan het veilig kan dragen — en wat zouden wij er werkelijk aan doen? Cognitieve belasting is de stille regelaar van veilige levering: een team kan maar zoveel klinisch domein en zoveel diensten overzien voordat zijn vertrouwen in de gevolgen voor veiligheid van zijn eigen wijzigingen begint af te brokkelen, en in de gezondheid is die erosie onzichtbaar tot een incident haar blootlegt. De moeilijkheid is dat overbelasting zich zelden aankondigt — zij ziet eruit als iets tragere levering, meer gebreken, vaker “laat me het even met iemand checken”, en teams onder druk absorberen haar liever dan haar te melden, vooral wanneer een team splitsen politiek duur is of de formatie bevroren. Debatteer wat uw vroege waarschuwingssignalen zouden zijn (een team dat het veiligheidsdossier van zijn eigen release niet meer zelfverzekerd kan uitleggen is een sterk signaal) en of u vandaag enig mechanisme hebt dat overbelasting aan het licht zou brengen voordat de levering zichtbaar stokt. Overweeg ook de tegendruk: teams splitsen schept nieuwe grenzen en overdrachten, dus de remedie kan het risico van fragmentatie uit vraag één terugbrengen. Een eerlijk antwoord spreekt concrete, waarneembare signalen af in plaats van een vaag “we zouden het voelen”, noemt wie het gezag heeft het domein van een team af te bakenen of te splitsen en geeft de afweging toe tussen verlichting van belasting en wildgroei aan grenzen.

4. Welke van onze gedeelde vermogens moeten als platforms worden gerund en als dienst worden gebruikt, en bemensen wij ze werkelijk zo — of geven wij slechts een nieuw etiket aan een rij tickets? De belofte van een platformteam is dat stroomgerichte teams een integratie-engine, een identiteitsdienst of een API voor een gedeeld zorgdossier zelf bedienen zonder een ticket in te dienen en te wachten, zodat het hele systeem sneller gaat; het falen is iets “platform” noemen terwijl het een onderbemande centrale functie blijft waar iedereen nog steeds in de rij voor staat. De afweging is echt: een vermogen als werkelijk intern product bouwen betekent het een eigen team, roadmap, documentatie en gebruikers geven, wat een serieuze investering is die concurreert met het opleveren van functies voor gebruikers, en in een NHS met beperkt geld is die investering gemakkelijk onbepaald uit te stellen. In gezondheid en zorg is de inzet scherper omdat de gedeelde vermogens vaak de veiligheidskritische zijn — de index voor het matchen van personen, de FHIR-koppelvlakken, het controlespoor — waar een dun platformteam een single point of failure wordt voor elke dienst erbovenop. Kijk naar de vermogens waarvan meerdere teams al afhangen en vraag voor elk of de interactie werkelijk X-as-a-service met weinig wrijving is of een verkapte samenwerking met verborgen wachttijden. Een eerlijk antwoord noemt welke vermogens nu platforminvestering verdienen en welke later, is duidelijk over wie ze financiert en bemenst en weerstaat de verleiding een platform uit te roepen dat geen productverantwoordelijke, geen roadmap en geen pad voor zelfbediening heeft.

5. Waar vertrouwen wij op leveranciers onder contract of geleend personeel, en welke rollen moeten wij intern houden om een intelligente opdrachtgever te blijven en geen uitgeholde? Veel digitale levering in gezondheid en zorg wordt uitbesteed, en een leverancier kan snel capaciteit en specialisme brengen — maar als het productbezit, de technische borging en de klinische goedkeuring van veiligheid allemaal met het contract het gebouw verlaten, verliest de organisatie het vermogen te beoordelen wat zij verkocht krijgt, te specificeren wat zij nodig heeft of het resultaat veilig te bezitten. De spanning is die tussen snelheid en vermogen: inhuur van personeel en sleutelklare bouw brengen snel iets live, maar kunnen stilletjes de interne spierkracht uithollen waarmee u een leverancier ter verantwoording roept, en leveren vaak structuren op in de vorm van onderdelen met veel overdrachten in plaats van stroomgerichte teams die een uitkomst bezitten. In dit domein clusteren de niet-delegeerbare behouden rollen rond verantwoording die niet kan worden gedelegeerd — de Senior Responsible Owner, de klinischeveiligheidsfunctionaris die de go-live goedkeurt, de productverantwoordelijke die prioriteiten bepaalt en genoeg technische borging om te inspecteren wat leveranciers bouwen. Onderzoek uw huidige levering en vraag welke vermogens u niet zou kunnen herstellen als een leverancier morgen wegliep. Een goed antwoord onderscheidt werk dat prima kan worden uitbesteed van de kern van de intelligente opdrachtgever die intern moet blijven, staat erop dat teams onder contract worden gehouden aan eigenaarschap van uitkomsten en niet aan bezetting door uitzendbureaus en noemt de beslissingen over veiligheid en bestuur die altijd bij uw eigen verantwoordelijke mensen moeten rusten.

6. Hoe weten wij dat onze teamstructuur werkelijk een snelle, veilige stroom van waarde produceert — en wat zou ons aanzetten haar opnieuw te tekenen? Teamontwerp is een middel, geen doel: het punt van stroomgerichte teams, platforms en benoemde vormen van interactie is snellere, veiligere levering van waarde, maar organisaties instrumenteren zelden of de structuur dat levert, zodat reorganisaties plaatsvinden op politiek en intuïtie in plaats van op bewijs. De moeilijkheid is signalen kiezen die stroom en veiligheid weerspiegelen zonder ze te bespelen — ruwe velocity of doorvoer in storypoints nodigt uit tot het verkeerde gedrag, terwijl stroommaten (doorlooptijd van idee tot live, frequentie van uitrol, aantal overdrachten per wijziging) en indicatoren van veiligheid (hoe snel gevaren worden gesloten, of teams hun eigen veiligheidsdossier bezitten) u meer vertellen over of grenzen helpen of schaden. Er is een echte spanning met stabiliteit: voortdurende reorganisatie vernietigt de levensduur van teams en de gedeelde cognitieve ruimte die levering veilig maken, dus u hebt een hoge lat en duidelijke triggers nodig voordat u grenzen opnieuw trekt. Bespreek welk bewijs u zou vertellen dat een grens verkeerd is — aanhoudende wachttijden tussen teams, een veiligheidsdossier dat geen enkel team bezit, een platform dat niemand zelf bedient — en wie bevoegd is erop te handelen. Een eerlijk antwoord verbindt zich aan een kleine set signalen van stroom en veiligheid die u werkelijk zult volgen, stelt een bewuste drempel in die de stabiliteit van teams beschermt en noemt de voorwaarden voor de trigger en de besluitvormer voor elke toekomstige herschikking.

In de praktijk: een voorbeeld uit gezondheid en zorg#

Een integrated care system (ICS) rolt een gedeeld zorgdossier uit over acute zorg, gemeenschapszorg, ggz, eerste lijn en sociale zorg.

Het instinct is één groot “team gedeeld zorgdossier” te creëren. In plaats daarvan past het ICS Team Topologies toe. Een platformteam bezit de kern van het gedeelde dossier: de index voor het matchen van personen, de FHIR-API’s en de integratie-engine, gepubliceerd als zelfbedieningsmogelijkheden. Verscheidene stroomgerichte teams bezitten elk een echte gebruikersreis erbovenop — “het dossier van een patiënt bekijken op de spoedeisende hulp”, “weergave van een maatschappelijk werker voor bescherming van kwetsbare personen”, “medicatieverificatie bij de huisarts” — en gebruiken het platform as-a-service. Een team voor een ingewikkeld subsysteem bezit het probabilistische algoritme voor het matchen van patiënten, waar een valse match een echt veiligheidsincident is. Een ondersteunend team van specialisten in klinische veiligheid en toegankelijkheid roteert door de stroomgerichte teams en coacht hen om hun eigen workshops over gevaren onder DCB0160 te houden in plaats van het voor hen te doen.

Elk team heeft een benoemde productmanager, leveringsmanager en klinischeveiligheidsfunctionaris, en een RACI maakt duidelijk dat de go-live verantwoording draagt bij de Senior Responsible Owner maar niet kan doorgaan zonder goedkeuring van de CSO en informatiebestuur. Wanneer het team van de spoedeisende hulp een nieuw gegevensveld nodig heeft, is de vorm van interactie expliciet: X-as-a-service van het platformteam via een gedocumenteerd API-verzoek, niet een samenwerking van zes weken. De levering is sneller en, cruciaal, het veiligheidsdossier voor elke reis wordt bezeten door het team dat haar oplevert.

Sectorperspectieven#

Startup#

Een startup in digitale gezondheid van tien mensen kan geen vier verschillende typen teams bezetten — zij is gewoonlijk één stroomgericht team waarin één persoon meerdere petten draagt (een engineer die ook gebruikersonderzoek doet, een oprichter-clinicus die de feitelijke klinischeveiligheidsfunctionaris is). De prioriteit is het hele team in één gedeelde cognitieve ruimte te houden zodat beslissingen snel zijn; een formele RACI is overdreven wanneer iedereen in dezelfde kamer zit. Het echte risico is het knelpunt van de oprichter: klinische veiligheid en informatiebestuur rusten op één drukke persoon, en verplichtingen onder DCB0129/0160 zijn gemakkelijk uit te stellen. Wanneer het bedrijf zijn eerste NHS-contract wint, moeten de eerste aanwervingen van specialisten degene zijn die die poort minder riskant maken — een benoemde CSO en een leider informatiebestuur — vóór de formatie van engineering wordt opgeschaald.

Klein bedrijf#

Een gevestigde kleine aanbieder — een huisartsenpraktijk, een gemeenschapsapotheek, een verzorgingshuis of een kliniek met één vestiging — heeft echte patiënten en lopende operaties maar zelden een toegewijd digitaal of IT-team, dus er is geen “topologie van teams” te ontwerpen; de praktijkmanager of een klinisch leider is naast het dagelijks werk feitelijk het hele leveringsvermogen. De realistische zet is niet platform- en ondersteunende teams te bouwen maar verantwoordelijkheden expliciet te benoemen bij de mensen die u al hebt — wie is de klinischeveiligheidsfunctionaris voor de systemen die u inzet, wie bezit informatiebestuur, wie keurt een wijziging goed — ook als dat deeltijdse petten zijn voor een handvol medewerkers. Omdat dezelfde wettelijke plichten (DCB0129/0160, UK GDPR, toegankelijkheid) gelden als voor een groot ziekenhuis, is het praktische patroon te leunen op de gedeelde platforms en ondersteunende hulp van uw leveranciers en uw ICS in plaats van ze opnieuw uit te vinden, terwijl u net genoeg vermogen van de intelligente opdrachtgever behoudt om leveranciers ter verantwoording te roepen. Het grootste risico is dat van de ene persoon als knelpunt: als de enige die het klinische systeem begrijpt vertrekt, lopen zowel veiligheid als continuïteit met hem mee de deur uit, dus de RACI opschrijven en een tweede persoon inwerken doet hier meer ertoe dan enig formeel model van teams.

Grote onderneming#

Een groot NHS-ziekenhuis of bedrijf in health-tech heeft het tegenovergestelde probleem: te veel teams, getrokken langs oude lijnen van onderdelen en afdelingen, met overal overdrachten. Hier verdient een bewust model van teamontwerp zijn plek — teams per onderdeel omvormen tot stroomgerichte, platformteams optuigen voor vermogens voor het gedeelde zorgdossier en integratie en ondersteunende teams gebruiken om schaarse expertise in klinische veiligheid en toegankelijkheid te verspreiden. RACI en expliciete beslissingsrechten worden essentieel omdat het aantal belanghebbenden informele coördinatie onmogelijk maakt. De omgekeerde manoeuvre van Conway is hier een levende hefboom: een organigram van tientallen jaren oud vormt de architectuur al, dus leiders moeten teamgrenzen opzettelijk opnieuw trekken in plaats van de structuur het zorgdossier voor hen te laten ontwerpen.

Overheid#

Een nationaal orgaan (NHS England, DHSC) of lokale overheid stelt de normen vast waartegen anderen bemensen — het Government Digital and Data capability framework, de Service Standard, DCB0129/0160 — en is verantwoordelijk tegenover het Parlement en het publiek voor hoe geld teamcapaciteit koopt. Structuren worden hier gevormd door regels voor inkoop en financiering: veel levering wordt uitbesteed aan leveranciers, dus de cruciale rollen om intern te houden zijn die van de intelligente opdrachtgever (productbezit, technische borging, klinische goedkeuring van veiligheid) die voorkomen dat vermogen wordt uitgehold. Verantwoording is formeel en controleerbaar — een benoemde Senior Responsible Owner, gepubliceerde uitgavebeheersing, plichten tot transparantie — dus modellen van verantwoordelijkheid zijn publiek vastgelegd en geen optionele hygiëne. Het kenmerkende risico is dat structuur verstart tot permanente programmabesturen en poorten die de stroom smoren; de tegenzet is leveranciers te houden aan stroomgerichte teams die uitkomsten bezitten in plaats van aan bezetting door uitzendbureaus.

Veelvoorkomende faalpatronen#

• De valkuil van teams per onderdeel. Teams gesplitst naar technologielaag (“front-endteam”, “databaseteam”) creëren overdrachten bij elke functie en bezitten geen uitkomst. Reorganiseer rond stromen van waarde.
• Spotify als cargocult. “Squads, tribes, chapters, guilds” als etiketten kopiëren zonder de onderliggende autonomie, afstemming en investering in platforms. Het Spotify-model was een momentopname van één bedrijf op één moment — zelfs Spotify ging verder. Leen beginselen, niet het organigram.
• Het heroïsche knelpunt. Eén CSO, één architect of één leider informatiebestuur die over alles wordt geraadpleegd, zodat elk team wacht. Zet hen om in een ondersteunend vermogen dat ieders competentie verhoogt.
• Bestuur als bijzaak. Klinische veiligheid en informatiebestuur vertegenwoordigd als externe poorten in plaats van ingebedde teamleden, zodat hun zorgen te laat komen om er goedkoop op te handelen.
• Onbegrensde teams. Een team dat diensten blijft opnemen tot niemand het geheel begrijpt. Cognitieve overbelasting toont zich als vertragende levering en verwaterend vertrouwen in veiligheid.
• Permanente samenwerking. Twee teams die onbepaald “samenwerken” is gewoonlijk een ontbrekende grens. Beperk samenwerking in de tijd en ga over op een schone interface as-a-service.

Volwassenheidsmodel#

Checklist#

• Elke dienst heeft een stroomgericht team dat haar van begin tot eind bezit.
• Elk team bevat, of heeft benoemde toegang tot, product, levering, onderzoek, ontwerp, engineering, data, klinische veiligheid en informatiebestuur.
• Een benoemde, getrainde klinischeveiligheidsfunctionaris per team heeft beschermde tijd en gezag om een release te stoppen.
• Gedeelde vermogens (integratie, identiteit, API’s voor zorgdossiers) worden gerund als interne platforms die as-a-service worden gebruikt.
• Schaarse specialisten werken via tijdgebonden ondersteunende teams, niet via permanente knelpunten.
• Een RACI (of gelijkwaardig) bestaat voor klinische goedkeuring, go-live, goedkeuring van informatiebestuur en uitgaven, en wordt werkelijk gebruikt.
• Elke afhankelijkheid tussen teams heeft een benoemde vorm van interactie (samenwerking / X-as-a-service / faciliteren).
• Domeinen van teams zijn afgebakend tot een beheersbare cognitieve belasting; overbelaste teams worden gesplitst.
• Teamgrenzen zijn bewust gekozen om de architectuur en interoperabiliteit te produceren die u wilt.

Belangrijkste bronnen#

• Team Topologies — Matthew Skelton & Manuel Pais (vier typen teams, drie vormen van interactie, cognitieve belasting): teamtopologies.com
• NHS Digital Service Standard en NHS Service Manual — rollen in multidisciplinaire teams en werkwijzen
• GOV.UK Service Manual (GDS) — “Set up a service team” en richtlijnen voor agile levering
• Government Digital and Data (voorheen DDaT) Profession Capability Framework — roldefinities: ddat-capability-framework.service.gov.uk
• Normen voor klinisch risicobeheer DCB0129 (fabricage) en DCB0160 (inzet), NHS Digital — rol van de klinischeveiligheidsfunctionaris
• De wet van Conway — Melvin Conway, “How Do Committees Invent?” (1968)
• Spotify engineering culture (Henrik Kniberg) — squads/tribes/chapters/guilds, kritisch gelezen als momentopname van een model

Referenties#

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

Zie ook Onderwerp 7.2 — Personeelsplanning, Onderwerp 7.3 — Personeelsstrategie, Onderwerp 7.5 — Mensen- en organisatieontwikkeling en Onderwerp 8.1 — Verandermanagement.