Reestructuración del equipo de productos de Braze

La fuerza impulsora más importante detrás de cualquier producto de software es el grupo de personas que lo crean y sus relaciones entre sí. Por lo tanto, es importante organizar los equipos de manera que les permita tener la mayor influencia e impacto posible.

En Braze, hemos pensado mucho en cómo se diseña nuestra organización de producto e ingeniería, y queremos compartir nuestros aprendizajes de una importante reorganización departamental que nos ayudó a mejorar en gran medida la forma en que priorizamos las funciones, desarrollamos la experiencia del equipo y creamos nuestro producto de manera más eficiente.

Estructura inicial: ajuste de producto/mercado y más allá

Encontrar el ajuste del producto/mercado, y aprovecharlo para hacer crecer un negocio, es un crisol por el que deben pasar todas las empresas emergentes. A lo largo de esta etapa en el desarrollo de una startup, la velocidad de experimentación y la capacidad de capitalizar rápidamente las oportunidades son fundamentales. Con ese fin, nuestra estructura de equipo de producto original se veía así:

Esta estructura, que dividía a nuestro equipo en función de las especialidades funcionales, funcionó bien por varias razones.

En primer lugar, nos permitió abordar de manera eficiente los cambios de transformación del producto en el camino hacia el ajuste del producto/mercado: los expertos podían poseer grandes porciones de nuestra base de código y usar los lenguajes, marcos y decisiones de diseño con los que se sintieran más cómodos. Impulsados ​​por cantidades masivas de cafeína, los "equipos" de proyectos del ejército de uno abordaron regularmente grandes esfuerzos. Estos incluyeron la creación de nuestra API pública orientada al cliente y la revisión de toda nuestra infraestructura de envío de mensajes, a menudo desempeñando el papel de ingeniero único, gerente de producto y diseñador. Este tipo de medidas extremas serían una locura en una gran empresa, pero son necesarias y casi rutinarias durante el crecimiento inicial.

Además, esta estructura nos ayudó a obtener un dominio profundo de ciertas áreas técnicas con solo un equipo de 10 a 15 personas. Muchos elementos de nuestros productos principales, por ejemplo, la capa de controlador de vista de modelo de nuestro front-end, las API y el código de envío de mensajes de alto rendimiento, fueron entendidos completamente por solo unas pocas personas.

En ese momento, era simple y todo lo que necesitábamos. Cuando la velocidad lo es todo, la organización basada en pautas simples ayudó a reducir la sobrecarga cognitiva y nos permitió centrar la atención donde podría ser más beneficioso.

Estructura posterior: crecimiento y escalamiento

Sin embargo, a medida que nuestro equipo creció más allá de los 30 o 40, esta estructura comenzó a desmoronarse. Finalmente identificamos la reorganización de nuestro equipo de productos como una solución a algunos de nuestros mayores desafíos. Estábamos gastando un esfuerzo insostenible haciendo malabarismos con conjuntos de habilidades y plazos para formar equipos para proyectos estratégicos. También dedicamos una cantidad excesiva de tiempo a la priorización y, a menudo, nos encontramos forzando la clasificación de todas las prioridades de productos en toda la empresa, ya que nuestra estructura de equipo basada en tecnología no se asignaba directamente a las necesidades de productos más esenciales. Y finalmente, tuvimos pocas oportunidades para que los miembros del equipo desarrollaran una experiencia profunda con casos de uso de clientes particulares.

Finalmente cambiamos a una organización estructurada en torno a equipos multifuncionales Agile similar al modelo Squad/Tribe popularizado por Spotify. Nuestra nueva estructura organizativa se ve así:

La mayoría de nuestro equipo trabaja dentro de "productos verticales", correspondientes a un área clave de nuestro producto o negocio. Por ejemplo:

• Nuestro equipo de Correo electrónico y empresa maneja el correo electrónico de arriba a abajo, así como ciertas áreas de productos, como la administración de permisos, que son fundamentales para muchos de nuestros clientes más grandes.
• Nuestro equipo de Mensajería y Automatización posee varias áreas de productos relacionadas con la segmentación de usuarios, la mensajería y nuestro producto insignia de orquestación, Canvas.

Dentro de una vertical, esperamos que la priorización sea (relativamente) sencilla, ya que cada vertical corresponde a un conjunto específico de necesidades del cliente. Ciertos equipos, como Diseño Visual, DevOps y nuestros grupos de Ingeniería de Infraestructura abarcan toda la plataforma, creando consistencia en áreas clave.

