Día de notas: Un vistazo a la cultura de ingeniería de Meraki

Solución de problemas de base inspirada en Pixar.

Escrito por Adam Berman

Hace poco más de dos años, en marzo de 2015, firmé mi carta de oferta para unirme a Meraki. Me alegró unirme a la compañía; me sentí muy bien desde el momento en que puse un pie en la oficina, y estaba masticando un poco para comenzar. Poco sabía, estaba a punto de entrar en un gran experimento que demostraría la confianza de nuestro liderazgo en el equipo.

Meraki estaba pasando por una transición importante. La compañía había sido adquirida recientemente por Cisco y nuestros fundadores se habían mudado, dejándonos preguntándonos: si ya no éramos una startup, ¿qué éramos? ¿Un liderazgo diferente conduciría a valores diferentes? Los nuevos líderes que asumieron el control para los fundadores estaban trabajando arduamente para identificar y resolver los problemas provocados por esta transición.

Alrededor de este tiempo, varios de nuestros nuevos líderes de ingeniería leyeron Creativity Inc: un libro sobre administración de Ed Catmull, el fundador de Pixar. Una sección del libro resonó: el capítulo que describe un evento llamado Día de las Notas. El libro relató que después de algunas películas exitosas, el liderazgo de Pixar se dio cuenta de que había una serie de problemas en la compañía que no sabían cómo resolver. En lugar de que los gerentes desarrollen y anuncien cambios, los líderes de Pixar decidieron abrir la palabra, permitiendo a los más cercanos a los problemas ofrecer soluciones.

Inspirado por el enfoque de Pixar, el liderazgo de Meraki decidió que el equipo de ingeniería en sí estaba mejor posicionado para comprender y resolver muchos de los problemas relacionados con la adquisición y los cambios en la membresía y estructura del equipo. Entonces, al igual que los líderes de Pixar, los líderes de ingeniería de Meraki tomaron la desgarradora decisión de poner su confianza en el equipo, dar un paso atrás y dejarnos correr con eso. Todos en el departamento de ingeniería tenían la tarea de averiguar qué queríamos arreglar y cómo solucionarlo. Las ideas tendrían éxito porque otras personas del equipo de ingeniería compraron, no porque un gerente lo aprobara.

Diseñando el primer día de notas

La decisión de crear un Meraki Notes Day creó un nuevo conjunto de desafíos. ¿Cómo nos aseguraríamos de que Notes Day sería un buen uso del tiempo y el esfuerzo de los ingenieros? Los líderes de Meraki necesitaban descubrir cómo capacitar al equipo para enfrentar desafíos fuera de su descripción de trabajo habitual. El equipo necesitaba sentirse dueño de los problemas que enfrentaba la empresa, y necesitaba sentir que tenía los medios y la autoridad para proponer y ejecutar soluciones.

Con estos objetivos en mente, los líderes de ingeniería diseñaron el primer Día de notas de Meraki. Los líderes dejaron en claro que si bien ayudarían organizando el evento, en realidad no participarían. Cualquier miembro del equipo de ingeniería podría proponer problemas para que el equipo los aborde. Un ingeniero inspirado consolidó la lista de temas y creó un foro interno de estilo Reddit para publicarlos para que las personas pudieran comenzar a profundizar en la causa raíz de cada problema.

Como cualquiera en el equipo podía sugerir un tema, la lista compilada de temas era bastante amplia. Algunos problemas fueron muy técnicos, como los desafíos con nuestro proceso de implementación. Otros abordaron cuestiones culturales generales, como la mejor manera de integrar a los nuevos empleados. Algunos problemas surgieron una y otra vez. Por ejemplo, muchas personas notaron que necesitamos abordar los problemas con nuestro proceso de entrevistas. Muchas personas también mencionaron la importancia de administrar nuestra deuda técnica. El proceso de propuesta de tema de abajo hacia arriba también trajo a la luz algunos problemas que no habían sido evidentes para el liderazgo. Por ejemplo, varias personas señalaron que nuestro trabajo desde la política de la casa no estaba claro, sin embargo, los líderes de Ingeniería no lo sabían hasta el Día de las Notas.

El fuera del sitio

Después de algunas semanas de discusión, llegó el Día de las Notas, y el equipo de ingeniería se dirigió fuera del sitio. Cada ingeniero se inscribió en tres sesiones: mis sesiones fueron Mentoría, Misión y Cultura. En cada sesión, 10-15 personas discutieron un problema específico. Cada grupo analizó el problema, ideó soluciones procesables y luego decidió quién asumiría la responsabilidad de avanzar en las soluciones. Antes de comenzar con nuestras sesiones, uno de los líderes de ingeniería se dirigió al equipo, reiterando la importancia de pensar críticamente y buscar soluciones. Luego nos dio instrucciones de apagar nuestras computadoras portátiles y teléfonos y ponernos a trabajar.

