Tecnología y organizaciones de escalada junto con Randy Shoup

GitPrime eleva el liderazgo de la ingeniería con datos objetivos. En esta serie de entrevistas, los líderes de la ingeniería hablan de cómo construir equipos de alto rendimiento.

Cuando los inicios se ponen en marcha, el equipo inicial es pequeño y suele resolver problemas relativamente discretos (aunque centrales). Pero a escala, la cantidad y el tamaño de los problemas crecen más de lo que un solo equipo manejable puede manejar.

Ahí es cuando se dan los primeros dolores crecientes de la escalada, tanto organizativa como tecnológicamente. Y esa es la etapa en la que muchos de nosotros no sabemos qué hacer para iniciar la siguiente era de nuestra compañía.

«¿Cómo se pasa de un equipo, donde todo el mundo cabe en una mesa de conferencias, a una organización al estilo de Amazon o del tamaño de Google?» pregunta Randy Shoup, el vicepresidente de ingeniería de WeWork.

El mismo Shoup ha trabajado como líder de ingeniería con varias compañías de varios tamaños durante períodos de intensa escalada en las últimas tres décadas. Fue vicepresidente de ingeniería en Stitch Fix, director de ingeniería de Google App Engine, director técnico y cofundador de Shoplilly, e ingeniero jefe de eBay, entre otros cargos de liderazgo.

En esta entrevista exclusiva, Shoup expone varias estrategias que las organizaciones pueden emprender a medida que crecen para escalar de manera eficiente, rentable y lo menos dolorosa posible.

Dividan su organización orgánicamente en equipos más pequeños.

Hay algunas maneras de manejar la circunstancia inevitable de que los equipos superen los problemas en los que están trabajando (así como los problemas que superan a los equipos que trabajan en ellos), pero sólo una manera que tanto Shoup como la industria en general han encontrado para trabajar bien.

«Las Amazonas y los Googles y los Netflixes del mundo han co-evolucionado todos a esencialmente el mismo modelo», dice Shoup, «que es un equipo individual de dos pizzas, cada uno de los cuales es responsable de un servicio o un pequeño elemento de una aplicación. Luego se forma una organización a partir de muchos de ellos».

Shoup llama a esto una organización fractal. En un nivel de granularidad, tienes la característica o servicio de gran imagen. En niveles más altos de aumento, ese producto se subdivide en equipos más pequeños, equipos con un enfoque más específico. Si se hace un zoom desde allí, se tienen individuos con un enfoque aún más preciso.

Los equipos son como los organismos celulares, necesitan dividirse para crecer.

Ya sea que esté pasando de un equipo a dos, o de docenas a cientos, considere su organización como un organismo microscópico. A Shoup le gusta analogizar la escalada de equipos con la mitosis celular.

«La gente tal vez recuerde de la biología de la escuela secundaria que hay una célula y que esa célula se subdivide en dos células, y luego cada una de esas células se subdivide en dos células más, etcétera, etcétera», dice. «Tarde o temprano tienes un humano o un mono o una ballena azul o algo así, pero todos empezamos como una célula. Las organizaciones, las organizaciones sanas, funcionan de la misma manera.»

En los inicios de la etapa inicial, todos trabajan como un solo equipo con un solo conjunto de objetivos. Una vez que el equipo es lo suficientemente grande, digamos diez o doce personas, necesita someterse a la mitosis. Puedes dividirlo en el lado del comprador y el del vendedor, o el lado del conductor y el del piloto.

Esos equipos seguirán creciendo, y en algún momento cada uno deberá dividirse de nuevo, por ejemplo, en el lado de las aplicaciones y el lado administrativo.

Permita que los equipos le muestren sus divisiones orgánicas.

En lugar de insistir en cómo dividir los equipos cuando crecen lo suficiente, puedes confiar en que los equipos te muestren sus puntos naturales para dividirse en dos o tres equipos distintos.

«Cuando se es un equipo un poco grande, no se trabaja en una sola cosa», señala Shoup. «De todas formas, estás trabajando en dos o tres cosas diferentes. Así que típicamente los puntos naturales de la mitosis celular, donde dividimos la célula, son naturales. Nunca he encontrado un problema en el que un equipo fuera demasiado grande para ser un equipo, pero no era obvio cómo subdividirlo».