Impactos

Nuestra reorganización redujo significativamente las dependencias entre equipos. Anteriormente, luchamos con el problema de programación similar a Sudoku de ubicar el equilibrio correcto de conjuntos de habilidades especializadas (ingeniería, diseño, gestión de productos, etc.) en un proyecto determinado en un momento determinado. También alineó los incentivos a corto plazo: antes de la transición, los equipos a menudo dependían de contrapartes que apuntaban a objetivos no relacionados. Con nuestra nueva estructura, los equipos de productos son independientes, tienen mucho más control sobre los plazos y están totalmente alineados con los objetivos, lo que aumenta la productividad y la moral.

El nuevo diseño de la organización también mejoró la priorización. Por ejemplo, es posible que nuestro equipo de correo electrónico y empresa deba decidir entre actualizar nuestra infraestructura de correo electrónico, crear una función de correo electrónico central o solucionar un problema de usabilidad empresarial, una decisión sencilla y fácilmente cuantificable, ya que las tres se relacionan con las necesidades de nuestros clientes de manera similar. .

Un equipo que lucha con demasiadas necesidades de alta prioridad también es un indicador de que su área de productos necesita más recursos. Esto nos permite replantear problemas difíciles de priorización como necesidades de personal, que siguen siendo desafiantes pero conceptualmente sencillos de abordar.

Finalmente, enfocar a la mayoría de los equipos en un área de producto en particular ha permitido a las personas desarrollar una gran experiencia y relaciones de trabajo altamente productivas a lo largo del tiempo. Inicialmente, en los primeros años de construcción, las personas podían tener esencialmente todo el producto y la base de código en sus cabezas, pero a medida que crecimos, esto se volvió imposible. Los problemas del producto son fractales: cada vez que miras más de cerca, encuentras más matices y profundidad. Como resultado, pasar muchas horas en un área particular de un producto o base de código y comprender profundamente sus necesidades comerciales es una de las mejores maneras de lograr avances reales en el producto. Además, la creación de equipos enfocados a largo plazo genera propiedad y relación, y permite que se formen relaciones de trabajo tácitas entre un conjunto constante de colaboradores.

Por supuesto, ningún sistema es perfecto. Con un enfoque en los pilares orientados al producto, aumentamos el potencial de los equipos para optimizar las necesidades localizadas a expensas de las prioridades holísticas. Por ejemplo, uno podría centrarse en la deuda tecnológica localizada ("este controlador es engorroso") en lugar de los problemas globales ("cambiar nuestro marco de front-end aumentaría la velocidad de ingeniería general"). Anticipándonos a esta necesidad, tomamos medidas para establecer los equipos transversales mencionados anteriormente y hemos utilizado comités dedicados para otros proyectos amplios, por ejemplo, un comité para construir un producto/sistema de diseño holístico de componentes frontales y patrones de diseño. .

Nuestra nueva estructura también brinda una mayor energía de activación para cambios de productos holísticos y transformadores. Algunas áreas de nuestro producto, como nuestras API de back-end, son propiedad conjunta de varios equipos. El umbral para realizar cambios radicales en áreas amplias y transversales de nuestra base de código es más alto, por lo que este tipo de estructura funciona mejor una vez que se ha formado en gran medida el esqueleto de su producto.

comida para llevar

En general, estamos satisfechos con nuestra estructura organizativa de productos rediseñada: hemos resuelto o mejorado en gran medida nuestros desafíos en torno a las dependencias del equipo, la priorización y la creación de experiencia en productos a largo plazo, y también tenemos una hoja de ruta útil sobre cómo escalaremos. En particular, hemos aprendido que:

• La eliminación de dependencias y la alineación de incentivos conduce a enormes ganancias de eficiencia.
• La priorización de manzanas con manzanas es más simple y más efectiva.
• La profunda experiencia en un cliente en particular o una necesidad comercial conduce a mejores resultados del producto.
• Trabajar con los mismos miembros del equipo durante un período prolongado es fundamental para construir excelentes relaciones de trabajo.

Recomendaría esta estructura para cualquier equipo que comparta ciertas características clave: una organización multifuncional en la que los expertos funcionales, como gerentes de producto, diseñadores e ingenieros, son partes interesadas iguales; más de aproximadamente 15 a 20 personas en el equipo de desarrollo de productos combinado; y, lo que es más importante, un ajuste firme entre el producto y el mercado. Y si este tipo de estructura de equipo te parece atractiva, ¡estamos contratando!