Wenn Personalleiter zu Entwicklern werden
Erkenntnis aus dem Experiment: Kollaborative KI-Projekte lieferten tiefgreifende Erkenntnisse über die Fähigkeiten im Personalwesen, die über die reine Entwicklung von Werkzeugen hinausgehen.
Problemfokus: Der Wechsel von der Stimmungsanalyse zur Kompetenzzuordnung verdeutlichte, wie wichtig es ist, klare und erreichbare Ziele zu definieren.
Skepsis gegenüber KI: Fachkräfte im Personalwesen stehen bei bestehenden KI-Plattformen vor erheblichen Herausforderungen hinsichtlich Verantwortlichkeit und Transparenz.
Struktur des Werkzeugs: Das KI-Bewertungswerkzeug betonte die Zusammenarbeit und ermöglichte es den Nutzern, KI-generiertes Feedback zu bestätigen oder infrage zu stellen.
Gegnerische Tests: Eine erfolgreiche Werkzeugentwicklung erfordert strenge Tests mit vielfältigen Eingaben, um Sonderfälle wirksam zu berücksichtigen.
Die Sitzungen waren auf eine Stunde angesetzt. Fast immer dauerten sie länger.
Das ist nicht ungewöhnlich, wenn eine Gruppe von HR-Fachleuten zusammenkommt, um über KI zu sprechen. Ungewöhnlich war jedoch, was sie mit diesem Gespräch tun sollten. Es nicht analysieren, keinen Meinungsbeitrag darüber veröffentlichen, sondern tatsächlich etwas entwickeln.
Im Herbst 2025 stellte ich das zusammen, was ich als Entwicklerkohorten bezeichnete: eine kleine Gruppe von HR- und Personalverantwortlichen, von denen ich wusste, dass sie bereits an den entsprechenden Themen arbeiteten und bereits darüber nachdachten, was der HR-Beruf mit KI erreichen könnte.
Lesen Sie weiter – und führen Sie weiterhin intelligenter
Erstellen Sie ein kostenloses Konto, um diesen Beitrag fertigzulesen und Teil einer Community zukunftsorientierter Führungskräfte zu werden, die Werkzeuge, Leitfäden und Einblicke für den Erfolg im Zeitalter der KI erschließen.
Have an account? Log In
Die Hypothese war einfach. Diejenigen, die den Problemen am nächsten sind, sind am besten in der Lage, Lösungen zu entwickeln. Die Frage war, ob sie dazu in der Lage wären.
Insgesamt würde ich vier Kohorten aufbauen und dabei feststellen, dass es leichter gesagt als getan ist, Ziele für diese Sitzungen zu definieren. Letztendlich verliefen die meisten Kohorten im Sande, da sie Schwierigkeiten hatten, die ursprüngliche Vision umzusetzen oder sich auf ein einziges Ziel zu einigen. Kalender, Arbeitsbelastungen und die Anforderungen unserer tatsächlichen Jobs führten oft zu Gesprächen, aus denen großartige Ideen hervorgingen, ohne dass diese jemals verwirklicht wurden.
Aber eine Kohorte fand tatsächlich zusammen und legte so gut sie konnte die gesamte Strecke zurück. Tatsache ist: Je tiefer man in die Entwicklung eigener Lösungen eintaucht, desto schwieriger wird es, eine gemeinsame Vision zu wahren und die technische Herausforderung zu meistern.
Diese Geschichte berichtet, was aus diesen Sitzungen hervorgegangen ist, und ich biete sie Ihnen als Fallstudie für die Entwicklung eigener Lösungen an.
Die Kohorte
Dies waren keine KI-Skeptiker, die erst überzeugt werden mussten. Es waren Praktiker, die bereits auf diesen Moment gesetzt hatten. Was die Kohorte ihnen bot, war ein strukturierter Raum, in dem sie aufhören konnten zu beraten und anfangen konnten, etwas zu erschaffen.
Das erste ehrliche Gespräch
In der ersten Sitzung kam etwas zur Sprache, das nur selten in veröffentlichten HR-Kommentaren auftaucht: wie frustriert diese Fachleute tatsächlich von den Werkzeugen sind, die sie verwenden sollen.
Turnmeyer gab den Ton an. Sie hatte versucht, technische Dokumentation darüber zu erhalten, wie die Stimmungsanalyse in BambooHR, Paycom und Gusto funktionierte – nicht, um die Werkzeuge abzulehnen, sondern weil ihr Rechtsteam sie verstehen musste, bevor es deren Einsatz genehmigen konnte.
Weder die Vertriebsteams noch die Rechtsvertreter konnten ihre Fragen beantworten. Die KI-Funktionen existierten. Die Verantwortlichkeit dafür, wie sie funktionierten, jedoch nicht.
Gillies sah sich mit einer ähnlichen Spannung konfrontiert. Interne Stimmen hatten Bedenken hinsichtlich der Umweltauswirkungen von KI geäußert, und einige Kollegen wollten die Nutzung von KI durch Mitarbeitende einfach verbieten. Gillies widersprach.
KI vollständig zu verbieten, führt zu verdeckter Nutzung und erhöhtem Risiko. Ein sinnvollerer Ansatz ist, sich mit Leitplanken auf KI einzulassen.
Melina Gillies · Leiterin des Personalbereichs, Flex Networks
Aus dieser ersten Stunde ging eine Diagnose hervor, auf die sich die Gruppe einigen konnte. Die integrierten KI-Funktionen von HR-Plattformen für Unternehmen seien, wie Gillies es formulierte, „oft grundlegend und verfügten über einen eingeschränkten Funktionsumfang.“
Die Werkzeuge, die tatsächlich funktionieren, sind in der Regel maßgeschneidert – entwickelt für spezifische Probleme, spezifische Kontexte und spezifische Unternehmen. Turnmeyer wollte weniger Werkzeuge, nicht mehr – ein Wunsch, den ich von Führungskräften aus Personalwesen und Unternehmensbetrieb oft höre. Sie konnte sich eine Zukunft vorstellen, in der eine leistungsfähige KI, die mit den richtigen Dokumenten versorgt wird, ein HRIS überflüssig macht.
Sie setzten sich außerdem mit etwas auseinander, das selten so direkt thematisiert wird: der Ethik der Verhaltensüberwachung. Schon früh kam die Idee auf, Ablehnungsraten von Besprechungen, Lücken bei Systemanmeldungen oder ungewöhnliche Arbeitszeiten als Stellvertreter für mangelndes Engagement zu verwenden.
Ebenso wurden die Grenzen dieses Ansatzes thematisiert. Satterfield benannte ein Risiko, mit dem jedes Instrument zur Messung des Engagements irgendwann konfrontiert ist: Ermüdung durch Untätigkeit. Wenn man Daten sammelt und nicht sichtbar darauf reagiert, verlieren Mitarbeitende das Vertrauen in das System. Die Daten werden zu Rauschen und das Werkzeug zu KI-Theater.
Sie waren noch nicht bereit, ein Werkzeug zur Stimmungsanalyse zu entwickeln. Das Thema war zu breit gefasst, mit zu vielen ethischen Dilemmata behaftet und zu leicht katastrophal falsch einzuschätzen. Also schlugen sie eine neue Richtung ein.
Das richtige Problem finden
Die zweite Sitzung begann mit dem ehrlichen Eingeständnis, dass die ursprüngliche Richtung zu ehrgeizig und zu unklar war.
„Ich weiß nicht, ob damit Engagement gemessen wird“, sagte Turnmeyer, „oder ob einfach etwas gemessen wird, das ein Gespräch erfordert.“
Dieser Unterschied ist wichtiger, als es vielleicht klingt. Viele Technologien für das Personalwesen machen den Fehler, Daten als Ersatz für ein Gespräch zu behandeln. Die Gruppe versuchte, KI einzusetzen, um die Momente sichtbar zu machen, in denen ein Gespräch stattfinden muss, und dieses Gespräch anschließend besser zu gestalten.
Satterfield brachte die Idee ein, die den Rest des Projekts verankern sollte. Während eines Einstellungsstopps bei einem früheren Arbeitgeber hatte sie für ihr Team zur Talentgewinnung eine Selbsteinschätzung der Fähigkeiten entwickelt – eine Möglichkeit, abzubilden, was Menschen tun konnten und was sie tatsächlich tun wollten. Dadurch entstand eine Wärmekarte, die Entscheidungen über den Personaleinsatz menschlicher und strategischer machte.
Sie war nicht KI-gestützt. Es handelte sich um ein Microsoft-Formular. Doch die zugrunde liegende Logik war überzeugend, der Anwendungsfall real, und sie hatte erlebt, dass das Konzept funktionierte.
„Große Anbieter versuchen, so etwas umzusetzen, aber bisher macht es noch niemand wirklich gut, und viele Unternehmen haben zusätzlich zu ihrem zentralen HRIS kein Budget für diese Art von Technologie eingeplant“, sagte sie.
Die Gruppe erkannte die Möglichkeit. Was wäre, wenn sie eine KI-basierte Version entwickeln würden? Eine, die statt klinisch dialogorientiert, statt auf Regelkonformität ausgerichtet zukunftsorientiert und für einzelne Personalleitungen erschwinglich wäre, anstatt hinter Verträgen für Großunternehmen verborgen zu sein?
Die Art und Weise, wie sich Personalerinnen und Personaler untereinander über Personalthemen austauschen, ist grundlegend anders. Das kann einen echten Mehrwert darstellen, und die meisten Werkzeuge übersehen ihn vollständig.
Melina Gillies · Leiterin des Personalbereichs, Flex Networks
Fisher, der den Ausführungen der Gruppe zu den verschiedenen Möglichkeiten zuhörte, machte eine Beobachtung, die das Potenzial des Projekts in ein neues Licht rückte. Er hatte beide Enden des HR-Spektrums erlebt: die transaktionale, auf Regelkonformität und Rahmenwerken basierende Art und die seltenere, menschenorientierte Fachkraft, die mit ihm sprach „wie jemand, der das Gefühl vermittelte, auf meiner Seite zu sein.“
„Die Sprache der zweiten Art“, sagte er, „fühlte sich nie so an, als stamme sie aus einem vor Jahrzehnten verfassten Rahmenwerk. Sie fühlte sich einfach gut an.“
Gillies griff diesen Gedanken auf. Der entscheidende Unterschied ihres Werkzeugs, argumentierte sie, liege in Ton und Struktur. Was wäre, wenn es die Art und Weise nachbilden könnte, wie sich Personalfachleute auf einer Konferenz, zwischen den Sitzungen und abseits der offiziellen Gespräche tatsächlich untereinander austauschen? Was wäre, wenn es „politisches Geschick“ nicht als Kontrollkästchen verstünde, sondern als etwas vielschichtiges, umstrittenes und situationsabhängiges, über das erfahrene Praktikerinnen und Praktiker untereinander diskutieren?
Das war die Richtung: ein Beurteilungsinstrument vor der Einstellung, das für Führungskräfte im Personalwesen und in der Talentgewinnung entwickelt wurde, die eine bessere Möglichkeit brauchen, Bewerberinnen und Bewerber für Positionen in der Personalgewinnung vor ihrer Einstellung zu beurteilen. Kein Persönlichkeitstest und keine Lebenslaufprüfung, sondern eine strukturierte, konversationelle Diagnose, die einer einstellenden Führungskraft sagen konnte, ob die ihr gegenübersitzende Person tatsächlich wusste, wie man die Aufgabe ausführt. Ein Werkzeug, das sich weniger wie eine Leistungsbeurteilung und mehr wie ein Gespräch mit jemandem anfühlte, der Personalgewinnung von innen heraus verstand.
Der entscheidende Geistesblitz
In der dritten Sitzung war die Gruppe tief in die Architektur des Werkzeugs eingestiegen: Welche Kompetenzen sollten bewertet werden, wie sollten sie über verschiedene Ebenen hinweg strukturiert werden, und wie sollte die Lücke zwischen dem, was Menschen zu können behaupten, und dem, was sie tatsächlich können, berücksichtigt werden?
Die Kritik an bestehenden Rahmenwerken kam von Gillies, die das Kompetenzmodell von SHRM als „in mancher Hinsicht sehr traditionell und sehr rückwärtsgewandt“ bezeichnete. Der Berufsstand stecke, wie sie es ausdrückte, noch immer in einem „postindustriellen Kater“ – auf Regelkonformität ausgerichtet, hierarchisch und für eine Welt konzipiert, die bereits im Verschwinden begriffen war.
Ihr Tool musste sich an etwas anderem orientieren – nicht daran, was HR-Führungskräfte wissen mussten, sondern daran, wozu sie in der Lage sein mussten.
Sind Sie bereit, mit dem CEO über seine Leistung zu sprechen? Wenn nicht, sind Sie kein Experte für schwierige Gespräche.
Erin Turnmeyer · Vizepräsidentin für Personalprozesse
Turnmeyer hatte ein einprägsames Beispiel. Sie hatte kürzlich die SPHR-Prüfung abgelegt. Die Dinge, die sie dafür wissen musste – Gesetze, verfahrensbezogene Definitionen und Klassifizierungsregeln – würde jede kompetente HR-Fachkraft einfach nachschlagen.
Die entscheidenden Fähigkeiten waren nicht Bestandteil des Zertifizierungsmaterials. Es ging um Dinge wie: Können Sie einem CEO gegenübersitzen und ihm etwas sagen, das er nicht hören möchte? Können Sie sich für einen Mitarbeitenden einsetzen, wenn die geschäftliche Begründung nicht eindeutig ist? Das Auswendiglernen von Arbeitsgesetzen beantwortet diese Fragen nicht.
Fisher ging noch einen Schritt weiter. Er hatte jahrelang im Veränderungsmanagement gearbeitet und festgestellt, dass die aussagekräftigste Variable für die Fähigkeit einer Organisation, sich durch eine Transformation zu navigieren, keine bestimmte Fähigkeit war. Es war die Beziehung eines Menschen zu Mehrdeutigkeit.
Herauszufinden, wie wohl sich jemand damit fühlt, sich unwohl zu fühlen – oder ganz allgemein mit dem Tempo von Veränderungen –, ist ein so guter Indikator für die eigene Fähigkeit, in dieser neuen Welt zu funktionieren.
Tim Fisher · Leiter für KI, Black and White Zebra
Dann kam das, was die Gruppe später das Geheimrezept nennen sollte.
Gillies brachte eine Frage ins Gespräch. Was wäre, wenn das Tool eine Gegenprüfung einbauen würde? Wenn jemand sich selbst als Experten für Konfliktmanagement einschätzte, aber dann in einer natürlichsprachlichen Antwort auf eine Folgefrage Situationen beschrieb, die nach allem anderen als nach Expertise klangen – könnte die KI das markieren? Könnte sie vorsichtig darauf hinweisen, dass hier möglicherweise eine Lücke besteht?
„Das ist der Aha-Moment“, sagte Turnmeyer.
Satterfield merkte an, dass jeder, der mit Kompetenzinventaren gearbeitet hat, Varianten desselben Problems kennt. Menschen schätzen sich oft ganz anders ein, als es ihre tatsächliche Erfahrung oder ihr Verhalten vermuten lassen würde.
Der Wert des Tools würde nicht daraus entstehen, festzuhalten, was Menschen über sich selbst glaubten. Er würde aus der Kalibrierung entstehen – aus der sanften, datengestützten Reibung zwischen Selbstwahrnehmung und nachgewiesener Fähigkeit.
Die Bewertung wäre nicht nur ein Spiegel. Sie wäre eher „Spieglein, Spieglein an der Wand“, als die meisten Menschen es von Bewertungen am Arbeitsplatz gewohnt sind.
Die Realitäten der Entwicklung
Nichts davon war einfach. Und die Gruppe wusste das von Anfang an.
Die hartnäckigste Herausforderung war nicht technischer Natur. Es war der Umfang. Jede Sitzung brachte zehn neue Richtungen hervor, die allesamt wirklich wertvoll waren und das Potenzial hatten, das gesamte Projekt zu verschlingen. Turnmeyer sprach das früh und immer wieder an.
„Stellt sicher, dass es die erste Sache richtig macht, damit der Umfang nicht so ausufert, dass ihr es nicht mehr entwickeln könnt“, sagte sie.
Satterfield führte für die Gruppe ein Leitprinzip ein: den Unterschied zwischen einem minimal funktionsfähigen Produkt und einem minimal wertvollen Produkt. Ein funktionsfähiges Produkt funktioniert. Ein wertvolles Produkt sorgt dafür, dass Menschen wiederkommen.
In einem Markt, der von Bewertungstools gesättigt ist, bekommt eine Benutzeroberfläche, die bei der ersten Interaktion nichts Bedeutungsvolles liefert, keine zweite Chance zur Verbesserung. Der Maßstab ist nicht Funktionalität. Es ist der Nutzen.
Wenn das Produkt beim ersten Einstieg nicht genügend Nutzen bietet, kommen die Nutzer wahrscheinlich später nicht zurück, um zu sehen, ob es besser geworden ist.
Kelly Satterfield · HR-Führungskraft und Beraterin
Hinzu kamen die praktischen Einschränkungen, die jeder kennt, der schon einmal versucht hat, außerhalb eines Entwicklungsteams etwas aufzubauen: Bereitstellung, Zahlungsinfrastruktur, Integration in bestehende Systeme, Kontextfenster, die sich mitten in einer Sitzung schließen und stundenlange produktive Arbeit zunichtemachen.
Der erste Aufbau spiegelte den Kernablauf des Tools wider. Ein Bewerber für eine Stelle als Personalrekrutierer lädt einen Lebenslauf hoch, das Tool leitet daraus ein vorläufiges Kompetenzprofil ab und führt ihn anschließend durch eine Reihe dialogorientierter Fragen, die darauf ausgelegt sind, diese erste Einschätzung zu kalibrieren sowie um Kontext und Tiefe zu ergänzen.
Am Ende erhält eine für Einstellungen verantwortliche Führungskraft ein Bild davon, wo der Bewerber tatsächlich im Verhältnis zu einem definierten Kompetenzrahmen steht.
Fisher richtete die primäre Entwicklungsumgebung in Lovable ein – einem KI-Entwicklungswerkzeug ohne Programmierung, das durch Gespräche öffentlich zugängliche Tools erstellt, ohne Nutzer an ein bestimmtes LLM zu binden –, damit die technische Architektur mit den Gedanken der Gruppe Schritt halten konnte, ohne selbst zum Engpass zu werden.
Vom Entwurf zur Umsetzung
Bis zur vierten Sitzung entwarf die Gruppe kein abstraktes Tool mehr. Sie baute eines und stellte dabei – wie es beim Entwickeln immer geschieht – fest, dass genau in der Distanz zwischen der Idee und ihrer Umsetzung das eigentliche Lernen stattfindet.
Fisher hatte vor dem Einstieg in den Anruf ein grundlegendes benutzerdefiniertes GPT zusammengestellt, das mit Anweisungen, einem vorläufigen Kompetenzmodell und den Anfängen der Gesprächslogik ausgestattet war, die sie in früheren Sitzungen erarbeitet hatten. Der Plan war, dass alle darauf zugreifen, es gemeinsam mit Eingaben versehen und seine Stimme und sein Verhalten in Echtzeit zu kalibrieren beginnen würden. Der Plan stieß sofort auf die Realität.
Der geteilte Link funktionierte für niemanden außer mir. Arbeitsbereichsberechtigungen, Eigenheiten der Plattform und die besondere Art und Weise, wie ChatGPT den externen Zugriff handhabt, verschlangen das erste Viertel der Sitzung.
Es war eine kleine Frustration, genau die Art, die es niemals in eine Produktankündigung schaffen würde, und zugleich war sie lehrreich. Werkzeuge, die Praktiker tatsächlich zum Erstellen von Dingen verwenden, verhalten sich nicht wie Demos.
Dieser Screenshot zeigt, wie der Willkommensbildschirm für das von der Gruppe entwickelte Tool namens Talent Scout aussehen würde.
Als alle denselben Bildschirm betrachteten, geschah etwas Interessanteres. Während die Gruppe noch darüber sprach, welches Format die Kompetenzdefinitionen haben sollten, öffnete Gillies Claude in einem separaten Fenster und wandelte die Bewertungstabelle live im Anruf in strukturiertes JSON um.
„Ich verwende Claude, weil es dafür besser ist als ChatGPT“, sagte sie ohne großes Aufheben. Wenige Minuten später stellte sie die formatierte Datei in den Gruppenchat. Niemand hielt inne, um das anzuerkennen. Sie machten einfach weiter.
Diese Art der Problemlösung im laufenden Prozess – einen Engpass in ein gelöstes Problem zu verwandeln, ohne ihn zum Hauptthema des Treffens zu machen – zeichnet Praktiker aus, die diese Werkzeuge wirklich verinnerlicht haben, und unterscheidet sie von jenen, die noch lernen, sich darin zurechtzufinden.
Wer das letzte Wort hat
Satterfield warf eine Frage auf, die erhebliche Auswirkungen sowohl auf die Architektur des Tools als auch auf seine spätere Akzeptanz haben würde: Gibt die KI die abschließende Bewertung ab, oder bestätigt der Nutzer sie?
Der Unterschied ist nicht bloß kosmetischer Natur. Wenn das Tool ein Urteil wie „Auf Grundlage Ihrer Antworten befinden Sie sich bei der Kandidatenorientierung auf Stufe 2“ abgibt, positioniert es die KI als Autorität. Wenn es stattdessen eine vorläufige Einschätzung präsentiert und den Nutzer auffordert, ihr zu widersprechen, verändert sich die Dynamik vollständig. Die Beurteilung wird gemeinschaftlich statt bewertend. Der Nutzer ist Teil des Prozesses und nicht dessen Gegenstand.
„Akzeptieren Sie dieses Feedback?“, sagte Turnmeyer, als die Idee Anklang fand. „Ich liebe es irgendwie.“
Gillies arbeitete die Logik aus. Wenn der Nutzer die Bewertung nicht akzeptiert, fragt das Tool, was sich falsch anfühlt – und nutzt die Antwort dann entweder zur Neukalibrierung oder dazu, seine Einschätzung behutsam zu bestätigen, indem es die zugrunde liegenden Belege durchgeht.
Dieser Gesprächswechsel ist es, der die psychologische Sicherheit schafft, die das Tool benötigt, um wirklich nützlich zu sein. Menschen verändern sich nicht aufgrund von Feedback, dem sie nicht vertrauen. Zustimmung zu gewinnen, ist kein nettes Zusatzmerkmal, sondern der Mechanismus.
Der erste echte Test
Sie beschlossen, den Prototyp live zu testen. Turnmeyer meldete sich freiwillig mit einer bewusst dürftigen Antwort auf eine der Bewertungsfragen – der Art von Antwort, die ein unmotivierter Kandidat oder ein abgelenkter Mitarbeiter geben könnte.
Sie beschrieb, wie sie mit ihrem Vorgesetzten über eine Abweichung beim Gehalt gestritten, den Kandidaten verloren und keine Ahnung gehabt hatte, wie das Ergebnis ausgefallen war. Es war das HR-Äquivalent zu der Antwort „Ich mag Menschen einfach wirklich sehr“, wenn man gefragt wird, warum man im Personalwesen arbeiten möchte.
Das Tool bewertete die Antwort sofort. Es ordnete eine Stufe zu. Die Bewertung war ermutigend. Sie war jedoch auch falsch – nicht in faktischer Hinsicht, sondern weil sie verfrüht war. Das Tool hatte Annahmen darüber getroffen, was die Antwort implizierte, statt nach dem zusätzlichen Kontext zu fragen, den es für eine genaue Bewertung benötigt hätte.
Wenn man jemandem etwas anderes als „entspricht den Erwartungen“ geben will, muss man detaillierte Beispiele liefern. Die KI sollte sich an denselben Maßstab halten.
Erin Turnmeyer · Vizepräsidentin für Personalabläufe
Turnmeyer zog die Parallele direkt aus ihrer Praxis bei Leistungsbeurteilungen. Sie hatte von Führungskräften schon lange verlangt, konkrete Belege vorzulegen, bevor sie jemanden über oder unter „entspricht den Erwartungen“ bewerteten.
Dieselbe Disziplin sollte auch für das Tool gelten. Bevor es eine Stufe zuweist, muss es sich das Recht dazu verdienen, indem es die Fragen stellt, die die Bewertung begründbar machen würden. Wieder einmal war es das HR-Fachwissen im Raum, das die KI besser machte – nicht umgekehrt.
Satterfield fügte eine Komplikation hinzu, die das Tool übersehen hatte. Die dürftige Antwort könnte eher die Unternehmensrichtlinie als die tatsächliche Fähigkeit widergespiegelt haben.
Wenn der Vorgesetzte tatsächlich eine feste Obergrenze für die Vergütung festgelegt hatte, hätte energischeres Verhandeln am Ergebnis nichts geändert. Das Tool hatte die Person bewertet, obwohl es nach der Situation hätte fragen sollen. Klärende Fragen waren kein Detail für den letzten Feinschliff. Sie waren der entscheidende Faktor, der eine nützliche von einer anmaßenden Bewertung unterscheiden würde.
Turnmeyer nahm die Aufgabe, die Anweisungen zu formulieren, als Hausaufgabe mit: Wie bringt man ein Tool dazu, im richtigen Moment klärende Fragen zu stellen, ohne dass sich jede Interaktion wie ein Verhör anfühlt?
Dieser Screenshot zeigt ein Beispiel dafür, wie das fertige Produkt funktionieren würde: Es stellt klärende Fragen und fordert die Bewerberin auf, näher ins Detail zu gehen.
Es ist ein schwierigeres Problem, als es klingt, und ihr war sehr bewusst, dass die Messlatte ungewöhnlich hoch lag.
„Es muss besser sein als ein Mensch“, sagte sie. „Das ist der Maßstab.“
Testen als Disziplin
Die Sitzung brachte außerdem eine der praktisch nützlichsten methodischen Erkenntnisse der gesamten Kohorte hervor. Als Satterfield fragte, wie die Gruppe Tools wie dieses typischerweise testete, antworteten sowohl Turnmeyer als auch Gillies auf eine Weise, die etwas Wichtiges darüber erkennen ließ, wie rigoroses Testen in der Praxis tatsächlich aussieht.
Für ihr Tool zur Empfehlung von Leistungen, das zuverlässig erkennen musste, ob bestimmte Medikamente durch den Krankenversicherungsplan des Unternehmens abgedeckt waren, testete Turnmeyer gezielt die Grenzfälle. Nicht die offensichtlichen Medikamente oder die beliebten, auf die das Modell im Training wiederholt gestoßen wäre. Sie testete die unbekannten Medikamente in den Kategorien, bei denen am ehesten eine selbstbewusste Halluzination zu erwarten war.
„Ich habe die nicht beliebten Medikamente getestet“, sagte sie, „weil Claude mir beim Erstellen gezeigt hat, was es tut.“
Diese bewusst konfrontative Herangehensweise an Tests ist bei Entwicklern, die nicht aus einem technischen Umfeld kommen, selten. Sie ist aber genau das, was Tools, die Vertrauen gewinnen, von Tools unterscheidet, die nach einem peinlichen Fehler stillschweigend aufgegeben werden.
Bereits Erstelltes streichen
Eine Sitzung zur Neuaufstellung kurz vor den Feiertagen begann mit einer Frage, die schwieriger zu stellen war, als es klingt: Wozu dient die Funktion zum Hochladen eines Lebenslaufs eigentlich?
Gillies brachte die Frage auf. Die Bewertung forderte die Nutzer auf, sorgfältig über ihre eigenen Fähigkeiten nachzudenken. Fügte der Lebenslauf Informationen hinzu, die der Nutzer nicht direkter hätte bereitstellen können, indem er einfach die Fragen beantwortete? Niemand in der Gruppe war sicher, dass dies der Fall war. Ursprünglich sollte Zeit gespart werden, ähnlich wie bei einem Lebenslauf-Parser, aber wir waren nicht länger überzeugt, dass die Funktion dies tatsächlich leistete.
Sie beschlossen, die Funktion zu streichen.
In der Produktentwicklung ist das seltener, als es klingt. Die Gruppe hatte viel Zeit in die Upload-Funktion gesteckt – sie entwickelt, getestet und beobachtet, wie Satterfields Lebenslauf analysiert und falsch bewertet wurde. Ihre Streichung erforderte, die Logik der versunkenen Kosten außer Kraft zu setzen, die Teams dazu bringt, Dinge weiter auszubauen, in die sie bereits investiert haben.
Beginne mit dem Ergebnis vor Augen und definiere, wie ein gutes Ergebnis aussieht. Wenn du nicht erklären kannst, wozu eine Funktion dient, kannst du sie nicht verteidigen.
Turnmeyer brachte ein damit verbundenes Argument zur Methodik vor. Rückblickend dachte sie, dass sie möglicherweise schneller vorangekommen wären, wenn sie das Verhalten des Tools vollständig definiert hätten, bevor sie auch nur einen einzigen Prompt verfassten. Sie hatten nach einem agilen Modell gearbeitet – entwickeln, testen, anpassen –, obwohl die Komplexität des von ihnen entwickelten Systems möglicherweise eher einen Wasserfallansatz erfordert hätte: zuerst die Spezifikation richtig festlegen und anschließend darauf aufbauen.
Von einem anderen Tool, das sie entwickelt hatte, besaß sie ein 130-seitiges Designdokument, das ihr diese Lektion vermittelt hatte. Eine vollständige Spezifikation sagt dir nicht nur, was du entwickeln sollst. Sie sagt dir auch, was du nicht entwickelst – und das erweist sich als ebenso nützlich.
Gillies schärfte das Kernproblem des Produkts. Was auch immer das Tool auf dem Bildschirm anzeigte, musste weiterführen. Eine Bewertung, die Daten sichtbar macht, ist nicht dasselbe wie ein Tool, das dir sagt, was du damit tun sollst. Diese Lücke zwischen Ergebnis und Handlung ist der Punkt, an dem diagnostische Tools unbemerkt aufhören, nützlich zu sein – und es ist die Lücke, die die meisten von ihnen niemals schließen.
Allein entwickeln
Im Januar hatte Satterfield den größten Teil der Entwicklung selbst übernommen, während der Sog ihres 9-bis-17-Uhr-Jobs für den Rest der Gruppe zu stark und zu zeitaufwendig war, als dass noch Raum für das Projekt geblieben wäre. Schließlich wurde niemand dafür bezahlt.
Sie hatte den Upload des Lebenslaufs entfernt, wie die Gruppe vereinbart hatte. Außerdem hatte sie Spracheingabe hinzugefügt – Nutzer konnten die Bewertungsfragen nun durch Sprechen statt durch Tippen beantworten, wodurch eine dialogischere Antwortweise möglich wurde, die schwerer zu manipulieren war als ein Textfeld.
Sie hatte ChatGPT verwendet, um synthetische Testantworten zu erstellen („Ich bin ein Junior-Recruiter, der in diesem Bereich stark und in jenem schwach ist. Gib mir Antworten“), und anschließend zu Lovable gewechselt, um diese Antworten einzugeben und zu beobachten, wie das Tool sie bewertete.
Das Führungskräfte-Dashboard war die andere Hälfte der Logik des Tools – die Ansicht, die eine Leitung der Talentakquise oder ein CHRO nutzen würde, um zu sehen, wie ein Kandidat abgeschnitten hatte, wo Lücken bestanden und wie seine Fähigkeiten die Stärken und Bedürfnisse eines bestehenden Teams ergänzen könnten.
Dadurch wurde die Organisationsstruktur zu einem echten Problem, denn das Tool musste wissen, wer wen beurteilte und wer berechtigt war, die Ergebnisse zu sehen.
Satterfield hatte versucht, dieses Problem zu lösen, indem sie die Nutzer aufforderte, ihren Namen, ihre Berufsbezeichnung und den Namen ihrer Führungskraft einzugeben (wenn keine Datenintegration vorhanden war). Diese Logik versagte jedoch in einem häufigen Szenario: Eine Leitung der Talentakquise wollte die Bewertung an eine größere Recruiting-Organisation senden, die sowohl direkte als auch indirekte Berichtslinien umfasste. Die Logik zur Abbildung der Organisation war nicht differenziert genug, um diese Struktur zu berücksichtigen.
Theoretisch würden diese Informationen dem Tool einen besseren Kontext zur Rolle der Person geben, die die Bewertung durchführt, doch das Sammeln weiterer Daten machte die Dinge komplizierter.
Turnmeyer hatte eine Version dieses Problems bereits in einem anderen Kontext gelöst. Das Tool für das Leistungsmanagement, das sie für ihr eigenes Unternehmen entwickelt hatte, lief mit Google Sheets, Slack und Claude. Google Sheets speicherte die Daten. Slack war die Oberfläche, mit der die Mitarbeitenden interagierten. Claude übernahm die Analyse sowie die Erstellung von Feedback.
Die Architektur war einfacher, als es klang: eine Tabelle mit Name, E-Mail-Adresse, Joblevel und Berufsbezeichnung. Eine separate Registerkarte, die Joblevel und Kompetenzen einander zuordnete.
„Die Sicherheitsabteilung meines Unternehmens wollte mein Tool überprüfen“, erzählte sie der Gruppe. „Ich sagte, es sei in Google Docs gespeichert. Sie meinten: ‚Oh, so einfach ist das also.‘“
Einfach, aber Turnmeyer hatte es erst durch das Entwickeln gelernt. Was sie drei Wochen zuvor noch nicht gewusst hatte, war, dass es eine Protokollierungsfunktion gab – eine Funktion, die den Fortschritt eines Nutzers speichert, damit das Tool nicht zurückgesetzt wird, wenn jemand eine Pause macht und später zurückkehrt.
„Ich habe Claude beschimpft“, sagte sie, „bis es mir mitteilte, dass es eine Protokollierungsfunktion gibt.“
Das ist es, was das Entwickeln tatsächlich lehrt. Nicht das, was man zu lernen geplant hat, sondern das, von dem man nicht wusste, dass man es wissen musste.
Die grundlegende Frage
Irgendwann während der Sitzung im Januar kam das Gespräch bei der Frage an, um die es seit Monaten kreiste.
Die Gruppe sprach weiter über Architektur, Berechtigungen, Speicherung und Dashboards – allesamt reale Probleme. Doch darunter lag ein grundlegenderes Problem. Was versuchten sie eigentlich zu entwickeln und für wen?
Das Tool war ursprünglich als Diagnosetool für Auswahlentscheidungen konzipiert – etwas, das eine Führungskraft der Talentakquise an einen Kandidaten oder einen internen Mitarbeitenden senden konnte, um zu beurteilen, ob dessen tatsächliche Fähigkeiten mit den Angaben im Lebenslauf übereinstimmten, und dieses Bild vor einer Auswahlentscheidung sichtbar zu machen.
Was Sie hier sehen, ist eine Auswahl von Screenshots der Art von Bericht, den das Tool für die interviewte Person erstellt hat. Für die beurteilende Person hilft ein Dashboard mit den aktuellen Teamstärken dabei, sich darauf zu konzentrieren, wo die interviewte Person beurteilt werden sollte, um festzustellen, ob sie Schwächen des Talentakquise-Teams ausgleichen kann.
Dieser Kern hatte sich nicht verändert. Doch jede praktische Entscheidung, die sie trafen – ein Führungskräfte-Dashboard hinzuzufügen, Abonnementmodelle zu durchdenken und einen Anmeldeablauf zu entwickeln – zog sie in Richtung etwas Komplexeren.
Echtzeit-Dashboards bedeuteten fortlaufenden Zugriff, was Abonnementgebühren bedeutete und sie damit immer näher an die Art von Unternehmenssoftware brachte, deren Finanzierung oder effektive betriebliche Umsetzung vielen Organisationen Schwierigkeiten bereitet.
„Wir versuchen nicht, ein Anbieter von HCM-Software zu werden“, sagte Satterfield.
Turnmeyer war ehrlich, was ihre eigene Position betraf.
„Meine Absicht war einfach, etwas Neues zu lernen.“
Das war kein Rückzug aus dem Projekt. Es war eine zutreffende Beschreibung dessen, was das Experiment ihr bereits gebracht hatte. Sie hatte einige neue Dinge gelernt und arbeitete bereits an der Entwicklung eines neuen Tools für das Leistungsmanagement, in das sie die Erkenntnisse aus der Gruppe einfließen ließ.
Sie musste das Tool der Gruppe nicht zu einem marktfähigen Produkt machen, um einen echten Nutzen daraus gezogen zu haben.
In dieser Phase galt mein eigenes Interesse in erster Linie der redaktionellen Seite. Ich wollte eine Geschichte erzählen und etwas zeigen können – kein Abonnementprodukt, sondern eine Demonstration, über die HR-Praktiker nachdenken und vielleicht selbst etwas Ähnliches entwickeln konnten.
Das Schreiben dieses Artikels war ein Teil davon. Konnte ich einen Leitfaden zum Herunterladen erstellen? Später vielleicht eine Live-Veranstaltung, bei der die Gruppe über ihre Arbeit sprechen, ein Publikum mit dem Tool interagieren lassen und das Gespräch als Podcast aufzeichnen konnte? Ich hatte viele Ideen, aber der zeitliche Spielraum, um sie umzusetzen, wurde immer kürzer, während sich die Ziele des neuen Jahres vor uns allen auftürmten.
Satterfields Interesse war am stärksten kommerziell ausgerichtet, und sie machte daraus keinen Hehl. Sie war daran interessiert, das Tool später zu einem marktfähigen Produkt zu machen. Sie würde das nicht allein tun. Aber sie war bereit, weiter auf etwas hinzuarbeiten, das eines Tages verkauft werden könnte.
Diese Dreiteilung der Absichten – Lernen, Geschichten erzählen, Produktentwicklung – ist wahrscheinlich jeder Gruppe dieser Art inhärent. Das offene Gespräch darüber im Januar war hilfreicher, als so zu tun, als hätten alle von Anfang an dasselbe gewollt.
Die Demo als Antwort
Die Frage, wie man Menschen das Tool ausprobieren lassen könnte, war seit der Einführung des Uploads von Lebensläufen ungeklärt geblieben. Tests mit echten Nutzern sind wertvoll, bringen aber eigene Probleme mit sich. Das Tool muss zuverlässig funktionieren, die Nutzer brauchen genügend Kontext, um zu wissen, was sie tun, und eine schlechte erste Erfahrung lässt sich nur schwer wiedergutmachen.
Turnmeyer bot die einfachste Lösung an, die die Gruppe bisher in Betracht gezogen hatte.
Sie hatte sich Demoaufzeichnungen angesehen – kurze Rundgänge von ein oder zwei Minuten, die zeigten, wie ein Tool funktionierte, ohne dass die Zuschauer es tatsächlich benutzen mussten. Sie schlug vor, dass das ausreichen könnte. Die Menschen könnten das Tool in Aktion sehen, verstehen, was es tat und warum, und mit dem Gefühl zurückbleiben, dass es machbar war.
Sie müssten sich nicht durch eine Anmeldung navigieren, kein Organigramm bereitstellen oder stecken bleiben, wenn eine Frage der Einschätzung nicht zu ihrer Situation passte.
Das Feedback, das ich zu vielen Blogs bekomme, die ich schreibe, ist, dass die Leute nicht wirklich exakt dasselbe kopieren und einfügen wollen. Sie wollen einfach nur wissen, dass sie es schaffen können.
Erin Turnmeyer · VP für Personalbetrieb
Diese Beobachtung weist auf etwas Reales darüber hin, wie Personalfachleute derzeit mit KI-Tools umgehen. Die Lücke, die viele von ihnen überbrücken müssen, liegt nicht zwischen dem Wissen, dass etwas existiert, und dessen Nutzung. Sie liegt zwischen dem Glauben, überhaupt dazu fähig zu sein, so etwas zu tun.
Eine Demo, die zeigt, wie Personalfachleute ihr eigenes Tool entwickeln, beantwortet eine andere Frage als ein fertiges Produkt – nicht „Ist dieses Tool gut?“, sondern „Hätte jemand wie ich es erstellen können?“
Die Idee wurde gut aufgenommen. Sie ging auf die Bedenken beim Testen ein, verringerte die Komplexität, etwas zu teilen, das noch nicht produktionsreif war, und hielt den Schwerpunkt dort, wo die Gruppe ihn von Anfang an haben wollte: auf dem Prozess und dem Denken, nicht nur auf dem Ergebnis.
Was das Experiment lehrte: Ein Leitfaden für HR-Entwickler
- Beginnt mit dem Problem, nicht mit der Technologie. Die anfängliche Begeisterung der Gruppe für die Stimmungsanalyse war echt, führte sie aber von einem leichter lösbaren und wertvolleren Problem weg. Der Schwenk zur Kompetenzkartierung funktionierte, weil er bei einem realen Anwendungsfall ansetzte, der bereits in der Praxis getestet worden war.
- Maßgeschneidert schlägt allgemein. Jeder Teilnehmer hatte die Grenzen von HR-Plattformen für Unternehmen erlebt. Die für bestimmte Kontexte entwickelten Tools – Turnmeyers Empfehlungsprogramm für Sozialleistungen, Satterfields Heatmap – schnitten besser ab als die fertigen Alternativen. Das Argument für die Entwicklung eigener Lösungen war noch nie so stark, und die Hürden waren noch nie so niedrig.
- Der Gegencheck ist das A und O. Selbsteinschätzungen sind nur so gut wie die Selbsterkenntnis der Menschen, und diese ist bekanntermaßen unzuverlässig. Der eigentliche Wert eines Tools liegt in seiner Fähigkeit, nachzufragen, herauszufordern und behutsam neu zu justieren – nicht lediglich darin, festzuhalten, was Menschen über sich selbst glauben.
- Das wertvolle Minimum, nicht das lebensfähige Minimum. Wenn die erste Version nichts liefert, das einen Nutzer zur Rückkehr bewegen möchte, spielt die Roadmap keine Rolle. Entwickelt für den ersten Eindruck, nicht für den fünften.
- Akzeptanz ist strukturell, nicht nebensächlich. Die Frage, ob die KI die endgültige Bewertung erstellt oder der Nutzer sie bestätigt, ist kein UX-Detail. Sie entscheidet darüber, ob das Tool eine Autorität oder ein Partner ist, und diese Unterscheidung prägt alles daran, wie es aufgenommen und genutzt wird.
- Streicht Funktionen, die ihr bereits entwickelt habt. Die Logik versunkener Kosten führt dazu, dass Teams Dinge weiter ausbauen, in die sie investiert haben, lange nachdem diese Dinge ihren Platz nicht mehr rechtfertigen. Wenn ihr nicht erklären könnt, wofür eine Funktion gedacht ist, habt ihr damit die Antwort. Sie zu streichen ist Produktdisziplin, kein Scheitern.
- Testet konfrontativ und frühzeitig. Findet Menschen, die euch sagen werden, dass das Tool schlecht ist. Gebt ihm die schlechteste vernünftige Eingabe, die ihr euch vorstellen könnt, und seht, was es tut. Berücksichtigt die Sonderfälle, bevor ihr die typischen Fälle ausarbeitet. Die Glaubwürdigkeit des Tools hängt davon ab, wie es mit den Momenten umgeht, für die es nicht entwickelt wurde.
- Das Tool sollte sich das Recht zur Bewertung verdienen. Zu einer Bewertung zu springen, bevor genügend Fragen gestellt wurden, ist Anmaßung, keine Effizienz. Klärende Fragen machen die Einschätzung belastbar, und ihre Belastbarkeit sorgt dafür, dass das Feedback Wirkung zeigt.
- Seid ehrlich, warum alle dabei sind. Unterschiedliche Absichten innerhalb einer Gruppe sind kein Problem, das man verwalten muss – sie sind Informationen. Wenn man sie früh offenlegt, bewahrt das alle davor, auf ein Ziel hinzuarbeiten, das tatsächlich nur einige von ihnen teilen.
- Die schwierigsten Gespräche sind die wichtigsten. Die Gruppe entwickelte ein Tool zur Bewertung von HR-Kompetenzen und führte dabei eines der ehrlichsten Gespräche über die Grenzen von HR, an die sich jemand von ihnen erinnern konnte. Dieses Gespräch – über rückwärtsgewandte Rahmenwerke, über die Lücke zwischen Prüfungswissen und situationsbezogenem Urteilsvermögen – war ebenso sehr das Produkt wie das Tool.
Die Sitzungen, die als Verpflichtung zu vier Gesprächen begonnen hatten, zogen sich bis in den Winter und dann bis ins neue Jahr. Der Prototyp entwickelte sich weiter. Die Absichten der Menschen, die ihn entwickelt hatten, waren auf eine Weise klarer geworden, die sich nicht sauber auflösen ließ.
Satterfield war noch immer am Bauen. Turnmeyer hatte das, was sie gelernt hatte, übernommen und an anderer Stelle angewendet. Gillies hatte die Gruppe dazu gebracht, disziplinierter damit umzugehen, was das Tool eigentlich tun sollte. Ich schrieb die Geschichte von alldem.
Turnmeyer hatte zu Beginn des Prozesses etwas gesagt, das sich als wahr erwies: Sie baute nicht, weil man sie darum gebeten hatte, sondern weil sie es verstehen musste.
Dieses Verständnis dafür, was KI-Tools tatsächlich tun, worin sie sich irren und was nötig ist, um sie nützlich zu machen, war in keiner Konferenzsitzung und keiner Produktdemo eines Anbieters zu finden. Es entstand aus den Entscheidungen, die die Gruppe traf, den Funktionen, die sie strich, und den Momenten, in denen das Tool jemanden falsch einschätzte und sie herausfinden mussten, warum.
Die nützlichsten Dinge, die die Gruppe hervorbrachte, befanden sich nicht im Prototyp. Sie lagen in den Überlegungen, die dahinterstanden.