La espiral de mierda
¿Por qué todo parece ir más lento si cada vez somos más? Analizamos las causas que llevan a que muchas startups fracasen durante su proceso de escala y cómo evitarlo.
Una pregunta común que se hacen todos los emprendedores cuando escalan su empresa es por qué todo parece ir más lento pese a que cada vez hay más gente contratada.
Una de las razones nos la da Austen Allred en este hilo de Twitter: la muerte por la espiral de mierda (traducción libre de “death spiral of bullshit”).
A más gente > más equipos > más necesidad de que te “compren” tus iniciativas > mayor recompensa a ser persuasivo en lugar de a construir > los que construyen huyen > se termina no construyendo nada.
Allred pone de ejemplo a Jeff Bezos. Cuenta la historia que cuando Amazon empezó a sufrir sus primeros problemas de escala, uno de sus empleados le sugirió que lo que necesitaban era más comunicación. Bezos respondería diciendo, “No, la comunicación es terrible.”
Bezos llevaría al extremo su postulado enviando al poco tiempo probablemente uno de los emails que más impacto ha tenido en la historia reciente de la tecnología. En él, dictaba las siguientes directrices a los ingenieros de Amazon:
All teams will henceforth expose their data and functionality through service interfaces.
Teams must communicate with each other through these interfaces.
There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
It doesn't matter what technology they use. HTTP, Corba, Pubsub, custom protocols -- doesn't matter. Bezos doesn't care.
All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
Anyone who doesn't do this will be fired.
Thank you; have a nice day!
Bezos terminó con los problemas de comunicación forzando que los equipos se comunicaran a través de APIs. Sin excepción. Aquél correo fue la base del multimillonario negocio que es hoy AWS y dio inicio a lo que hoy conocemos como Cloud Computing.
Cómo escapar de la espiral de mierda
El problema de la comunicación es que escala muy mal. Coordinar a 10 personas en torno a un objetivo es sencillo. Alinear a 200, 500 o 1000, es casi imposible, y si no lo gestionamos bien, puede llevar al traste a cualquier empresa.
Allred da unos consejos para escapar de la muerte por la espiral de mierda:
Vayamos uno a uno.
Equipos tan pequeños como sea posible
No hay duda aquí. Cuánto más pequeño es un equipo, más fácil es la comunicación entre todos los miembros y más sencilla la coordinación.
Esto es contraintuitivo, porque una solución típica en otros ámbitos cuando un proyecto se retrasa es añadir más gente al mismo pero, cómo Frederick Brooks escribió hace ya 40 años en The Mythical Man Month, esto no funciona cuando se trata de software.
“Adding manpower to a late software project, makes it later.” ― Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering
La clave consiste en mantener el equipo pequeño, siempre combinado con el siguiente punto.
Poner el listón muy alto a nivel de talento
Obviamente, cuánto mejor sea el nivel del equipo, más fácil será salir de la espiral. No es cuestión de cantidad, sino de calidad. Si no mantenemos el listón alto, aquellos que no lleguen por capacidades lastrarán al resto del equipo.
Debe haber un decisor último + discrepar y comprometerse
En todo equipo tiene que haber una persona que cargue con la responsabilidad de decidir. Pero no puede imponer su decisión sin escuchar antes a todo el mundo.
Utilizando la técnica de discrepar y comprometerse, cualquier miembro del equipo debe poder argumentar su propia opinión. De esta forma, cuando se tome la decisión, al menos su voz habrá sido escuchada, y aunque no sea de su agrado, deberá comprometerse a implementarla al 100%.
Permiso de facto para cualquier cosa
En un equipo donde el listón de talento es alto, dónde todos se suponen responsables para lograr el objetivo marcado, nadie debería tener que pedir permiso. Si alguien considera que tiene que levantar un servicio nuevo, se hace. Si alguien considera que hay que hacer un cambio en producción, se hace.
Todos somos adultos, todos somos responsables. Levantar barreras y procesos artificiales para mantener una falsa sensación de control es una receta para naufragar en la espiral.
Alta tolerancia a los (buenos) fallos
No se puede salir de la espiral si el equipo tiene miedo a cometer un fallo. Salvo que trabajemos en entornos realmente críticos, el coste de solventar un error suele ser menor que el de establecer un complicado proceso tratando de prevenirlo.
Alta tolerancia a la deuda técnica (buena/no relacionada con infra)
La deuda no siempre es mala. Endeudarte para comprarte un capricho suele ser un mal negocio, pero endeudarte para pagarte una buena formación, no tanto. La deuda técnica debemos mirarla con los mismos ojos.
¿Podemos aceptar algo de deuda técnica para validar si el producto o la funcionalidad antes de seguir invirtiendo más recursos? Podemos y debemos. Retrasar la validación por no querer tener deuda técnica es el camino directo a la espiral de mierda.
Eso no quiere decir que no haya que pagarla nunca. Habrá que hacer hueco para ella. Pero mejor asumirla cuando sea necesario, que retrasarlo todo por no querer contraerla.
Tolerancia cero a no estar en los detalles
El producto es responsabilidad de todos. Si hemos puesto el listón alto y tenemos un equipo comprometido, no hay excusa posible para fracasar.
“Eso no es cosa mía, depende del equipo X.” “No estaba como criterio de aceptación”. “Yo he hecho lo que ponía en la historia de usuario.”
Frases que te llevan directo a la espiral de la mierda.
Hasta aquí las recomendaciones de Allred para evitar caer en la espiral. A continuación añado algunas de mi cosecha, basadas en mi propia experiencia.
Los equipos deben ser autónomos
Tener equipos pequeños no es suficiente. Los equipos tienen que ser autónomos para llevar cualquier funcionalidad a producción. Si para hacer cualquier cambio en su producto, un equipo se tiene que coordinar con otros dos y buscar sitio entre sus otras prioridades y OKRs, es imposible que cojas velocidad.
Tener un buena estrategia
Por mucho que aprobemos en todos los otros puntos, no hay organización que sobreviva a una mala estrategia. Si tenemos equipos independientes, talentosos, y autónomos, pero la estrategia de la empresa hace que cada uno esté remando en una dirección, estamos perdidos.
Justo la semana pasada comentamos cuáles son las bases de una buena estrategia.
Concentrar esfuerzos
Relacionado con el punto anterior, pues es una de las claves de una buena estrategia.
Tendemos a pensar que a más gente tenemos contratada más cosas podemos hacer, más proyectos podemos iniciar, pero la realidad es que el éxito de una empresa consiste en concentrar los recursos allí donde más impacto tienen, que suele ser fortaleciendo su ventaja competitiva.
Muchas veces ocurre que sí, tenemos muchos equipos, y mucha más gente contratada, pero cuando te detienes a mirar resulta que cada uno está abriendo una línea de negocio nueva y a su vez todos están generando dependencias y tensionando el core, a la vez que robándole tiempo de atención.
Crecer es imprescindible. También es difícil, porque consiste básicamente en gestionar dos o tres negocios a la vez, cada uno con distintas necesidades. En el artículo sobre los tres horizontes de McKinsey podréis leer sobre un modelo para afrontarlo.
Conclusiones
La espiral de mierda es un sitio tan agradable como su nombre. Y lamentablemente casi todas las startups que escalan van a pasar por ahí.
Afortunadamente, ya comenzamos a tener cierta experiencia en navegar esas situaciones. Evita caer en la espiral siguiendo estos consejos:
Crea equipos tan pequeños como sea posible
Pon el listón muy alto a nivel de talento
Debe haber un decisor último + discrepar y comprometerse
Da permiso de facto para cualquier cosa
Tolera a los (buenos) fallos
Tolera la deuda técnica cuando esté justificada
Tolerancia cero a no estar en los detalles
Da autonomía a tus equipos evitando interdependencias
Ten una buena estrategia
Concentra tus esfuerzos
Y hasta aquí el artículo de hoy. Me disculpo si ha sido un poco más escatológico que de costumbre. Pero hay cosas que no vale la pena endulzar, y más aún en estos tiempos.
De la espiral se sale. Haz por salir.
