• Campagnes verslaan projecten

    Tom Critchlow maakt een onderscheid tussen fast en slow consulting. Fast consulting gaat met de stroom mee — je verduidelijkt wat er al is, je voert uit, je levert op. Slow consulting gaat tegen de stroom in. Je probeert te veranderen hoe mensen denken. En dat doe je niet met een project. Dat doe je met een campagne.

    Projecten hebben een einddatum. Je levert iets op, iedereen schudt handen, en drie maanden later doet de organisatie precies wat ze daarvoor ook deed. Eén presentatie maakt geen jaren van slecht proces ongedaan. Een nieuw systeem wordt niet gebruikt als niemand zijn gedrag verandert.

    Een campagne werkt anders. Het is dezelfde boodschap, steeds opnieuw, vanuit verschillende invalshoeken, over langere tijd. Niet omdat mensen dom zijn, maar omdat overtuigingen langzaam verschuiven.

    Er zijn een paar manieren om dat te doen. Een wekelijks bericht werkt goed — een korte email of Slack-post met een observatie, een datapunt, een relevant artikel. Niet om te overtuigen, maar om aanwezig te blijven. Tegen week acht verwachten mensen het. Tegen week twaalf beïnvloedt het hoe ze nadenken.

    Je kunt ook de buitenwereld naar binnen halen. Critchlow noemt dat “bring the outside in.” Klantgesprekken, gebruikersonderzoek, reacties op Reddit of forums — het is makkelijker om iemands mentaal model te veranderen door het te laten zien dan door het te vertellen.

    Taal helpt ook. Als je consequent dezelfde woorden gebruikt voor wat er moet veranderen, gaan anderen die woorden overnemen. Dat klinkt subtiel, maar taal vormt cultuur. Na twaalf weken hoor je je eigen zinnen terug in meetings waar je niet bij was.

    En dan is er nog iets dat Critchlow benadrukt: intern bloggen. Niet een manifest of een groot rapport, maar korte, deelbare stukken. Gepubliceerd over tijd. Het punt is niet dat elk stuk briljant is, maar dat het een constante druppel van ideeën creëert. En het moet deelbaar zijn — niet begraven in een emailthread of verloren in Slack, maar op een plek met een vaste URL die mensen kunnen doorsturen.

    Het lastige is dat dit moeilijker te verkopen is dan een project. Een project heeft een scope, een tijdlijn, een deliverable. Een campagne heeft dat niet. Maar snelle oplossingen blijven niet plakken. Als jij vertrekt en alles terugvalt naar het oude, heb je niks veranderd. Veranderen hoe mensen denken is de enige verandering die blijft.

  • Laat de kans zien

    Klanten vertellen wat ze moeten doen werkt niet. Laat ze zien wat mogelijk is.

  • Bevestig alles

    Details zijn vertrouwenssignalen. Doe ze fout en het project gebeurt nooit.

  • Meetings hebben doelen nodig, geen agenda's

    Een agenda is een lijst met onderwerpen. Een doel vertelt je wat je probeert te bereiken.

  • Bouw voor wat erna komt

    Dan belt de klant in paniek omdat je precies hebt gebouwd wat ze vroegen. Niets meer.

  • Begin met beslissingen, niet met features

    Een CRM is er niet om stakeholders te imponeren. Het is er om mensen te helpen betere keuzes te maken.

  • Advice

    Collison’s advies gaat tegen de standaard carrièrewijsheid in.

    Ga vroeg diep op meerdere dingen. De vraag “specialist of generalist?” is verkeerd gesteld. Doe beide. Word heel goed in twee of drie dingen in plaats van oké in tien. Vroege expertise compoundeert. De opties die het creëert kun je later niet meer bouwen.

    Status loopt achter op realiteit. De veilige carrièrepaden van vandaag zijn gebaseerd op de wereld van gisteren. Banking, dan consulting, dan big tech. Elke generatie denkt dat hun veilige keuze voor altijd zal duren. Dat is zelden waar.

    Bouw netwerken online. De beste kansen komen via mensen die je digitaal ontmoet, niet via lokale koffiemeetings. Remote werk heeft de geografie van opportunity veranderd. Beperk jezelf niet tot je stad.

    Vermijd treinspoor-denken. Studie, master, corporate, promotie. Het voelt veilig omdat iedereen het doet. Maar dat is precies waarom het risicovol is — je concurreert met iedereen op hetzelfde spoor.

    De interessante kansen zitten op paden waar minder mensen lopen.

  • Frank Slootman - Doing Less, Doing Better

    Slootman runt bedrijven anders. Geen consensuscultuur, geen eindeloze meetings, geen iedereen-blij-houden. Focus en executie.

    Het scherpste punt gaat over gedrag versus prestatie. Prestatie is iets waar je tijd voor geeft — iemand kan groeien in hun rol. Gedrag is een keuze. Als iemand zich misdraagt, is dat geen ontwikkelpunt. Het is een beslissing die ze maken.

    Hetzelfde geldt voor prioriteren. Niet kiezen is het ergste wat je kunt doen. Dan compromitteer je alles. Alles een beetje doen betekent niets goed doen.

    Zijn kijk op ambitie is ook interessant. Het komt voort uit een gebrek aan aanpassing. Een perfect gebalanceerd persoon zou geen ambitie hebben — waarom zou je? Je bent tevreden. Maar mensen met ambitie hebben een kloof tussen waar ze zijn en waar ze willen zijn. Die kloof drijft ze.

    En over hiring: langzamer maar beter aannemen. De kosten van een verkeerde hire zijn enorm. Niet alleen in geld, maar in tijd, energie, en teamdynamiek. Wachten op de juiste persoon is bijna altijd beter dan snel de verkeerde aannemen.

  • Nobody Codes Here Anymore

    Veel mensen speculeren over AI die coderen vervangt. Minder praten over hoe het er vandaag uitziet. Dit stuk beschrijft wat er gebeurt bij een 12 jaar oude SaaS met ongeveer 40 developers die Cursor en Claude Code gebruiken.

    Productiviteit is omhoog, misschien 20 procent, maar ongelijk verdeeld. Agents zijn geweldig voor refactors, klusjes en ideeën deblokkeren. Ze zijn zwakker bij subtiele bug fixes en schrijven geen mooie code.

    De grootste winst zit niet in snelheid maar in ambitie. Solo developers shippen nu projecten die vroeger een team kostten. En de kosten vallen mee — de zwaarste Claude-gebruikers geven amper vijftig dollar per maand uit.

    Het moeilijke deel van programmeren blijft hetzelfde: beslissen wat de software moet doen. Het omzetten van ideeën in syntax wordt alleen maar sneller.

  • Reverse Geocoding is Hard

    Je hebt coördinaten: 52.3676, 4.9041. Je wilt een adres: Amsterdam, Nederland. Simpel toch?

    Niet echt. Welk adres? Het dichtstbijzijnde gebouw? De straat? De wijk? De stad? Het land? Het hangt af van wat je gebruiker nodig heeft, en dat verschilt per context.

    Nog lastiger: grenzen zijn fuzzy. Sta je in Amsterdam of in Amstelveen? De gemeentegrens loopt soms door een parkeerplaats. Postcodes overlappen niet altijd netjes met wijken. Sommige adressen bestaan officieel niet maar worden wel gebruikt.

    De technische uitdaging is niet het algoritme. Het is beslissen wat “correct” betekent voor jouw use case. En dat is een productbeslissing, geen engineering beslissing.

    Mooie reminder dat ogenschijnlijk simpele features vaak politieke en UX-vragen verbergen die niemand vooraf bedacht had.

  • Good Product Manager/Bad Product Manager

    Horowitz schreef dit in 1996. Het is nog steeds relevant.

    Het onderscheid is simpel. Een goede product manager gedraagt zich als de CEO van het product. Niet in de zin van autoriteit, maar in de zin van eigenaarschap. Alles wat misgaat is hun probleem. Alles wat goed gaat is het team.

    Een slechte product manager heeft excuses. Engineering leverde niet. Sales beloofde dingen die niet konden. Marketing begreep de positioning niet. Altijd iemand anders.

    Het sterkste punt: goede product managers focussen op business outcomes, niet op technische specs of feature checklists. Een product met geweldige features dat niemand koopt is een mislukt product. De vraag is niet “werkt het?” maar “lost het het probleem op waarvoor we het bouwden?”

  • A practical guide to building agents

    OpenAI’s gids snijdt door de hype. Agents zijn geen magie. Het zijn loops die tools aanroepen tot een taak klaar is.

    De kern: geef een model toegang tot tools, laat het beslissen welke tool te gebruiken, voer de tool uit, geef het resultaat terug aan het model, herhaal tot klaar. Dat is een agent.

    Waar het interessant wordt is de orkestratie. Wanneer geef je de agent vrijheid en wanneer dwing je structuur af? Te veel vrijheid en het model hallucineert paden die nergens toe leiden. Te veel structuur en je had net zo goed een script kunnen schrijven.

    De praktische les: begin klein. Eén tool, één taak, duidelijke grenzen. Voeg complexiteit toe als je begrijpt waar het misgaat. De meeste agent-projecten falen niet door te weinig capabilities, maar door te veel.