Kapers in kostuums: rebels blijven als developer in een corporate omgeving

Het begint altijd met hetzelfde gevoel. Je zit in je derde vergadering van de dag over een feature die eigenlijk in een middag te bouwen is, terwijl je laptop wacht met een half afgemaakt idee dat niemand officieel heeft goedgekeurd. Je weet dat het werkt. Je collega weet dat het werkt. Maar het staat niet op de roadmap.

Welkom in enterprise-land — waar goede ideeën soms sterven in een Confluence-pagina die niemand meer opent.

Toch zijn er developers die dit systeem weten te omzeilen. Niet door ontslag te nemen en een startup te beginnen (hoewel dat ook een optie is), maar door van binnenuit te opereren. Ze bouwen stiekem prototypes, starten interne communities en creëren ruimte voor experiment in een omgeving die dat eigenlijk niet toestaat. Wij spraken met een aantal van hen — en met een paar die liever anoniem blijven, want ja, zo werkt dat ook.

De skunk works-traditie: rebels bouwen heeft een geschiedenis

Het fenomeen is niet nieuw. Lockheed Martin had in de jaren veertig al een geheime afdeling die buiten de normale bureaucratie opereerde en vliegtuigen ontwierp die de wereld zouden veranderen. Ze noemden het 'Skunk Works', naar een fictieve destilleerderij uit een stripverhaal. De naam bleef hangen, en het concept ook.

In de techwereld kennen we vergelijkbare verhalen. Gmail begon als een 20%-project bij Google. Post-its kwamen voort uit een 'mislukt' experiment bij 3M. Maar die bedrijven hadden die cultuur min of meer ingebakken. Wat doe je als jouw werkgever dat niet heeft?

Je bouwt het zelf. Stukje bij beetje.

Wat Nederlandse developers zeggen

Bij een groot Nederlands logistiek bedrijf — laten we het gewoon 'een grote speler in de haven' noemen — werkt een team van vijf developers aan wat ze intern 'het lab' noemen. Officieel valt het onder een vage noemer als 'innovatie-exploratie', maar in de praktijk is het een vrijplaats voor experimenten met open-source tooling die de rest van het bedrijf nog niet durft aan te raken.

"We hebben gewoon een Slack-kanaal aangemaakt en mensen uitgenodigd die we vertrouwden", vertelt één van hen. "Na drie maanden hadden we een werkende tool die onze deploymenttijd halveerde. Toen pas zijn we naar management gegaan."

Dat is precies de tactiek: eerst bouwen, dan toestemming vragen. Of zoals een andere developer het verwoordt: "Het is makkelijker om vergiffenis te vragen dan toestemming te krijgen."

Een vergelijkbaar verhaal hoor je bij een grote Nederlandse bank, waar een informele groep developers begon met wekelijkse 'open-source lunches'. Geen agenda, geen notulen, gewoon mensen die praten over tools die ze thuis gebruiken en die misschien ook intern nuttig zijn. Wat begon als een informeel samenzijn, groeide uit tot een intern kennisplatform met meer dan tweehonderd actieve deelnemers.

De bureaucratie als puzzel, niet als vijand

Een veelgemaakte fout is om de corporate structuur als de tegenstander te zien. Dat is begrijpelijk, maar niet productief. De developers die het langst rebels blijven in grote organisaties, hebben geleerd om het systeem te lezen en er gebruik van te maken.

Dat betekent: weten welke budgetpotjes er zijn voor 'onderzoek en ontwikkeling'. Begrijpen welke managers ruimte willen geven maar niet weten hoe. Ontdekken welke compliance-regels er écht toe doen en welke er staan omdat ze ooit door iemand zijn opgeschreven die al lang weg is.

"Ik heb een keer zes weken besteed aan het uitzoeken hoe onze interne goedkeuringsprocessen werken", zegt een developer bij een grote Nederlandse retailer. "Niet om ze te omzeilen, maar om te begrijpen waar de ruimte zat. En die ruimte was er. Je moet alleen weten waar je moet kijken."

