Creando una cultura de producto en Ingeniería
Os comparto cinco temas que son claves para conseguir crear esa cultura.
Te animo a echar un vistazo a los cursos que acabo de abrir para Mayo:
Fundamentals of Software Engineering si quieres tener una base técnica para trabajar mejor con ingeniería; puedes hacerlo a tu propio ritmo. Puedes hacerlo a tu ritmo desde ya (self-paced), o a partir del 30 de abril en un grupo con sesiones en vivo (cohort-based).
Fundamentals of Product Analytics si quieres empezar a ser analítico, empezando a analizar datos y definir KPIs y funnels. Puedes hacerlo a tu ritmo desde ya (self-paced), o a partir del 30 de abril en un grupo con sesiones en vivo (cohort-based).
Advanced Course in Product Analytics si quieres aprender a hacer análisis avanzados y conectar métricas de negocio con producto. La octava edición comienza el 30 de abril.
Advanced Course in Product Engineering si desde ingeniería o datos quieres acercarte a negocio y producto. La cuarta edición comienza el 30 de abril.
Los diversos profesionales de Producto deben trabajar como un solo equipo, con una misma cultura. Esto sin embargo no siempre sucede; ya sea porque los líderes de Product Management, Design, Engineering y Data no están alineados en la forma de trabajar, o porque no forman a sus equipos para que tengan esa cultura.
Cuando ayudo a equipos de producto a mejorar, muchas veces me encuentro con que invierten demasiado tiempo en resolver problemas del día a día con el equipo de ingeniería. Hace meses escribí un artículo sobre cómo conseguir que tu equipo entregue con calidad y en tiempo, que os da buenas prácticas para atajar esos problemas.
Los PMs o PDs no pueden trabajar en discovery de problemas y oportunidades, si tienen que estar pendientes de hacer QA. No se puede. Simón Muñoz hizo el otro día esta encuesta en twitter.
No diría que me sorprendiera que el 63% de las personas respondieran que los Product Managers deben hacer QA. Desgraciadamente, la mayoría de Product Managers actúan realmente de Product Owners y la mayoría de desarrolladores no tienen cultura de producto y calidad.
Esta pregunta me hizo recordar mis primeros años en Ontruck. Yo era el líder de producto, y único PM. No todos los ingenieros que teníamos tenían esa cultura de producto y calidad. Por tanto, me veía obligado, como os sucederá a muchos, a hacer QA de gran parte de las funcionalidades. Como además, soy un buen tester ya que piensa en todo el flujo y casos, a algunos ingenieros les solía encontrar fallos casi siempre. Esto creaba frustraciones. A mí porque tenía que estar probando, al diseñador porque no dejaban la UI como estaba diseñada, a los ingenieros porque no les había indicado en la user story absolutamente todos los casos, y a negocio porque no lanzábamos rápido.
Trabajamos en que las User Stories reflejaran todos los casos, en incluir casos de prueba, en tener todos los detalles de los diseños listos antes de empezar a programar, etc. Sin embargo, con ciertos desarrolladores siempre había conflicto.
Tras mucho debatir, concluimos que estábamos metiendo demasiados procesos cuando el problema estaba en la cultura y en la actitud de ciertos perfiles. Por tanto, decidimos crear un Manifiesto con los Valores de un Product Engineer. En este artículo que escribí en #Desdeelbarro expliqué los 5 valores que fijamos.
Durante los siguientes meses, los managers de ingeniería hicieron seguimiento de estos valores con cada ingeniero y conseguimos nuestros objetivos de mejorar cómo trabajábamos y aumentó la calidad de las discusiones, soluciones y output. Parte de los ingenieros, los que más dolores de cabeza nos daban, decidieron irse o les despedimos. Meses después ya no teníamos problemas de calidad y tiempo, porque la inmensa mayoría de ingenieros eran accountable de su trabajo.
Posteriormente trabajamos con los PMs y PDs en que involucraran a los ingenieros desde el problema, y con los ingenieros para que participaran activamente del diseño de las soluciones. Dos años después, los ingenieros más senior ya lideraban incluso OKRs siendo ellos responsables de las métricas (PM es accountable).
La gran ventaja que tuvimos al final es que íbamos muy rápido. Si “todo el mundo hace su parte” no invertimos tiempo en controles ni en procesos que no sean útiles para sacar una feature que resuelva un problema. Los PMs podían dedicar la mayor parte de su tiempo a hablar con usuarios y negocio, no a diseñar la solución (diseño+ingeniería), escribir user stories (ingeniería) ni a hacer QA (ingeniería). Diseño podía invertir más tiempo en testar las soluciones asegurando la calidad y escalabilidad a nivel de producto de lo que íbamos a sacar. E ingeniería proponía mejores soluciones que nos ayudaban a construir lo que necesitábamos para mejorar las métricas de una manera más rápida mientras aseguraban la escalabilidad técnica de la solución a futuro.
Claves para crear una cultura de producto en Ingeniería
Cada empresa y situación es distinta, pero en general, os recomiendo los siguientes pasos si queréis llegar a esa fantástica situación donde todos tenéis la misma cultura de producto.
El liderazgo de la empresa debe estar alineado.
Si sois dos personas las que lideráis producto e ingeniería (e.g. CPO y CTO), debéis ser uña y carne. Debéis tener claro la forma de trabajar que queréis, y que si cualquier persona pregunta o se queja, la respuesta que obtendrá de ambos sea la misma. No debéis ser Producto e Ingeniería. Debéis ser un solo equipo aunque oficialmente haya varios departamentos.
El resto del liderazgo de la empresa también debe estar alineado con este cambio de cultura porque puede que necesitéis hacer movimientos de personas (contratar y depedir) y debéis ganar tiempo mientras se implementa la nueva forma de trabajar. Por ejemplo, puede que queráis retrasar ciertas features a cambio de invertir más tiempo en una feature para entrenar al equipo.
Los managers deben ser buenos managers, y ser ejemplos de la cultura de producto que se espera
Lo mismo que es necesario que suceda en el liderazgo de arriba, debe suceder también en todos los niveles. Un manager intermedio que no crea y que no sea ejemplo de la cultura de producto que queréis implementar, no va a formar correctamente a su equipo.
Cuando hicimos todo este cambio en Ontruck, nuestro VP Engineering entonces, Iván Hernández, hizo un trabajo muy bueno con todo su equipo de Engineering Leads. Tenían dos sesiones cada semana donde ponían en común los problemas y dudas que les surgían en este cambio de cultura, y consiguieron que todos fueran una única voz. Aquellos que no terminaron de encajar con esa cultura, se fueron tras unos meses de intentarlo.
Todos los perfiles deben trabajar como un equipo
Cuando hay conflictos entre roles y las cosas no funcionan, el playbook clásico es delimitar responsabilidades. ¿Qué debe hacer el PM? ¿Qué debe tener la PD para la grooming? ¿Quién hace la user story? Esto puede ayudaros a salir del bache, pero para ser un equipo de producto high performing deberéis ser perfiles multidisciplinares.
Esto implica que los ingenieros se coordinan con la PM o PD para involucrarse desde el principio del problema, o el Engineering Lead hace el discovery, o la PD escribe la user story, o el ingeniero decide la solución, o el PM hace el QA más complejo. Las tareas del equipo se van balanceando según el proyecto, la disponibilidad, las fortalezas o planes de carrera de cada uno.
La clave es que el equipo sea una piña y que sean responsables individualmente y como equipo. Los problemas se deben tratar en las retros de una forma honesta y clara, de cara a mejorar la coordinación y comunicación.
Los ingenieros deben ser accountable
Cuando hablo sobre este tema con managers de otras empresas, desde startups en España a multinacionales como Amazon o Stripe, hay dos atributos que me repiten constantemente.
El primero es que los ingenieros deben ser accountable (responsables de su trabajo). Os voy a ser sincero, me parece triste que tengamos que mencionarlo. Se debería dar por hecho que un profesional es responsable del trabajo que hace. Sin embargo, posiblemente por la mala cultura de trabajo que hay en muchas empresas, es un atributo que hay que validar al contratar y que formar continuamente.
Un aspecto claro es que todos entendamos lo mismo por accountable. Esa conversación es muy importante tenerla en el equipo, para que todos puedan entenderlo bien y que sepan qué se les va a exigir. Se les dará feedback si no lo cumplen, se les ayudará; pero si siguen sin ser accountable, tendrán que irse del equipo.
Para mí ser accountable significa que me responsabilizo de la calidad de lo que genero, que levanto la mano si tengo dudas o no estoy seguro, que intento dar lo máximo y que cumplo razonablemente con los tiempos que me comprometo.
Un ingeniero no es accountable si mueve su ticket a QA o Done y contiene fallos obvios, si tiene dudas sobre todos los edge cases y no levanta la mano pidiendo ayuda, si su parte ya está hecha y no se preocupa de ayudar a su compañero, si tarda un día en hacer una tarea de dos horas o si se le complica una tarea y no lo comunica, ni pide ayuda ni ofrece alternativas.
Es responsabilidad de su manager que entienda qué es ser accountable y después tome acciones para llegar a serlo. Importa más esto que cualquier aprendizaje técnico que pueda tener. Como estas conversaciones no son fáciles, se deben tener managers y líderes que sepan tener estas conversaciones con su equipo.
La proactividad es clave en el equipo
Este es el segundo atributo que muchos líderes de ingeniería me repiten constantemente. Todas las personas del equipo deben ser proactivas. Hay muchos ingenieros que no tienen esta actitud. En algunos casos por personalidad, y en muchos otros porque nunca nadie les ha dado voz o incluso se les ha callado.
Si estás construyendo un producto, los ingenieros son realmente quienes saben cómo están las tripas, y qué es posible a qué coste. Si solo les das user stories a construir, te las harán pero buscarán el reto en cómo hacerlo mejor técnicamente. En cambio, si les das retos de negocio o de producto, te propondrán la mejor manera de hacerlo que respete los principios técnicos acordados.
Esa es la proactividad que se espera. Un ingeniero debe poder proponer quick wins cuando hable con usuarios o gente de negocio, debe proponer alternativas para resolver un problema, debe levantar la mano y sugerir alternativas cuando la estrategia de producto no crea que sea la adecuada, debe saber cuando refactorizar y sólo debe quitar deuda técnica si merece la pena.
Hay muchos otros temas que contribuyen a crear una cultura de producto sólida, pero en general, son temas más tácticos. Los importantes son los cinco de arriba. Si los tenéis bien cubiertos, el resto de temas saldrán fácil.
¿Cuál es vuestra experiencia? Me encantaría escuchar vuestras situaciones y problemas para seguir ayudando a que entre todos construyamos una mejor cultura de producto en las empresas tecnológicas.