Cuando los líderes de RRHH se convierten en constructores
Perspectiva del experimento: Los proyectos colaborativos de IA ofrecieron conocimientos profundos sobre las capacidades de RRHH, más allá del desarrollo de la herramienta.
Enfoque en el problema: El cambio de análisis de sentimiento a mapeo de habilidades destacó la importancia de definir objetivos claros y alcanzables.
Escepticismo ante la IA: Los profesionales de RRHH enfrentan grandes retos relacionados con la rendición de cuentas y la transparencia en las plataformas de IA existentes.
Estructura de la herramienta: La herramienta de evaluación con IA enfatizó la colaboración, permitiendo a los usuarios confirmar o cuestionar los comentarios generados por la IA.
Pruebas adversariales: El desarrollo exitoso de herramientas requiere pruebas rigurosas con insumos diversos para abordar eficazmente los casos límite.
Las reuniones estaban programadas para durar una hora. Casi siempre se extendían más allá del tiempo previsto.
Eso no es raro cuando se reúne a un grupo de profesionales de RR. HH. para hablar sobre IA. Lo inusual era lo que se les pedía hacer con esa conversación. No analizarla, no publicar un artículo de opinión sobre el tema, sino realmente construir algo.
En el otoño de 2025, reuní lo que llamaba "cohortes de constructores": 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, ya pensaban en los límites de lo que la profesión de RR. HH. podría lograr con la IA.
Keep Reading—and Keep Leading Smarter
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
La hipótesis era simple. Las personas más cercanas a los problemas son las que están mejor posicionadas para construir las soluciones. La pregunta era si podían hacerlo.
En total formé cuatro cohortes, y en el camino me di cuenta de que definir objetivos para estas sesiones es más fácil decirlo que hacerlo. Al final, la mayoría de las cohortes se disiparon, luchando por cumplir la visión inicial o decidirse por un solo objetivo. Los calendarios, la carga de trabajo y las exigencias de nuestros empleos reales, a menudo llevaron a conversaciones que generaron grandes ideas pero que nunca lograron concretarse.
Pero una cohorte se unió y de hecho logró llegar tan lejos como le fue posible. La realidad es que, cuanto más te adentras en el mundo de construir soluciones propias, más difícil se vuelve mantener una visión compartida y afrontar el reto de ingeniería.
Esta historia es el relato de lo que surgió de esas sesiones y se la ofrezco como un caso práctico para construir tus propias soluciones.
La Cohorte
Estos no eran escépticos de la IA que necesitaran ser convencidos. Eran profesionales que ya habían apostado por este momento. Lo que les ofrecía la cohorte 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 se menciona en los comentarios publicados sobre RR. HH.: cuán frustrados están en realidad estos profesionales con las herramientas que se supone que deben usar.
Turnmeyer marcó la pauta. Había intentado conseguir documentación técnica sobre cómo funcionaba el análisis de sentimientos dentro de BambooHR, Paycom y Gusto, no para desacreditar las herramientas, sino porque su equipo legal necesitaba entenderlas antes de aprobar su uso.
Ni los equipos de ventas ni los representantes legales pudieron responder a sus preguntas. Las funciones de IA existían. La responsabilidad sobre cómo funcionaban no.
Gillies navegaba una tensión paralela. Voces internas habían planteado preocupaciones sobre el impacto ambiental de la IA, y algunos colegas querían simplemente prohibir el uso de IA por parte de los empleados. Gillies se resistió.
Prohibir abiertamente la IA conduce a un uso encubierto y a un mayor riesgo. Adoptar la IA con ciertas limitaciones es un enfoque más adecuado.
Melina Gillies · Directora de Personas, Flex Networks
Lo que surgió de esa primera hora fue un diagnóstico con el que el grupo pudo estar de acuerdo. Las funcionalidades de IA integradas en las plataformas empresariales de RR. HH. eran, en palabras de Gillies, "a menudo muy básicas y carecen de funcionalidad".
Las herramientas que realmente funcionan tienden a ser hechas a medida—diseñadas para problemas concretos, contextos específicos, empresas particulares. Turnmeyer quería menos herramientas, no más, un estribillo que escucho a menudo entre responsables de personas y operaciones. Ella podía imaginar un futuro en el que una IA capaz, alimentada con los documentos adecuados, hiciera innecesario un HRIS.
También enfrentaron algo que rara vez se aborda de forma tan directa: la ética del seguimiento del comportamiento. La idea de usar tasas de rechazo de reuniones, lagunas en el inicio de sesión en sistemas o horarios de trabajo inusuales como indicadores indirectos de desinterés surgió muy pronto.
También salieron a la luz los límites de este enfoque. Satterfield nombró un riesgo que toda herramienta de compromiso acaba afrontando: la fatiga por inacción. Si recoges datos y no actúas visiblemente sobre ellos, 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 listos para crear una herramienta de análisis de sentimientos. Era demasiado amplia, cargada de dilemas éticos y fácil de arruinar de manera catastrófica. Así que cambiaron de rumbo.
Encontrar el problema correcto
La segunda sesión comenzó con una admisión honesta de que la dirección original era demasiado ambiciosa y demasiado ambigua.
"No sé si eso mide el compromiso," dijo Turnmeyer, "o si simplemente mide algo que requiere una conversación."
Esa distinción es más importante de lo que parece. Mucha tecnología de RR. HH. comete el error de tratar los datos como si fueran un sustituto de la conversación. El grupo intentaba usar la IA para identificar los momentos en los que una conversación debe ocurrir, y luego hacer que esa conversación fuera mejor.
Satterfield presentó la idea que anclaría el resto del proyecto. Durante una congelación de contrataciones en un anterior empleador, ella 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 reubicación fueran más humanas y estratégicas.
No empleaba IA. Era un Microsoft Form. Pero la lógica subyacente era sólida, el caso de uso era real, y había visto cómo funcionaba.
"Los grandes proveedores están intentando hacer esto, pero nadie lo está haciendo realmente bien todavía, y muchas empresas ni siquiera tienen presupuesto reservado para este tipo de tecnología además de su HRIS principal," dijo.
El grupo vio la oportunidad. ¿Y si construían una versión nativa de IA? Una que fuera conversacional en lugar de clínica, orientada al futuro y no centrada en el cumplimiento, y con un precio accesible para líderes individuales de RR. HH. en vez 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 ser un valor real y la mayoría de las herramientas lo pasan por alto completamente.
Melina Gillies · Directora de Personas, Flex Networks
Fisher, escuchando mientras el grupo debatía las posibilidades, ofreció una observación que replanteó el potencial del proyecto. Había experimentado ambos extremos del espectro de RR. HH.: el tipo centrado en el cumplimiento, los marcos y las transacciones, y el más raro practicante centrado en las personas que se dirigía a él "como alguien que sentía que estaba de mi lado."
"El lenguaje del segundo tipo," dijo, "nunca daba la sensación de provenir de un marco escrito hace décadas. Simplemente se sentía bien."
Gillies se fijó en eso. El aspecto diferenciador de su herramienta, argumentó, era el tono y la estructura. ¿Y si pudiera replicar la forma en que los profesionales de RR. HH. realmente hablan entre ellos en una conferencia, entre sesiones, fuera de lo formal? ¿Y si entendiera "saber moverse políticamente" no como una casilla a marcar, sino como algo profundo, debatido y situacionalmente complejo que los profesionales experimentados discuten entre sí?
Esa fue la dirección: una herramienta de evaluación previa a la contratación, diseñada para líderes de RR. HH. y adquisición de talento que necesitan una mejor manera de evaluar candidatos a reclutador antes de contratarlos. No un test de personalidad o criba curricular, sino un diagnóstico estructurado y conversacional que pudiera decirle a un gestor de contratación si la persona frente a ellos realmente sabía hacer el trabajo. Una herramienta que se sintiera menos como una evaluación de desempeño y más como una conversación con alguien que comprende la selección de personal desde dentro.
El momento "eureka"
En la tercera sesión, el grupo estaba inmerso en la arquitectura de la herramienta: qué competencias evaluar, cómo estructurarlas en distintos niveles, cómo considerar la brecha entre lo que la gente dice que puede hacer y lo que realmente puede 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 ciertos aspectos." La profesión seguía, en sus palabras, en una "resaca posindustrial": basada en el cumplimiento, jerárquica, diseñada para un mundo que ya estaba quedando atrás.
Su herramienta necesitaba orientarse hacia otra cosa, no hacia lo que los líderes de RRHH necesitaban saber, sino hacia lo que necesitaban ser capaces de hacer.
¿Estás dispuesto a tener 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 · VP de Operaciones de Personas
Turnmeyer tenía un ejemplo revelador. Recientemente había realizado el examen SPHR. Las cosas que le exigía saber —estatutos, definiciones de procedimientos, reglas de clasificación— eran cosas que cualquier profesional de RRHH competente simplemente consultaría.
Las competencias difíciles no estaban en el material de certificación. Eran cosas como: ¿Puedes sentarte frente a un CEO y decirle algo que no quiere escuchar? ¿Puedes abogar por un empleado cuando el caso empresarial es ambiguo? Memorizar los códigos laborales no responde 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 en la capacidad de una organización para navegar una transformación no era ninguna habilidad específica. Era la relación de una persona con la ambigüedad.
Sacar a alguien cuánto le acomoda sentirse incómodo —o el ritmo del cambio en general— es un indicador de tu capacidad para desenvolverte en este nuevo mundo.
Tim Fisher · Jefe de IA , Black and White Zebra
Luego vino lo que el grupo llamaría más tarde la salsa secreta.
Gillies planteó una pregunta. ¿Y si la herramienta incorporara una verificación cruzada? Si alguien se calificaba a sí mismo como experto en gestión de conflictos, pero luego, en una respuesta en lenguaje natural a una pregunta de seguimiento, describía situaciones que no sonaban para nada a experiencia, ¿podría la IA detectarlo? ¿Podría decir, de forma sutil, que podría haber una brecha aquí?
"Ese es el momento de la bombilla encendida", dijo Turnmeyer.
Satterfield señaló que cualquiera que haya trabajado con inventarios de habilidades ha visto versiones del mismo problema. Las personas suelen evaluarse a sí mismas de manera muy diferente a lo que su experiencia real o comportamiento sugerirían.
El valor de la herramienta no provendría de registrar lo que las personas creen sobre sí mismas. Provendría de la calibración: la fricción suave, informada por datos, entre la auto-percepción y la capacidad demostrada.
La evaluación no sería solo un espejo. Sería más un “espejito, espejito” de lo que la mayoría está acostumbrada a ver en evaluaciones profesionales.
Las realidades de la construcción
Nada de esto fue 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, cada una capaz de absorber el proyecto completo. Turnmeyer lo nombró desde el principio, y no dejó de recordarlo.
"Asegúrate de que haga bien lo primero, para que el alcance no se expanda tanto que no se pueda crear", dijo.
Satterfield introdujo un principio guía 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 ofrece algo realmente significativo en la primera interacción no tendrá una segunda oportunidad para mejorar. El listón no es la funcionalidad. Es el valor.
Si el producto no genera suficiente valor en la primera entrada, probablemente los usuarios no regresen después para ver si ha mejorado.
Kelly Satterfield · Líder y consultora de RRHH
También estaban las limitaciones prácticas que cualquiera que haya intentado construir fuera de un equipo de desarrollo conoce bien: despliegue, infraestructura de pagos, integración con sistemas existentes, ventanas de contexto que se cierran a mitad de 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 su 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 primera lectura.
Al final, un líder de contratación obtiene una imagen de dónde se encuentra realmente el candidato según un marco de competencias definido.
Fisher preparó el entorno principal de construcción en Lovable—un generador de IA sin código que permite crear herramientas para el público final mediante conversación, sin encerrar a los usuarios en un modelo de lenguaje específico—para que la arquitectura técnica pudiera avanzar al ritmo de los planteamientos del grupo sin convertirse en un obstáculo.
Del plano a la construcción
Para la cuarta sesión, el grupo ya no estaba diseñando una herramienta abstracta. Estaban construyendo una y descubriendo, como siempre hacen los constructores, que la distancia entre la idea y la ejecución es, precisamente, donde ocurre el verdadero aprendizaje.
Fisher había montado un GPT personalizado de nivel básico antes de la llamada, cargado con instrucciones, un marco de competencias preliminar y los inicios de la lógica conversacional que habían trazado en sesiones anteriores. El plan era que todos pudieran acceder, interactuar de manera colaborativa y empezar a calibrar su tono y comportamiento en tiempo real. Pero, de inmediato, la realidad se impuso al plan.
El enlace compartido solo funcionó para mí. Los permisos del espacio de trabajo, rarezas de la plataforma y la forma particular en la que ChatGPT maneja el acceso externo consumieron el primer cuarto de la sesión.
Fue una pequeña frustración, justo del tipo que nunca se menciona en un anuncio de producto, y fue ilustrativa. Las herramientas que los profesionales realmente utilizan para construir cosas no se comportan como demos.
Esta captura de pantalla muestra cómo llegaría a verse la pantalla de bienvenida de la herramienta que el grupo construyó, llamada Talent Scout.
Una vez que todos miraban la misma pantalla, ocurrió algo más interesante. Mientras el grupo aún debatía sobre qué formato debían tener las definiciones de competencias, Gillies abrió Claude en una ventana separada y convirtió la tabla de puntuación en JSON estructurado—en vivo, durante la llamada.
"Uso Claude porque para esto es mejor que ChatGPT", dijo, sin rodeos. Minutos después, soltó el archivo formateado en el chat grupal. Nadie se detuvo a comentarlo. Simplemente siguieron adelante.
Esa resolución de problemas en movimiento—convertir un cuello de botella en un problema resuelto sin que sea el centro de la reunión—es lo que distingue a quienes realmente han internalizado estas herramientas de quienes aún aprenden a navegar con ellas.
¿Quién tiene la última palabra?
Satterfield planteó una cuestión que tendría implicaciones significativas para la arquitectura de la herramienta y su recepción final: ¿la IA emite la valoración final o la confirma el usuario?
La distinción no es meramente estética. Si la herramienta dicta un veredicto como "Según tus respuestas, estás en el Nivel 2 en enfoque en candidatos", entonces posiciona a la IA como autoridad. Si en cambio presenta una interpretación provisional e invita al usuario a discrepar, la dinámica cambia completamente. La evaluación se vuelve colaborativa, no simplemente evaluativa. El usuario es partícipe del proceso, no sujeto del mismo.
"¿Aceptas este feedback?" dijo Turnmeyer, al captar la idea. "Me encanta, la verdad."
Gillies desarrolló la lógica. Si el usuario no acepta la valoración, la herramienta pregunta qué no le cuadra—y después utiliza la respuesta para recalibrar o reconfirmar su diagnóstico, explicando la evidencia mediante una conversación guiada.
Esa ida y vuelta conversacional es lo que genera la seguridad psicológica que la herramienta necesita para ser realmente útil. Las personas no cambian por feedback en el que no confían. Conseguir la aceptación del usuario no es solo una función opcional, es el mecanismo fundamental.
La primera prueba real
Decidieron probar el prototipo en directo. Turnmeyer ofreció una respuesta deliberadamente escueta a una de las preguntas—el tipo de respuesta que podría dar un candidato poco motivado o un empleado distraído.
Describió discutir con su gerente por una discrepancia salarial, perder al candidato y no saber siquiera cuál fue el resultado. Era el equivalente en RRHH a responder "Simplemente adoro a las personas" cuando preguntan por qué quieres trabajar en ese campo.
La herramienta la evaluó de inmediato. Asignó un nivel. Fue alentadora. También se equivocó, no en los hechos, sino en el momento. Supuso lo que implicaba la respuesta en lugar de pedir el contexto adicional que necesitaría para evaluar con precisión.
Si vas a dar cualquier valoración distinta a 'cumple con las expectativas', hay que dar ejemplos detallados. La IA debería atenerse al mismo estándar.
Erin Turnmeyer · VP de Operaciones de Personas
Turnmeyer estableció el paralelismo directamente desde sus prácticas de revisión de desempeño. Siempre había exigido a los gerentes que aportaran evidencia específica antes de evaluar a alguien por encima o por debajo de "cumple con las expectativas".
La misma disciplina debería aplicarse a la herramienta. Antes de asignar un nivel, hay que ganarse ese derecho planteando las preguntas que harían la valoración defendible. De nuevo, fue la experiencia en RRHH la que hacía mejor a la IA, no al revés.
Satterfield añadió una complicación que la herramienta había pasado por alto. Una respuesta escueta podía reflejar la política, no la destreza.
Si el gerente realmente había fijado un techo de compensación, insistir más no habría cambiado el resultado. La herramienta había evaluado a la persona cuando debía preguntar por la situación. Las preguntas aclaratorias no eran un retoque; eran lo que diferencia una evaluación útil de una presuntuosa.
Turnmeyer asumió como tarea redactar las instrucciones: ¿cómo logras que una herramienta pregunte lo necesario para aclarar sin que cada interacción se sienta como un interrogatorio?
Esta captura de pantalla muestra un ejemplo de lo que haría el producto final, haciendo preguntas aclaratorias e impulsando al candidato a profundizar más.
Es un problema más difícil de lo que parece, y ella era muy consciente de que el listón estaba 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 y prácticas de toda la cohorte. Cuando Satterfield preguntó cómo solía probar el grupo herramientas como esta, tanto Turnmeyer como Gillies respondieron de maneras que revelaron algo importante sobre cómo se ve una prueba rigurosa en la práctica.
Para su herramienta de recomendación de prestaciones, que debía identificar con precisión si ciertos medicamentos estaban cubiertos por el plan de salud de la empresa, Turnmeyer probó específicamente los casos límite. No los medicamentos obvios, los populares que el modelo habría visto repetidamente en su entrenamiento. Probó los casos poco comunes, en las categorías más propensas a provocar una alucinación confiada.
"Fui y probé con los medicamentos que no son populares", dijo, "porque Claude me mostró lo que estaba haciendo mientras lo construía".
Ese nivel de intencionalidad adversaria en las pruebas es raro para quienes vienen de fuera del contexto de ingeniería. También es exactamente lo que separa las herramientas en las que se confía de las que son abandonadas en silencio tras un fallo embarazoso.
Eliminar lo que ya has construido
Una sesión de recapitulación justo antes de las fiestas empezó con una pregunta más difícil de plantear de lo que parece: ¿para qué sirve realmente la función de subir el currículum?
Gillies sacó el tema. La evaluación pedía a los usuarios que pensaran detenidamente sobre sus propias capacidades. ¿El currículum aportaba información que el usuario no podía proporcionar más directamente, simplemente respondiendo las preguntas? Nadie en el grupo estaba seguro de que así fuera. La intención original era ahorrar tiempo, como un analizador de currículum, pero ya no estábamos convencidos de que cumpliera esa función.
Acordaron eliminarla.
Esto es menos común de lo que parece en el desarrollo de productos. El grupo había invertido tiempo real en la función de subir currículum—desarrollándola, probándola, viendo cómo el currículum de Satterfield se analizaba y se puntuaba mal. Eliminarla requirió ignorar la lógica del coste hundido que lleva a los equipos a seguir añadiendo cosas a las que ya han dedicado esfuerzo.
Empieza con el resultado en mente y define en qué consiste el éxito. Si no puedes articular para qué sirve una función, no puedes defender su inclusión.
Turnmeyer hizo un argumento relacionado sobre la metodología. En retrospectiva, creía que podrían haber avanzado más rápido si hubieran definido por completo el comportamiento de la herramienta antes de redactar una sola solicitud. Habían estado trabajando con algo parecido a un modelo ágil: construir, probar, ajustar; cuando la complejidad de lo que estaban construyendo quizá requería un enfoque más tipo cascada: definir bien la especificación primero y luego construir en función de ella.
Tenía un documento de diseño de 130 páginas de otra herramienta que había creado y que le enseñó esta lección. Una especificación completa no solo te dice qué construir. También te dice qué no vas a construir, lo cual resulta igual de útil.
Gillies afinó el problema central del producto. Fuera lo que fuera lo que la herramienta mostrara en pantalla, debía ir más allá. Una evaluación que arroja datos no es igual que una herramienta que te dice qué hacer con ellos. Esa distancia entre el resultado y la acción es donde las herramientas de diagnóstico dejan de ser útiles, y es la brecha que la mayoría nunca logra cerrar.
Construyendo en solitario
En enero, Satterfield estaba haciendo la mayor parte de la construcción ella misma, ya que el resto del grupo sentía el tirón de sus trabajos de 9 a 5 demasiado fuerte, y les resultaba imposible dejar tiempo libre para el proyecto. Al fin y al cabo, nadie estaba cobrando por esto.
Había eliminado la subida de currículum, como había acordado el grupo. Había añadido entrada de voz: ahora los usuarios podían responder a las preguntas de evaluación hablando en vez de escribiendo, lo que abría la posibilidad de un estilo de respuesta más conversacional y menos fácil de manipular que un campo de texto.
Había estado usando ChatGPT para generar respuestas de prueba sintéticas ("Soy una reclutadora junior que es fuerte en esto y débil en esto otro, dame respuestas"), luego pasaba a Lovable para alimentar dichas respuestas y observar cómo la herramienta las evaluaba.
El panel de control para líderes era la otra mitad de la lógica de la herramienta: la vista que un director de Adquisición de Talento o un CHRO usaría para ver cómo había puntuado un candidato, dónde estaban las brechas y cómo sus capacidades podrían complementar las fortalezas y necesidades de un equipo existente.
Eso hizo que la estructura organizacional fuera un verdadero problema, porque la herramienta necesitaba saber quién evaluaba a quién, y quién tenía derecho a ver los resultados.
Satterfield había intentado manejar esto pidiendo a los usuarios que ingresaran su nombre, puesto de trabajo y el nombre de su gerente (en ausencia de una integración de datos). Pero esa lógica fallaba en un escenario común: un director de adquisición de talento que quería enviar la evaluación a una organización de reclutamiento más amplia que incluyera relaciones tanto directas como indirectas de reporte. La lógica de mapeo organizacional no era lo suficientemente sutil para contemplar esa estructura.
En teoría, esta información le daría a la herramienta un mayor contexto sobre el rol del evaluado, 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 rendimiento 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 la generación de feedback.
La arquitectura era más sencilla de lo que parecía: una hoja de cálculo con nombre, correo electrónico, nivel de puesto y título del puesto. Una pestaña separada cruzaba el nivel de puesto con las competencias.
"El área de seguridad de mi empresa quería revisar mi herramienta", le dijo al grupo. "Dije que estaba almacenada en Google Docs. Ellos dijeron: 'Oh, es así de simple.'"
Sencillo, pero Turnmeyer solo lo aprendió haciéndolo. Lo que no sabía tres semanas antes era que existía el registro (logging), una función que guarda el progreso del usuario para que la herramienta no se reinicie si alguien se aleja y luego regresa.
"Estuve maldiciendo a Claude", dijo, "hasta que me dijo que existía el registro."
Eso es lo que realmente enseña construir. No lo que planeabas aprender, sino lo que no sabías que necesitabas saber.
La pregunta de fondo
En algún momento de la sesión de enero, la conversación llegó a la pregunta que había estado rondando durante meses.
El grupo seguía discutiendo sobre arquitectura, permisos, almacenamiento, paneles de control—problemas reales, todos ellos. Pero debajo de ellos había uno más fundamental. ¿Qué estaban realmente tratando de construir y para quién?
La herramienta, según el concepto original, era un diagnóstico de selección: algo que un líder de Adquisición de Talento pudiera enviar a un candidato o empleado interno para evaluar si sus capacidades reales coincidían con lo que decía su currículum y obtener esa imagen antes de tomar una decisión de selección.
Lo que ves aquí es una selección de capturas de pantalla del tipo de informe que la herramienta producía para el entrevistado. Para el evaluador, un panel de control de las fortalezas actuales del equipo le ayuda a centrarse en dónde evaluar al entrevistado para ver si cubre debilidades del equipo de Adquisición de Talento.
Ese núcleo no había cambiado. Pero cada decisión práctica que iban tomando—añadir un panel de control para líderes, pensar en modelos de suscripción, definir un flujo de inicio de sesión—los estaba conduciendo hacia algo más complejo.
Los paneles de control en tiempo real significaban acceso continuado, lo que implicaba cuotas de suscripción y los acercaba a herramientas empresariales que muchas organizaciones tienen dificultades para costear o implementar eficazmente.
"No estamos intentando convertirnos en un proveedor de HCM", dijo Satterfield.
Turnmeyer fue honesta sobre su postura.
"Mi intención era simplemente aprender algo nuevo."
Eso no era un retroceso respecto al proyecto. Era una constatación precisa de lo que el experimento ya le había aportado. Había aprendido cosas nuevas y ya estaba en proceso de construir una nueva herramienta de gestión del rendimiento aplicando las lecciones del grupo.
No necesitaba convertir la herramienta del grupo en un producto para haber obtenido valor real de ella.
En esta etapa, mi propio interés era principalmente editorial. Quería una historia que contar y algo que la gente pudiera ver, no un producto de suscripción, sino una demostración que los profesionales de RRHH pudieran considerar y quizá replicar por su cuenta.
Escribir este artículo formaba parte de ello. ¿Podría crear una guía descargable? ¿Quizá un evento en vivo donde el grupo pudiera debatir lo que hicieron, permitir que el público interactuara con la herramienta y grabar la conversación como un pódcast? Tenía muchas ideas, pero el margen para ejecutarlas se hacía más corto a medida que se acumulaban los objetivos del nuevo año para todos nosotros.
El interés de Satterfield era el más orientado comercialmente, y lo dejó claro. Le interesaba convertirlo en producto eventualmente. No pensaba hacerlo sola. Pero estaba dispuesta a seguir construyendo hacia algo que un día pudiera venderse.
Esa triple divergencia de intenciones—aprendizaje, narración, producto—probablemente es inherente a cualquier cohorte de este tipo. Tener una conversación honesta al respecto, en enero, fue más útil que fingir que todos siempre habían querido lo mismo.
La Demo como Respuesta
La pregunta de cómo permitir que las personas probaran la herramienta había quedado sin resolver desde que se habilitó la carga de currículums. Probar con usuarios reales es valioso, pero genera sus propios problemas. La herramienta debe funcionar de forma consistente, los usuarios necesitan suficiente contexto para saber lo que están haciendo, y una mala primera experiencia es difícil de corregir.
Turnmeyer ofreció la resolución más sencilla que el grupo había considerado.
Había estado observando grabaciones de demostraciones: recorridos breves, de uno o dos minutos, mostrando cómo funcionaba una herramienta sin requerir que el espectador realmente la usara. Sugirió que eso podría ser suficiente. Las personas podrían ver la herramienta en acción, entender lo que hacía y por qué, y marcharse sintiendo que era posible.
No tendrían que navegar un inicio de sesión, proporcionar un organigrama, o quedarse atascados si una pregunta de evaluación no coincidía con su situación.
Los comentarios que recibo de muchos de los blogs que escribo es que la gente realmente no quiere copiar y pegar exactamente lo mismo. Solo quieren saber que son capaces de hacerlo.
Erin Turnmeyer · VP de Operaciones de Personas
Esa observación señala algo real sobre cómo los profesionales de RRHH se están relacionando con las herramientas de IA en este momento. La brecha que muchos de ellos están atravesando no es entre saber que algo existe y usarlo. Es entre creer que son capaces de hacer algo así en absoluto.
Una demo que muestre a los profesionales construyendo su propia herramienta responde a una pregunta diferente que un producto terminado: no "¿es buena esta herramienta?" sino "¿alguien como yo podría haberla creado?"
La idea fue bien recibida. Atendía las preocupaciones de pruebas, reducía la complejidad de compartir algo que no estaba listo para producción, y mantenía el énfasis donde la cohorte siempre había querido, en el proceso y el pensamiento, no solo en el resultado.
Lo que Enseñó el Experimento: Una Guía para Creadores de RRHH
- Empieza por el problema, no por la tecnología. El entusiasmo inicial del grupo por el análisis de sentimientos era genuino y los desvió de un problema más abordable y valioso. El giro hacia el mapeo de habilidades funcionó porque partía de un caso de uso real que ya se había probado en el campo.
- Lo personalizado supera a lo genérico. Todos los participantes habían experimentado los límites de las plataformas empresariales de RRHH. Las herramientas construidas para contextos específicos—el recomendador de beneficios de Turnmeyer, el "mapa de calor" de Satterfield—superaron a las alternativas prefabricadas. El argumento a favor de construir tu propia herramienta es más fuerte que nunca, y las barreras son más bajas.
- La verificación cruzada lo es todo. Las autoevaluaciones solo son tan buenas como el autoconocimiento de las personas, que es notoriamente poco fiable. El verdadero valor de una herramienta reside en su capacidad para indagar, desafiar y recalibrar suavemente, no solo en registrar lo que la gente cree de sí misma.
- Mínimo Valioso, no Mínimo Viable. Si la primera versión no ofrece algo que haga que un usuario quiera regresar, el plan no importa. Diseña para la primera impresión, no para la quinta.
- El compromiso es estructural, no blando. La cuestión de si la IA otorga la calificación final o 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 lo condiciona todo sobre cómo se recibe y se usa.
- Recorta funcionalidades que ya has construido. La lógica del coste hundido hace que los equipos sigan añadiendo a cosas en las que han invertido mucho después de que ya no valgan la pena. Si no puedes articular para qué sirve una funcionalidad, ahí tienes la respuesta. Eliminarla es disciplina de producto, no un fracaso.
- Prueba de manera adversa y pronto. Busca personas que te digan que la herramienta es mala. Dale la entrada más desfavorable razonable que puedas imaginar y observa qué hace. Integra los casos extremos antes de perfeccionar los típicos. 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 arrogancia, no eficiencia. Las preguntas clarificadoras son las que hacen que la evaluación sea defendible, y la capacidad de defensa es lo que hace que los comentarios perduren.
- Sé honesto sobre el motivo por el que está cada uno. Las intenciones divergentes dentro de un grupo no son un problema que deba gestionarse: son información. Ponerlas sobre la mesa pronto ahorra a todos construir hacia un objetivo que solo comparten algunos.
- Las conversaciones más difíciles son las más importantes. La cohorte construyó una herramienta para evaluar habilidades de RRHH, y al hacerlo, tuvo una de las conversaciones más honestas sobre las limitaciones de RRHH que cualquiera de ellos pudiera recordar. Esa conversación—sobre marcos retrospectivos, sobre la brecha entre el conocimiento de examen y el juicio situacional—fue el producto tanto como la herramienta.
Las sesiones que comenzaron como un compromiso de cuatro llamadas se extendieron hasta el invierno, y luego hasta el nuevo año. El prototipo todavía seguía evolucionando. Las intenciones de quienes lo habían construido se habían aclarado de formas que no se resolvían de manera sencilla.
Satterfield seguía construyendo. Turnmeyer había tomado lo que aprendió y lo aplicó en otro lugar. Gillies había impulsado al grupo a ser más disciplinado respecto a lo que la herramienta realmente debía hacer. Yo estaba escribiendo la historia de todo esto.
Turnmeyer dijo algo al principio del proceso que se mantuvo cierto: ella estaba construyendo no porque se lo hubieran pedido, sino porque necesitaba entender.
Esa comprensión de lo que realmente hacen las herramientas de IA, en qué se equivocan, lo que se necesita para hacerlas útiles, no estaba disponible en ninguna sesión de conferencias ni en ninguna demostración de proveedores. Surgió de las decisiones que tomó el grupo, de las funciones que descartaron, de los momentos en los que la herramienta evaluó a alguien incorrectamente y tuvieron que averiguar por qué.
Las cosas más valiosas que produjo la cohorte no estaban en el prototipo. Estaban en el razonamiento detrás de él.