Cuando los líderes de RR. HH. se convierten en creadores
Conclusión del experimento: Los proyectos colaborativos de IA ofrecieron perspectivas profundas sobre las capacidades de RR. HH., más allá del simple desarrollo de herramientas.
Enfoque en el problema: Cambiar del análisis de sentimientos al mapeo de habilidades puso de relieve la importancia de definir objetivos claros y alcanzables.
Escepticismo ante la IA: Los profesionales de RR. HH. afrontan importantes dificultades relacionadas con la rendición de cuentas y la transparencia en las plataformas de IA existentes.
Estructura de la herramienta: La herramienta de evaluación mediante IA hizo hincapié en la colaboración, permitiendo a los usuarios confirmar o cuestionar los comentarios generados por la IA.
Pruebas adversariales: El desarrollo satisfactorio de una herramienta requiere pruebas rigurosas con entradas diversas para abordar eficazmente los casos límite.
Las reuniones estaban programadas para durar una hora. Casi siempre se alargaban.
Eso no es inusual cuando se reúne a un grupo de profesionales de RR. HH. para hablar sobre IA. Lo inusual era lo que se les estaba pidiendo que hicieran con esa conversación. No analizarla, ni publicar un artículo de opinión sobre ella, sino realmente construir algo.
En el otoño de 2025, reuní lo que llamaba cohortes de creación: un pequeño grupo de profesionales de RR. HH. y operaciones de personas que había identificado como personas que ya estaban haciendo el trabajo y pensando en los límites de lo que la profesión de RR. HH. podía hacer con la IA.
Sigue leyendo—y sigue liderando de manera más inteligente
Crea una cuenta gratuita para terminar este artículo y unirte a una comunidad de líderes visionarios que están desbloqueando herramientas, guías prácticas e ideas para prosperar en la era de la IA.
Have an account? Log In
La hipótesis era sencilla. Las personas más cercanas a los problemas son quienes están mejor posicionadas para crear las soluciones. La pregunta era si podrían hacerlo.
En total, crearía cuatro cohortes y, por el camino, me daría cuenta de que definir los objetivos de estas sesiones es más fácil de decir que de hacer. Al final, la mayoría de las cohortes se fueron desvaneciendo, con dificultades para cumplir la visión inicial o establecer un único objetivo. Los calendarios, las cargas de trabajo y las exigencias de nuestros trabajos reales a menudo daban lugar a conversaciones que producían grandes ideas, pero nunca las convertían en realidad.
Pero una cohorte sí logró reunirse y llegar hasta el final, en la medida de sus posibilidades. Lo cierto es que cuanto más te adentras en el laberinto de construir algo por tu cuenta, más difícil se vuelve respetar una visión compartida y afrontar el desafío de ingeniería.
Esta historia es un relato de lo que surgió de aquellas sesiones y se la ofrezco como estudio de caso para construir sus propias soluciones.
La cohorte
No eran escépticos de la IA a los que hubiera que convencer. Eran profesionales que ya habían apostado por este momento. Lo que la cohorte les ofrecía era un espacio estructurado para dejar de asesorar y empezar a crear.
La primera conversación honesta
La primera sesión sacó a la luz algo que rara vez aparece en los comentarios publicados sobre RR. HH.: lo frustrados que están realmente estos profesionales con las herramientas que se supone que deben utilizar.
Turnmeyer marcó el tono. Había intentado obtener documentación técnica sobre cómo funcionaba el análisis de sentimientos dentro de BambooHR, Paycom y Gusto, no para descartar las herramientas, sino porque su equipo jurídico necesitaba comprenderlas antes de aprobar su uso.
Ni los equipos de ventas ni los representantes jurídicos pudieron responder a sus preguntas. Las funciones de IA existían. La responsabilidad sobre su funcionamiento no.
Gillies afrontaba una tensión paralela. Algunas voces internas habían expresado su preocupación por el impacto ambiental de la IA, y algunos compañeros querían simplemente prohibir el uso de la IA por parte de los empleados. Gillies se opuso.
Prohibir por completo la IA conduce a un uso encubierto y a un aumento del riesgo. Adoptar la IA con límites de seguridad es un enfoque mejor.
Melina Gillies · Responsable de Personas, Flex Networks
Lo que surgió de esa primera hora fue un diagnóstico con el que el grupo podía estar de acuerdo. Las funciones de IA integradas en las plataformas empresariales de RR. HH. eran, como explicó Gillies, «a menudo básicas y carecen de funcionalidad».
Las herramientas que realmente funcionan tienden a ser personalizadas: creadas para problemas, contextos y empresas específicos. Turnmeyer quería menos herramientas, no más, una idea que escucho a menudo de responsables de personas y operaciones. Podía imaginar un futuro en el que una IA capaz, alimentada con los documentos adecuados, hiciera innecesario un HRIS.
También se enfrentaron a algo que rara vez se aborda de forma tan directa: la ética del seguimiento del comportamiento. La idea de utilizar las tasas de rechazo de reuniones, las interrupciones inusuales en los inicios de sesión del sistema o los horarios de trabajo atípicos como indicadores indirectos de desinterés surgió desde el principio.
También surgieron los límites de ese enfoque. Satterfield señaló un riesgo al que acaba enfrentándose toda herramienta de compromiso: la fatiga por inacción. Si recopilas datos y no actúas sobre ellos de forma visible, los empleados dejan de confiar en el sistema. Los datos se convierten en ruido y la herramienta se convierte en teatro de IA.
No estaban preparados para crear una herramienta de análisis de sentimientos. Era demasiado amplia, estaba cargada de demasiados dilemas éticos y era demasiado fácil equivocarse de forma catastrófica. Así que cambiaron de rumbo.
Encontrar el problema adecuado
La segunda sesión comenzó con el reconocimiento honesto de que la dirección original era demasiado ambiciosa y demasiado ambigua.
«No sé si eso está midiendo el compromiso», dijo Turnmeyer, «o si simplemente está midiendo algo que requiere una conversación».
Esa distinción importa más de lo que podría parecer. Muchas tecnologías de RR. HH. cometen el error de tratar los datos como un sustituto de la conversación. El grupo intentaba utilizar la IA para poner de manifiesto los momentos en que era necesario mantener una conversación y, después, mejorar esa conversación.
Satterfield introdujo la idea que serviría de eje para el resto del proyecto. Durante una congelación de contrataciones en una empresa anterior, había creado una autoevaluación de habilidades para su equipo de adquisición de talento: una forma de mapear lo que las personas podían hacer frente a lo que realmente querían hacer, generando un mapa de calor que hacía que las decisiones de reasignación fueran más humanas y estratégicas.
No funcionaba con IA. Era un formulario de Microsoft. Pero la lógica subyacente era sólida, el caso de uso era real y ella había visto que funcionaba.
«Los grandes proveedores están intentando hacer esto, pero todavía nadie lo está haciendo realmente bien y muchas empresas no tienen un presupuesto asignado para este tipo de tecnología además de su HRIS principal», dijo.
El grupo vio la oportunidad. ¿Y si creaban una versión nativa de IA? Una que fuera conversacional en lugar de clínica, orientada al futuro en lugar de impulsada por el cumplimiento normativo y con un precio pensado para responsables individuales de RR. HH. en lugar de estar bloqueada tras contratos empresariales.
La forma en que RR. HH. habla con RR. HH. sobre RR. HH. es dinámicamente diferente. Eso puede aportar un valor real y la mayoría de las herramientas lo pasan completamente por alto.
Melina Gillies · Responsable de Personas, Flex Networks
Fisher, mientras escuchaba al grupo trabajar en las posibilidades, hizo una observación que replanteó el potencial del proyecto. Había experimentado ambos extremos del espectro de RR. HH.: el enfoque transaccional centrado primero en el cumplimiento y los marcos, y el profesional, menos habitual, centrado primero en las personas, que le hablaba «como una persona que sentía que estaba de mi lado».
«El lenguaje del segundo tipo», dijo, «nunca parecía proceder de un marco escrito décadas atrás. Simplemente sentaba bien».
Gillies se aferró a esa idea. El elemento diferenciador de su herramienta, argumentó, era el tono y la estructura. ¿Y si pudiera reproducir la forma en que los profesionales de RR. HH. realmente se hablan entre sí en una conferencia, entre sesiones y fuera de grabación? ¿Y si entendiera «políticamente hábil» no como una casilla de verificación, sino como algo cargado, discutido y complejo según la situación, sobre lo que los profesionales con experiencia debaten entre ellos?
Esa era la dirección: una herramienta de evaluación previa a la contratación diseñada para responsables de RR. HH. y adquisición de talento que necesitan una forma mejor de evaluar a candidatos a puestos de selección antes de incorporarlos. No un cuestionario de personalidad ni un filtro de currículos, sino un diagnóstico estructurado y conversacional que pudiera indicar a un responsable de contratación si la persona sentada frente a él realmente sabía hacer el trabajo. Una herramienta que se sintiera menos como una evaluación del desempeño y más como una conversación con alguien que entendiera la selección desde dentro.
El momento revelador
Para la tercera sesión, el grupo ya estaba inmerso en la arquitectura de la herramienta: qué competencias evaluar, cómo estructurarlas por niveles y cómo tener en cuenta la brecha entre lo que las personas dicen que pueden hacer y lo que realmente pueden hacer.
La crítica a los marcos existentes vino de Gillies, quien describió el modelo de competencias de SHRM como «muy tradicional y muy orientado al pasado en algunos aspectos». La profesión seguía, en sus palabras, en una «resaca posindustrial»: basada en el cumplimiento normativo, jerárquica y diseñada para un mundo que ya estaba desapareciendo.
Su herramienta necesitaba orientarse hacia otra cosa, no hacia lo que los líderes de RR. HH. necesitaban saber, sino hacia lo que necesitaban ser capaces de hacer.
¿Estás dispuesto a mantener una conversación con el CEO sobre su desempeño? Si no lo estás, no eres un experto en conversaciones difíciles.
Erin Turnmeyer · Vicepresidenta de Operaciones de Personal
Turnmeyer tenía un ejemplo revelador. Recientemente había hecho el examen SPHR. Lo que este le exigía saber —estatutos, definiciones de procedimiento, reglas de clasificación— era algo que cualquier profesional competente de RR. HH. simplemente buscaría.
Las habilidades difíciles no eran el material de certificación. Eran cosas como: ¿Puedes sentarte frente a un CEO y decirle algo que no quiere oír? ¿Puedes defender a un empleado cuando el caso de negocio es ambiguo? Memorizar los códigos laborales no responde a esas preguntas.
Fisher fue más allá. Había pasado años en gestión del cambio y había descubierto que la variable más predictiva de la capacidad de una organización para afrontar una transformación no era ninguna habilidad específica. Era la relación de una persona con la ambigüedad.
Lograr que alguien explique hasta qué punto se siente cómodo estando incómodo —o con el ritmo del cambio en general— es un indicador muy importante de tu capacidad para desenvolverte en este nuevo mundo.
Tim Fisher · Director de IA, Black and White Zebra
Entonces llegó lo que el grupo más tarde llamaría el ingrediente secreto.
Gillies planteó una pregunta. ¿Y si la herramienta incorporara una comprobación cruzada? Si alguien se calificara como experto en gestión de conflictos, pero luego, en una respuesta en lenguaje natural a una pregunta de seguimiento, describiera situaciones que no sonaran en absoluto a experiencia, ¿podría la IA señalarlo? ¿Podría decir, con tacto, que quizá había una brecha?
"Ese es el momento de revelación", dijo Turnmeyer.
Satterfield señaló que cualquiera que haya trabajado con inventarios de habilidades ha visto versiones del mismo problema. A menudo, las personas se califican de manera muy distinta de lo que sugerirían su experiencia real o su comportamiento.
El valor de la herramienta no provendría de registrar lo que las personas creían de sí mismas. Provendría de la calibración: la fricción amable e informada por datos entre la autopercepción y la capacidad demostrada.
La evaluación no sería solo un espejo. Sería más bien un «espejo, espejito en la pared» que la mayoría de las personas está acostumbrada a recibir de las evaluaciones laborales.
Las realidades de la creación
Nada de esto era fácil. Y el grupo lo sabía desde el principio.
El desafío más persistente no era técnico. Era el alcance. Cada sesión generaba diez nuevas direcciones, todas realmente valiosas y capaces de absorber por completo el proyecto. Turnmeyer lo señaló desde el principio y lo repitió a menudo.
"Asegúrense de que haga bien lo primero, para que el alcance no se descontrole tanto que no puedan crearlo", dijo.
Satterfield introdujo un principio rector para el grupo: la diferencia entre un Producto Mínimo Viable y un Producto Mínimo Valioso. Un producto viable funciona. Un producto valioso hace que las personas quieran volver.
En un mercado saturado de herramientas de evaluación, una interfaz que no ofrezca algo significativo en la primera interacción no tendrá una segunda oportunidad para mejorar. El estándar no es la funcionalidad. Es el valor.
Si el producto no proporciona suficiente valor al entrar por primera vez, es probable que los usuarios no vuelvan más adelante para comprobar si ha mejorado.
Kelly Satterfield · Líder y consultora de RR. HH.
También estaban las limitaciones prácticas que conoce bien cualquiera que haya intentado crear algo fuera de un equipo de desarrollo: implementación, infraestructura de pagos, integración con sistemas existentes, ventanas de contexto que se cierran a mitad de la sesión y borran horas de trabajo productivo.
La primera versión reflejaba el flujo central de la herramienta. Un candidato para un puesto de reclutador sube un currículum, la herramienta infiere un perfil preliminar de habilidades y luego lo guía a través de una serie de preguntas conversacionales diseñadas para calibrar y añadir contexto y profundidad a esa evaluación inicial.
Al final, un responsable de contratación obtiene una imagen de la situación real del candidato frente a un marco de competencias definido.
Fisher configuró el entorno principal de desarrollo en Lovable —un creador de IA sin código que genera herramientas orientadas al público mediante conversaciones, sin obligar a los usuarios a utilizar un LLM específico— para que la arquitectura técnica pudiera seguir el ritmo de las ideas del grupo sin convertirse en su propio cuello de botella.
Del plano a la creación
Para la cuarta sesión, el grupo ya no estaba diseñando una herramienta abstracta. Estaba construyendo una y descubriendo, como siempre les ocurre a quienes crean, que la distancia entre la idea y la ejecución es precisamente donde tiene lugar el aprendizaje real.
Fisher había ensamblado un GPT personalizado de nivel básico antes de que comenzara la llamada, cargado con instrucciones, un marco preliminar de competencias y los comienzos de la lógica conversacional que habían trazado en sesiones anteriores. El plan era que todos pudieran acceder a él, darle indicaciones de forma colaborativa y empezar a calibrar su voz y comportamiento en tiempo real. El plan se topó inmediatamente con la realidad.
El enlace compartido no funcionaba para nadie excepto para mí. Los permisos del espacio de trabajo, las peculiaridades de la plataforma y la forma particular en que ChatGPT gestiona el acceso externo consumieron el primer cuarto de la sesión.
Era una pequeña frustración, precisamente del tipo que nunca aparecería en un anuncio de producto, y resultó instructiva. Las herramientas que los profesionales realmente utilizan para construir cosas no se comportan como las demostraciones.
Esta captura de pantalla muestra cómo terminaría viéndose la pantalla de bienvenida de la herramienta que construyó el grupo, llamada Talent Scout.
Una vez que todos estaban mirando la misma pantalla, ocurrió algo más interesante. Mientras el grupo aún debatía qué formato debían tener las definiciones de competencias, Gillies abrió Claude en una ventana aparte y convirtió la tabla de puntuación en JSON estructurado, en directo, durante la llamada.
«Uso Claude porque es mejor que ChatGPT para esto», dijo sin darle mayor importancia. Unos minutos después, dejó el archivo formateado en el chat del grupo. Nadie se detuvo para reconocerlo. Simplemente siguieron adelante.
Ese tipo de resolución de problemas sobre la marcha —convertir un cuello de botella en un problema resuelto sin convertirlo en el acontecimiento principal de la reunión— es lo que distingue a los profesionales que han interiorizado verdaderamente estas herramientas de aquellos que aún están aprendiendo a desenvolverse con ellas.
Quién tiene la última palabra
Satterfield planteó una pregunta que tendría importantes implicaciones tanto para la arquitectura de la herramienta como para su recepción final: ¿la IA genera la calificación final o la confirma el usuario?
La distinción no es meramente estética. Si la herramienta emite un veredicto como «Según tus respuestas, estás en el nivel 2 en orientación al candidato», posiciona a la IA como la autoridad. Si, en cambio, presenta una evaluación provisional e invita al usuario a cuestionarla, la dinámica cambia por completo. La evaluación se vuelve colaborativa en lugar de evaluativa. El usuario participa en el proceso, no es su objeto.
«¿Aceptas estos comentarios?», dijo Turnmeyer cuando surgió la idea. «Me encanta».
Gillies desarrolló la lógica. Si el usuario no acepta la calificación, la herramienta pregunta qué le parece incorrecto y después utiliza la respuesta para recalibrar su evaluación o reafirmarla cuidadosamente, repasando las pruebas.
Ese intercambio conversacional es lo que crea la seguridad psicológica que la herramienta necesita para ser verdaderamente útil. Las personas no cambian basándose en comentarios en los que no confían. Conseguir aceptación no es una función secundaria, es el mecanismo.
La primera prueba real
Decidieron probar el prototipo en directo. Turnmeyer se ofreció como voluntaria para dar deliberadamente una respuesta escueta a una de las preguntas de evaluación, del tipo que podría dar un candidato poco comprometido o un empleado distraído.
Describió una discusión con su gerente por una discrepancia salarial, la pérdida del candidato y el hecho de no tener idea de cuál había sido el resultado. Era el equivalente en RR. HH. a responder «Es que me encanta la gente» cuando te preguntan por qué quieres trabajar en Recursos Humanos.
La herramienta la evaluó de inmediato. Le asignó un nivel. Era alentadora. También estaba equivocada, no en términos fácticos, sino por prematura. Había hecho suposiciones sobre lo que implicaba la respuesta en lugar de solicitar el contexto adicional que necesitaría para evaluar con precisión.
Si vas a darle a alguien una calificación distinta de «cumple las expectativas», debes proporcionar ejemplos detallados. La IA debería exigirse el mismo nivel.
Erin Turnmeyer · Vicepresidenta de Operaciones de Personas
Turnmeyer estableció directamente el paralelismo con su práctica de evaluación del desempeño. Desde hacía mucho tiempo exigía a los gerentes que proporcionaran pruebas específicas antes de calificar a alguien por encima o por debajo de «cumple las expectativas».
La misma disciplina debería aplicarse a la herramienta. Antes de asignar un nivel, hay que ganarse el derecho a hacerlo formulando las preguntas que permitirían justificar la calificación. Una vez más, era la experiencia de RR. HH. presente en la sala la que mejoraba la IA, y no al contrario.
Satterfield añadió una complicación que la herramienta había pasado por alto. La respuesta escueta podría haber reflejado una política y no una habilidad.
Si el gerente había establecido realmente un límite máximo fijo para la compensación, abogar con más insistencia no habría cambiado el resultado. La herramienta había evaluado a la persona cuando debería haber estado preguntando por la situación. Las preguntas aclaratorias no eran un elemento de acabado. Eran lo que separaría una evaluación útil de una presuntuosa.
Turnmeyer se llevó como tarea la redacción de instrucciones: ¿cómo se puede indicar a una herramienta que formule preguntas aclaratorias en los momentos adecuados sin hacer que cada interacción parezca un interrogatorio?
Esta captura de pantalla muestra un ejemplo de lo que haría el producto final: formular preguntas aclaratorias y animar al candidato a profundizar más.
Es un problema más difícil de lo que parece, y ella era plenamente consciente de que el listón era inusualmente alto.
«Tiene que ser mejor que un humano», dijo. «Ese es el estándar».
Las pruebas como disciplina
La sesión también produjo una de las ideas metodológicas más útiles desde el punto de vista práctico de toda la cohorte. Cuando Satterfield preguntó cómo probaba normalmente el grupo herramientas como esta, tanto Turnmeyer como Gillies respondieron de maneras que revelaron algo importante sobre cómo son realmente las pruebas rigurosas en la práctica.
Para su herramienta de recomendación de prestaciones, que tenía que identificar con precisión si determinados medicamentos estaban cubiertos por el plan de salud de la empresa, Turnmeyer hizo pruebas específicas con los casos extremos. No con los medicamentos obvios, los populares que el modelo habría encontrado repetidamente durante el entrenamiento. Probó los menos conocidos, en las categorías con mayor probabilidad de producir una alucinación expresada con confianza.
«Fui a probar con los medicamentos que no son populares», dijo, «porque Claude me mostró lo que estaba haciendo mientras lo construía».
Ese nivel de intencionalidad adversarial en las pruebas es poco habitual en personas que desarrollan herramientas fuera de un contexto de ingeniería. También es exactamente lo que separa las herramientas que se ganan la confianza de aquellas que se abandonan silenciosamente después de un fallo vergonzoso.
Eliminar lo que ya has construido
Una sesión de reorganización justo antes de las vacaciones comenzó con una pregunta más difícil de formular de lo que parece: ¿para qué sirve realmente la función de carga del currículum?
Gillies la planteó. La evaluación pedía a los usuarios que reflexionaran detenidamente sobre sus propias capacidades. ¿Añadía el currículum información que el usuario no pudiera proporcionar de forma más directa, simplemente respondiendo a las preguntas? Nadie del grupo estaba seguro de que así fuera. La intención original había sido ahorrar tiempo, como un analizador de currículos, pero ya no estábamos convencidos de que cumpliera ese objetivo.
Acordaron eliminarla.
Esto es menos habitual de lo que parece en el desarrollo de productos. El grupo había dedicado mucho tiempo real a la función de carga: desarrollarla, probarla y observar cómo se analizaba y puntuaba incorrectamente el currículum de Satterfield. Eliminarla requería anular la lógica del coste hundido que hace que los equipos sigan añadiendo cosas en las que ya han invertido.
Empieza teniendo presente el objetivo final y define cómo sería un buen resultado. Si no puedes explicar para qué sirve una función, no puedes defenderla.
Turnmeyer planteó un argumento relacionado con la metodología. En retrospectiva, pensaba que podrían haber avanzado más rápido si hubieran definido por completo el comportamiento de la herramienta antes de escribir una sola instrucción. Habían estado siguiendo algo parecido a un modelo ágil —construir, probar, ajustar—, cuando la complejidad de lo que estaban creando quizá requería un enfoque más próximo al modelo en cascada: definir primero correctamente las especificaciones y construir después conforme a ellas.
Tenía un documento de diseño de 130 páginas de otra herramienta que había creado y que le había enseñado esta lección. Una especificación completa no solo te dice qué debes construir. También te dice qué no estás construyendo, lo cual resulta ser igual de útil.
Gillies precisó el problema central del producto. Fuera lo que fuese que la herramienta mostrara en pantalla, tenía que ir más allá. Una evaluación que muestra datos no es lo mismo que una herramienta que te dice qué hacer con ellos. Esa brecha entre el resultado y la acción es donde las herramientas de diagnóstico dejan de ser útiles silenciosamente, y es la brecha que la mayoría de ellas nunca cierra.
Construir en solitario
Para enero, Satterfield había estado haciendo por su cuenta la mayor parte del desarrollo, mientras el resto del grupo sentía con demasiada fuerza el peso de sus trabajos de 9 a 5, que consumían demasiado tiempo como para dejar espacio al proyecto. Al fin y al cabo, a nadie le pagaban por esto.
Había eliminado la carga del currículum, tal como había acordado el grupo. Había añadido la entrada de voz: ahora los usuarios podían responder a las preguntas de la evaluación hablando en lugar de escribir, lo que permitía un estilo de respuesta más conversacional y más difícil de manipular que un campo de texto.
Había estado utilizando ChatGPT para generar respuestas de prueba sintéticas («Soy un reclutador junior que destaca en esto y es débil en esto; dame respuestas»), y después cambiaba a Lovable para introducir esas respuestas y observar cómo las puntuaba la herramienta.
El panel de control del líder era la otra mitad de la lógica de la herramienta: la vista que usaría un director de AT o un CHRO para ver la puntuación obtenida por un candidato, dónde estaban las brechas y cómo sus capacidades podían complementar las fortalezas y necesidades de un equipo existente.
Eso convertía la estructura organizativa en un problema real, porque la herramienta necesitaba saber quién evaluaba a quién y quién tenía autoridad para ver los resultados.
Satterfield había intentado resolverlo pidiendo a los usuarios que introdujeran su nombre, cargo y el nombre de su responsable (ante la ausencia de una integración de datos). Pero esa lógica fallaba en un escenario común: el de un director de adquisición de talento que quería enviar la evaluación a una organización de selección más amplia que incluía relaciones de dependencia tanto directas como indirectas. La lógica de mapeo organizativo no tenía el nivel de detalle suficiente para contemplar esa estructura.
En teoría, esta información daría a la herramienta un mayor contexto sobre el rol de la persona que realiza la evaluación, pero recopilar más datos complicaba las cosas.
Turnmeyer ya había resuelto una versión de este problema en un contexto diferente. La herramienta de gestión del desempeño que había creado para su propia empresa funcionaba con Google Sheets, Slack y Claude. Google Sheets almacenaba los datos. Slack era la interfaz con la que interactuaban los empleados. Claude se encargaba del análisis y de generar los comentarios.
La arquitectura era más sencilla de lo que parecía: una hoja de cálculo con nombre, correo electrónico, nivel profesional y cargo. Una pestaña independiente que relacionaba los niveles profesionales con las competencias.
«El equipo de seguridad de mi empresa quería revisar mi herramienta», contó al grupo. «Les dije que estaba almacenada en Google Docs. Respondieron: “Ah, es así de sencillo”».
Sencillo, pero Turnmeyer solo lo descubrió al construirla. Lo que no sabía tres semanas antes era que existían los registros: una función que guarda el progreso de un usuario para que la herramienta no se reinicie cuando alguien se aleja y vuelve.
«Le gritaba a Claude», dijo, «hasta que me dijo que existían los registros.
Eso es lo que realmente enseña construir. No aquello que planeabas aprender, sino aquello que no sabías que necesitabas saber.
La pregunta subyacente
En algún momento de la sesión de enero, la conversación llegó a la pregunta alrededor de la cual había estado girando durante meses.
El grupo no dejaba de hablar de arquitectura, permisos, almacenamiento y paneles de control: todos eran problemas reales. Pero debajo de ellos había uno más fundamental. ¿Qué intentaban construir realmente y para quién?
La herramienta, tal como se había concebido originalmente, era un diagnóstico de selección: algo que un líder de AT podía enviar a un candidato o a un empleado interno para evaluar si sus capacidades reales coincidían con lo que figuraba en su currículum y sacar a la luz esa imagen antes de tomar una decisión de selección.
Lo que se ve aquí es una selección de capturas de pantalla del tipo de informe que la herramienta generaba para la persona entrevistada. Para el evaluador, un panel de control con las fortalezas actuales del equipo le ayuda a centrarse en los aspectos que debe evaluar de la persona entrevistada para comprobar si aborda las debilidades del equipo de AT.
Ese núcleo no había cambiado. Pero cada decisión práctica que estaban tomando —añadir un panel de control para líderes, analizar modelos de suscripción y definir un flujo de inicio de sesión— los acercaba a algo más complejo.
Los paneles de control en tiempo real implicaban un acceso continuo, lo que suponía cuotas de suscripción y los acercaba cada vez más al tipo de herramientas empresariales que a muchas organizaciones les cuesta permitirse o poner en funcionamiento de manera eficaz.
«No intentamos convertirnos en un proveedor de HCM», dijo Satterfield.
Turnmeyer fue sincera sobre su posición.
«Mi intención era simplemente aprender algo nuevo».
Eso no suponía retirarse del proyecto. Era una descripción precisa de lo que el experimento ya había producido para ella. Había aprendido algunas cosas nuevas y ya estaba avanzando en la creación de una nueva herramienta de gestión del desempeño, aplicando las lecciones aprendidas en la cohorte.
No necesitaba convertir en producto la herramienta del grupo para haber obtenido un valor real de ella.
En esta etapa, mi propio interés era principalmente editorial. Quería contar una historia y ofrecer algo que la gente pudiera consultar, no un producto de suscripción, sino una demostración de que los profesionales de RR. HH. podían reflexionar sobre algo así y quizá construir uno similar.
Escribir este artículo formaba parte de ello. ¿Podía crear una guía descargable? ¿Y, más adelante, un evento en directo en el que el grupo pudiera hablar sobre lo que había hecho, permitir que el público interactuara con la herramienta y grabar la conversación como pódcast? Tenía muchas ideas, pero el margen para llevarlas a cabo, mientras los objetivos del nuevo año se acumulaban delante de todos nosotros, se estaba acortando.
El interés de Satterfield era el más orientado a lo comercial, y lo dejó claro. Le interesaba convertirlo en un producto con el tiempo. No iba a hacerlo sola. Pero estaba dispuesta a seguir construyendo algo que algún día pudiera venderse.
Esa divergencia tripartita de intenciones —aprender, contar historias y crear un producto— probablemente sea inherente a cualquier grupo como este. La conversación honesta al respecto, en enero, fue más útil que fingir que todos siempre habían querido lo mismo.
La demostración como respuesta
La cuestión de cómo permitir que la gente probara la herramienta llevaba sin resolverse desde que se habilitó la carga del currículum. Probarla con usuarios reales es valioso, pero genera sus propios problemas. La herramienta debe funcionar de manera coherente, los usuarios necesitan suficiente contexto para saber qué están haciendo y es difícil recuperarse de una mala primera experiencia.
Turnmeyer ofreció la solución más sencilla que el grupo había considerado.
Había estado viendo grabaciones de demostraciones —recorridos breves, de uno o dos minutos, que mostraban cómo funcionaba una herramienta sin exigirle al espectador que la utilizara realmente—. Sugirió que eso podría ser suficiente. La gente podría ver la herramienta en acción, entender qué estaba haciendo y por qué, y terminar con la sensación de que era posible.
No necesitarían iniciar sesión, proporcionar un organigrama ni quedarse atascados cuando una pregunta de la evaluación no se ajustara a su situación.
Los comentarios que recibo de muchos de los blogs que escribo indican que la gente realmente no quiere copiar y pegar exactamente lo mismo. Solo quiere saber que puede hacerlo.
Erin Turnmeyer · VP de Operaciones de Personal
Esta observación apunta a algo real sobre cómo los profesionales de RR. HH. se están relacionando ahora mismo con las herramientas de IA. La brecha que muchos de ellos están atravesando no está entre saber que algo existe y utilizarlo. Está entre creer que son capaces de hacer algo así en absoluto.
Una demostración en la que se vea a profesionales creando su propia herramienta responde a una pregunta diferente de la que responde un producto terminado: no «¿es buena esta herramienta?», sino «¿podría haberla creado alguien como yo?»
La idea fue bien recibida. Abordaba las preocupaciones relacionadas con las pruebas, reducía la complejidad de compartir algo que aún no estaba listo para producción y mantenía el énfasis donde el grupo siempre había querido ponerlo: en el proceso y el razonamiento, no solo en el resultado.
Lo que enseñó el experimento: una guía para quienes crean herramientas de RR. HH.
- Empieza por el problema, no por la tecnología. El entusiasmo inicial del grupo por el análisis de sentimientos era genuino y los alejó de un problema más abordable y valioso. El giro hacia el mapeo de habilidades funcionó porque partió de un caso de uso real que ya había sido probado en el campo.
- Lo personalizado supera a lo genérico. Todos los participantes se habían encontrado con los límites de las plataformas empresariales de RR. HH. Las herramientas creadas para contextos específicos —el recomendador de beneficios de Turnmeyer y el mapa de calor de Satterfield— superaron a las alternativas disponibles de serie. El argumento a favor de crear tu propia herramienta es más sólido que nunca y las barreras son menores.
- La verificación cruzada lo es todo. Las autoevaluaciones solo son tan buenas como el autoconocimiento de las personas, que es célebremente poco fiable. El verdadero valor de una herramienta reside en su capacidad para indagar, cuestionar y recalibrar suavemente, no simplemente en registrar lo que las personas creen sobre sí mismas.
- Lo mínimo valioso, no lo mínimo viable. Si la primera versión no ofrece algo que haga que el usuario quiera volver, la hoja de ruta no importa. Diseña pensando en la primera impresión, no en la quinta.
- La aceptación es estructural, no superficial. La cuestión de si la IA genera la calificación final o si el usuario la confirma no es un detalle de experiencia de usuario. Determina si la herramienta es una autoridad o una colaboradora, y esa distinción condiciona todo sobre cómo se recibe y se utiliza.
- Elimina las funciones que ya has creado. La lógica del coste hundido hace que los equipos sigan añadiendo cosas en las que han invertido mucho tiempo después de que esas cosas hayan dejado de justificar su existencia. Si no puedes explicar para qué sirve una función, ahí tienes la respuesta. Eliminarla es disciplina de producto, no un fracaso.
- Prueba de forma adversarial y desde el principio. Busca personas que te digan que la herramienta es mala. Dale la peor entrada razonable que puedas imaginar y observa qué hace. Incorpora los casos límite antes de pulir los habituales. La credibilidad de la herramienta depende de cómo maneja los momentos para los que no fue diseñada.
- La herramienta debe ganarse el derecho a evaluar. Saltar a una calificación antes de hacer suficientes preguntas es presunción, no eficiencia. Las preguntas aclaratorias son las que hacen defendible la evaluación, y la posibilidad de defenderla es lo que hace que los comentarios calen.
- Sé honesto sobre el motivo por el que está ahí cada persona. Las intenciones divergentes dentro de un grupo no son un problema que haya que gestionar, sino información. Ponerlas sobre la mesa desde el principio evita que todos construyan en dirección a un objetivo que, en realidad, solo algunos comparten.
- Las conversaciones más difíciles son las más importantes. El grupo creó una herramienta para evaluar las habilidades de RR. HH. y, al hacerlo, mantuvo una de las conversaciones más honestas sobre las limitaciones de RR. HH. que cualquiera de ellos podía recordar. Esa conversación —sobre los marcos orientados al pasado y sobre la brecha entre los conocimientos de examen y el juicio situacional— era el producto tanto como lo era la herramienta.
Las sesiones que comenzaron como un compromiso de cuatro llamadas se prolongaron durante el invierno y luego hasta el nuevo año. El prototipo seguía evolucionando. Las intenciones de las personas que lo habían creado se habían aclarado de maneras que no se resolvían con facilidad.
Satterfield seguía construyendo. Turnmeyer había tomado lo que había aprendido y lo había aplicado en otros ámbitos. Gillies había impulsado al grupo a ser más disciplinado respecto a lo que realmente debía hacer la herramienta. Yo estaba escribiendo la historia de todo ello.
Turnmeyer había dicho algo al principio del proceso que seguía siendo cierto: estaba construyendo no porque se lo hubieran pedido, sino porque necesitaba entender.
Ese entendimiento de lo que realmente hacen las herramientas de IA, en qué se equivocan y qué hace falta para que sean útiles, no estaba disponible en ninguna sesión de una conferencia ni en ninguna demostración de un proveedor. Surgió de las decisiones que tomó el grupo, de las funciones que descartaron y de los momentos en que la herramienta evaluó incorrectamente a alguien y tuvieron que averiguar por qué.
Las cosas más útiles que produjo la cohorte no estaban en el prototipo. Estaban en el razonamiento que había detrás.