Wanneer HR-leiders bouwers worden
Inzicht uit het experiment: Samenwerkingsprojecten rond AI leverden diepgaande inzichten op in HR-capaciteiten die verder gaan dan alleen de ontwikkeling van hulpmiddelen.
Focus op het probleem: De overstap van sentimentanalyse naar het in kaart brengen van vaardigheden benadrukte hoe belangrijk het is om duidelijke, haalbare doelen te definiëren.
Scepsis over AI: HR-professionals staan voor aanzienlijke uitdagingen op het gebied van verantwoording en transparantie in bestaande AI-platforms.
Structuur van het hulpmiddel: Het AI-beoordelingshulpmiddel legde de nadruk op samenwerking, waardoor gebruikers door AI gegenereerde feedback konden bevestigen of ter discussie stellen.
Adversariële tests: Voor een succesvolle ontwikkeling van hulpmiddelen zijn grondige tests met uiteenlopende invoer nodig om uitzonderingssituaties effectief aan te pakken.
De vergaderingen waren gepland voor een uur. Ze duurden bijna altijd langer.
Dat is niet ongebruikelijk wanneer je een groep HR-professionals bij elkaar brengt om over AI te praten. Wat wel ongebruikelijk was, was wat er van hen werd gevraagd met dat gesprek te doen. Niet het analyseren ervan, niet het publiceren van een opiniestuk erover, maar daadwerkelijk iets bouwen.
In het najaar van 2025 stelde ik samen wat ik bouwersgroepen noemde: een kleine groep professionals op het gebied van HR en personeelszaken die ik had geïdentificeerd als mensen die het werk al deden en al nadachten over de grenzen van wat het HR-vak met AI zou kunnen doen.
Create a Free Account to Keep Reading—and Keep Leading Smarter
Unlock this piece and join a community of forward-thinking leaders discovering tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
De hypothese was eenvoudig. De mensen die het dichtst bij de problemen staan, zijn het best gepositioneerd om de oplossingen te bouwen. De vraag was of ze dat konden.
In totaal zou ik vier groepen samenstellen en gaandeweg beseffen dat het definiëren van doelen voor deze sessies gemakkelijker gezegd dan gedaan is. Uiteindelijk doofden de meeste groepen uit, omdat ze moeite hadden om de oorspronkelijke visie te realiseren of zich op één doelstelling vast te leggen. Agenda's, werkdruk en de eisen van onze daadwerkelijke banen leidden er vaak toe dat gesprekken geweldige ideeën opleverden, zonder dat die ooit werkelijkheid werden.
Maar één groep kwam wel samen en wist zo goed mogelijk de eindstreep te halen. Feit is dat hoe dieper je in het konijnenhol van zelf iets bouwen duikt, hoe moeilijker het wordt om een gedeelde visie te respecteren en de technische uitdaging aan te gaan.
Dit verhaal beschrijft wat er uit die sessies voortkwam en ik bied het je aan als een casestudy voor het bouwen van je eigen oplossingen.
De groep
Dit waren geen AI-sceptici die nog overtuigd moesten worden. Het waren professionals die al op dit moment hadden ingezet. Wat de groep hun bood, was een gestructureerde ruimte om te stoppen met adviseren en te beginnen met maken.
Het eerste eerlijke gesprek
De eerste sessie bracht iets aan het licht wat zelden in gepubliceerde HR-commentaren terechtkomt: hoe gefrustreerd deze professionals daadwerkelijk zijn over de tools die ze geacht worden te gebruiken.
Turnmeyer zette de toon. Ze had geprobeerd technische documentatie te krijgen over de werking van sentimentanalyse binnen BambooHR, Paycom en Gusto—niet om de tools af te wijzen, maar omdat haar juridische team ze moest begrijpen voordat het het gebruik ervan kon goedkeuren.
Niet de verkoopteams en niet de juridische vertegenwoordigers konden haar vragen beantwoorden. De AI-functies bestonden. De verantwoordelijkheid voor de manier waarop ze werkten niet.
Gillies navigeerde door een vergelijkbare spanning. Interne stemmen hadden zorgen geuit over de ecologische impact van AI en sommige collega's wilden het AI-gebruik door werknemers eenvoudigweg verbieden. Gillies verzette zich daartegen.
AI volledig verbieden leidt tot heimelijk gebruik en een groter risico. AI omarmen met beschermende maatregelen is een betere aanpak.
Melina Gillies · Hoofd Personeelszaken, Flex Networks
Wat uit dat eerste uur naar voren kwam, was een diagnose waar de groep zich in kon vinden. De ingebouwde AI-functies van HR-platforms voor ondernemingen waren, zoals Gillies het verwoordde, "vaak basaal en missen functionaliteit."
De tools die daadwerkelijk werken, zijn doorgaans maatwerk—gebouwd voor specifieke problemen, specifieke contexten en specifieke bedrijven. Turnmeyer wilde minder tools, niet meer, een geluid dat ik vaak hoor van leiders op het gebied van personeel en bedrijfsvoering. Ze kon zich een toekomst voorstellen waarin een capabele AI, gevoed met de juiste documenten, een HRIS overbodig zou maken.
Ze werden ook geconfronteerd met iets dat zelden zo rechtstreeks wordt besproken: de ethiek van gedragsmonitoring. Het idee om afwijzingspercentages van vergaderingen, hiaten in systeemaanmeldingen of ongebruikelijke werktijden te gebruiken als aanwijzingen voor verminderde betrokkenheid kwam al vroeg ter sprake.
Ook de beperkingen van die aanpak kwamen aan bod. Satterfield benoemde een risico waar elke tool voor betrokkenheid uiteindelijk mee te maken krijgt: actiemoeheid. Als je gegevens verzamelt en er niet zichtbaar naar handelt, verliezen medewerkers hun vertrouwen in het systeem. De gegevens worden ruis en de tool wordt AI-theater.
Ze waren nog niet klaar om een tool voor sentimentanalyse te bouwen. Het idee was te breed, te beladen met ethische dilemma's en te gemakkelijk catastrofaal verkeerd toe te passen. Dus gooiden ze het roer om.
Het juiste probleem vinden
De tweede sessie begon met de eerlijke erkenning dat de oorspronkelijke richting te ambitieus en te onduidelijk was.
"Ik weet niet of dit betrokkenheid meet," zei Turnmeyer, "of dat het gewoon iets meet waarvoor een gesprek nodig is."
Dat onderscheid is belangrijker dan het misschien klinkt. Veel HR-technologie maakt de fout gegevens te behandelen als vervanging voor een gesprek. De groep probeerde AI te gebruiken om de momenten aan het licht te brengen waarop een gesprek moet plaatsvinden, en dat gesprek vervolgens beter te maken.
Satterfield introduceerde het idee dat de rest van het project zou verankeren. Tijdens een personeelsstop bij een vorige werkgever had ze een zelfbeoordeling van vaardigheden ontwikkeld voor haar team voor talentwerving—een manier om in kaart te brengen wat mensen konden doen tegenover wat ze daadwerkelijk wilden doen, waarbij een warmtekaart werd gegenereerd die beslissingen over herplaatsing menselijker en strategischer maakte.
Het werd niet aangedreven door AI. Het was een Microsoft Formulier. Maar de onderliggende logica was solide, de toepassing was reëel en ze had gezien dat het werkte.
"Grote leveranciers proberen dit te doen, maar niemand doet het nog echt goed en veel bedrijven hebben geen budget gereserveerd voor dit soort technologie naast hun kern-HRIS," zei ze.
De groep zag een kans. Wat als ze een versie bouwden die van meet af aan rond AI was opgebouwd? Een versie die conversationeel was in plaats van klinisch, toekomstgericht in plaats van compliancegedreven en geprijsd voor individuele HR-leiders in plaats van opgesloten achter bedrijfscontracten?
De manier waarop HR met HR over HR praat, is wezenlijk anders. Dat kan echte waarde bieden en de meeste tools missen dat volledig.
Melina Gillies · Hoofd Personeelszaken, Flex Networks
Fisher, die luisterde terwijl de groep de mogelijkheden verkende, deed een observatie die het potentieel van het project in een ander licht plaatste. Hij had beide uiteinden van het HR-spectrum ervaren: het compliancegerichte, raamwerkgerichte, transactionele type en de zeldzamere mensgerichte professional die met hem praatte "als een persoon die het gevoel gaf dat hij aan mijn kant stond."
"De taal van het tweede type," zei hij, "voelde nooit alsof die uit een raamwerk kwam dat tientallen jaren geleden was geschreven. Het voelde gewoon goed."
Gillies haakte daarop in. Het onderscheidende element van hun tool, betoogde ze, was toon en structuur. Wat als de tool de manier kon nabootsen waarop HR-professionals daadwerkelijk met elkaar praten op een conferentie, tussen sessies door, vertrouwelijk? Wat als hij "politiek inzichtelijk" niet zou begrijpen als een selectievakje, maar als iets beladens, omstredens en situationeel complex waar ervaren professionals onderling over discussiëren?
Dat was de richting: een beoordelingsinstrument vóór indiensttreding, ontworpen voor HR- en talentwervingsleiders die een betere manier nodig hebben om kandidaten voor recruiters te beoordelen voordat ze hen aannemen. Geen persoonlijkheidsquiz of cv-screening, maar een gestructureerde, conversationele diagnose die een aanstellende manager kon vertellen of de persoon tegenover hem of haar daadwerkelijk wist hoe het werk moest worden gedaan. Een instrument dat minder aanvoelde als een prestatiebeoordeling en meer als een gesprek met iemand die werving van binnenuit begreep.
Het moment waarop het kwartje viel
Tegen de derde sessie was de groep diep in de architectuur van de tool gedoken: welke competenties moesten worden beoordeeld, hoe ze over niveaus heen moesten worden gestructureerd en hoe rekening moest worden gehouden met de kloof tussen wat mensen zeggen dat ze kunnen en wat ze daadwerkelijk kunnen.
De kritiek op bestaande raamwerken kwam van Gillies, die het competentiemodel van SHRM omschreef als "op sommige vlakken zeer traditioneel en sterk op het verleden gericht." Het vakgebied bevond zich nog steeds, in haar woorden, in een "postindustriële kater"—compliancegericht, hiërarchisch en ontworpen voor een wereld die al aan het verdwijnen was.
Hun tool moest zich op iets anders richten: niet op wat HR-leiders moesten weten, maar op wat zij moesten kunnen doen.
Ben je bereid om met de CEO over zijn functioneren te praten? Als je dat niet bent, ben je geen expert in moeilijke gesprekken.
Erin Turnmeyer · VP People Operations
Turnmeyer had een verhelderend voorbeeld. Ze had onlangs het SPHR-examen afgelegd. De dingen die ze daarvoor moest kennen—statuten, procedurele definities, classificatieregels—waren zaken die iedere bekwame HR-professional gewoon zou opzoeken.
De harde vaardigheden waren niet de examenstof. Het ging om dingen als: Kun je tegenover een CEO zitten en hem iets vertellen wat hij niet wil horen? Kun je voor een medewerker opkomen wanneer de zakelijke onderbouwing niet eenduidig is? Het uit het hoofd leren van arbeidswetgeving geeft geen antwoord op die vragen.
Fisher ging nog verder. Hij had jarenlang in verandermanagement gewerkt en had ontdekt dat de meest voorspellende variabele voor het vermogen van een organisatie om een transformatie te doorlopen geen specifieke vaardigheid was. Het ging om iemands verhouding tot ambiguïteit.
Als je te weten komt hoe comfortabel iemand zich voelt bij ongemak—of bij het tempo van verandering in het algemeen—is dat zo'n goede indicator van je vermogen om in deze nieuwe wereld te functioneren.
Tim Fisher · Hoofd AI, Black and White Zebra
Toen kwam wat de groep later het geheime ingrediënt zou noemen.
Gillies wierp een vraag op. Wat als de tool een kruiscontrole inbouwde? Als iemand zichzelf als expert in conflictbeheersing beoordeelde, maar vervolgens in een antwoord in natuurlijke taal op een vervolgvraag situaties beschreef die allesbehalve deskundigheid lieten zien, zou de AI dat dan kunnen signaleren? Zou de AI voorzichtig kunnen aangeven dat hier misschien een kloof zit?
"Dat is het eureka-moment", zei Turnmeyer.
Satterfield merkte op dat iedereen die met vaardigheidsinventarissen heeft gewerkt, varianten van hetzelfde probleem heeft gezien. Mensen beoordelen zichzelf vaak heel anders dan hun daadwerkelijke ervaring of gedrag zou doen vermoeden.
De waarde van de tool zou niet voortkomen uit het vastleggen van wat mensen over zichzelf geloofden. Die zou voortkomen uit de kalibratie—de voorzichtige, datagestuurde wrijving tussen zelfbeeld en aangetoonde bekwaamheid.
De beoordeling zou niet alleen een spiegel zijn. Ze zou meer “spiegeltje, spiegeltje aan de wand” zijn dan de meeste mensen gewend zijn van werkplekbeoordelingen.
De realiteit van het bouwen
Niets hiervan was eenvoudig. En de deelnemers wisten dat voordat ze eraan begonnen.
De meest hardnekkige uitdaging was niet technisch. Het was de reikwijdte. Elke sessie leverde tien nieuwe richtingen op, elk oprecht waardevol en elk in staat om het project volledig op te slokken. Turnmeyer benoemde dit al vroeg en bleef het herhalen.
"Zorg ervoor dat het eerste onderdeel goed werkt, zodat de reikwijdte niet zo uit de hand loopt dat je het niet meer kunt maken", zei ze.
Satterfield introduceerde een leidend principe voor de groep: het verschil tussen een minimaal levensvatbaar product en een minimaal waardevol product. Een levensvatbaar product werkt. Een waardevol product zorgt ervoor dat mensen willen terugkomen.
In een markt die wordt overspoeld door beoordelingsinstrumenten, krijgt een interface die bij de eerste interactie niets betekenisvols oplevert geen tweede kans om zich te verbeteren. De lat ligt niet bij functionaliteit. Het gaat om waarde.
Als het product bij de eerste kennismaking niet genoeg waarde biedt, komen gebruikers waarschijnlijk later niet terug om te zien of het beter is geworden.
Kelly Satterfield · HR-leider en consultant
Er waren ook de praktische beperkingen die iedereen die buiten een ontwikkelingsteam heeft geprobeerd iets te bouwen goed kent: implementatie, betalingsinfrastructuur, integratie met bestaande systemen, contextvensters die halverwege een sessie sluiten en uren productief werk wissen.
De eerste versie weerspiegelde de kernstroom van de tool. Een kandidaat voor een recruitersfunctie uploadt een cv, de tool leidt een voorlopig vaardighedenprofiel af en begeleidt de kandidaat vervolgens door een reeks gespreksvragen die bedoeld zijn om die eerste beoordeling te kalibreren en van context en diepgang te voorzien.
Aan het einde krijgt een leidinggevende die verantwoordelijk is voor werving een beeld van waar de kandidaat daadwerkelijk staat ten opzichte van een vastgesteld competentiekader.
Fisher richtte de primaire bouwomgeving in Lovable in—een AI-bouwer zonder code die via gesprekken hulpmiddelen voor het publiek genereert, zonder gebruikers aan een specifiek LLM te binden—zodat de technische architectuur het denkproces van de groep kon bijhouden zonder zelf een knelpunt te worden.
Van blauwdruk naar bouw
Tegen de vierde sessie ontwierp de groep niet langer een abstracte tool. Ze bouwden er een en ontdekten, zoals bouwers altijd doen, dat de afstand tussen het idee en de uitvoering precies de plek is waar het echte leren plaatsvindt.
Fisher had vóór de start van het gesprek een aangepaste GPT op basisniveau samengesteld, voorzien van instructies, een voorlopig competentiekader en het begin van de gesprekslogica die ze in eerdere sessies hadden uitgestippeld. Het plan was dat iedereen er toegang toe zou krijgen, er gezamenlijk prompts voor zou schrijven en de toon en het gedrag ervan in realtime zou gaan afstemmen. Het plan botste onmiddellijk op de werkelijkheid.
De gedeelde link werkte voor niemand behalve voor mij. Werkruimtemachtigingen, eigenaardigheden van het platform en de specifieke manier waarop ChatGPT omgaat met externe toegang namen het eerste kwartier van de sessie in beslag.
Het was een kleine frustratie, precies het soort dat nooit in een productaankondiging zou belanden, en het was leerzaam. Tools die professionals daadwerkelijk gebruiken om dingen te bouwen, gedragen zich niet zoals demo's.
Deze schermafbeelding laat zien hoe het welkomstscherm eruit zou komen te zien voor de tool die de groep bouwde, genaamd Talent Scout.
Toen iedereen naar hetzelfde scherm keek, gebeurde er iets interessanters. Terwijl de groep nog besprak in welk formaat de competentiedefinities moesten worden vastgelegd, opende Gillies Claude in een apart venster en zette ze de beoordelingstabel live, tijdens het gesprek, om in gestructureerde JSON.
"Ik gebruik Claude omdat het hiervoor beter is dan ChatGPT," zei ze zonder er verder woorden aan vuil te maken. Een paar minuten later zette ze het opgemaakte bestand in de groepschat. Niemand stond erbij stil om het te erkennen. Ze gingen gewoon verder.
Dat soort probleemoplossing in beweging—een knelpunt omzetten in een opgelost probleem zonder het tot het hoofdpunt van de vergadering te maken—is wat professionals onderscheidt die deze tools echt hebben geïnternaliseerd van degenen die nog leren ermee om te gaan.
Wie heeft het laatste woord?
Satterfield wierp een vraag op die belangrijke gevolgen zou hebben voor zowel de architectuur van de tool als de uiteindelijke ontvangst ervan: geeft de AI de definitieve beoordeling, of bevestigt de gebruiker die?
Het onderscheid is niet cosmetisch. Als de tool een oordeel geeft zoals "Op basis van uw antwoorden bevindt u zich op niveau 2 wat betreft kandidaatgerichtheid", positioneert hij de AI als de autoriteit. Als de tool daarentegen een voorlopige interpretatie geeft en de gebruiker uitnodigt om daartegenin te gaan, verandert de dynamiek volledig. De beoordeling wordt samenwerkend in plaats van evaluatief. De gebruiker neemt deel aan het proces en is er niet het onderwerp van.
"Accepteert u deze feedback?" zei Turnmeyer toen het idee vorm kreeg. "Ik vind het eigenlijk geweldig."
Gillies werkte de logica verder uit. Als de gebruiker de beoordeling niet accepteert, vraagt de tool wat niet goed voelt—en gebruikt het antwoord vervolgens om zijn interpretatie opnieuw af te stemmen of deze voorzichtig opnieuw te bevestigen, waarbij het de onderbouwing doorloopt.
Die heen-en-weergaande conversatie creëert de psychologische veiligheid die de tool nodig heeft om echt nuttig te zijn. Mensen veranderen niet op basis van feedback die ze niet vertrouwen. Draagvlak creëren is geen zachte functie, maar het mechanisme.
De eerste echte test
Ze besloten het prototype live te testen. Turnmeyer bood vrijwillig een opzettelijk summier antwoord op een van de beoordelingsvragen—het soort antwoord dat een ongeïnteresseerde kandidaat of afgeleide medewerker zou kunnen geven.
Ze beschreef hoe ze met haar manager ruzie had gemaakt over een verschil in salaris, de kandidaat was kwijtgeraakt en geen idee had gehad wat de uitkomst was. Het was het HR-equivalent van antwoorden met: "Ik hou gewoon echt van mensen" wanneer wordt gevraagd waarom je in HR wilt werken.
De tool beoordeelde het onmiddellijk. Hij kende een niveau toe. Het was bemoedigend. Het was ook verkeerd—niet feitelijk onjuist, maar voorbarig. De tool had aannames gedaan over wat het antwoord impliceerde, in plaats van te vragen om de aanvullende context die nodig was voor een nauwkeurige beoordeling.
Als je iemand iets anders wilt geven dan 'voldoet aan de verwachtingen', moet je gedetailleerde voorbeelden geven. De AI zou zichzelf aan dezelfde standaard moeten houden.
Erin Turnmeyer · VP Personeelsactiviteiten
Turnmeyer trok de parallel rechtstreeks vanuit haar praktijk van functioneringsbeoordelingen. Ze had managers al lange tijd verplicht om specifiek bewijs te leveren voordat ze iemand boven of onder "voldoet aan de verwachtingen" beoordeelden.
Dezelfde discipline zou op de tool moeten worden toegepast. Verdien het recht om een niveau toe te kennen door eerst de vragen te stellen die de beoordeling verdedigbaar zouden maken. Opnieuw was het de HR-expertise in de ruimte die de AI beter maakte—niet andersom.
Satterfield voegde een complicatie toe die de tool over het hoofd had gezien. Het summiere antwoord kon eerder beleid dan vaardigheid hebben weerspiegeld.
Als de manager daadwerkelijk een vaste bovengrens voor de beloning had vastgesteld, zou harder pleiten de uitkomst niet hebben veranderd. De tool had de persoon beoordeeld, terwijl hij naar de situatie had moeten vragen. Verduidelijkende vragen waren geen punt voor de afwerking. Ze waren wat het verschil zou maken tussen een nuttige beoordeling en een aanmatigende beoordeling.
Turnmeyer nam de taak om de instructies te schrijven mee als huiswerk: hoe geef je een tool de opdracht om op de juiste momenten verduidelijkende vragen te stellen zonder dat elke interactie als een verhoor aanvoelt?
Deze schermafbeelding toont een voorbeeld van wat het eindproduct zou doen: verduidelijkende vragen stellen en de kandidaat aansporen om meer diepgang te bieden.
Het is een moeilijker probleem dan het klinkt, en ze was zich er scherp van bewust dat de lat ongewoon hoog lag.
"Het moet beter zijn dan een mens," zei ze. "Dat is de norm."
Testen als discipline
De sessie leverde ook een van de praktisch bruikbaarste methodologische inzichten van de hele groep op. Toen Satterfield vroeg hoe de groep hulpmiddelen als dit doorgaans testte, antwoordden zowel Turnmeyer als Gillies op manieren die iets belangrijks onthulden over hoe rigoureus testen er in de praktijk werkelijk uitziet.
Voor haar hulpmiddel voor aanbevelingen rond arbeidsvoorwaarden, dat nauwkeurig moest aangeven of specifieke medicijnen onder het zorgverzekeringsplan van het bedrijf vielen, testte Turnmeyer specifiek op uitzonderingsgevallen. Niet de voor de hand liggende medicijnen, de populaire middelen die het model tijdens de training herhaaldelijk zou zijn tegengekomen. Ze testte de obscure middelen, in de categorieën die het meest waarschijnlijk tot een zelfverzekerde hallucinatie zouden leiden.
"Ik ben de niet-populaire medicijnen gaan testen," zei ze, "omdat Claude me liet zien wat het deed terwijl het die tool bouwde."
Die mate van doelbewuste adversariële intentie bij het testen is zeldzaam bij bouwers die van buiten een technische context komen. Het is ook precies wat hulpmiddelen die vertrouwen winnen onderscheidt van hulpmiddelen die na een gênante fout stilletjes worden opgegeven.
Schrappen wat je al hebt gebouwd
Een hergroepssessie vlak voor de feestdagen begon met een vraag die moeilijker te stellen was dan het klinkt: waar dient de functie voor het uploaden van cv's eigenlijk voor?
Gillies bracht de vraag ter sprake. De beoordeling vroeg gebruikers om zorgvuldig na te denken over hun eigen capaciteiten. Voegde het cv informatie toe die de gebruiker niet directer kon geven door simpelweg de vragen te beantwoorden? Niemand in de groep wist zeker of dat zo was. De oorspronkelijke bedoeling was tijd te besparen, zoals een cv-parser, maar we waren er niet langer van overtuigd dat de functie dat waarmaakte.
Ze besloten de functie te schrappen.
Dit komt minder vaak voor dan het klinkt bij productontwikkeling. De groep had echt tijd besteed aan de uploadfunctie—deze gebouwd, getest en toegekeken hoe het cv van Satterfield werd geparseerd en verkeerd beoordeeld. Het schrappen ervan vereiste dat ze de logica van verzonken kosten negeerden die teams ertoe aanzet om steeds meer toe te voegen aan zaken waarin ze al hebben geïnvesteerd.
Begin met het einddoel voor ogen en bepaal hoe een goed resultaat eruitziet. Als je niet kunt uitleggen waarvoor een functie dient, kun je haar niet verdedigen.
Turnmeyer voerde een verwant argument aan over de methodologie. Achteraf dacht ze dat ze misschien sneller vooruitgang hadden kunnen boeken door het gedrag van het hulpmiddel volledig te definiëren voordat ze ook maar één prompt schreven. Ze hadden iets gebruikt dat leek op een agilemodel—bouwen, testen, aanpassen—terwijl de complexiteit van wat ze bouwden misschien meer om een watervalbenadering vroeg: zorg eerst dat de specificatie klopt en bouw het daarna volgens die specificatie.
Ze had een ontwerpdocument van 130 pagina's voor een ander hulpmiddel dat ze had gebouwd, en dat haar deze les had geleerd. Een volledige specificatie vertelt je niet alleen wat je moet bouwen. Ze vertelt je ook wat je níét bouwt, wat uiteindelijk net zo nuttig blijkt te zijn.
Gillies bracht het kernprobleem van het product scherper onder woorden. Wat het hulpmiddel ook op het scherm liet zien, het moest verder gaan. Een beoordeling die gegevens aan het licht brengt, is niet hetzelfde als een hulpmiddel dat je vertelt wat je ermee moet doen. In die kloof tussen uitvoer en actie houden diagnostische hulpmiddelen stilletjes op nuttig te zijn, en het is de kloof die de meeste ervan nooit dichten.
Alleen bouwen
In januari deed Satterfield het meeste bouwwerk zelf, omdat de aantrekkingskracht van hun baan van negen tot vijf voor de rest van de groep te sterk was en te veel tijd kostte om nog ruimte over te laten voor het project. Niemand werd hier immers voor betaald.
Ze had de uploadfunctie voor cv's verwijderd, zoals de groep had afgesproken. Ze had spraakinvoer toegevoegd—gebruikers konden beoordelingsvragen nu beantwoorden door te spreken in plaats van te typen, wat een meer conversationele manier van antwoorden mogelijk maakte die moeilijker te manipuleren was dan een tekstveld.
Ze gebruikte ChatGPT om synthetische testantwoorden te genereren ("Ik ben een junior recruiter die hier sterk in is en daarin zwak, geef me antwoorden"), waarna ze naar Lovable overschakelde om die antwoorden in te voeren en te observeren hoe het hulpmiddel ze beoordeelde.
Het dashboard voor leidinggevenden vormde de andere helft van de logica van de tool: de weergave die een TA-directeur of CHRO zou gebruiken om te zien hoe een kandidaat had gescoord, waar de hiaten lagen en hoe diens capaciteiten de sterke punten en behoeften van een bestaand team konden aanvullen.
Daardoor werd de organisatiestructuur een reëel probleem, omdat de tool moest weten wie wie beoordeelde en wie bevoegd was om de resultaten te bekijken.
Satterfield had geprobeerd dit op te lossen door gebruikers te vragen hun naam, functietitel en de naam van hun manager in te voeren (bij gebrek aan een gegevensintegratie). Maar die logica liep vast bij een veelvoorkomend scenario: een directeur talentacquisitie die de beoordeling wilde versturen naar een bredere recruitmentorganisatie met zowel directe als indirecte rapportagelijnen. De logica voor het in kaart brengen van de organisatie was niet verfijnd genoeg om rekening te houden met die structuur.
In theorie zou deze informatie de tool meer context geven over de rol van degene die de beoordeling aflegt, maar het verzamelen van meer gegevens maakte de zaken ingewikkelder.
Turnmeyer had een versie van dit probleem al in een andere context opgelost. De tool voor prestatiemanagement die ze voor haar eigen bedrijf had gebouwd, draaide op Google Sheets, Slack en Claude. Google Sheets sloeg de gegevens op. Slack was de interface waarmee medewerkers interacteerden. Claude verzorgde de analyse en het genereren van feedback.
De architectuur was eenvoudiger dan ze klonk: een spreadsheet met naam, e-mailadres, functieniveau en functietitel. Een apart tabblad waarin functieniveau en competenties aan elkaar werden gekoppeld.
"De beveiligingsafdeling van mijn bedrijf wilde mijn tool beoordelen," vertelde ze de groep. "Ik zei dat die was opgeslagen in Google Docs. Zij reageerden: 'O, zo eenvoudig is het dus.'"
Eenvoudig, maar Turnmeyer had dat pas geleerd door te bouwen. Wat ze drie weken eerder nog niet wist, was dat er logging bestond: een functie die de voortgang van een gebruiker opslaat, zodat de tool niet wordt gereset wanneer iemand even weggaat en later terugkomt.
"Ik schold Claude uit," zei ze, "totdat die me vertelde dat logging bestond."
Dat is wat bouwen je werkelijk leert. Niet wat je van plan was te leren, maar wat je niet wist dat je moest weten.
De onderliggende vraag
Ergens tijdens de sessie in januari kwam het gesprek uit bij de vraag waar het al maanden omheen draaide.
De groep bleef architectuur, toegangsrechten, opslag en dashboards bespreken: allemaal reële problemen. Maar daaronder lag een fundamentelere vraag. Wat probeerden ze eigenlijk te bouwen, en voor wie?
De tool was oorspronkelijk opgevat als een selectiediagnose: iets dat een TA-leider naar een kandidaat of interne medewerker kon sturen om te beoordelen of diens werkelijke capaciteiten overeenkwamen met wat er op diens cv stond, en om dat beeld zichtbaar te maken voordat er een selectiebeslissing werd genomen.
Wat je hier ziet, is een selectie screenshots van het type rapport dat de tool voor de geïnterviewde opleverde. Voor de beoordelaar helpt een dashboard met de huidige sterke punten van het team om te bepalen waarop de geïnterviewde moet worden beoordeeld, om te zien of die de zwakke punten van het TA-team kan aanpakken.
Die kern was niet veranderd. Maar elke praktische beslissing die ze namen — een dashboard voor leidinggevenden toevoegen, nadenken over abonnementsmodellen en een aanmeldproces uitwerken — trok hen in de richting van iets complexers.
Dashboards in realtime betekenden voortdurende toegang, wat abonnementskosten betekende, waardoor ze steeds dichter kwamen bij het soort bedrijfssoftware dat veel organisaties moeilijk kunnen betalen of effectief kunnen implementeren.
"We proberen geen HCM-leverancier te worden," zei Satterfield.
Turnmeyer was eerlijk over haar eigen positie.
"Mijn bedoeling was gewoon om iets nieuws te leren."
Dat was geen terugtrekking uit het project. Het was een accurate weergave van wat het experiment haar al had opgeleverd. Ze had een aantal nieuwe dingen geleerd en was al bezig een nieuwe tool voor prestatiemanagement te bouwen waarin ze de lessen uit het cohort toepaste.
Ze hoefde de tool van de groep niet tot een product te maken om er echte waarde uit te halen.
In dit stadium was mijn eigen interesse vooral redactioneel. Ik wilde een verhaal om te vertellen en iets dat mensen konden bekijken, geen abonnementsproduct, maar een demonstratie waar HR-professionals over konden nadenken en misschien iets soortgelijks mee konden bouwen.
Dit artikel schrijven maakte daar deel van uit. Kon ik een downloadbare gids maken? En uiteindelijk misschien een live-evenement waar de groep kon bespreken wat ze hadden gedaan, een publiek met de tool kon laten interageren en het gesprek als podcast kon opnemen? Ik had veel ideeën, maar de tijd om ze uit te voeren werd korter naarmate de doelstellingen voor het nieuwe jaar zich voor ons allemaal opstapelden.
Satterfields interesse was het meest commercieel gericht, en daar was ze duidelijk over. Ze wilde het uiteindelijk tot een product maken. Dat zou ze niet alleen doen. Maar ze was bereid te blijven bouwen aan iets dat op een dag verkocht zou kunnen worden.
Die drievoudige divergentie van intentie—leren, verhalen vertellen, product—is waarschijnlijk inherent aan elke groep als deze. Het eerlijke gesprek erover, in januari, was nuttiger dan doen alsof iedereen altijd al hetzelfde had gewild.
De demo als antwoord
De vraag hoe mensen de tool konden uitproberen, was onopgelost gebleven sinds het uploaden van cv's live was gegaan. Testen met echte gebruikers is waardevol, maar brengt zijn eigen problemen met zich mee. De tool moet consistent werken, gebruikers hebben voldoende context nodig om te weten wat ze doen, en een slechte eerste ervaring is moeilijk te herstellen.
Turnmeyer bood de eenvoudigste oplossing die de groep had overwogen.
Ze had demoregistraties bekeken—korte rondleidingen van een minuut of twee, die lieten zien hoe een tool werkte zonder dat de kijker hem daadwerkelijk hoefde te gebruiken. Ze stelde voor dat dit misschien voldoende was. Mensen konden de tool in actie zien, begrijpen wat hij deed en waarom, en vertrekken met het gevoel dat het mogelijk was.
Ze hoefden niet door een login te navigeren, een organigram aan te leveren of vast te lopen wanneer een beoordelingsvraag niet bij hun situatie paste.
De feedback die ik krijg op veel van de blogs die ik schrijf, is dat mensen niet echt precies hetzelfde willen kopiëren en plakken. Ze willen gewoon weten dat ze het kunnen.
Erin Turnmeyer · VP Personeelsoperaties
Die observatie wijst op iets wezenlijks in de manier waarop HR-professionals momenteel omgaan met AI-tools. De kloof die velen van hen proberen te overbruggen, ligt niet tussen weten dat iets bestaat en het gebruiken ervan. Het gaat om de vraag of ze geloven dat ze überhaupt in staat zijn om zoiets te doen.
Een demo waarin professionals hun eigen tool bouwen, beantwoordt een andere vraag dan een afgewerkt product—niet "is deze tool goed?", maar "had iemand zoals ik dit kunnen maken?"
Het idee werd goed ontvangen. Het nam de zorgen over het testen weg, verminderde de complexiteit van het delen van iets dat nog niet productierijp was, en hield de nadruk waar de groep die altijd had willen leggen: op het proces en het denkwerk, niet alleen op het resultaat.
Wat het experiment leerde: een gids voor HR-bouwers
- Begin met het probleem, niet met de technologie. Het vroege enthousiasme van de groep voor sentimentanalyse was oprecht, maar leidde hen weg van een beter hanteerbaar en waardevoller probleem. De overstap naar het in kaart brengen van vaardigheden werkte omdat die begon met een echte gebruikssituatie die al in de praktijk was getest.
- Maatwerk verslaat generieke oplossingen. Elke deelnemer was de grenzen van HR-platforms voor ondernemingen tegengekomen. De tools die voor specifieke contexten waren gebouwd—de aanbeveler voor arbeidsvoorwaarden van Turnmeyer, de warmtekaart van Satterfield—presteerden beter dan de kant-en-klare alternatieven. Het argument om zelf iets te bouwen is sterker dan ooit en de drempels zijn lager.
- De kruiscontrole is het hele spel. Zelfbeoordelingen zijn maar zo goed als de zelfkennis van mensen, en die is berucht onbetrouwbaar. De werkelijke waarde van een tool ligt in het vermogen om door te vragen, uit te dagen en mensen voorzichtig bij te sturen—niet alleen vast te leggen wat mensen over zichzelf geloven.
- Minimaal Waardevol, niet Minimaal Levensvatbaar. Als de eerste versie niets oplevert waardoor een gebruiker wil terugkomen, doet de routekaart er niet toe. Ontwerp voor de eerste indruk, niet voor de vijfde.
- Draagvlak is structureel, niet vrijblijvend. De vraag of de AI de uiteindelijke beoordeling geeft of dat de gebruiker die bevestigt, is geen UX-detail. Dit bepaalt of de tool een autoriteit of een samenwerkingspartner is, en dat onderscheid bepaalt alles aan de manier waarop de tool wordt ontvangen en gebruikt.
- Schrap functies die je al hebt gebouwd. De logica van verzonken kosten zorgt ervoor dat teams blijven toevoegen aan zaken waarin ze hebben geïnvesteerd, lang nadat die zaken hun bestaansrecht hebben verloren. Als je niet kunt uitleggen waarvoor een functie dient, is dat je antwoord. Haar schrappen is productdiscipline, geen mislukking.
- Test vijandig en vroegtijdig. Zoek mensen die je zullen vertellen dat de tool slecht is. Geef hem de slechtst denkbare, maar redelijke invoer en kijk wat hij doet. Bouw de uitzonderingssituaties in voordat je de gebruikelijke situaties oppoetst. De geloofwaardigheid van de tool hangt af van de manier waarop hij omgaat met de momenten waarvoor hij niet was ontworpen.
- De tool moet het recht verdienen om te beoordelen. Meteen naar een beoordeling springen voordat er voldoende vragen zijn gesteld, is aanmatiging, geen efficiëntie. Verhelderende vragen maken de beoordeling verdedigbaar, en verdedigbaarheid zorgt ervoor dat feedback blijft hangen.
- Wees eerlijk over waarvoor iedereen er is. Uiteenlopende intenties binnen een groep zijn geen probleem dat moet worden beheerd—ze zijn informatie. Door ze vroegtijdig op tafel te leggen, voorkom je dat iedereen toewerkt naar een doel dat slechts door een deel van de groep werkelijk wordt gedeeld.
- De moeilijkste gesprekken zijn de belangrijkste. De groep bouwde een tool om HR-vaardigheden te beoordelen en voerde daarbij een van de eerlijkste gesprekken over de beperkingen van HR die iemand van hen zich kon herinneren. Dat gesprek—over naar achteren gerichte raamwerken, over de kloof tussen kennis uit examens en situationeel beoordelingsvermogen—was net zo goed het product als de tool.
De sessies die begonnen als een afspraak voor vier gesprekken, liepen door tot in de winter en vervolgens tot in het nieuwe jaar. Het prototype was nog steeds in ontwikkeling. De intenties van de mensen die het hadden gebouwd, waren op manieren verduidelijkt die niet netjes tot een oplossing kwamen.
Satterfield was nog steeds aan het bouwen. Turnmeyer had wat ze had geleerd elders toegepast. Gillies had de groep ertoe aangezet gedisciplineerder om te gaan met wat de tool daadwerkelijk moest doen. Ik schreef het verhaal van dit alles.
Turnmeyer had vroeg in het proces iets gezegd dat waar bleef: ze bouwde niet omdat haar dat was gevraagd, maar omdat ze het moest begrijpen.
Dat begrip van wat AI-tools daadwerkelijk doen, waar ze fouten maken en wat ervoor nodig is om ze nuttig te maken, was niet te vinden in een conferentiesessie of een demonstratie van een leverancier. Het kwam voort uit de beslissingen die de groep nam, de functies die ze schrapten en de momenten waarop de tool iemand verkeerd beoordeelde en ze moesten uitzoeken waarom.
De nuttigste dingen die het cohort voortbracht, zaten niet in het prototype. Ze zaten in de redenering erachter.