Dentro de Ai Parte III: Escuadr贸n de la Compa帽铆a

Alinear nuestra estructura organizativa con el viaje del cliente

Esta es la Parte III de una serie sobre c贸mo Automated Insights renov贸 su estructura organizativa interna. Comience por el principio con Parte I .

En el 煤ltimo art铆culo, describ铆 c贸mo implementamos una versi贸n de Tribus y Escuadrones de Spotify en nuestra organizaci贸n de Ingenier铆a. Como est谩bamos plenamente comprometidos con la transici贸n de una empresa de servicios a una empresa de productos, era hora de replantearnos la estructura organizativa para el resto de la empresa. Anteriormente, est谩bamos alineados funcionalmente (es decir, Ingenier铆a, Ventas, Marketing, etc.) como es com煤n en empresas grandes y peque帽as.

Organigrama Tradicional

Un gran desaf铆o con ese modelo es que se puede perder de vista al cliente. Uno de los valores de nuestra empresa es Think Like a Customer . Los empleados, especialmente los ingenieros que se encuentran en el proceso de crear caracter铆sticas y corregir errores, a veces pueden olvidar la verdadera raz贸n por la que hacemos lo que hacemos. Nuestro valor Think Like a Customer es simplemente un recordatorio de que Automated Insights es capaz de permanecer en el negocio gracias a los clientes. No significa que “el cliente siempre tiene raz贸n” ni nada de eso, pero no podemos simplemente crear caracter铆sticas s贸lo porque nosotros pensemos que es una buena idea o algo divertido de hacer. Tambi茅n debe ser algo que el cliente desea en 煤ltima instancia.

Con ese contexto, el modelo de organizaci贸n funcional no se alinea bien con el viaje del cliente. Si desea mejorar o cambiar alg煤n aspecto de la experiencia del cliente, a menudo es dif铆cil asignar la propiedad de extremo a extremo para ese cambio. Digamos que tenemos el objetivo de hacer que el proceso de prueba gratuita sea m谩s exitoso. 驴Posee la gesti贸n de productos esto, ya que especifican las caracter铆sticas? 驴O a Ingenier铆a porque van a construir las caracter铆sticas? 驴O deber铆an ser las ventas porque tienen la interacci贸n m谩s directa con los clientes que hacen las pruebas?

Fue en una reuni贸n con nuestro Director de Ingresos, Adam Smith, y el Vicepresidente de Gesti贸n de Productos, Adam Long, que discutimos la alineaci贸n de nuestros equipos con el viaje del cliente. De esta manera, la responsabilidad de las caracter铆sticas y procesos clave (desde la perspectiva del cliente) tendr铆a una clara titularidad. Gran parte del resto de este art铆culo provino de sesiones de lluvia de ideas que los tres tuvimos antes de implementar Squads en toda la compa帽铆a.

Alinear los escuadrones con el viaje del cliente

En primer lugar, necesit谩bamos definir el recorrido del cliente para nuestro producto Wordsmith. Este fue un buen ejercicio, ya que nunca hab铆amos pensado en el proceso de extremo a extremo por el que atraviesa un cliente al interactuar con nosotros como empresa. Una versi贸n simplificada de esto es la siguiente:

