El discurso es siempre el mismo: "¡Hagamos un hackathon! Dos días de pura innovación, sin reuniones, sólo construcción". Entonces alguien pregunta sobre las reglas y la sala queda en silencio. Luego alguien pregunta sobre los criterios de evaluación y tres vicepresidentes comienzan a tener una reunión diferente. Entonces alguien pregunta si los empleados remotos pueden participar y todos miran sus portátiles.
Los hackatones internos son uno de los pocos eventos corporativos a los que la gente realmente quiere asistir. Los desarrolladores quieren crear cosas sin tickets de Jira. Los diseñadores quieren explorar ideas sin las revisiones de las partes interesadas. Los gerentes de producto quieren... bueno, los gerentes de producto quieren administrar el hackathon, lo cual, honestamente, probablemente deberías dejarles hacer.
El desafío no es generar entusiasmo. Está canalizando 48 horas de energía creativa en algo que no colapsa bajo su propia ambigüedad.
Reglas del hackathon que la gente realmente sigue
Las reglas del Hackathon existen en un espectro que va desde "literalmente, todo vale" hasta "aquí hay un documento de requisitos de 12 páginas". Ambos extremos producen malos resultados. Libertad total significa que la mitad de los equipos pasan el primer día discutiendo sobre qué construir. La sobreespecificación significa que simplemente estás haciendo un trabajo regular sin el proceso regular, lo cual es peor que trabajar con él.
El punto ideal es el tema más las limitaciones. Un tema da dirección: "Mejorar la experiencia de incorporación" o "Crear algo que resuelva un problema interno". Las restricciones dan estructura: "Debemos usar nuestra tecnología existente", "Debe poder demostrarse en cinco minutos", "Equipos de 3 a 5 personas". El tema sin restricciones es el caos. Las restricciones sin tema son una especificación.
Las reglas por las que la gente realmente pelea son las que no son obvias. ¿Puedes comenzar con el código existente? (Decida esto explícitamente o los equipos lo interpretarán de manera diferente). ¿Pueden los equipos ser multifuncionales? (Sí. Siempre sí. Los equipos formados exclusivamente por ingenieros construyen cosas técnicamente impresionantes que nadie puede explicar en la demostración). ¿Puedes trabajar en algo relacionado con tu proyecto habitual? (Aquí es donde la cosa se vuelve política. La respuesta honesta es "sí, pero el juez debería recompensar la novedad").
Hackathon que juzga que no es un concurso de popularidad
La evaluación del Hackathon es donde los buenos eventos van a morir. El modo de fracaso habitual: tres ejecutivos que no participaron en ningún trabajo pasan 90 segundos viendo cada demostración y luego votan por el equipo que incluye a alguien que conocen. O, peor aún, votan por el proyecto más alineado con la hoja de ruta existente de su equipo, convirtiendo el "día de la innovación" en "mano de obra gratuita para la organización del producto".
Corrija los criterios de evaluación antes de que comience el hackathon. Publicarlos. Hazlos específicos y ponderados. Algo así como: Ambición técnica (25%), Impacto potencial (25%), polaco y presentación (25%), Creatividad (25%). Los jueces califican cada categoría de forma independiente. Los totales determinan el ganador. Esto no es perfecto, pero es mucho mejor que la deliberación basada en las vibraciones.
Mejor aún, utilice varios paneles de jueces. Un panel técnico de ingenieros superiores. Un panel de productos de PM y diseñadores. Una votación de "elección popular" de todos los participantes. Los diferentes paneles a menudo eligen diferentes ganadores, y eso está bien: múltiples premios significan que más equipos se sienten reconocidos y la presión política sobre un solo panel cae dramáticamente.
La logística de alimentar a los desarrolladores durante 48 horas
Nadie habla de logística de alimentos hasta que se lleva a cabo el hackathon y cuarenta desarrolladores tienen hambre. La comida no es un detalle. La comida es infraestructura. La gente hambrienta no innova; se quejan y luego ordenan DoorDash individualmente, lo que anula la energía comunitaria que estás tratando de crear.
El plan de alimentación mínimo viable: buen café disponible continuamente (no la máquina de cápsulas, café de verdad), almuerzo abundante ambos días, cena el primer día, desayuno el segundo día y una mesa de refrigerios continua que incluya cosas con valor nutricional real junto con las patatas fritas y los dulces obligatorios. Presupuesto para esto. Si su presupuesto para el hackathon no incluye comida, su presupuesto para el hackathon es incorrecto.
Lo que no es obvio: las restricciones dietéticas en un grupo de 50 a 300 personas no son casos extremos. Son un porcentaje significativo de sus participantes. Vegetariano, vegano, sin gluten, kosher, halal, alérgicos a las nueces: recopile esta información durante el registro, no cuando llega la comida. (Este es uno de esos Detalles de accesibilidad que separan los eventos reflexivos de los descuidados..) Un desarrollador celíaco que mira fijamente una mesa de pizza y sándwiches no está teniendo una tarde innovadora.
Participación remota sin ciudadanos de segunda clase
La tentación es decir "el hackathon es sólo en persona". Esto es más fácil de organizar y también es una excelente manera de excluir a sus empleados remotos del único evento que realmente disfrutarían. Si su empresa tiene trabajadores remotos, su hackathon debe incluirlos, lo que significa diseñar para una participación híbrida en lugar de incorporar un enlace de Zoom a un evento en persona.
La participación remota en un hackathon funciona cuando los equipos son totalmente remotos o totalmente en persona. Los equipos mixtos en los que tres personas están en una sala y dos en una llamada siempre producen el mismo resultado: las personas remotas se convierten en espectadores. Si permite equipos mixtos, exija que toda la colaboración se realice en espacios digitales compartidos (chat, documentos compartidos, pantalla compartida) para que los participantes remotos no escuchen conversaciones apagadas desde el micrófono de una computadora portátil en la esquina de una sala de conferencias.
El día de demostración es cuando la inclusión remota funciona o falla visiblemente. Ofrezca a los equipos remotos el mismo tiempo de demostración, el mismo acceso a la pantalla y los mismos criterios de evaluación. Prográmelos en el flujo principal, no como una ocurrencia tardía. "Y ahora escuchemos a los equipos remotos" al final de una sesión de demostración de dos horas, cuando todos están cansados y revisando, no es un juicio equitativo. Es un trofeo de participación.
Kagibag maneja limpiamente la logística del hackathon: registro y formación del equipo, perfiles de los participantes (incluidas restricciones dietéticas y tallas de camisetas, porque alguien lo preguntará), gestión de horarios durante el período de 48 horas y registro para el día de la demostración. La recopilación de datos de los asistentes durante el registro significa que tiene información dietética, asignaciones de equipo y contactos de emergencia en un solo lugar.
Después del hackathon, el herramientas de campaña de seguimiento ayudarlo a capturar el impulso: encuestar a los participantes, compartir presentaciones ganadoras e iniciar la conversación sobre qué proyectos merecen una inversión continua.
Día de demostración: cinco minutos de gloria
El día de demostración es el evento dentro del evento y requiere su propia planificación, similar a ejecutar un lanzamiento de producto para una audiencia con opiniones. El error universal es no imponer límites de tiempo. Cada equipo cree que su proyecto necesita 15 minutos para explicarse. Ningún proyecto necesita 15 minutos para explicarse. Cinco minutos por demostración, corte estricto, con dos minutos para preguntas. Designe un cronometrador que no tenga miedo de interrumpir a la gente. Los desarrolladores se lo agradecerán: todo el mundo odia sentarse a ver 20 demostraciones largas, excepto las personas que las realizan.
El orden de la demostración importa más de lo que cree. Primero coloque una demostración sólida para generar energía. Ponga otro fuerte justo después del almuerzo, cuando la atención baje. No pongas todas las demostraciones remotas al final. Alterne entre diferentes tipos de proyectos para que la audiencia no se distraiga viendo cinco mejoras consecutivas en la canalización de datos.
Los premios deben ser significativos, lo que no significa caros. Un día libre. El proyecto ganador suma tiempo de ingeniería a la hoja de ruta. El equipo se presentará en el próximo evento. Presupuesto para enviar realmente el prototipo. Estos premios indican que el hackathon es importante para la organización, no sólo para los participantes. Una tarjeta de regalo de $50 dice "gracias por jugar". El tiempo de ingeniería protegido dice "nos tomamos esto en serio".
¿Qué pasa el lunes por la mañana?
El sucio secreto de los hackathons internos es que el 90% de los proyectos mueren el lunes por la mañana. La gente vuelve a sus sprints, el prototipo se encuentra en un repositorio que nadie visita y, en el siguiente hackathon, todos han olvidado lo que se construyó en el último. Este no es un problema de hackathon, es un problema de seguimiento organizacional.
Si va a realizar un hackathon, comprométase con un proceso posterior al hackathon. En una semana: documente todos los proyectos (incluso los que no ganaron). En dos semanas: el liderazgo revisa los proyectos principales y toma una decisión: enviarlos, archivarlos o programar el trabajo de seguimiento. En un mes: los equipos con proyectos aprobados han asignado tiempo para continuar.
Este seguimiento es lo que convierte a los hackatones de eventos morales en programas de innovación reales. Sin él, estás gastando mucho tiempo y dinero en un ejercicio de formación de equipos de dos días. Lo cual no es inútil, pero tampoco es lo que prometió cuando presentó "48 horas de pura innovación" al liderazgo.