Cuando un equipo se vuelve demasiado difícil de manejar, eso casi por definición muestra que el equipo necesita ser dividido, y la división se hará tan clara que no hay que preocuparse por dónde dibujar las líneas.

Construir equipos multifuncionales que sean dueños de su trabajo de punta a punta.

El enfoque tradicional de desarrollo de software empresarial distingue a los técnicos de producto de los ingenieros, y a los ingenieros del control de calidad, y a todos ellos del servicio de atención al cliente.

«Lo que hemos aprendido en los últimos treinta años es que eso no funciona muy bien», dice Shoup. «Es mucho mejor tener en un solo equipo, a la gente que tiene la idea, a la gente que escribe, a la gente responsable de la calidad y a la gente que opera el software. En muchos de los lugares en los que he trabajado, Google por ejemplo y Stitch Fix, teníamos equipos completos, equipos multifuncionales que poseían una pieza de software en particular, como una aplicación o un servicio, y la poseían por completo, de principio a fin, desde la idea de la misma hasta su funcionamiento en el mundo real».

No importa quién hace qué, siempre y cuando el equipo tenga las habilidades adecuadas.

Los papeles exactos que pertenecen a cada equipo individual dependen de los objetivos y el propósito de ese equipo. Los papeles pueden estar divididos entre individuos distintos, o cada persona puede tocar varios aspectos de ese proceso. La idea clave, dice Shoup, es que todos los conjuntos de habilidades necesarias existen dentro de los límites de ese equipo.

También hace hincapié en que la idea de un equipo de «pila completa» es un nombre un poco equivocado. «Nadie quiere decir realmente todo el camino hasta el silicio», dice. «No la gente que coloca y apila el hardware en el centro de datos. No la gente que construye chips. Son todas las habilidades que necesitas para hacer el trabajo.»

La propiedad de extremo a extremo reduce el ciclo de retroalimentación.

El objetivo fundamental de crear equipos con una propiedad completa de extremo a extremo es reducir el ciclo de retroalimentación. Cuando no tienes que comunicarte entre los equipos para hacer tu trabajo principal, puedes tener ideas, probarlas, desplegarlas y aprender de ellas en un ciclo mucho más estrecho.

«La forma que tenemos como industria para hacerlo, es ubicando todos esos conjuntos de habilidades en un solo equipo y convirtiendo un proceso de tuberías en cascada en un equipo más interfuncional donde todos trabajan juntos», dice Shoup.

Optimizar para proporcionar el máximo valor al cliente lo más rápido posible.

La meta-razón para reducir el ciclo de retroalimentación con los equipos de propósito único y de pila completa es que usted está optimizando su organización para proporcionar tanto valor al cliente como sea posible, tan rápido como sea posible.

«Cuando tu equipo es demasiado grande, se ralentiza», dice Shoup. «No somos capaces de proporcionar la misma cantidad de valor tan rápidamente siendo un equipo, como siendo dos equipos independientes.»

Aquí es donde la cultura organizativa entra en juego. Si una organización es reacia a dividir equipos poco manejables, lo más probable es que su preocupación de primer orden no sea producir el mayor valor para el cliente en el menor tiempo. Lo mismo ocurre con las organizaciones que pasan un tiempo indebido construyendo cimientos sin liberar e iterar en su trabajo.

Apunta a liberar el producto mínimo viable.

Para escalar sus equipos y tecnología con éxito, se necesita una cultura construida sobre las tres patas de los productos mínimos viables. Necesitas un producto para lanzarlo; el producto necesita ser viable; y debes lanzarlo cuando tenga el mínimo necesario para ser realmente viable.

«Vamos a obtener algunos comentarios de nuestro grupo inicial de clientes», explica Shoup. «Vamos a iterar y continuar refinando ese producto. Con suerte conseguiremos más clientes, con suerte empezaremos a escalar y tendremos más y más clientes.»

Al enfocar su cultura en torno a la obtención de valor para los clientes rápidamente, usted lanza productos que pueden no ser perfectos, pero es la única manera de obtener información valiosa de sus clientes actuales. Shoup ve culturas exitosas construyendo sus equipos alrededor de estos lazos de retroalimentación, para que puedan responder a la retroalimentación de manera eficiente y productiva.

Iterar a la solución.