De open-source community heeft hier overigens veel van te leren. Het principe van 'fork first, merge later' werkt ook in organisaties. Bouw iets buiten de hoofdstroom, bewijs dat het werkt, en breng het dan in als een pull request naar de grotere organisatie.

Praktische tactieken voor de corporate piraat

Als je zelf in een grote organisatie werkt en de open-source geest levend wilt houden, zijn hier een paar benaderingen die in de praktijk blijken te werken:

Bouw je eigen 'crew' op. Zoek de mensen die ook dat gevoel hebben. Ze zijn er bijna altijd — de developer die altijd iets extra's doet, de designer die open-source projecten bijhoudt in hun vrije tijd. Vind ze, en vorm een informeel netwerk. Geen officiële naam, geen vergaderstructuur, gewoon mensen die elkaar vertrouwen.

Maak je werk zichtbaar, maar niet te vroeg. Deel wat je bouwt op het moment dat het iets te laten zien heeft. Een werkende demo overtuigt meer dan een tien pagina's tellend voorstel. Maar wacht ook niet zo lang dat iemand anders met het idee komt.

Gebruik de taal van de organisatie. Rebels zijn is prima, maar als je 'kostenreductie' zegt in plaats van 'efficiency', en 'risicomitigatie' in plaats van 'dit gaat mis als we het niet fixen', dan kom je verder. Het is geen verraad aan je principes. Het is vertalen.

Documenteer alles. Ironisch genoeg is dit een van de sterkste wapens van de interne rebel. Als jij de enige bent die bijhoudt wat jullie hebben gebouwd, waarom, en wat het heeft opgeleverd, dan ben jij degene die het verhaal vertelt. En wie het verhaal vertelt, bepaalt hoe het wordt onthouden.

Weet wanneer je moet loslaten. Soms werkt het niet. Soms is een organisatie echt te ver heen, of te bang, of te traag. Het herkennen van dat moment — en dan een keuze maken, of je blijft of vertrekt — is ook onderdeel van de rebellie.

De prijs van rebels zijn

Laten we eerlijk zijn: er zijn risico's. Niet iedereen die buiten de lijntjes kleurt, wordt omarmd. Sommige developers die we spraken, hebben ook negatieve ervaringen gehad. Projecten die werden stopgezet. Ideeën die werden ingepikt zonder credits. Een beoordelingsgesprek dat opeens een stuk minder positief was dan verwacht.

De kunst is om rebels te zijn op een manier die je ook op de lange termijn kunt volhouden. Dat betekent: weten welke gevechten de moeite waard zijn. Je politieke kapitaal niet verspillen aan iets wat uiteindelijk niet uitmaakt. En altijd, altijd zorgen dat je werk zichzelf verdedigt.

De beste interne rebellen zijn niet degenen die het hardst schreeuwen. Het zijn degenen die consequent goede dingen bouwen, mensen om zich heen verzamelen en langzaam maar zeker de cultuur verschuiven — één pull request tegelijk.

Waarom dit ertoe doet

Het gaat hier niet alleen om persoonlijk avontuur of de kick van het omzeilen van regels. Grote organisaties hebben intern rebels nodig. Zonder wrijving geen warmte, zonder experiment geen innovatie. De bedrijven die dat begrijpen — en developers de ruimte geven om te spelen — zijn uiteindelijk de bedrijven die overleven in een markt die sneller verandert dan welke roadmap dan ook kan bijhouden.

En voor de developers zelf? Het gaat om het levend houden van iets wat hen ooit naar dit werk heeft getrokken. De nieuwsgierigheid. Het plezier van iets bouwen dat werkt. De community-geest die open source zo krachtig maakt.

Je hoeft geen garage te hebben om een piraat te zijn. Soms is een vergaderzaaltje op de derde verdieping genoeg.