Mentores en un hackathon: cómo es hacerlo bien

Un buen mentor de hackathon ayuda a un equipo a pensar con más claridad sobre su propia idea, con preguntas, opiniones honestas y algún que otro desbloqueo, sin apropiarse de ella. La buena mentoría se diseña: un grupo reducido con roles claros, un calendario de revisiones ligado a los momentos en que los equipos se atascan y una breve sesión de preparación sobre qué hacer y qué no. Así se monta.

Para qué sirven los mentores

Los mentores existen para acortar el tiempo que los equipos pasan atascados. En un evento de 36 o 48 horas, un equipo puede perder seis horas por un supuesto equivocado, una conexión de datos rota o un problema planteado de forma demasiado amplia. Un buen mentor lo detecta pronto y hace la pregunta que los pone de nuevo en marcha.

Para lo que no sirven: juzgar, diseñar la solución o traer una idea propia. Los mejores mentores dejan al equipo sintiendo que la idea es más suya, no menos. Eso importa durante el evento y después: si llega un piloto, el equipo tiene que creer en lo que construyó, y no defenderá una idea que le entregó un visitante senior.

Hay cuatro roles de mentor útiles. La mayoría de los eventos necesitan al menos los dos primeros:

• Mentores de dominio: conocen el problema desde dentro, el servicio, la normativa, la historia de lo que ya se ha intentado.
• Mentores usuarios: son, o representan, a las personas afectadas. En muchos eventos son las personas más valiosas de la sala.
• Mentores técnicos: ayudan con datos, herramientas, integración y lo que de verdad se puede construir.
• Mentores de método y de pitch: ayudan a los equipos a probar supuestos, estructurar el relato e ir al grano.

Siete pasos para un programa de mentoría que funcione

1. Decide qué necesitarán los equipos, y cuándo. Recorre tu agenda y marca dónde suelen tener dificultades los equipos: plantear el problema en las primeras horas, elegir una idea, la primera prueba, el muro técnico de madrugada, el relato final. Cada uno de esos puntos es un momento de mentoría. Elige los roles en consecuencia. Si el reto trata de un servicio público, un mentor de dominio que conozca las reglas vale más que dos desarrolladores extra. El enunciado del reto (consulta cómo redactar un reto que la gente quiera resolver) te dice qué conocimiento escasea.

2. Recluta menos mentores, pero mejores. Una proporción de aproximadamente un mentor por cada dos o tres equipos, por sesión, suele bastar si su tiempo está planificado. Busca capacidad de escucha y paciencia, no antigüedad. Un alto directivo puede ser un buen mentor, pero solo si es capaz de sentarse veinte minutos con un equipo y preguntar más de lo que dice. Pide a cada candidato un compromiso de tiempo concreto, al menos dos bloques, antes de aceptarlo. Un nombre en la web que aparece diez minutos es uno de los 9 errores que los organizadores de hackathons siguen repitiendo.

3. Prepara a los mentores antes del evento. Entre treinta y sesenta minutos, idealmente el día anterior. Repasa el reto y sus restricciones, los criterios de evaluación (para que los mentores orienten hacia lo que importa; consulta criterios de evaluación que eligen al ganador correcto), el horario y las normas de la casa. La norma más importante es sencilla: pregunta, no digas. Dales un breve conjunto de preguntas, por ejemplo:

• ¿Para quién es exactamente, y qué momento de su día estáis mejorando?
• ¿Qué es lo más arriesgado que estáis suponiendo? ¿Cómo podríais comprobarlo hoy?
• ¿Qué recortaríais si tuvierais la mitad de tiempo?
• ¿Qué habéis aprendido en las últimas tres horas que os haya hecho cambiar de opinión?

Estas preguntas llevan directamente a un mapa de supuestos y a una rápida prueba de hipótesis; los mentores deberían conocer ambas lo bastante bien como para sugerirlas.

4. Planifica el tiempo; no lo dejes al azar. El modelo sin estructura de «los mentores andan por aquí, preguntad» falla de dos maneras: los equipos más seguros acaparan a los mentores y los más callados nunca preguntan. Organiza en su lugar rondas fijas: por ejemplo, una revisión de 15 minutos con cada equipo tras el bloque de planteamiento del problema, otra tras la primera prueba y una tercera antes del pitch. Entre rondas, se puede llamar a los mentores bajo petición mediante una cola sencilla. Rota a los mentores para que cada equipo oiga más de un punto de vista, pero mantén un mentor de referencia por equipo como contacto principal, para que los consejos no tiren en cinco direcciones.

