# Cómo organizar un hackathon de IA que tenga impacto Antes de nada, poneos en situación: 120 personas, 22 equipos, departamentos distintos, niveles de soltura con la IA muy dispares y dos días de trabajo. Tengo que ser honesto: cuando empezamos con la idea de organizar un hackathon para tanta gente, pensé que sería un desastre. 120 personas... ¡He estado en bodas con menos gente! Pero funcionó. Y aprendimos mucho de la experiencia. ---- En Technosylva, desde principios de año, tenemos el objetivo de convertirnos en una empresa *AI first*. Y no me refiero solo a ingeniería: queremos que toda la empresa integre las herramientas de IA en su día a día. Como os podéis imaginar, esto incluye perfiles de todo tipo, con funciones, capacidades, objetivos y *background* técnico diferentes. El reto no era fácil. Durante este proceso hemos pasado por varias fases, pero en este artículo quiero centrarme en algo que realmente dio un empujón a la implantación y marcó un antes y un después en la adopción: los hackathons. Obviamente, no estoy descubriendo la pólvora. Pero, por si estáis planteándoos organizar uno, os comparto nuestros aprendizajes y consejos. ## El punto de partida Ya habíamos impartido formaciones, organizado talleres internos, dado alguna charla y elaborado documentación. No obstante, seguíamos viendo que la gente no utilizaba la IA en su día a día. Seguramente los motivos eran distintos, pero podían resumirse así: > «Vale, la IA está muy bien, pero no sé cómo puede hacerme la vida más fácil». En definitiva: desconocimiento, miedo, falta de tiempo para experimentar y, sobre todo, no encontrar el punto de unión con el trabajo diario. Por eso decidimos organizar dos hackathons: uno centrado en los *managers* de la empresa y otro exclusivamente para el equipo de ingeniería y ciencia. Como podéis imaginar, tanto el formato como las dinámicas fueron diferentes. El primero estuvo más centrado en crear *awareness* y quitar el miedo inicial. El segundo, en el desarrollo agéntico. Para este último ya teníamos identificadas las etapas de madurez en el uso de IA, así que se trataba de mover a la gente lo más a la derecha posible. Para nosotros, el éxito del hackathon consistía en que, fuera cual fuese el punto de partida, cada persona terminase al menos en el siguiente nivel. ![Etapas de madurez en el uso de IA](/images/hackathon-ia/niveles-madurez-ia.png) ## 1. Objetivo claro: ¿qué queréis conseguir? Cuando pensáis en un hackathon, es posible que se os venga a la cabeza desarrollar el nuevo producto del siglo. Teníamos claro que ese no era nuestro caso. Queríamos que los equipos de desarrollo entendiesen y experimentasen una nueva manera de trabajar. Que tuviesen su momento *ajá*. Que sintiesen que ya no había vuelta atrás. > **El éxito no sería el software. Sería el aprendizaje.** ## 2. El *prework*: la clave **Sin trabajo previo no tenéis un hackathon; tenéis un taller improvisado.** Teníamos que organizar un evento para 120 personas y dejar el menor margen posible a la improvisación. Lo peor que podéis hacer es llegar sin organización, sin haber tenido en cuenta las necesidades y características de este tipo de eventos. Nuestro mayor miedo era perder tiempo en la configuración de entornos, la formación de grupos o la explicación de los retos. Por eso, durante semanas nos centramos en varias cosas: - **Definir los retos.** Problemas reales: *backlog* de ideas, iniciativas atascadas e innovación de producto. - **Formar los equipos.** Multidisciplinares y equilibrados en su nivel de uso de IA agéntica. - **Preparar el entorno y una base mínima.** Pedimos a la gente que, al menos, hubiese añadido un test unitario a su proyecto utilizando Claude Code de manera agéntica. Todo un *win-win*. También habilitamos canales abiertos en Slack para dudas y soporte durante la fase de preparación. ## 3. Durante el evento: ejecución y reglas Establecimos unas pocas reglas básicas, pero no eran negociables: - Todo el código tenía que estar generado al 100 % con IA. No se podía desarrollar de manera manual. - Era obligatorio comenzar con un plan. - Se debía entregar algo funcional. El objetivo no era desarrollar *skills* o *prompts* sueltos, sino construir soluciones siguiendo buenas prácticas de ingeniería. - Reservamos un día y medio sin interrupciones. ## 4. Cierre: demos, premios y celebración Al final, cada equipo tuvo que presentar su solución en un ambiente distendido. Hubo *live demos*, vídeos, anuncios y mucho ruido. Creamos diferentes categorías de premios: - Mejor uso de IA. - Solución más creativa. - Solución más cercana a *production ready*. ## 5. Después del evento: el trabajo que nadie ve Tened claro que el hackathon no termina con la última presentación. El trabajo real —seguramente el más importante y el que menos visibilidad tiene— empieza justo cuando dais por cerrado el evento. Si queréis que la iniciativa realmente merezca la pena, tenéis que hacer seguimiento de las soluciones generadas y analizar cuidadosamente cuáles tienen verdadero potencial. Esto exige sincronizar y alinear a los equipos de ingeniería y producto para evaluar *roadmap*, tiempos y prioridades. Solo así tiene sentido el esfuerzo y el tiempo invertidos durante esos dos días. Para ello hicimos una plantilla en la que puntuamos cada iniciativa según tres variables: - Nivel de *production ready*. - Innovación. - Impacto en producto. ## Lo que aprendimos - **No todo el mundo es igual de entusiasta con la IA.** Hay gente que la ve como una herramienta más de trabajo, no como algo disruptivo. Y eso está bien: hay que diseñar el evento teniendo esto en cuenta. - **Lo más importante pasó antes del primer día.** Dedicad tiempo de calidad a organizar los equipos, los retos y el entorno. Y, sobre todo, comunicad y documentad todo con claridad. Ante la duda, *over-communicate*. - **La práctica deliberada con un objetivo concreto es la clave.** Es la mejor manera de llegar a ese momento *ajá* que buscáis. - **Hay que dar seguimiento para mantener el impulso.** El hackathon es el empujón inicial, el seguimiento es lo que mantiene la inercia. - **El entorno colaborativo funciona mucho mejor que los talleres y las formaciones.** La gente aprende haciéndolo, no escuchándolo. - **Dad libertad de experimentación y fomentad la creatividad.** Los mejores resultados vinieron de equipos que se arriesgaron. - **Todo funciona mejor en un ambiente distendido, con comida y bebida.** No es un detalle menor. - **Bloquead la agenda de las personas.** Si no lo hacéis, el evento compite con el día a día y pierde. - **Los retos tienen que importar.** Si el problema no es real, el compromiso tampoco lo será. ## Conclusión En nuestro caso, cumplimos el objetivo. Nunca se trató de construir prototipos. > **Se trataba de cambiar la forma en que la gente trabaja cuando el lunes siguiente se sienta delante del ordenador.** Al menos en nuestro caso, eso fue lo que ocurrió. ¿Y vosotros? Si habéis organizado un hackathon, ¿qué hizo que tuviera impacto más allá de esos dos días?