Ik kijk zes maanden terug en ik kan me nu al nauwelijks herinneren hoe we een jaar geleden werkten. Niet uit nostalgie, uit pure verbazing. Zoals wanneer je terugkeert naar een huis waar je ooit woonde en de kamers niet meer herkent.
Het begon als een experiment zonder naam. Vandaag heeft het er nog steeds geen, maar het heeft wel een herkenbare vorm. Bij Dcycle draagt het hele bedrijf bij aan de codebase van het product. Niet alleen de engineers. Customer Success zet automatiseringen in. Marketing bouwt eigen datastromen. Ops stelt dashboards samen die voorheen drie vergaderingen en een ticket vereisten. Niemand hoeft het hen expliciet te vragen. De tools maken het mogelijk en nieuwsgierigheid doet de rest.
Wat er tijdens dat experiment gebeurde, is dat snelheid de cultuur veranderde. Niet andersom. Het was niet zo dat we eerst een autonomiemanifest ontwierpen en dat mensen toen begonnen te bouwen. Het was dat iemand van CS het zat was om twee cycli te wachten om een probleem op te lossen dat hij goed kende, Claude Code opende en het oploste. Toen het team het resultaat zag, vroeg niemand of dat "zijn rol" was. Ze vroegen hoe het moest.
We hadden het autonomiegen al in ons, maar de tools hebben het laten exploderen.
Wat wel een bewuste keuze is, is het in stand houden. Ik hoop dat elke persoon in dit team de reflex heeft om op te lossen voordat hij delegeert. Als je een probleem ziet en je kunt het oplossen, los het op. Je hebt al toestemming. Als je het niet kunt, leer dan genoeg om het de volgende keer wel te kunnen. Zoek een manier om te leren; als je die niet vindt, vraag om hulp. Je zult altijd een helpende hand in de buurt vinden.
Je titel beschrijft niet meer wat je doet
Er is iets wat niet genoeg wordt gezegd over wat er gebeurt als iedereen oplossingen kan bouwen: je titel houdt op met uitsluitend beschrijven wat je doet.
Marina zit nog steeds bij Customer Success. Maar vorige week heeft ze een bot uitgerold die gebruiksdata kruist met churnsignalen en Slack-alerts genereert met aanbevolen acties. Juan zit nog steeds bij Finance, maar hij heeft een financieel afstemmingssysteem gebouwd dat ons voorheen twee dagen kostte en nu tien minuten duurt. Ze zijn niet gestopt met hun werk. Het is dat hun werk nu ook het ontwerpen van de machines omvat die een deel van hun werk doen.
Ik weet dat dit kan klinken als een LinkedIn-ondernemer. Maar het beleven heeft een heel andere smaak dan het lezen. Het beleven voelt meer als een productieve desoriëntatie: het gevoel dat wat je kon niet meer genoeg is, maar dat wat je kunt meer is dan ooit. Ik kan erover meepraten.
Managers van jezelf en van velen
We noemen het "managers van jezelf en van velen" en ik weet dat het vreemd klinkt. Maar het vangt iets reeëls.
Elke persoon bij Dcycle beheert zijn eigen werk. Dat is het "van jezelf". Ze hebben de autonomie om te beslissen wat ze bouwen, hoe ze iets oplossen of wanneer ze itereren. Ze wachten niet op goedkeuring om iets te verbeteren. De neiging is naar actie.
En elke persoon orkestreert ook agents. Dat is het "van velen". Niet op een sciencefictionmanier. Op een praktische manier: ze ontwerpen prompts, definiëren flows, breken dingen en repareren ze, bewaken outputs, corrigeren fouten. Ze hebben een team van agents dat hun capaciteit versterkt. We zijn gegaan van "doen" naar "ontwerpen hoe het gedaan wordt" en daarna verifiëren dat het goed is gedaan.
De "Agent Manager" is geen nieuwe functietitel (als je het ergens ziet, wees wantrouwig, het is de nieuwe 'Director of Innovation'). Het is een nieuwe competentielaag die onder al het andere zit. Het maakt niet uit of je bij CS, product of sales zit. Als je niet weet hoe je agents moet orkestreren, gebruik je twintig procent van je capaciteit en bereik je tien procent van wat je zou kunnen.
Dit is niet optioneel. Ik verwacht dat iedereen tijd besteedt aan het leren werken met agents. Het is het verschil tussen iemand die taken uitvoert en iemand die systemen ontwerpt. En hier, nu, zoeken we dat laatste.
Silo's zijn voorbij
En hier is het gevolg dat ik het minst zag aankomen: functionele silo's zijn voorbij. Niet omdat we een workshop cross-functionele samenwerking organiseren. Niet omdat we een gedeelde OKR hebben. Ze lossen op omdat je, als je meer dingen kunt doen, onvermijdelijk meer terrein raakt.
De afhankelijkheid tussen teams was de lijm die silo's op hun plek hield. Door de afhankelijkheid te elimineren, verliezen silo's hun bestaansrecht. Wat overblijft zijn mensen die steeds meer weten over alles en die zich tussen problemen bewegen in plaats van tussen afdelingen.
Er is geen innovatiecommissie. Er is geen lab dat losstaat van de rest. Wat er is, is een sneeuwbal die elke persoon in een andere richting duwt, en het resultaat is iets dat geen van ons alleen had kunnen ontwerpen. De grens wordt niet gepland. Die wordt ontdekt, elke dag, wanneer iemand een grens overschrijdt waarvan niemand hem had verteld dat hij die mocht overschrijden.
Lees die zin nog eens
Vorige week loste onze Talent Manager een bug op in productie. Hij heeft niet het verkeerde beroep gekozen. Hij zag iets dat kapot was, leerde genoeg om het te begrijpen, en loste het op. Binnenkort zal een developer gaan luisteren naar opnames van prospectiegesprekken, uit een prospectiecadans die een SDR van begin tot eind zal hebben ontworpen, maar die hij niet alleen uitvoert. De SDR ontwerpt de strategie, de agents voeren die uit, en de developer wil nog steeds begrijpen wat klanten zeggen om te verbeteren wat hij aan het bouwen is.
Een SDR die ontwerpt maar niet uitvoert. Een developer die verkoopgesprekken beluistert. Een Talent Manager die code pusht. Als je het bekijkt vanuit de logica van het organogram, is het een ramp. Als je het bekijkt vanuit de logica van resultaten, zijn we efficiënter dan ooit.
Dit is wat er gebeurt als je stopt met het beschermen van de grenzen tussen rollen en begint met het beschermen van nieuwsgierigheid. De sneeuwbal groeit in alle richtingen. En de grens is niet vooruit. Die is overal.
De spanningen
Ik wil dit niet afschilderen als een Eden. Het heeft zijn spanningen.
De meest voor de hand liggende: als iedereen kan bouwen, wie beslist dan wat er gebouwd wordt? Autonomie zonder afstemming is chaos. Het antwoord is niet minder autonomie maar meer zichtbaarheid. Daarom verwacht ik iets heel specifieks: deel wat je aan het bouwen bent, voordat je het bouwt. Denk hardop. Publiceer voordat je perfectioneert. Transparantie is geen extraatje. Het is wat autonomie laat werken zonder dat het anarchie wordt.
Er is een stille valkuil in bouwcapaciteit: het is heel makkelijk om output te verwarren met outcome. Iets bouwen dat werkt is niet hetzelfde als iets oplossen dat ertoe doet.
Voordat je Claude Code opent, voordat je de flow ontwerpt, is er een vraag waarvan ik hoop dat ieder van jullie die stelt: wat moet er anders zijn als dit klaar is? Niet "wat ga ik bouwen", maar "wat moet er veranderd zijn". De output is het middel; de outcome is het doel.
Dit vertraagt de actie niet: het richt haar. Een builder die precies weet wat hij probeert te veranderen, bouwt sneller, niet langzamer, omdat elke beslissing een helder kompas heeft.
De tweede spanning: professionele identiteit. Als je niet meer "alleen marketing" of "alleen ops" bent, wat ben je dan? Dat creëert ongemak. Er zijn mensen die zekerheid vonden in specialisatie en die nu de grond voelen bewegen. Ik begrijp het. Maar ik hoop dat jullie dat ongemak omarmen in plaats van ervoor te vluchten. Want wat je bent, is een builder die veel weet van marketing. Een learner die ops beheerst. Je expertise verdwijnt niet. Die wordt je perspectief, niet je perimeter. De perimeter uitbreiden is een teken van een goede richting.
60 mensen, 100x meer capaciteit
We zijn dezelfde zestig mensen. Maar de output van dit bedrijf zal onherkenbaar zijn vergeleken met een jaar geleden. Niet omdat we meer uren werken. We werken, en zullen werken, hetzelfde aantal uren. Het is dat elke persoon met een team van agents achter zich dat alles versterkt wat ze doet, haar actieradius met 100 vermenigvuldigt. Wat voorheen twee mensen en een week kostte, kan nu één persoon in een middag oplossen. Niet altijd. Maar steeds vaker.
Dit heeft enorme implicaties voor hoe we over groei nadenken. De vraag is niet meer "hoeveel mensen moeten we aannemen" maar "hoeveel kunnen we de capaciteit versterken van degenen die we al hebben". Het is geen argument tegen aannemen. Het is een argument om anders aan te nemen: mensen die kunnen orkestreren, die snel leren, die zich op hun gemak voelen in de ambiguïteit van een rol die elk kwartaal verandert. En ik verwacht hetzelfde van degenen die er al zijn: dat jullie elke maand in staat zijn meer te doen dan de maand daarvoor. Niet meer uren. Meer capaciteit.
Builders en learners
Zo beschrijven we wat we zoeken en hoe we werk benaderen.
Builder omdat je bouwt. Je denkt niet alleen, je plant niet alleen, je maakt niet alleen strategieën (laat staan PowerPoints). Je brengt dingen in de wereld. Code, automatiseringen, documenten, systemen. Dingen die werken, die een output hebben, die iemand morgen kan gebruiken. Ik verwacht dat elke week, elke persoon in dit team iets in de wereld heeft gebracht dat op maandag nog niet bestond.
Learner omdat wat je vandaag weet niet genoeg is voor morgen. Zes maanden geleden wist niemand in dit team hoe agents te orkestreren. Drie maanden geleden deden sommigen het met moeite. Vandaag wordt het de standaard. De snelheid waarmee tools veranderen, de drempel van het mogelijke, vereist een gelijkwaardige leersnelheid. Wacht niet tot iemand je komt opleiden. Ga leren. Het is makkelijker dan ooit. Wie stopt met leren, stopt. Ik verwacht onvermoeibare nieuwsgierigheid. Ik verwacht dat jullie dingen kapotmaken door te proberen. Ik verwacht vragen voor zekerheden. Als je iets nieuws hebt geleerd, deel het, binnen en buiten Dcycle.
Het zijn geen twee verschillende dingen. Het is hetzelfde: je bouwt om te leren en je leert om te bouwen.
Mijn deel
Alles hierboven is wat ik van jullie verwacht. Nu mijn deel.
Als ik jullie vraag te bouwen, verplicht ik mezelf om obstakels uit de weg te ruimen. Elk proces dat niets toevoegt, elke goedkeuring die alleen uit traagheid bestaat, elke vergadering die een bericht had kunnen zijn: het is mijn verantwoordelijkheid om het te elimineren. Wijs erop als je het ziet. Jullie energie moet naar bouwen gaan, niet naar het navigeren van bureaucratie.
Als ik jullie vraag dingen kapot te maken door te proberen, verplicht ik mezelf ervoor te zorgen dat dingen kapotmaken geen gevolgen heeft. Fouten te goeder trouw worden hier niet bestraft. Ze worden geanalyseerd, we leren ervan, en we gaan verder. De enige onvergeeflijke fout is het niet proberen. Als jullie ooit het gevoel hebben dat een fout maken politieke kosten heeft, vertel het me. Want dat zal betekenen dat er iets in de cultuur kapot is gegaan, en het repareren daarvan zal mijn prioriteit nummer één zijn.
En als ik jullie vraag om constant te leren, verplicht ik mezelf om met jullie te leren. Niet vanuit een kantoor. Vanuit dezelfde loopgraven. Als ik stop met bouwen, met dingen kapotmaken, met ongemakkelijke vragen stellen, hebben jullie het recht mij daarop aan te spreken. Dit pact werkt in beide richtingen of het werkt niet.
Het meest transformatieve van alles
Ik weet niet of we over een jaar nog precies zo zullen werken. Waarschijnlijk niet. We zullen waarschijnlijk problemen hebben ontdekt die we nu niet zien, en oplossingen hebben uitgevonden die we ons nu niet kunnen voorstellen.
En dat, geloof ik, is het meest transformatieve van alles. Niet de technologie. Niet de agents. Niet de code. Het is de mentaliteit van iemand die stopt met wachten en begint met oplossen. Van iemand die een probleem ziet en, in plaats van te escaleren, bouwt. Dat is wat ik verwacht van elke persoon in dit bedrijf. Niet meer, niet minder.
Zo werken we bij Dcycle. Builders. Learners. Managers van jezelf en van velen. En de weg blijft zich vormen al wandelend.
J.