Por qué dejamos de ser ágiles (y cómo arreglarlo)

Uno de los sentimientos que más me acompañan a veces es lo lentos que nos hemos vuelto como empresa al crecer. Nosotros seguimos siendo un equipo pequeño –de solo 15 personas– pero siempre pienso que producíamos mucho más cuando éramos menos. Y, por lo que he hablado con otros fundadores, no es un sentimiento que solo tenga yo: te paras y piensas, ¿cómo es posible que haya tipos en su casa programando en pijama que lancen diez productos al año y nosotros desplegamos tres features al trimestre? Veamos qué está sucediendo y cómo evitarlo.

¿Realmente producimos menos?

En la cabeza de los fundadores, la agilidad se mide por el número de funcionalidades que se despliegan. Pero la realidad es que en una empresa SaaS que despega, la mayor parte del tiempo no se va a dedicar a crear nuevas funcionalidades.

El trabajo de creación es súper importante en la fase inicial pero, una vez tengamos algo de product market fit, el trabajo se va a convertir en una mezcla entre pequeños momentos de creación y muchos momentos de burocracia y gestión. Gestión de muchos tipos: gestión de bugs, gestión de personas, gestión de clientes. Pero todo ello alejado de la creación. Y hay que asumirlo.

Cuando solamente había una cosa que hacer, que era crear producto, la sensación de rapidez siempre era brutal. Pero cuando hay muchas otras cosas que hacer, la sensación de que no se está produciendo está ahí. El fundador suele recordar la primera fase de la empresa y eso provoca que en la comparativa se sienta frustrado con la agilidad actual.

Por qué sucede esto

Según los equipos van creciendo, la gestión aumenta. Las tareas de gestión se comen el tiempo de todos, la coordinación es una capa de trabajo con la que no se cuenta pero existe. Además, la delegación hace que los trabajos sean cada vez más y más largos. Casi nadie acepta una versión de algo que ha delegado sin aportar comentarios que acaban generando una, dos o hasta tres iteraciones innecesarias. Esto alarga procesos que ya podrían estar cerrados.

Cuando vamos creciendo, vamos introduciendo más y más labores de gestión que afectan al tiempo efectivo de creación. Cualquier empleado de una startup mediana pierde tranquilamente el 25% de su tiempo en reuniones. Eso sin tener en cuenta el coste del cambio de contexto que hace que el tiempo efectivo perdido sea mucho más alto.

Hay otro punto importante y es la calidad. Si no tienes clientes ni nadie te está pagando aún, puedes sacar cosas que sean vergonzosas porque nadie va a utilizarlas. Pero cuando ya tienes una base de clientes hay un sentimiento de perfección que quizás nos tendríamos que quitar de encima.

Además, en la fase inicial de una empresa, está clarísimo qué construir. Porque el producto está poco maduro, habrá mil cosas que le falten y cada una de las que añadamos será clave. Pero después saber qué construir es un problema muchísimo más complejo.

¿Tenemos tanto útil que construir?

Una pregunta importante que yo me hago es, ¿después de la primera versión del producto nos quedan cosas útiles que construir? La realidad es que, a lo largo de la vida de una empresa, las cosas que se construyan cada vez van a tener una utilidad percibida decreciente.

Me explico: cuando estás facturando 10.000€ al mes, añadir una funcionalidad que haga crecer tu MRR hasta 13.000€ al mes es una aportación bestial. Pero, a pesar de que la cantidad es la misma, cuando estás en 200.000 de MRR aumentar esos 3.000 mensuales es una aportación que tiene una utilidad percibida mínima.

Hay que ser muy hábil para conseguir añadir funcionalidades que impacten de verdad cuando ya tenemos un producto maduro. La realidad es que pocos acaban dando con nuevas teclas. Pero, si queremos provocar cambios en nuestras empresas, tenemos que hacer cambios en nuestros productos.

No es igual un producto que facture 10.000 al mes que uno que haga 100.000 o que uno que haga 1.000.000. A menos que hayamos dado con una tecla enorme desde el principio, la empresa y el producto van a ser distintos en cada una de las etapas. Y, para intentar abandonar cada una de esas etapas, tendremos que hacer cambios profundos. Aquí un hilo interesante sobre este tema hablando de máximos locales.

