Er zit een bekend moment in veel softwareorganisaties: iets moet worden aangepast, een team wacht op een akkoord, en ondertussen verschuift de planning weer een dag. Niet omdat mensen tegenwerken, maar omdat de route door governance langer is dan de wijziging zelf.
Op dat punt voelt centralisatie vaak logisch. Eén plek, één beheerlaag, één set regels. Tot het werk groter wordt en teams net genoeg verschillen om die ene standaard telkens opnieuw te laten schuren. Dan ontstaat de echte vraag: wat moet centraal blijven, en wat mag juist dichter bij het team liggen?
De recente GitHub-update over managed settings voor enterprise teams is interessant omdat hij precies op dat spanningsveld landt. Niet als groot productverhaal, maar als signaal dat governance niet per se meer volume nodig heeft. Soms heeft het vooral meer precisie nodig.
De frictie zit vaak niet in techniek, maar in inrichting
In performance-teams zie je dit snel terug. Een configuratiewijziging die formeel klein is, kan informeel veel tijd kosten: afstemming in Slack, een terugkerende goedkeuringsstap, iemand die moet nagaan of een uitzondering past binnen het beleid, en dan nog een team dat wacht tot alles is afgetikt.
Van buiten lijkt dat een beheerkwestie. Van binnen is het vaak een doorstroomprobleem.
Niet elk team heeft dezelfde mate van begeleiding nodig. Niet elke instelling verdient dezelfde route. En niet elke vertraging wordt opgelost door “meer mensen op governance” te zetten. Soms is de bottleneck simpelweg dat één centraal pad te veel verschillende situaties moet dragen.
Dat is ook waarom deze GitHub-aanpassing meer is dan een kleine productupdate. Het wijst naar een ouder patroon in enterprise software: schaalbaarheid loopt zelden vast op intentie, maar wel op inrichting. Als alles via dezelfde knoop moet, wordt het beheer netjes, maar niet altijd snel.
De keuze: alles gelijk trekken of eerst één bottleneck zichtbaar maken?
Hier zit het praktische dilemma voor leiders.
De eerste logische reflex is vaak om standaardisatie verder aan te scherpen. Dat voelt controleerbaar. Alles blijft herkenbaar, iedereen volgt dezelfde weg, en centrale teams houden overzicht.
De andere route is kleiner en vaak rustiger: eerst vaststellen waar de meeste wrijving zit. Niet alle settings tegelijk, niet alle teams tegelijk, maar één concreet pad dat vaak terugkomt en merkbaar tijd opslokt.
Die tweede route vraagt minder overtuiging en levert sneller bewijs op. Je hoeft nog niet te beslissen hoe de hele organisatie eruit moet zien. Je hoeft alleen te zien waar governance nu de doorstroom vertraagt, en waar team-specifieke inrichting juist ruimte geeft.
Dat onderscheid maakt veel uit. Want als je nog niet weet of het probleem zit in teveel centrale afstemming of in te weinig lokale duidelijkheid, dan is een brede oplossing meestal te vroeg.
Eén team, één instelling, één meetpunt
De meest bruikbare eerste stap is vaak opvallend klein.
Kies één enterprise team of één terugkerende configuratiestap. Kijk vervolgens naar één meetpunt: hoeveel tijd gaat er van wijzigingsverzoek naar uitvoering? Of hoeveel keer wordt dezelfde afstemming opnieuw gevraagd voordat er beweging komt?
Dat is geen audit. Het is een klein bewijs.
Je probeert niet meteen alle governance te herontwerpen. Je probeert te zien of een specifieker ingericht pad rust oplevert. Dat kan betekenen dat een team meer autonomie krijgt binnen duidelijke grenzen. Of dat een centrale regel juist wél centraal moet blijven, omdat de variatie te klein is om te specialiseren.
In beide gevallen win je iets belangrijks: eigenaarschap.
De vraag verschuift van “wie moet hier nog akkoord op geven?” naar “wie ziet deze vertraging en kan er iets aan doen?”. Die verschuiving is vaak waardevoller dan een extra tool of een grotere beheerstructuur.
Waarom dit relevant is voor performance-teams
Performance wordt vaak besproken alsof het alleen draait om snelheid, capaciteit of optimalisatie. Maar in de praktijk raakt performance ook de manier waarop werk door de organisatie beweegt.
Als een wijziging drie stakeholders nodig heeft voordat een team verder kan, dan verlies je niet alleen tijd. Je verliest momentum. En momentum is moeilijk terug te winnen met extra inzet.
Daarom is managed settings interessant als lens. Niet omdat het om instellingen gaat, maar omdat instellingen vaak blootleggen hoe een organisatie echt werkt. Welke teams mogen zelfstandig handelen? Waar is centrale controle nodig? En waar houden we vooral historische gewoonten in stand?
Voor softwareleiders is dat een nuttige vraag, juist omdat hij concreet is. Je hoeft niet te speculeren over grote reorganisaties. Je kunt kijken naar één pad, één team, één beslissing.
Dat maakt het onderwerp minder abstract en tegelijk bestuurlijk relevanter. Want governance is pas goed genoeg als het de samenwerking niet onnodig belast.
Wat een proportionele beslissing eruitziet
Een proportionele beslissing is zelden spectaculair.
Ze ziet er eerder zo uit: één team krijgt een specifiek beheerd pad voor een bekende instelling. Eén eigenaar volgt wat dat doet met doorlooptijd. Eén centrale beheerder kijkt mee of de keuze nog binnen de kaders past. En na een paar iteraties zie je of de frictie werkelijk daalt.
Als dat gebeurt, heb je geen groot programma nodig om de waarde te begrijpen. Dan heb je al genoeg bewijs om te bepalen of verdere specialisatie zin heeft.
Als het niets oplevert, heb je ook iets geleerd. Dan zit de vertraging waarschijnlijk ergens anders: in besluitvorming, in verantwoordelijkheden, of in de manier waarop teams hun werk afstemmen. Ook dat is waardevol, omdat je dan niet per ongeluk een governance-oplossing inzet voor een samenwerkingsprobleem.
Dat is precies de blue-ocean verschuiving hier: weg van het idee dat schaal automatisch meer beheer vraagt, naar de vraag welke kleine inrichting daadwerkelijk doorstroom creëert.
De recente GitHub-update geeft dus vooral taal aan een herkenbaar patroon. Niet alles hoeft vanuit één centrale knoop te worden geregeld. Maar ook niet alles hoort meteen lokaal te worden losgelaten. De kunst is om te zien waar de eerste echte frictie zit.
Waar ik zelf op zou letten
Als ik dit in een team zie terugkomen, kijk ik eerst naar de configuratiestap die het vaakst blijft hangen. Niet naar het grootste proces, maar naar het kleinste herhaalde oponthoud.
Dat ene punt vertelt vaak genoeg om te starten.
Daarna volgt pas de beslissing: centraler maken, specialiseren of laten zoals het is. Niet op gevoel alleen, maar op een zichtbaar signaal.
Als dit herkenbaar voelt in jouw organisatie, dan is de rustige vraag niet hoe je governance groter maakt. De vraag is: welk team- of configuratiepad verdient eerst één klein bewijs van verbetering?
Daarvoor gebruiken we bij Fourlab de Pathfinder Signal-route: een compacte verkenning van één bottleneck, één eigenaar en één meetpunt, zodat je sneller ziet waar governance echt helpt en waar het alleen maar oponthoud toevoegt.