Shoup explica este predicado cultural de los productos mínimos viables: «Uno de los principales valores culturales es la idea del minimalismo y la idea de iterar a la solución», dice. «La idea de que no vamos a hacerlo bien la primera vez y no debemos intentarlo, pero al mismo tiempo debemos tratar de resolverlo de la manera más mínima y sencilla. Reconocemos, como equipo, en una organización, como negocio, vamos a iterar en ella y hacerla mejor».

Hace referencia a la vieja idea de que si no te avergüenzas un poco de tu liberación, esperaste demasiado tiempo para liberarla. No se puede resolver el problema más que en la seguridad del desarrollo; sin embargo, si se libera el trabajo en la naturaleza, se puede iterar a la solución mucho más rápidamente (y por lo tanto crear más valor) porque se obtienen respuestas valiosas de los usuarios reales.

«Si lo que dicen es: $0027Está bien, pero estas cosas podrían ser mejores$0027, genial. Ese es exactamente el régimen en el que quieres estar», dice Shoup. «Ahora puedes iterar y mejorar aquellas cosas que estaban mal.»

Construye alrededor de los problemas que estás tratando de resolver.

Si de hecho estás construyendo equipos para tener una sola característica de extremo a extremo, y ese equipo está equipado para abordar la entrada del cliente de manera eficiente, entonces lo más probable es que ya estés construyendo tus equipos en torno a los problemas que están tratando de resolver.

Pero aún así vale la pena ahondar en lo que realmente son esos problemas. A veces, dice Shoup, tus problemas de primer orden no son tus verdaderos problemas de raíz. Y muchos problemas profundamente arraigados son producto de tener silos en lugar de equipos verdaderamente interfuncionales.

«El problema más fundamental del silo es que la organización no está alineada con las necesidades del cliente», explica. «Hay una parte de la organización que se preocupa por los clientes, pero tal vez no está involucrada en la ingeniería, y llamamos a esas personas producto o negocio. Luego está esta otra parte de la organización, que son los ingenieros y los operadores del software».

Subdivide según la organización que quieras crear.

En lugar de crear suborganizaciones más grandes para manejar cada faceta creciente de un negocio, Shoup nos recuerda que sigamos subdividiendo los problemas de tal manera que cada problema sea aproximadamente de tamaño de equipo.

Al hacerlo, Shoup reforma la organización invocando la Ley de Conway: que los productos que las organizaciones desarrollan reflejen las estructuras de comunicación de esas organizaciones.

«Si quieres tener una organización construida en pequeños componentes, una de las primeras cosas que puedes hacer es construir tu organización a partir de estos pequeños equipos, porque la estructura organizativa y la arquitectura tienden a ser duales o reflejos de cada uno», dice. «En realidad, estoy haciendo activamente ahora mismo con algunos de mis equipos en WeWork-reformando la organización de manera que refleje más directamente el software que construimos, o el software que queremos construir».

Utiliza a los gerentes para que sus equipos sean lo más productivos posible.

En una organización sana y generativa, el trabajo de un gerente de ingeniería es eliminar los bloqueos de sus ingenieros y miembros del equipo.

Eso es esencialmente todo, dice Shoup.

«El trabajo es ayudar a hacer lo más productivo posible a las personas existentes en el equipo», dice. «Y también, francamente, hacer crecer el equipo. En organizaciones de alto crecimiento, como WeWork por ejemplo, uno de los grandes trabajos de la gerencia es reclutar y contratar y hacer crecer el equipo en general.»

Shoup subraya que los directivos no están ahí para decir a sus equipos lo que tienen que hacer. Están ahí para permitir a los miembros del equipo hacer lo que ya saben hacer.

Incorporar a los gerentes de producto en el equipo.

Además de los gerentes de ingeniería en el modelo de Shoup, los equipos también contienen un papel dedicado a la gestión de productos. Y a diferencia de un gerente de personas, que es casi siempre una sola persona, ha visto un par de maneras diferentes de hacer que la gestión de productos funcione bien.

«Una forma de hacerlo es tener una persona cuyo trabajo a tiempo completo es ser un gerente de producto», explica. «Otra solución totalmente legítima a ese problema es que los miembros del equipo en ese límite compartan esa responsabilidad de alguna manera. Juntos, llegan a la hoja de ruta y a las prioridades, y así sucesivamente».

La forma de trabajar mejor depende de cómo se construye cada equipo u organización en particular. Shoup no pretende que un enfoque sea mejor que el otro.

«Soy agnóstico en cuanto a cómo se asigna esa responsabilidad a la gente», dice. «Lo que creo que es la invariante, es que dentro de los límites del equipo hay una función de gestión de productos.»