¿Quién puede seguir el ritmo inicial?

Otro tema peliagudo es que es difícil –y, probablemente, poco recomendable– mantener el nivel de exigencia de las fases iniciales. Si uno de los principales problemas de las startups es la fuga de talentos, una de las formas de mantener al talento contento es no someterlos a una presión que acabe quemándolos.

Ese ritmo de entrega de la fase inicial en la que se construye sin distracciones y sin restricciones no es asumible cuando la compañía va creciendo. Es algo que tenemos que aceptar porque de lo contrario nos provocará muchas frustraciones.

Como consecuencia de querer evitar que nuestros talentos se vayan, muchas empresas se dedican a reducir la presión –mejores horarios, semanas de cuatro días, reducción de objetivos– lo que por un lado lleva a una productividad mejor pero, a largo plazo, hace que los empleados sean más felices y duren más. Cada fundador tendrá que decidir qué camino prefiere.

¿Hay soluciones?

¿Podemos conseguir recuperar algo del momentum inicial y sentir que estamos sacando funcionalidades como animales? Hay formas de intentarlo:

• El agile a veces es un problema: sé que me voy a meter en un jardín pero en ocasiones siento que las metodologías ágiles llevan a descomponer demasiado las funcionalidades y hacen que la gente no tenga ownership sobre el conjunto. A veces un problema de creación no es un problema de ingeniería si no de creatividad. Y creo que la creatividad necesita coherencia y que el proceso esté en pocas manos en lugar de repartido. Conozco empresas contentas con cosas como Shape Up que promete mayor ownership de cada feature.
• Build weeks: o hackatones de una semana o como queramos llamarlos. Se pueden hacer algunas de vez en cuando durante el año. Forzar al equipo a elegir algunas iniciativas que se puedan hacer durante una sola semana con el único requisito de que debe haber algo sólido al final de la semana. Así lo hacen por ejemplo en Buffer .
• Launch weeks: como las build weeks pueden parecer una quimera casi imposible –todo el mundo tiene mucho trabajo en el día a día– existe una alternativa: anuncia funcionalidades durante cada día durante una semana. Puedes hacerlo una vez al mes o al trimestre si eres lentorro. Pero así al menos vas a producir siete cosas que puedes anunciar sin avergonzarte a ti mismo.
• Reduce las reuniones: se que soy pesadísimo con este tema pero es que a veces me dan ganas hasta de hacer un SaaS para conseguirlo. El problema es que los que me lo tendrían que comprar son los que se pasan la vida reunidos y eso, tal vez, les obligaría a ponerse a trabajar. Muchas reuniones no son trabajo, son burocracia sobre el trabajo. Aquí la gente de Twist da unas recomendaciones para tener menos y mejores reuniones.
• Despliega cosas imperfectas: el coste de crear y desplegar algo guapísimo que no usa nadie es mucho más alto que el de cabrear a unos pocos usuarios porque han usado una funcionalidad que aún no está perfectamente terminada y pulida. Bajar el listón nos hacer producir mucho más. Este artículo tiene quince años pero sigue siendo la hostia.
• Las restricciones son mejores para producir. Si hay libertad y flexibilidad para que cada cosa se saque a producción cuando el que la está haciendo lo considere, todo irá más despacio. Restricciones de tiempo o incluso a nivel de funcionalidad son una de las formas más habituales de que los productos se muevan hacia adelante. Si yo no me obligase a publicar una newsletter cada semana, publicaría la mitad de la mitad de las que publico. Y pensarás que quizás fueran mejores pero te aseguro que cuando le doy a enviar no tengo ni idea de cuáles van a funcionar mejor o peor. Y aún (casi) nadie me ha insultado por mandar una mierda.
• Promociona las nuevas funcionalidades: obliga a los usuarios a que se enteren de las cosas nuevas que has sacado. Esto hará que el equipo se sienta más motivado a lanzar cosas. porque ven que su trabajo sirve para algo. Esto es algo que nosotros hacemos realmente mal. Estoy convencido de que la mitad de nuestros clientes todavía no saben que pueden mandar SMS con Acumba.

En resumen

La agilidad no es cuestión de velocidad, sino de intención. Y aunque el caos inicial no vuelva, siempre podemos diseñar sistemas que nos acerquen un poco más a ese espíritu.