5. Da a los mentores una forma de compartir lo que ven. Después de cada ronda, reúne a los mentores diez minutos. ¿Qué equipos están atascados? ¿Cuáles están a punto de construir algo que incumple una restricción? ¿Cuáles no han hablado con un solo usuario? Así los organizadores pueden actuar pronto, por ejemplo enviando un mentor usuario al equipo que lo necesita. También evita que los mentores repitan los consejos de otros. Las notas de los mentores nunca deben pasarse al jurado como puntuaciones; mentoría y evaluación deben ir separadas, o los equipos dejarán de ser sinceros con los mentores.

6. Protege la autoría del equipo. Vigila los fallos habituales: el mentor que rediseña la idea, el que insiste en su propia tecnología, aquel cuya jerarquía hace que el equipo abandone una buena dirección para complacerlo. Di a los mentores en la preparación que decide el equipo. Díselo también a los equipos: «Los mentores aconsejan. Vosotros decidís qué tomar». Si un mentor sigue imponiéndose, cámbialo discretamente a otro rol.

7. Cierra el círculo después del evento. Pregunta a los equipos qué mentoría les ayudó y cuál no, con una matriz de captura de retroalimentación. Agradece a los mentores con algo concreto: el equipo al que ayudaron, qué cambió gracias a ello. Si una idea ganadora pasa a piloto, el mentor que conoce el dominio suele ser la mejor persona para seguir implicada las primeras semanas. Esa continuidad forma parte de lo que pasa después del hackathon.

Qué hacer y qué no como mentor

Qué hacer

• Empieza cada conversación preguntando qué intenta hacer el equipo y dónde se ha atascado.
• Empuja para que haya contacto con usuarios y datos reales pronto, el primer día si es posible.
• Sugiere una prueba rápida (un prototipo en papel, una conversación de cinco minutos) en lugar de un largo debate.
• Di con honestidad cuando algo incumple una restricción, y explica por qué.
• Deja a cada equipo con un siguiente paso claro.

Qué no hacer

• No cojas el rotulador. Si estás dibujando la solución, la estás diseñando tú.
• No traigas tu propia idea buscando un equipo que la construya.
• No aconsejes sobre todo; elige lo único que más importa en ese momento.
• No contradigas a otro mentor delante del equipo; plantéalo en la reunión de mentores.
• No hagas de mentor de un equipo al que también vas a evaluar.

Ejemplo ilustrativo

Ilustrativo. Un trust del servicio nacional de salud del Reino Unido organizó un hackathon de dos días para reducir las ausencias a citas de consultas externas. En su primer evento figuraban como mentores doce médicos y gestores de alto nivel. La mayoría pasó una vez, brevemente. Tres equipos cambiaron de rumbo después de que un especialista sugiriera una app de recordatorios; en el pitch, cuatro equipos habían construido apps de recordatorios casi idénticas.

El siguiente evento se rediseñó en torno a los momentos en que los equipos se atascan. Los organizadores reclutaron a siete mentores: dos administrativos de consultas externas que gestionaban cambios de cita a diario, dos pacientes del panel de pacientes del trust, un analista de datos, un médico y un facilitador para las pruebas y el pitch. Los siete recibieron la preparación la tarde anterior, con una página de preguntas y una norma: pregunta, no digas. Cada equipo tuvo tres revisiones programadas y un mentor de referencia. En la primera reunión de mentores, estos señalaron que cinco equipos habían supuesto que los pacientes olvidaban sus citas; los administrativos sabían que muchos pacientes no podían salir del trabajo en los horarios ofrecidos. Los mentores pacientes lo confirmaron. Los equipos que lo probaron con ellos se orientaron hacia el intercambio flexible de citas en lugar de los recordatorios. La idea ganadora pasó a un pequeño piloto con la responsable de consultas externas como responsable, y uno de los administrativos siguió como asesor.

Preguntas frecuentes

¿Qué hace un mentor en un hackathon? Un mentor ayuda a los equipos a avanzar haciendo preguntas, dando opiniones honestas, compartiendo conocimiento técnico o del dominio y desbloqueando problemas. No evalúa ni diseña la solución por el equipo.

¿Cuántos mentores necesita un hackathon? Depende del número de equipos y de la duración del evento, pero aproximadamente un mentor por cada dos o tres equipos en cada sesión funciona cuando su tiempo está planificado. Importa más la combinación de roles que el total.

¿Puede un mentor ser también jurado? Mejor que no. Los equipos tienen que poder admitir sus dudas ante los mentores sin miedo a perder puntos. Si no hay más remedio que solapar, asegúrate de que nadie evalúe a un equipo al que ha mentorizado.

Por dónde seguir

Para el diseño completo del evento, consulta cómo organizar un hackathon que produzca algo real y el mapa de formatos en hackathons, jams y retos: todos los tipos explicados. Las guías de mapa de supuestos, prueba de hipótesis y prototipo en papel son las tres que todo mentor debería conocer.