Mientras caminaba hacia mi primera sesión, estaba nerviosa. Solo había estado en Meraki durante aproximadamente seis semanas, por lo que no estaba seguro de mi capacidad para contribuir. Pero cuando nuestro moderador nos pidió que pensáramos en nuestra experiencia con la tutoría, me di cuenta de que no tenía que preocuparme. La sala estaba llena de personas que habían sido mentores exitosos, pero muchos menos habían sido asesorados recientemente. Llevaba apenas unas semanas subiéndome a bordo, así que tuve una visión directa de lo que se siente ser guiado. Nuestra discusión fue más fructífera debido a la diversidad de perspectivas, y terminamos explorando algunas brechas importantes en nuestra historia de mentoría. Por ejemplo, como nuevo empleado, tenía muchas preguntas, pero no quería evitar que mi mentor hiciera su propio trabajo. No tenía idea de que los mentores tenían instrucciones de pasar al menos el 50% de su tiempo temprano para que su aprendiz se sintiera cómodo trabajando solo. Nos dimos cuenta de que los mentores debían comunicar mejor las expectativas a los aprendices para que se sintieran más cómodos pidiendo ayuda.

En unos pocos meses, los planes del Día de las Notas comenzaron a hacerse realidad. De la discusión de mentoría, algunas personas terminaron escribiendo documentación que aclaraba el proceso para que los líderes de equipo ayudaran a capacitar a mentores nuevos. Otros grupos de discusión propusieron cambios más amplios. Por ejemplo, el grupo de discusión sobre la diversidad geográfica resultó en un programa de rotación en el que los ingenieros de la oficina de SF trabajan con el equipo de infraestructura en nuestra oficina de Londres durante períodos de 6-8 semanas.

Iterando el día de las notas

Desde ese primer día de notas, hemos seguido experimentando con la estructura del sitio externo. Este año, nuestro equipo UX ayudó a introducir métodos de pensamiento de diseño en el proceso. El equipo de UX se asoció con el liderazgo de ingeniería para ayudar a reconstruir el proceso en torno a nuestro objetivo declarado de resolver problemas difíciles, no estrictamente de ingeniería. Al examinar los últimos dos días de notas, notaron que mientras algunos grupos redujeron con éxito el tema a un problema específico, muchos grupos se quedaron atrapados discutiendo el problema, o discutiendo la primera idea propuesta, y no pudieron explorar ideas o desarrollar Artículos accionables. El objetivo para este año era utilizar métodos de pensamiento de diseño para ayudar a los grupos a llegar al núcleo de un problema y crear soluciones prototipo.

El primer cambio importante fue que, en lugar de tener una sola discusión sobre cada tema con todos en la sala, cada sesión se dividió en grupos de tres o cuatro. El segundo cambio importante fue que las discusiones se estructuraron en pasos de tiempo. Cada grupo pasó períodos de tiempo predefinidos analizando las causas subyacentes de un problema, eligiendo una causa raíz para abordar, generando ideas de solución, eligiendo una idea y determinando cómo probar esa idea a pequeña escala.

Estas estrategias nos ayudaron a descubrir problemas que no eran visibles a nivel de superficie. Se suponía que mi primera sesión del día abordaría si Meraki necesitaba o no un equipo de pruebas centrado en la web. Después del proceso de diseño, profundizamos en el problema y nos preguntamos por qué podríamos necesitar un equipo de prueba. Pensamos que las personas no tenían mucha confianza en nuestro entorno de prueba actual, por lo que nos centramos en descubrir formas en que podríamos generar confianza en que nuestras pruebas detectan errores y evitan la regresión. Nuestra conclusión principal fue que nos faltaban pruebas de integración, por lo que los desarrolladores tuvieron que probar manualmente si los sistemas funcionaban juntos. Decidimos crear un entorno de pruebas de integración y comenzar a escribir pruebas de integración. En lugar de simplemente responder a la pregunta original que nos plantearon y luego dejar que la gerencia lo descubriera, nuestro grupo salió con un plan procesable que podríamos comenzar a seguir tan pronto como regresáramos del sitio.

Los resultados del nuevo proceso se notaron de inmediato. En grupos más pequeños, las personas que podrían haber dudado en hablar se convirtieron en participantes activos. La estructura agregada evitó que los grupos se atascaran en analizar el problema o en deshacerse de la primera idea que alguien propuso sin considerar a los demás. Además, Notes Day en general produjo muchas más ideas para probar, y mucha más gente entusiasmada por invertir en esas ideas.

Aunque recientemente completamos nuestro último Día de Notas, los organizadores ya están considerando posibles mejoras para el próximo año. ¿Es el intervalo anual adecuado para el Día de las notas? ¿Cómo debemos agrupar a las personas que trabajan juntas en un problema? ¿Deberíamos reevaluar la cantidad de tiempo que dedicamos a cada tema? Estas son preguntas abiertas que intentaremos responder en los próximos meses. Para resolver esto, los organizadores están haciendo un seguimiento individual con las personas que participaron para comprender sus experiencias del Día de las Notas. Queremos construir sobre lo que funcionó bien, resolver áreas de confusión y probar cosas nuevas.

Día de las Notas y cultura Meraki

El Día de las Notas ejemplifica un aspecto clave de la cultura Meraki: la confianza. Nuestro equipo de liderazgo confía en el equipo de ingeniería para encontrar las mejores soluciones a los problemas técnicos y organizativos. Confiamos en nuestros compañeros de trabajo para dejar a un lado el ego, entablar conversaciones difíciles y escuchar cuando decimos que creemos que algo podría ser mejor. La confianza es el núcleo de la cultura Meraki, y cada Día de Notas es un recordatorio de cuán poderosa es esa confianza.

Etiquetas: