POM bouwblok 3: teamtopologie die flow versnelt met heldere productgrenzen en platformteams
In de vorige blogs hebben we het fundament gelegd. Eerst de kern: waarom een Product Operating Model (POM) de brug is tussen strategie en uitvoering. Daarna het “menselijke besturingssysteem”: gedrag en productfilosofie. En vervolgens de mechaniek die productgedrag mogelijk maakt: cadence, besluitvorming en (hybride) funding.
Maar zelfs als je die twee bouwblokken goed hebt staan, kan het alsnog stroef voelen. Je hebt principes, je hebt ritme, je hebt governance die niet alles verstikt—en tóch blijft de operatie traag. Dan is de kans groot dat je tegen bouwblok 3 aanloopt: de manier waarop je teams organiseert en laat samenwerken.
Dit bouwblok is vaak het meest onderschat, omdat het al snel klinkt als “een organogram tekenen”. In de praktijk is het precies het tegenovergestelde. Organisatievorm en teamtopologie zijn geen HR-oefening; het is een productiviteitsmodel. Het bepaalt waar afhankelijkheden ontstaan, waar wachttijden groeien, en hoe vaak je ‘even moet afstemmen’—wat in grote organisaties een luxe is die ongemerkt de helft van je doorlooptijd opeet.
Teamstructuur is architectuur in menselijke vorm
Er is een bekend patroon in grote organisaties: als iets niet goed loopt, zetten we er extra coördinatie op. Een extra overleg, een extra afstemmoment, een extra stuurgroep, of “een regisseur”. Dat voelt logisch, maar het werkt vaak als pleisterwerk op een constructiefout. Want de echte vraag is niet: “hoe krijgen we meer grip?” De echte vraag is: “waarom hebben we zoveel afstemming nodig?”
Heel vaak is het antwoord: omdat teams niet zo zijn georganiseerd dat ze waarde kunnen leveren met minimale afhankelijkheden. Ze zijn ingericht op specialisme (database-team, integratie-team, rapportage-team) of op tijdelijke projecten (team wordt gevormd, levert op, valt uit elkaar). En dan is afhankelijkheid niet een uitzondering, maar het default werkmodel.
Je herkent dit direct aan de symptomen. Doorlooptijden zijn lang, maar niemand kan exact aanwijzen waar het stukloopt. Wachten is de norm: wachten op een review, wachten op toegang, wachten op een interface, wachten op “dat ene team”. Teams werken hard, maar er is weinig flow. En als er een deadline komt, wordt het dringen bij dezelfde bottleneck.
Dat is precies waarom bouwblok 3 zo belangrijk is. Het gaat over het organiseren van mensen zó dat het werk kan stromen.
Begin bij de vraag die iedereen overslaat: wat is hier een product?
De term “product” wordt in transformaties vaak te snel gebruikt. Alles krijgt ineens een productnaam: “Data Product X”, “Platform Product Y”, “Journey Z”. Maar als je doorvraagt wat het product precies is, waar het begint en eindigt, wie de gebruiker is en wie er verantwoordelijk is, wordt het vaag.
In een projectorganisatie is vaagheid soms nog te overleven: je scope is tijdelijk en je stuurt op deliverables. In een productorganisatie is vaagheid dodelijk, omdat eigenaarschap doorlopend is. Een product heeft een lifecycle: het wordt ontwikkeld, beheerd, doorontwikkeld, en is uiteindelijk verantwoordelijk voor een stuk waarde in de keten. Als je productgrenzen niet scherp zijn, ontstaan er “overlappende eigenaarschappen”: iedereen gaat er een beetje over, en niemand echt.
Een praktisch voorbeeld dat ik vaak zie bij data- en software-omgevingen: het begrip “Klant”. Het ene team gebruikt een definitie die past bij kanaalbediening, het andere bij financiële rapportage, een derde bij juridische compliance. Elk team is rationeel, maar samen ontstaat inconsistentie. Niet omdat mensen het niet snappen, maar omdat niemand expliciet eigenaar is van “Klant” als product- of platformcapability, inclusief definities, datakwaliteit en impactanalyse.
Daar komt de samenhang met blog 2 en 3 terug. Je productfilosofie (principes) helpt bepalen welke definitie leidend is. Je governance (cadence en decision rights) bepaalt wie dat besluit neemt en hoe het wordt geborgd. Maar zonder bouwblok 3—een duidelijke plek waar dat eigenaarschap woont—blijft het een discussie zonder eigenaar.
Platforms: de versneller die vaak per ongeluk een wachtrij wordt
In grote organisaties ontkom je niet aan platforms. Denk aan een data-platform, identity, integratie, developer tooling, CI/CD, observability. Het probleem is niet dat platforms bestaan; het probleem is hoe ze worden georganiseerd.
Veel platforms starten als “shared service”. Met goede bedoelingen: centraliseren, standaardiseren, risico’s beheersen. Alleen, als je platform werkt met ticketing, wachttijden en handmatige approvals, dan bouw je niet een platform—dan bouw je een bottleneck. En dan gebeurt het onvermijdelijke: teams gaan om het platform heen werken. Schaduw-IT groeit. Variatie neemt toe. Governance wordt strakker. En iedereen is verbaasd dat het nóg trager wordt.
Een platform dat productgericht werkt, doet iets anders. Het denkt in dienstverlening, self-service en herbruikbare capabilities. Het platform heeft een eigen backlog, een duidelijke roadmap en meetbare doelen: “hoeveel tijd besparen we teams?”, “hoeveel variatie reduceren we?”, “hoeveel sneller kunnen teams veilig deployen?”. Het platform maakt teams onafhankelijker, in plaats van afhankelijker.
Hier zit een mooie brug naar blog 3. Governance is niet alleen “regels”; governance is ook “enablement”. Guardrails werken pas goed als teams de tools en capabilities hebben om binnen die guardrails te bewegen. Een security-standaard zonder developer platform is een papieren werkelijkheid. Een datakwaliteitsnorm zonder geautomatiseerde checks is een wens.
Ondersteunende teams: de stille motor van schaalbaarheid
In volwassen productorganisaties zie je vaak teams die niet primair features leveren, maar teams ondersteunen in volwassenheid. Denk aan expertise op security, data governance, testautomatisering, cloud platforming, observability. Het doel is niet dat zij al het werk overnemen. Het doel is dat zij kennis verspreiden, versnellen en standaarden helpen landen.
Dit is een subtiel maar belangrijk verschil met de reflex van projectorganisaties, waar experts vaak “even komen helpen” en vervolgens weer verdwijnen. Op korte termijn voelt dat efficiënt, maar op lange termijn creëert het afhankelijkheid. Teams leren niet, bouwen geen capability op, en blijven tickets afschieten naar de experts.
In een POM-context is het een bewuste keuze: wil je capability bouwen in teams, of wil je capaciteit inkopen om problemen tijdelijk op te lossen? Beide kan, maar je moet weten welke je aan het doen bent.
Teaminteractie is minstens zo belangrijk als teamindeling
Een veelgemaakte vergissing is dat je denkt dat teamtopologie klaar is als je teams een naam hebt gegeven. In werkelijkheid bepaalt de interactie tussen teams je snelheid. Werken teams samen als tijdelijke samenwerking? Levert een platform capabilities als service? Is er een ondersteunende rol die teams helpt beter te worden?
Neem een concreet scenario: een productteam wil een nieuwe feature lanceren die data uit drie bronnen gebruikt. Als de interactie niet helder is, ontstaan er drie parallelle afstemmingen, vier interpretaties en een sprint vol wachten. Als de interactie wél helder is, ziet het er anders uit. Het platformteam levert de standaard ingestie en toegangsmechanismen self-service. Het datateam heeft eenduidige definities en kwaliteitschecks als onderdeel van de keten. Het productteam kan bouwen met duidelijke kaders en hoeft alleen af te stemmen op uitzonderingen.
Het verschil voelt alsof je “meer agile” bent geworden. In werkelijkheid heb je je organisatie zo ontworpen dat flow überhaupt mogelijk is.
De realiteit: afhankelijkheden verdwijnen niet, maar ze worden beheersbaar
Sommige afhankelijkheden zijn onvermijdelijk. Zeker in overheid en grote instellingen heb je compliance, security, privacy, architectuurkaders en legacy. Het doel is niet om afhankelijkheden uit te roeien. Het doel is om ze voorspelbaar en lichtgewicht te maken. Je wilt van “we moeten overal afstemmen” naar “we weten wanneer we moeten afstemmen, en het kost ons geen maand”.
Dat vraagt om drie dingen die mooi aansluiten op de eerdere blogs. Je hebt principes nodig om trade-offs te maken (blog 2). Je hebt cadence en decision rights nodig om het besluitvormingsritme te organiseren (blog 3). En je hebt teams en platformen nodig die zo zijn ingericht dat het werk stroomt met minimale frictie (deze blog).
Hoe je dit praktisch start zonder reorganisatie-epos
De meest werkbare start is niet “alles herindelen”, maar één keten nemen en daar productgrenzen en platformafspraken expliciet maken. Kies bijvoorbeeld één waardestroom waar afhankelijkheden voelbaar zijn. Breng in kaart waar werk wacht, wie waarop moet wachten en waarom. Vaak zie je dan dat de grootste vertraging niet in ontwikkeling zit, maar in overdracht en onduidelijk eigenaarschap.
Maak vervolgens twee afspraken die direct effect hebben. Eén: maak productgrenzen scherper, zodat eigenaarschap echt ergens landt. Twee: maak platformcapabilities self-service waar mogelijk, zodat teams minder tickets hoeven te schieten. Je hoeft niet alles in één keer perfect te maken; je moet vooral voorkomen dat je nieuwe manier van werken dezelfde oude wachtrijen blijft voeden.
Vooruitblik naar blog 5: waarom integratie alles is
Als je dit bouwblok los implementeert—teams herstructureren zonder principes of governance—dan krijg je vaak een reorganisatie met nieuwe namen en dezelfde problemen. Als je het goed integreert met de eerdere bouwblokken, krijg je iets anders: een organisatie die ritme, keuzes en eigenaarschap combineert met een teamontwerp dat flow mogelijk maakt.
In de volgende blog verbind ik die drie bouwblokken expliciet. Want het echte succes van een POM zit niet in één perfecte component, maar in het systeem dat ontstaat als gedrag, governance en organisatievorm elkaar versterken. Dat is het verschil tussen “we zijn met een transformatie bezig” en “we functioneren anders”.
