Una de mis tareas como CTO en marketgoo es formar un equipo de desarrollo de alto rendimiento. Para conseguir esto en un entorno de creación de producto necesitamos suprimir de una vez por todas el eterno enfrentamiento entre tecnología y negocio. Pienso que la mejor forma de hacerlo es teniendo una visión de compañía conjunta.
No tener esa visión compartida nos estaba haciendo menos eficientes y para mí ha sido una gran frustración personal. Hablándolo con otros CTOs descubrí que no era el único con estos problemas y que esto es bastante común en empresas de desarrollo de software.
Todo es lo mismo. O sea. Todo es design. Todo es producto. Todo es ingeniería. Todo es negocio. Nos empeñamos en separarlo todo y crear pequeñas cajitas. Pero eso nos limita, nos hace ser muy tontos y, en muchas ocasiones, muy soberbios
— David Stănete 🥑 (@stanete) June 4, 2020
Además, recientemente salió este tema en un Tweet de David Stanete con Félix López y eso ya fue el empujón definitivo para animarme a compartir mi experiencia por si le pudiera servir a alguien más en nuestra situación:
Los equipos de desarrollo se frustran por distintos motivos: sienten que nunca tienen tiempo de hacer mejoras técnicas, siempre van con prisa y no llegan a todo, sienten que son meros proveedores de otros equipos de negocio y que no se confía en su criterio.
Al final el equipo de desarrollo acaba por convertirse en una factoría de tickets sin motivación ni entendimiento del por qué de las cosas que hacen, porque no comprenden el negocio ni el momento por el que pasa la compañía.
Por otro lado, los equipos de producto o negocio también se frustran porque no comprenden porqué los desarrolladores están tan pendientes de detalles técnicos y no aportar valor o no se preocupan de las métricas de negocio.
¿Por qué les parece tan importante mejorar el rendimiento del cache en lugar de ver cómo aportar más valor al producto? Evidentemente hay una razón. Los desarrolladores siempre vamos a apostar por la tecnología porque es nuestro ámbito de conocimiento, y a falta de mayor contexto del negocio, nos lanzamos a hacer lo que sabemos hacer.
Esto es lo que yo llamo el “antipatrón de desalineación” y ocurre cuando los equipos trabajan en silos sin un entendimiento común del momento por el que pasa la compañía.
A veces ocurre que negocio tiene un plan, producto tiene un plan, tecnología tiene un plan, pero no hay un plan global común. O quizás sí lo hay pero nadie lo ha comunicado adecuadamente, así que tampoco sirve de mucho, pero eso es otra historia.
En mi experiencia, tener un plan común que alinee los planes de todos los equipos a un objetivo común hace una diferencia enorme y ayuda a que todos estemos más comprometidos y encontremos un propósito en lo que hacemos.
¿Crees que a los desarrolladores les apasiona cambiar un texto o el color de un botón? Obviamente no, y es exactamente lo que creen que hacen cuando se limitan a sacar adelante tareas de una lista sin mayor contexto ni explicación de los motivos.
¿Pero qué pasaría si entendieran que ese pequeño cambio va a mejorar el ratio de conversión de su producto, a hacer que la empresa gane más dinero, y por ende a mejorar su propia situación personal? Ahí es cuando se produce la magia y la gente visualiza un propósito. Ya no están cambiando un detalle técnico sino mejorando la situación de la compañía y la suya propia.
La alineación entre el interés propio y el de la compañía también es un potente motor de cambio. Esto convierte a la empresa en un vehículo para que cada uno alcance el estilo de vida que quiere tener.
Nosotros hemos experimentado este cambio en marketgoo. Estamos obsesionados con la organización, los procesos y las metodologías. Nada de lo que hacemos es casual.
El problema estaba en que cada equipo tenía su propio plan, pero desde que hemos hecho el ejercicio de trabajar en una visión conjunta y global para la compañía, detectamos inmediatamente que esto era un problema. Empezamos a preguntarnos a nosotros mismos el “por qué” de todo, y muchas veces la respuesta era “no lo sé” o “creo que esto es lo adecuado” en lugar de “esto nos acerca a nuestra visión de compañía” o “esto mejorar esta métrica de nuestro plan”.
Imagina el impacto que esto puede tener en un equipo de desarrollo que se estaba sintiendo como una factoría de tickets sin propósito concreto.
Ahora todos entienden el objetivo común, están más comprometidos y están creciendo como nunca antes en responsabilidad y propiedad. Hasta están cuestionando decisiones de producto y negocio con preguntas como “¿porqué debería hacer esto, en qué nos ayuda?” o “¿y si en vez de eso hacemos esto otro que impacta más en esa métrica?”.
Al final hemos acabado fusionando los equipos de producto y desarrollo en un solo equipo conjunto. Esto junto a la metodología “Shape Up” y la visión bien definida han hecho que el equipo evolucione de factoría proveedora a equipo de alto rendimiento que aporta valor constantemente.
No creas que esto significa que ya no hacemos proyectos técnicos. Hacemos incluso más que antes porque ahora esos proyectos están alineados con los objetivos de la compañía y tienen sentido en el plan global.
Un buen ejemplo es esa mejora de cache de la que hablaba antes. Es algo muy técnico pero creemos que si pensamos añadir más KPIs al producto (en el contexto de nuestro producto los KPIs son los indicadores SEO más relevante que el usuario debe monitorizar), la cantidad de datos que manejamos se incrementará mucho y empeorará el rendimiento de la aplicación, así que al final, esta mejora está ayudando a la compañía a cumplir con su visión de producto en vez de ser una ocurrencia técnica porque nos apetezca trastear con determinadas tecnologías. Esto también funciona en sentido inverso.
El equipo de desarrollo ha dejado de plantear proyectos técnicos porque sí y ha empezado a priorizar el impacto que tendrán en el negocio, y a nadie le supone un problema. Mientras el equipo entienda porqué hace o deja de hacer las cosas, la frustración desaparece en gran medida.
Para llegar hasta aquí hemos analizado en qué punto se encuentra la compañía y en qué punto se encuentra el equipo de desarrollo y los hemos alineado.
Situación de la compañía
¿Cómo entender la situación de la compañía de forma sencilla para que todo el mundo en la compañía pueda entenderlo y adaptarse?
Como explica Kent Beck en su “Modelo 3X”, generalmente las empresas suelen pasar por 3 etapas y dependiendo de la etapa en la que están, el comportamiento del equipo de desarrollo debe adaptarse en consecuencia. Estas fases son las siguientes:
- Exploración: Esta es una fase experimental en la que intentamos construir un negocio viable.
- Expansión: Ya tenemos un negocio en marcha y necesitamos consolidarlo para hacerlo rentable.
- Extracción: Cuando el negocio es estable y lo único que queda por hacer es optimizar detalles.
Generalmente cuando estás en fase de Expansión la empresa ha alcanzado el llamado “product-market fit”, es decir, ha encontrado un nicho de mercado y se ha asentado. En marketgoo consideramos que estamos en fase de Expansión y estamos trabajando en la visión de producto para consolidarnos y llegar a la fase de Extracción. Tenemos un crecimiento sólido pero aún no hemos llegado a ese punto de Extracción.
Esto tan solo es una visión de trazo grueso de la situación de la compañía, pero como CTO y con ayuda de tus compañeros del equipo directivo, debes entender con claridad en que fase está la compañía. A partir de ahí ya puedes centrarte en entender la situación del equipo técnico.
Situación del equipo de desarrollo
Roy Osherove explica muy bien en su libro “Elastic Leadership”, que los equipos de desarrollo de software suelen adoptar distintos modos de trabajo, y estos modos encajan como un guante con el modelo de fases de compañía de Kent Beck que acabamos de revisar.
Durante la fase de Exploración necesitamos entender que no es momento de preciosismos y de excelencia técnica per sè. Cuando exploras toca sobrevivir y ahorrar recursos para experimentar. En esta fase no tienes un gran equipo que pueda hacer muchas cosas a la vez, y los exploradores del equipo están en “Modo Supervivencia”. Los supervivientes no tienen demasiado tiempo para darle vueltas a las cosas o aprender nuevas técnicas. Se pasan el rato de fuego en fuego y generalmente tarde y con demasiado que hacer. En este caso se podría decir que no pasa nada por ser un poco “cutre”.
Si todo va bien y el negocio se consolida y entra en la fase de Expansión, pero el equipo de desarrollo sigue estancado en “Modo Supervivencia” debido a toda la deuda acumulada y a la tendencia anterior.
Si la empresa entra en fase de Expansión, el equipo técnico tiene que adaptarse y empezar a hacer las cosas de otra manera porque las necesidades de la compañía cambiarán. Deberán ponerse en “Modo Aprendizaje” y ya no podrán seguir improvisando. Se acabó hacer chapuzas porque ya no son exploradores supervivientes.
Ahora deberían centrarse en productivizar (si es que ese término existe) eficientemente la tecnología para que el negocio pueda crecer. A partir de ahora las decisiones deben tomarse con un objetivo específico: aportar valor al producto para que pueda hacerse un hueco en el mercado (alcanzar el “product market fit”). Esto es lo que Roy Osherove llama el “Modo Aprendizaje” para equipos de desarrollo.
El “Modo Aprendizaje” es un modo de transición para alcanzar el “Modo auto-organizado” durante la fase de Extracción.
Me voy a centrar en esta fase y modo porque según mi experiencia es cuando se produce este antipatrón de desalineación. Si un equipo está auto-organizado y en fase de extracción, probablemente ya habrá pasado por estas etapas previas.
En “Modo Aprendizaje”, los desarrolladores necesitan tiempo para hacer las cosas bien, crecer como profesionales e innovar aunque cometan errores. ¿Cómo pasar de Aprendizaje a Auto-organización? La respuesta de Roy es reducir la cantidad de cosas que tiene que hacer el equipo para que tengan más tiempo. Esto puede parece un poco vago. ¿Para que tengan tiempo de qué?
Desde el punto de vista de la compañía puedes definir una visión clara para mejorar el foco de todos los equipos. Nosotros lo hemos hecho en marketgoo inspirándonos en la metodología EOS y el ejercicio V/TO nos ha cambiado totalmente las reglas del juego.
Desde la perspectiva organizativa, cambiar la metodología de trabajo (Scrum) por “Shape Up” nos ha ayudado muchísimo a mejorar el foco y a centrarnos en todo aquello relacionado con la visión.
Desde una perspectiva técnica, incluso si nos centramos en lo importante, sigue habiendo una necesidad constante de adaptar la tecnología a las necesidades cambiantes del negocio, y hay que seguir lidiando con la deuda técnica heredada del modo de supervivencia. Sin embargo aún ajustando el foco con la visión y la metodología, hay un límite en lo que un grupo de personas puede hacer.
Llegados a este punto debemos plantearnos ¿Cuál es el coste de oportunidad por no producir el valor que el mercado demanda? En otras palabras: ¿Cómo de grande es el coste de oportunidad de no tener productos o funcionalidades críticas en producción y listas para vender?
Si la oportunidad es pequeña o no se alinea con la visión no importa, pero si es al contrario, quizás haya llegado el momento de escalar el equipo de desarrollo para abarcar más y generar más valor. Como bien dice Fernando Díaz, llega un momento en el que los proyectos no pueden ir más rápido, pero añadiendo personas puedes hacer más cosas a la vez, que es otra forma de incrementar el ritmo de aporte de valor.
Hora de escalar el equipo técnico
Si estás en esta situación probablemente tengas la necesidad de sacar adelante nuevos proyectos o mejorar y mantener los que ya tienes. Todo eso mientras pagas la deuda técnica.
Esta es la estrategia en que estamos siguiendo en marketgoo para que el equipo técnico pueda cambiar de modo.
- Ralentización. Al principio el equipo hace el mismo trabajo que antes y gestiona la entrada de nuevos miembros del equipo.
- Estabilización. Cuando los nuevos miembros están listos para ser productivos el equipo puede empezar a eliminar deuda técnica al mismo tiempo que evoluciona el producto. El equipo acomete su labor sin añadir nueva deuda porque ahora hay más personas haciendo la misma cantidad de trabajo, y eso les permite hacer las cosas bien. Toda la deuda en la que se trabaja debería estar relacionada con el roadmap de producto.
- Aceleración. Cuando se han eliminado los mayores problemas heredados del modo de supervivencia y la tecnología está preparada para satisfacer las necesidades del producto, los nuevos miembros puedes empezar a trabajar en la evolución de producto incrementando así el ancho de banda del equipo para nuevos proyectos.
Más gente haciendo el mismo trabajo supone que cada uno tiene más tiempo para hacerlo. Este tiempo extra se emplea en pensar la mejor solución posible sin tomar peligrosos atajos técnicos y en medir y planificar el trabajo con sentido y acorde al plan y la visión general.
Recuerda, ya no vale hacer chapuzas. Necesitamos consolidar la tecnología porque estamos en fase de expansión. Esta consolidación serán nuestros cimientos para algún día pasar a fase de Extracción.
¿Cómo optimizar el rendimiento del equipo? Equilibrando el coste del equipo con el valor que el equipo es capaz de generar. La mejor manera de optimizar el coste es tener a las personas adecuadas en los puestos adecuados.
No tiene mucho sentido contratar a un desarrollador con 25 años de experiencia y un salario de 70k/año para hacer pequeñas correcciones en textos o colores. Una buena combinación de juniors y seniors reparte mejor los costes. Los juniors pueden hacer tareas más sencillas y aún así aprender y crecer haciéndolo mientras los más seniors pueden centrarse en resolver problemas complejos que requieran de su experiencia.
Modo Aprendizaje
Una vez el equipo ha escalado y tiene más tiempo para aprender y planificar, necesitamos proveerles de las herramientas necesarias para su trabajo y así ayudar a la compañía a conseguir sus objetivos.
Si el plan de la compañía implica desarrollar una SPA (Single Page Application), el equipo necesitará aprender sobre GraphQL o React por ejemplo. Si el equipo necesita mejorar el sistema de cache, quizás necesiten una formación en Redis.
Lo que hemos hecho en marketgoo es poner este conocimiento a disposición del equipo. Los viernes por la tarde hacen una formación interna. Cada semana un miembro del equipo prepara un tema que esté alineado con nuestros objetivos y durante una o dos horas lo expone.
Esto requiere que los miembros tengan tiempo tanto de preparar el tema de la formación como para asistir a estas formaciones. Nos parece que este es un buen uso para el tiempo extra que hemos generado.
Nos han inspirado mucho otros equipos que ya hacen este tipo de formaciones como por ejemplo el equipo de Triporate (gracias a Ernesto por la idea).
Planificación de tecnología
Incluso si el equipo técnico escala y reduce la deuda técnica, es necesario planificar el futuro de manera que la tecnología esté alineada con las necesidades de producto.
He visto muchos planes de tecnología enfocados en la tecnología por la tecnología, sin relación alguna con la visión de producto.
Un buen plan de tecnología siempre debería estar alineado con el plan de producto y anticipar las necesidades que ese plan generará en nuestros sistemas. No tiene sentido planificar mejoras técnicas alucinantes que nadie va a notar o a usar.
Si tu compañía planea expandirse a otros mercados, quizás sería buena idea planificar temas relacionados con el escalado de la plataforma para soportar a un mayor número de usuarios, pero si cada vez hay menos usuarios, esto no tiene ningún sentido por mucho que técnicamente sea un reto precioso.
En resumen
Una vez tengas clara la visión de la compañía, la fase en la que está, y el modo en el que está el equipo de desarrollo, únelo todo como una cremallera. Esta es nuestra receta para combatir el “antipatrón de desalineación”.
- Alinea las expectativas de toda la compañía
- Céntrate en lo que es importante para la compañía y no solo para tecnología.
- Si no llegas a todo y tienes recursos escala el equipo lo que necesites y optimizar el rendimiento.
- Dale al equipo las herramientas necesarias para crecer (menos prisas, formación, iteración de metodologías, etc).
- Define un plan de tecnología acorde al plan de producto y de compañía.
Actualización 2022
Todo lo que hemos plasmado en este post lo hemos puesto en práctica durante al menos 2 años y nos ha ido de maravilla, pero la flexibilidad y capacidad para cambiar nuestra forma de trabajar según las necesidades del momento siempre ha sido uno de nuestros mejores recursos para mejorar como equipo. Hemos seguido iterando y mejorando nuestros procesos, siempre en la misma línea de tener un propósito conjunto y una visión clara para todos.
Para acercarnos lo más que podamos a esa visión conjunta tenemos que lograr ciertos objetivos como asegurar un servicio de altísima calidad a nuestros partners, expandir nuestro volumen de negocio actual o abrir nuevas vías de negocio diversificando la inversión de nuestros recursos.
Una de las cosas que hemos hecho para logarlo es reestructurar el equipo de desarrollo de producto. Hemos doblado el tamaño del equipo en los últimos años y lo hemos reestructurado de tal manera que ahora nos organizamos en equipos multidisciplinares por líneas de negocio. Lo que se suele conocer en el sector como “squads“. Lo relevante de estas squads o equipos no es el nombre fancy sino que nos permite centrar el tiro en nuestros objetivos, y permite que los integrantes de cada equipo tengan foco en su misión:
- El equipo de “Negocio existente” tiene la misión de incrementar el volumen de negocio existente mejorando nuestros productos, cuidando a nuestros partners y probando nuevas estrategias de expansión sobre nuestra base de clientes.
- El equipo de “Nuevo negocio” tiene como misión investigar, probar y validar nuevas vías de negocio. Esto significa formular hipótesis, probarlas, validarlas y explotarlas si hay una respuesta positiva del mercado.
- El equipo de “Plataforma” tiene como objetivo mantener la calidad del servicio que da nuestra tecnología y proveer de herramientas y recursos a los otros equipos. Todos nuestros productos se apalancan sobre nuestra plataforma y tiene que ir siempre como un reloj.
Con el fin de no generar silos de conocimiento, los miembros de los equipos puede cambiar de equipo cada trimestre y organizamos reuniones mensuales en las que los equipos enseñan lo que están haciendo, y los resultados que están obteniendo a los demás equipos (a.k.a. Townhall meetings).
Otro cambio interesante que hemos implementado es un cambio metodológico. Somos muy fans de Shape-Up y es la metodología ideal para un desarrollo de producto sostenible a largo plazo, pero no es la mejor opción para experimentar e iterar de manera rápida. En este momento hemos apostado por experimentar más, así que una metodología más ágil nos encaja más, por lo que hemos adoptado los principios de Extreme Programming para tener “feedback loops” más cortos.
Hasta ahora el resultado está siendo espectacular y los miembros del equipo sienten que tienen mayor impacto. Han pasado de pasajeros a conductores.
Leído en el Slack de la compañía: “La organización por squads es lo mejor que hemos hecho en años”
¿Quieres saber más?
He escrito esto basándome en mis experiencias, describiendo lo que nos funciona a nosotros en el contexto de una pequeña compañía de producto. Si estás en una gran empresa de servicios o consultoría puede que no sea lo más adecuado para tu caso.
Si quieres saber más sobre marketgoo y nuestra cultura, siempre estamos dispuestos a charlar. Nos encantaría conocer tus experiencias construyendo equipos.
Comments are closed.