Pasa del monolito a los microservicios, pero sólo si es necesario.

A medida que su organización y su tecnología se escalen, comenzarán a sospechar que necesitan pasar de un monolito a los microservicios.

Puede que sí y puede que no. «Mi fuerte creencia y mi experiencia es que las diferentes fases de un producto, y las diferentes fases de una compañía, tienden a ser mejor servidas por diferentes tipos de software», dice Shoup. «Quiero decir que probablemente el noventa por ciento de las aplicaciones del mundo están mejor servidas por una aplicación monolítica. Es la excepción más que la regla cuando se necesita construir un sistema distribuido con lo que llamamos microservicios».

Utiliza un diagrama de curva en S para demostrar estas fases generales de una organización de escalamiento: fase de inicio, fase de escalamiento, fase de optimización.

Cada inicio comienza bastante pequeño, con unos pocos clientes iniciales y un ligero crecimiento. Luego, en algún momento, las compañías exitosas llegan a una fase de escalamiento donde los clientes llegan rápidamente. Después de eso, a menudo verás la fase de optimización, la parte superior de la curva en S, donde se aplana y el crecimiento es más lento.

«En esa fase inicial, realmente sólo estás tratando de satisfacer las necesidades a corto plazo de tu pequeño grupo de clientes», explica Shoup. «Así que quieres iterar muy rápidamente. Estás tratando de optimizar para la productividad del desarrollador rápido y para la iteración. Para lo que no estás tratando de optimizar es para una escala masiva. Y es totalmente legítimo construir un monolito en esa fase.»

Busca señales de advertencia de que tu monolito se está quedando sin gasolina.

En algún momento, un inicio puede escalar lo suficiente como para que supere a su monolito. O bien está experimentando la velocidad de las características y sus equipos son incapaces de avanzar al pisarse unos a otros, o su monolito no escala físicamente desde una perspectiva de carga o latencia. El crecimiento del cliente podría crecer tanto, lo que Shoup llama «escalamiento relacionado con la carga», que el monolito no puede manejarlo. Tal vez necesita ser capaz de cargar diferentes partes del sistema independientemente de otras, o quiere que diferentes partes del sistema evolucionen a ritmos diferentes.

En realidad, sólo una vez que empiezas a experimentar estas necesidades quieres romper el monolito en pedazos más pequeños.

«Los microservicios son una solución a la fase de escalado, no la fase inicial o de estado estacionario», dice Shoup. «Sólo cuando estás haciendo esa escalada rápida es cuando los necesitas».

Tener conversaciones abiertas y maduras sobre todo.

El tema recurrente en nuestra entrevista con Shoup es que tener conversaciones abiertas, directas y abiertas es muy útil para ampliar tanto las organizaciones como la tecnología.

«No podría estar más de acuerdo en que en estas organizaciones sanas y generativas, la capacidad de mantener estas conversaciones de forma transparente y madura es un aspecto clave», dice.

«Si no puedes hablar con tus socios de negocios y explicarles, $0027Aquí está el porqué el sistema no está funcionando bien. Aquí está por qué no es confiable. Esto es lo que yo haría para arreglarlo. Aquí están las inversiones que deberíamos hacer$0027, y si tus socios comerciales no son receptivos a esa conversación, eso es malo. Se ha construido un montón de software terrible en organizaciones que no fueron capaces de tener conversaciones maduras sobre la viabilidad de la ingeniería a largo plazo».

Cada una de las siete estrategias de Shoup para escalar con éxito se beneficia de la comunicación abierta:

• Dividan su organización orgánicamente en equipos más pequeños.
• Construir equipos multifuncionales con propiedad integral.
• Optimizar para proporcionar valor al cliente lo más rápido posible.
• Construye tu arquitectura alrededor del problema que estás tratando de resolver.
• Utiliza a los gerentes para que sus equipos sean lo más productivos posible.
• La transición de un monolito a los microservicios, sólo cuando sea necesario.
• Tener conversaciones honestas y transparentes… incluso sobre tener conversaciones honestas y transparentes.

Al aprender de cada una de estas tácticas, equipará a su organización para que sea más ágil y llegue a más clientes de manera más eficiente. Sus equipos se construirán para aprender a medida que crecen, contribuyendo en última instancia a un proceso de escalamiento productivo e impactante.