Primero, usted escucha acerca de Wordsmith, luego aprende acerca de sus capacidades, luego quiere probar , y lo hace escribiendo una plantilla NLG, entonces querr谩 refinar ( editar esa plantilla hasta que est茅 listo para publicar su contenido.

Mapa inicial del viaje del cliente de Wordsmith

Luego, asignamos cada una de esas funciones a un Escuadr贸n y pensamos en lo que quedaba de nuestro organigrama original. El viaje del cliente no se asigna a cada trabajo que necesita hacer dentro de una empresa (por ejemplo, ejecutar la n贸mina o mantener los servidores en funcionamiento). Algunas Escuadras no est谩n alineadas con una interacci贸n definida con el cliente, pero eso est谩 bien. Ven铆amos de un modelo en el que pr谩cticamente no hab铆a alineaci贸n con el viaje del cliente, as铆 que esto fue al menos un paso en la direcci贸n correcta.

驴Qu茅 es un escuadr贸n?

Un escuadr贸n es otro nombre para un equipo. No hay nada revolucionario, pero en el modelo Spotify, los Squads son un tipo particular de equipo. Deben ser peque帽os, altamente alineados y sin apretar. Cada Escuadra debe tener los siguientes atributos:

  • Clear mission : c贸mo ayudar谩n a los clientes en una etapa particular o permitir谩n que otros Escuadrones hagan su trabajo
  • Autonom铆a clara : equipo auto-organizado que puede atacar los problemas de su escenario
  • Clear accountability : optimizar las m茅tricas de 1-3 que miden el desempe帽o de la Brigada en su etapa del viaje del cliente
  • Enfocado: cada persona en la organizaci贸n deber铆a estar en un solo pelot贸n (tuvimos un problema en el que nuestros mejores empleados estaban demasiado delgados)
  • Multifuncional: compuesto por personas de diferentes disciplinas (desarrollo, dise帽o, control de calidad, soporte, etc.)

Idealmente, cada Escuadra es completamente aut贸noma y tiene todos los recursos que necesita para realizar su trabajo, pero en una compa帽铆a de 50 personas eso no es pr谩ctico. Ser铆a dif铆cil implementar este modelo en empresas de menos de 30-40 personas. Simplemente no tiene suficientes empleados para llenar todas las Escuadras que se relacionan con el viaje del cliente. Y una cosa que aprendimos es que los escuadrones de solteros no funcionan bien.

En el modelo Ai, cada Escuadra tiene s贸lo dos roles definidos: L铆der de escuadr贸n y miembro de escuadr贸n. El L铆der del Escuadr贸n es el responsable 煤ltimo del desempe帽o del Escuadr贸n (y por lo tanto de sus miembros). Voy a entrar en muchos m谩s detalles sobre el papel de los l铆deres de escuadr贸n en la Parte V.

Una Tribu es una colecci贸n de Escuadrones alineados de manera similar. Cada Tribu tiene un L铆der de Tribu que trabaja estrechamente con los L铆deres de Escuadr贸n en la Tribu. El L铆der de Tribu ayuda a asegurar que los Escuadrones dentro de la Tribu no entren en conflicto entre s铆. El L铆der de Tribu tambi茅n es responsable de ayudar a definir la misi贸n y las m茅tricas para cada uno de sus Escuadrones en colaboraci贸n con los L铆deres de Escuadr贸n.

Tribus y escuadrones de Ai

Creamos diecis茅is Escuadrones dentro de cinco Tribus que cubr铆an todos los aspectos de nuestro negocio:

La Tribu Atraer consiste en nuestras antiguas funciones de Ventas y Marketing. Insertamos un Buy Squad despu茅s de aprender y antes de intentarlo, aunque los clientes generalmente no compran antes de intentarlo. Este fue el primero de algunos compromisos que tuvimos que hacer para que el modelo funcionara para nosotros. El equipo de compras en este contexto es nuestro antiguo equipo de ventas. Ya que la Tribu Atraida consist铆a en gente de Marketing y la Tribu Construida consist铆a mayormente en gente de Ingenier铆a y Administraci贸n de Productos, ten铆a m谩s sentido tener a Buy como parte de la Tribu Atraida (cuyo L铆der de Tribu era nuestro CRO).

A pesar de no ser totalmente coherentes con el viaje del cliente, decidimos desde el principio que no ser铆amos esclavos de una estructura r铆gida. Utilizamos el viaje del cliente como una gu铆a m谩s que como una regla estricta. Otra caracter铆stica clave de este modelo es que quer铆amos que fuera fluido con el tiempo. Nos dimos cuenta de que est谩bamos probando algo bastante diferente, as铆 que quer铆a que todos se sintieran c贸modos con la iteraci贸n en el modelo regularmente. Uno de los mayores defectos de la organizaci贸n tradicional es su inflexibilidad para el cambio. Quer铆a arreglar eso.

Para los Escuadrones de las tres primeras Tribus (que mapearon con el viaje del cliente), les dimos el nombre de verbos que estaban asociados con la acci贸n que el cliente estaba realizando. Esta fue una manera de tratar de romper con los nombres tradicionales de las organizaciones (Ventas se convierte en Comprar, Marketing en Escuchar y Aprender, etc.).

La Build Tribe estaba formada por ingenieros y gerentes de producto que constru铆an el producto principal de Wordsmith. Scale Tribe estaba formado por nuestro equipo de servicios gestionados, que contaba con una mezcla de cient铆ficos y desarrolladores de datos, as铆 como nuestro equipo de gesti贸n de cuentas.

Eso a煤n dejaba varias funciones que eran importantes pero que no estaban representadas en el viaje del cliente. Creamos una Tribu de Habilitaci贸n cuyo prop贸sito principal era ayudar a los otros Escuadrones a realizar su trabajo. Estaba formado por nuestros equipos de Investigaci贸n (Laboratorios), DevOps, Seguridad y Anal铆tica.

Finalmente, eso dej贸 a Finanzas, RRHH y Asuntos Legales, para lo cual creamos una Tribu de Operaciones. El principal beneficio de incluir las operaciones en nuestro modelo de escuadr贸n tiene m谩s que ver con la forma en que realizamos el trabajo que necesariamente con la alineaci贸n con el viaje del cliente, que describir茅 en el siguiente art铆culo.

Gremios

Aunque nuestros escuadrones cubrieron la mayor铆a de las funciones que se nos ocurrieron, todav铆a hab铆a algunos problemas. Por ejemplo, con los desarrolladores repartidos en al menos nueve de los diecis茅is Escuadrones, 驴c贸mo podr铆amos mantenerlos en la misma p谩gina? Del mismo modo, cuando se trata de dise帽o, 驴c贸mo nos aseguramos de que la gente de marketing de Attract Tribe est茅 usando las mismas pautas de estilo que los dise帽adores de Build Tribe?

La respuesta es Gremios. Un Guild es simplemente un grupo de inter茅s auto-organizado. Fuera de la puerta no especificamos ning煤n gremio. Quer铆amos ver lo que se formar铆a de forma org谩nica y segura, as铆 lo hicieron. Los gremios tienen la caracter铆stica adicional de ofrecer oportunidades de liderazgo a personas que a煤n no son l铆deres de escuadr贸n. Si te sientes listo para mostrar tu potencial de liderazgo, forma un Guild.

Los gremios suelen establecer normas sobre c贸mo desempe帽ar un determinado papel en toda la empresa, as铆 como compartir las lecciones aprendidas.

Spotify tambi茅n describi贸 el concepto de un Cap铆tulo , que es similar a un Guild, pero contenido dentro de una Tribu en particular. Eso puede ser necesario cuando eres de su tama帽o, pero no hemos encontrado la necesidad de tallar funciones dentro de una Tribu que no sean relevantes en todas las Tribus.

Gremio multifuncional

Resumen

En este art铆culo hemos explicado muchas cosas, como por qu茅 adoptamos el modelo de Spotify Tribes and Squads y c贸mo lo relacionamos con el viaje de los clientes de Wordsmith.

Aqu铆 hay algunos puntos clave sobre los escuadrones:

  • Los principales beneficios de este modelo incluyen autonom铆a, agilidad y enfoque.
  • Un Escuadr贸n por persona – m谩s de un Escuadr贸n por persona indica un vac铆o de recursos. Estar en un solo pelot贸n ayuda a impulsar la rendici贸n de cuentas y la concentraci贸n.
  • Cada escuadr贸n tiene de 1 a 3 m茅tricas de las que son responsables.
  • El l铆der del escuadr贸n es responsable de todo el trabajo producido por el escuadr贸n. El L铆der de Tribu es responsable de todo el trabajo producido por sus Escuadrones.
  • La estructura del escuadr贸n ser谩 fluida con el tiempo.

Durante el 煤ltimo a帽o, hemos visto muchos beneficios de este modelo. Aunque ning煤n modelo de organizaci贸n es la panacea que resolver谩 todos sus problemas, nos dimos cuenta de que el enfoque de Squad ofrec铆a:

  • Mayor responsabilidad
  • Mejor ejecuci贸n
  • Limpie las 谩reas de enfoque
  • Alineaci贸n multifuncional

Eso es todo por este art铆culo. A continuaci贸n en la Parte IV, voy a hablar de c贸mo trabajamos con los Escuadrones. Si usted est谩 familiarizado con Agile, no ser谩 nada nuevo – excepto que hacemos que cada Escuadra use Agile incluyendo HR!

Si te gusta este art铆culo, por favor h谩zmelo saber haciendo clic en el bot贸n de abajo 鉂わ笍 .

Gesti贸n de productosIniciosInicioManagementAgileContinuar la discusi贸n